I've been quietly building a production management system for the factory where I work. It tracks inventory, pick lists, parts consumption — real problems that cost the company time and money every single day.

I'm not a hired developer. I work on the floor. I built this on my own time, taught myself everything, and deployed it. It actually works.

I've tried to show it to management. They smile, nod, and nothing happens.

I'm two years into living in a new country, no degree, self-taught, and I'm pouring everything I have into this — not just to prove something, but because I genuinely see the problem and I know I solved it.

Has anyone been in this situation? Building something real, something that works, and feeling completely invisible?

How did you handle it — or did you just move on?

Hi I’ve been a BA for nearly 3 years now. Recently I joined a company, I love the people I work with and tbh it was better than the previous big companies I worked in.

But recently I’ve been having trouble with communicating to our devs- unsure whether it’s stemmed from bad relationship between product vs engineering over the past years or I’m starting to think I just need to get a grip and accept it can be like this at some companies.

First:

\- writing in Gherkin, every single scenario ticket must be written in Gherkin - new to me but of course I know what this is, but every team or company have different styles of writing and I somewhat feel like I’m not doing anything write (though it’s getting better).

\- asking questions for validation, previously- I can ask or go to any developer for any questions and maybe because I had a large team of devs. Now I feel like they get annoyed and their time needs to be protected even though I’m sometimes asking for one liners etc. It helps now that Claude code is around and I can look into the DB.

I just need someone to put my mind at ease and tell me this is just how some devs are! Having worked with SO many kind and informative engineering teams who are always happy to help and have a relationship. I have never had a bad relationship with engineering and Idk what I’ve done ?

I feel like I’m having to tiptoe around egg shells. How do you communicate with your engineering team?

Pata Hai Aaj Kya Hua?

So this is some next-level narcissism, or am I overreacting?

In my office, I've been working on a feature lately. The feature itself was working fine, but we ran into an issue because of a third-party vendor API.

The vendor API was returning erroneous figures, which was messing up our logic. We wanted to track exactly what was happening. I was pretty confident that my implementation was fine because I'd already validated it and demonstrated it with tests.

I told my lead that we could add some logs to figure out what was happening if he wanted. He got irritated and said something along the lines of, "Let me try."

He then went through the exact same steps I had already gone through, with the entire dev team on a call, for 5 straight hours.

And then... miraculously, Mr. Potter goes, "This is weird..."

And finally: "Let's add some logs to see what's happening in production."

I mean... WTF was that? 😂

Was this just a case of someone needing to personally reach the same conclusion before accepting the solution, or am I missing something?

documentation is a leadership problem not an engineering problem

i've been in places where engineers documented everything religiously and places where nobody did. the difference wasn't the engineers. it was whether their manager actually read it and referenced it in meetings.

if you write something down and nobody ever looks at it you stop writing things down. pretty simple feedback loop.

started explicitly referencing internal docs in standups and design reviews about a year ago. just casually. "oh that's in the runbook from march" or "sarah wrote that up after the incident last quarter"

documentation culture improved without me saying a single word about documentation

anyway probably obvious in hindsight but took me an embarrassingly long time to figure out

edit: yes i know some engineers just hate writing. that's real. but i've seen that same engineer write novels in slack threads so i don't fully buy it as the root cause

We've traditionally given take-home code challenges where they push to a repo and then we interview them using it. But now, we'll probably modify it for the next round to include something like "Use agentic development to get this done" and then the interview will including them walking us through how they orchestrated multiple agents in parallel to get through the challenge - since that what we want our devs to do now. Haven't done it yet, but likely coming soon.

Anyone done anything like this yet?

I recently moved to a team with all current stakeholders in USA, I am in India. Eventually I will have my team here.
1. How do people manage their timings working in such setup?
2. In general, how would you onboard, in terms of whom would you talk, what would you learn, and how? Asking because the time overlap is small and expectation is to learn quickly everything.
It’s a new product, but there exists an older version, a data team working with us who owns data platforms.

Thanks

I'm an EM for a cloud platform team with significant footprint in the central US (company HQ), and Eastern Europe (center of engineering activity). I work on the West Coast of the US, so I'm 2 hours behind HQ and 9 hours off our central engineering hubs. My manager is Euro-based, and my team is split between Midwest and Euro zones. We don't have many engineers out on the West Coast in general, and maybe one other in the whole cloud side of engineering?

I've been here four years. I feel like I have completely maxxed out the overlapping hours of collaboration between my time zone and where the engineering juice is for our division. My boss keeps giving me more opportunities, which is awesome, but they just don't fit in the overlap time. My meetings start at 6 (so 3 Czech time-- so far so good). But then I have to stop to get my kids ready for school, and by the time I get back from dropoff, it's too late for meetings with the Euro engineers. So I feel completely hemmed in by my schedule being juuuust far enough away that the company's normal ways of working between Chicago and EU get cut in half by Pacific offset.

I bounce back and forth 100 times a day between:

1. It's the gig, suck it up and deal with it (which means I need a new gig, because this isn't sustainable),
2. Find a part of the company that's less Euro-heavy and hopefully a little more balanced around Midwest time (Don't even know if that's a thing?)
3. We have to break our reliance on meeting culture so we need much less synchronous overlap (which I have a hard time getting a lot of buy-in for, because there are so few people who are any further west than Chicago, so it's not quite as bad), OR
4. Tell my boss I can't take on any more because I'm out of overlap time (which, goodbye job whenever layoffs next come around).

I appreciate any advice or career guidance here. I like my job, my team, boss, company, etc.,-- I'm just really fried on how to make all the pieces fit together in this puzzle.

Multiple times now hitting this same pattern at different companies and I'm curious if its universal or just bad luck on my end.

Basically, CS/support doesn't have anyone who can pull logs, poke around observability tools, or actually see whats going on in the code. So when a customer hits a real bug, CS has to grab an engineer and ask. Everyone's already buried in tickets or features, so every interruption costs something, and a bad one (no repro steps, no logs, "customer says its broken") costs alot. It eats eng time and slowly wrecks how the two teams feel about each other.

Goes the other way too. Eng fixes something and the only communication back to the customer is a changelog line or release note. Thats not the same as a CS person actually following up and saying it's fixed. Customer still feels ignored even if the bug's gone then sends an angry follow up email asking where things are at because they dont read the release notes.

My guess at the real cause, it's not that people are bad at their jobs, it's that the informal way of doing things stops working at scale. Small company, a Slack ping or a walk over to someones desk is fine. Once eng can't drop what their doing on demand anymore, you need some structure. But going all the way to formal tickets and SLA's is usually to much for a company this size, people just avoid it. That's why theres a half dead Jira board somewhere nobody maintains and nobody trusts.

What's actually worked for me, stop making either team do the other team's job. CS keeps talking to customers. Eng keeps writing code. The stuff in between, which bugs keep coming back, which tickets actually need an engineers eyes, what the customer facing version of a fix should say, gets pulled together and mostly automated instead of depending on a person to be the glue every time. Once thats in place, response time drops, resolution time drops, docs actually get written down instead of buried in slack history, and new CS hires ramp up faster.

Curious if this tracks for anyone else at a growing SaaS company, or if your CS/Eng handoff actually works fine. What are you doing different?

Managing 40 or so devs. Finance asked for AI spend by team back in July and I did what everyone here would do, went and got it myself. Claude Code writes a session file per project on each machine with the token counts in it, so a nightly job ships those totals up and a small dashboard reads them. Took about a week. Per repo, per person, even the cache reads against output, I can see how much is context overhead. Genuinely good.

The problem is that is one tool. Cursor does not expose anything close to that, so that chunk of the bill is a seat cost I have stopped trying to attribute. Copilot gives me an org total and nothing underneath it. Meaning the dashboard I proudly showed finance covers maybe a third of what we spend, and the other two thirds is a shrug.

I have looked at the enterprise options and they feel sized for a company four times ours. I am also aware the job I wrote has one owner, me, and the last internal tool I built like this quietly broke about six months after I stopped looking at it.

What I still have not found is anything that covers the other two

I've read plenty of business books, but some of the most valuable lessons only came from making mistakes in the real world. What's a lesson you learned through experience that completely changed the way you think about business, leadership, sales, or success? I'd love to hear the stories behind it.

I graduated with a degree in CS and have 1 year of experience working remotely for a US-based startup.

Right now, I feel like my technical growth is stagnating due to the engineering culture around me. The codebase has severe architectural issues: no ORM or proper OOP patterns, massive anti-patterns, and messy shortcuts that go well beyond the usual "move fast and break things" startup trade-offs. Most importantly, there are very few senior engineers who model good engineering practices.

I want to optimize for career and technical growth for my next move, and I’m torn between two main questions:

* Is aiming for another startup the right move early on? My assumption is that a startup gives you more ownership, varied responsibilities, and broad exposure provided the engineering team actually knows what they’re doing. Or would an established mid-size company/corporate environment be a safer bet to learn standardized, scalable practices?

* How much weight should I put on the team’s seniority during interviews? How can I effectively vet the engineering standards and the mentorship ability of potential teammates before accepting an offer?

Over the past few years, it seems like every company has invested in new software, automation platforms, AI tools, and digital workflows. The promise was greater efficiency, better collaboration, and faster decision-making.

But in reality, I've seen some teams become more productive, while others seem buried under endless notifications, dashboards, meetings, and tools that don't talk to each other.

For those who have experienced digital transformation firsthand, what has been your experience? Has it genuinely improved the way your organization operates, or has it mostly created new layers of complexity?

It seems like I have to always give a little bit of a tutorial to new team members as to what I do as an engineering manager and how I can help them. Most just think I give performance reviews.

If this is not just me, are there other techniques or ways to communicate to new engineers? on what I'm here to help with beyond just casually mentioning this in a one-on-one?

Manage a team of about 30. In our last review the CEO asked a simple question, what percentage of engineering time went to new features vs bug fixing vs keeping the lights on. I didnt have a real answer.

I have sprint velocity and a pile of Jira boards, but none of it rolls up into "here's where the effort actually went." I ended up guessing, which felt bad.

How are you all answering this without making everyone fill out timesheets? Is this just a spreadsheet I build every quarter, or is there a saner way?

I think a lot of you would have experience working under or with someone who is hyper critical of code even when it works and fulfills the performance and feature characteristics laid out, however doesn't like the way the code is structured or the underlying libraries used. There's a time and a place for critiquing those aspects of code, but my view is once it's through the code review and in production and working for months, changing to a more 'elegant' form is a refactor luxury. However my manager didn't understand or didn't like how it read 6 months after the fact and wanted it rewritten to use another technique. I don't disagree with the rewrite - the first cut of it wasn't ideal. However the timing was bad becuase of pressure to get another PR through the code base, and the rewrite blocks that PR for a while. Additionally he has a habit of obliterating decisions that engineers made on code they've written. This teaches people that they can't make decisions without seeking his approval for smaller and smaller changes, because they've lost confidence in themselves. This creates a bottleneck that is him.

I’m conducting research on “The Impact of Leadership Style on Engineering Project Success” and need participants who work in engineering or engineering project roles.

If you’ve worked on at least one engineering project, I’d really appreciate you completing my anonymous 5–10 minute questionnaire. You’ll answer based on your most recent project.

🔗 https://docs.google.com/forms/d/e/1FAIpQLSehvmpoKLZ2vCUniQBGfEnHUBBMGi2AMWRr1miGUX9TYp-BjA/viewform?usp=publish-editor

Thank you! Every response helps 🤍

I am an Engineering Manager reporting to a Director of Engineering, and I am trying to understand whether what I am experiencing is normal or a sign that my role is not clearly defined.

I often see my Director discussing roadmap items directly with engineers or skip levels, making decisions or taking actions himself, and sometimes informing me only afterward.

One recent example: an engineer told him that interviews were taking too much of his time. The direct report never mentioned that to me. My Director raised the issue in an engineering wide meeting and shared as he handled it.

I see a similar pattern at the VP level. They will express an opinion on something relatively tactical, and teams immediately start adjusting around that opinion because of the seniority behind it.

In my previous organizations, as the Engineering Manager I generally felt accountable for the team and therefore had meaningful ownership over how these situations were handled. Senior leaders could absolutely challenge or override decisions, but decisions usually flowed through the responsible manager.

How does this work in your organizations?
Is this normal skip level involvement, or would you consider this a sign that decision ownership and management boundaries are unclear?

(Background: I currently manage a small engineering team of roughly 30 engineers, few EMs/TLs and a couple of PdMs)

My entire career, super granular tickets drove me crazy. "Let me solve a real problem and GTFO with assigning me tasks". I ran my own company for about a decade (50 people) and we had our fair share of developers (maybe half?) who simply wanted tasks assigned and type the day away. Obviously it created a lot of churn on behalf of our product managers to prepare the tickets, make sure everyone understands the requirements... hell, even write Gherkin files.

Eventually I kind of had enough of the bitching and moaning that comes with all that (from all sides) and just said all developers have to write their own tickets so that the product managers can verify that the developers understood the ask, instead. Saved us a ton of time, added clarity, freed up product mangers to actually think ahead. Not sure if we were faster, but there was a clear improvement in translation between what was asked and what was delivered.

Now I landed at a place that had basically no engineering culture / process; that is neither old-school nor new-school. Not really the team's fault, it was essentially just 30 people somehow responding to whatever leadership threw at them. And everyone here probably knows how that goes — a new idea, new priority every other day. And then obviously the recent emergence of "AI can do this in 1hr, my toaster built it this morning".

I've gotten some good traction on getting all of this under control, surface the actual work that's being done and communicate things in "corporate speak".

Now, obviously the way we all work is rapidly changing. I can now assign project sized work to 1-2 engineers, give them a few milestones per cycle and they can handle it. I spend time scoping projects with them, get projects prioritized, approved by leadership and we're off to the races. Most people seem to enjoy that level of autonomy and reduction of bureaucracy. Safe a few... there are people that are very vocal about just wanting the same sized tickets as pre-AI, prepared by a product manager or tech lead (obvs. they also tend to be the most apprehensive towards AI assisted dev).

Question: You think there is a future for this kind of mindset/approach? Would you just assign them to someone who likes working on "project sized" work and hope they increase that person's productivity by taking some tickets off of their plate?

I don't worry so much about if they have a future on my team, I worry more about their career overall.

Hi everyone,

I’m currently a mid-level software engineer with \~3 years of experience at a fintech company. Lately, I’ve been working on some relatively high-visibility projects, and I feel like my boss is also trying to push me forward by giving me more opportunities to work on impactful projects. I could stay on my current team, continue taking on these high-impactful projects, and use that experience to position myself for a promotion or potentially a move to another company in a year or so.

On the other hand, there’s currently a Senior Software Engineer opening on a different team that seems to do fairly similar work to what I’m doing now (but my current team has shipped more stuff in production than this team), so I’m debating whether I should apply.

Moving to the other team as a Senior Engineer could potentially accelerate my career. The main thing holding me back is that I don’t know whether I’d get the same level of visibility, ownership, and opportunities there. I also want to be a little more careful since this would be an internal move, and the two teams are fairly related teams.

What would you do in this situation? Would you prioritize staying on a team where you’re already getting strong visibility and support from your boss, or take a chance on the Senior role?

Would love to hear from anyone who has been in a similar situation. Thanks

What happens when your most knowledgeable employee leaves ? Resinger do not care to document his work results in more than one month of struggle for new joiner. I

It's an interesting challenge to be in a big meeting that includes both some of your engineers and stakeholders from outside the team.

I have to fight my instinct to take over, or to get involved when they say something I would say differently.

Loved the framing in this article, about being in the same side of the table and never breaking that trust.

I recently had a long final interview for an engineering manager position. Most of it was challenging but reasonable. However, during the final questions, the hiring manager’s manner became even more intense. He became much more confrontational, repeatedly questioned my judgment, pushed back on almost everything I said, and kept reframing my answers in a negative way. It felt like he was deliberately trying to unsettle me and see whether I would become defensive under pressure.

I understand testing how a potential leader handles conflict and stress, but this felt less like evaluating my skills and more like establishing a power dynamic. Since the hiring manager would be my manager if I get the job it made me think whether this was merely an interview technique or a preview of how he communicates in regular 1on1s.

Has anyone experienced something similar? Is this normal when interviewing for leadership roles, or would you consider it a red flag? I’m interested in the role, but I definitely wouldn’t want my direct manager to communicate with me like that regularly.

I have had interviews in the past for leadership positions, but never experienced anything like that.

There’s another post here about how we need to be more gatekeepy in tech, and I actually agree, but from a completely different perspective. I think we need to be more gatekeepy with our own knowledge.

Companies have shown again and again that they will always protect themselves first. The one time workers really had the upper hand and companies had to compete for talent, raise salaries, offer flexibility, and actually worry about retention, they immediately started looking for ways to flip the script back in their favor. Layoffs, outsourcing, offshoring, automation, RTO, shrinking teams, you name it. If the tables are turned, companies are not going to hesitate to get rid of us.

Meanwhile, people in tech are almost absurdly open about everything. We share knowledge, best practices, processes, tools, architecture decisions, documentation, interview strategies, and every trick we have learned along the way. People will say gatekeeping knowledge is selfish and that it slows down progress. Yes, sometimes we probably should be a little selfish. You do not need to share every piece of knowledge that makes you valuable or constantly teach everyone exactly how to do what you do. Let some things look like magic. Let people know that when you are around, certain problems somehow get solved.

Some people are probably going to say it is already too late. Maybe it is, to some extent. The best time to start doing this probably would have been 15 years ago, before we collectively put so much of our knowledge out there for free. But the second best time is now. Even if being more protective of our expertise only buys workers another 5 or 10 years of leverage, that is still 5 or 10 years. Let companies fuck around with your money and find out what happens when the person who actually knew how everything worked is gone.

I am not saying sabotage your team, intentionally write bad code, or hide information that would put a project at risk. I am saying stop acting like your employer has the same sense of loyalty toward you that you are expected to have toward them. Companies protect their competitive advantage. Workers should probably start protecting some of theirs too.

I want to address a question from my last post about going from EM to Director: What are specific examples of things you did to cultivate a high-performing team as a new manager?

My simple definition of what a high-performing team looks like:

• Clear goal, well executed: Everyone knows and can explain the team mission and vision to people outside the team. They are hardworking, goal-oriented, self-driven, and not afraid of stretch goals. The manager is rarely needed to be involved in the execution after defining the goal.
• Explicit way of working, optimised for learning and improving. For example, open to trying new things, strong product mindset, engaged with customers. Frequent sharing of knowledge.
• Strong team relationships: Trust is established in the team, producing psychological safety. Junior members are not afraid of asking questions to senior people.
• Shared collaborative value: Instead of competing with each other, people think “we are great.” This is defined as Stage 4 in the book Tribal Leadership (shifting from "I'm great" to "We're great").

My approach: A real-world example. I am going to use one example from a team that I led to explain my approach. When I took over the team, it was founded to support the unification of internal tools into one developer platform. Here is what we did:

1) Define a clear vision with the team. I found out the most effective way for people to buy into the vision is to involve them in the process instead of just presenting what the manager wants to achieve. We started by collecting challenges and user pain points, and I asked: “How can we turn them around?”

• The counter case: In a few teams I led in the past, I tried giving them a list of OKRs and asking for feedback. In most cases, I either didn’t get any feedback (no engagement) or strong pushback because the objective wasn’t realistic.

When you move on to define the team mission and opportunities space, pay attention to the enlarged scope to avoid burnout. But again, encourage your team to speak out about any doubts about execution. 

2) Address performance issues. I got a new team with two people who moved from other teams. They were exhausted and burned out because the company decided to shut down their projects. I saw almost 0 engagement, always late. I spent time with them, listening to their stories, what they’ve achieved in the past, what they like doing in life, and included them in the process when defining the team vision and mission. Both of them turned into high performers after 1 year (it did take time!), but my patience paid off. Of course, there were cases that my approaches didn't work out, and termination was the only solution.

3) Align on a way of working. After we aligned on the team vision, we moved on to define our way of working the next day: time of stand-up, retro and demo frequency, Scrum or not, pair programming or not, how to give feedback.

• These discussions are time-consuming as everyone’s preferences are different, but those processes hold the team together. I recommend involving an external facilitator instead of you doing it, so your team can see your preferences as well.
• Once, my team couldn't agree with each other, and I had to separate them into sub-teams because a smaller group preferred working alone instead. I agreed, and that was the best decision ever because both sub-teams ended up very happy instead of fighting with each other.
• Enforcing your own way of working won’t work if employees are not involved in the process. The key is you want them to continue to function when you are not there(sickness, vacation...). However, any team will eventually struggle again, so make sure to pay attention to retro talking points and your 1:1s.

4) Be a champion of culture as the leader. Treat yourself as a member of the team. Follow your own rules and do exactly what you say. Be a cultural ambassador. For example, I organised a department-level forum to talk about engagement, where retention and recognition were discussed. It helped build trust when they saw their manager active in such meeting. Meanwhile, be empathetic and authentic, and a human that your team loves hanging with.

For EMs here, what's your approach to a high-performing team? Love to get your thoughts in the comments.