The Biggest Mistakes I Made as an Engineering Manager

I became a manager the way most people do: I was a good engineer, and someone assumed that meant I would be a good manager. Nobody trained me and nobody warned me, so for the first couple of years I made mistakes that were both painful and entirely predictable in hindsight.

Looking back, almost every mistake traces back to the same root: I managed the way that made me comfortable, not the way the role required. Coding instead of leading. Answering instead of asking. Avoiding conflict. Saying yes. Performing certainty. All of them were comfort-preserving behaviors, and all of them exported the discomfort onto my team.

For my first year I clung to coding tasks, usually the fun ones rather than the strategically important ones. I told myself I was staying close to the codebase and leading by example. What I was actually doing was avoiding the uncomfortable, ambiguous work of managing humans, and cherry-picking the interesting tickets while leaving the boring, necessary tasks to my team.

When someone came to me with a problem, I solved it. I was fast, I was usually right, and I felt useful. It was also one of the most damaging things I did. By jumping in with answers, I trained my team to outsource their thinking to me. The same people came back with the same types of problems, because I had trained them to escalate, not to think.

The shift that changed everything was replacing “here is what you should do” with “what have you tried so far, and what do you think we should do” – and then sitting in the silence that followed. It felt agonizing. Coaching is slower than solving, but solving creates dependency and coaching creates autonomy.

I once had a brilliant engineer who left a trail of bruised colleagues behind them. I noticed it within the first two months and said nothing. Not in month three, or six, or nine. I told myself I was giving it time and letting the team sort itself out. What I was really doing was protecting my own comfort at the expense of everyone else on the team.

By the time I finally addressed it, two good engineers had already quit, and the conversation was far harder, and more unfair, than it would have been months earlier. They were genuinely blindsided, because from their perspective I had been fine with the behavior all along. I had been.

When product or leadership asked for more, my reflex was agreement. I wanted to be reliable and helpful, so I committed to a date I had computed with overtime baked in, then returned to the team to figure out how to fit it in. I did that several times in one quarter without ever going back and saying that the new thing replaces the old thing.

The team shipped, barely. Then the medical leaves and the quiet quitting started. Saying yes to everything without capacity math was not flexibility. It was silently passing the cost to my team in hours and health. A silent yes is a deferred invoice with interest.

Velocity was our north star, and I celebrated the weeks we shipped the most stories. I reported green dashboards upward while the product went nowhere. We optimized for tickets closed instead of problems solved, and velocity looked amazing right up until someone handed in their notice.

My VP asked me once what the team had changed for the customer that quarter. I talked about velocity. He said that was not what he asked. Now I push for one question in every planning: what outcome will be different for a user if we do this well. If we cannot answer that, we do not build it. Sometimes the most valuable week of the quarter is the one where the team deletes a subsystem and the roadmap shows nothing shipped.

I believed a manager’s job was to absorb chaos, so I translated every messy organizational discussion into a clean task list and hid the rest. Smart, motivated people were asked to execute decisions they did not understand, for reasons they were never given. Humans do not take ownership of things they do not understand, and the people closest to the code often spotted flaws in plans I had already committed to.

At the same time I spent years thinking that managing my boss was politics, and politics was beneath me. I did not negotiate deadlines, so my team absorbed unrealistic ones. I did not communicate our wins, so we lost headcount to louder teams. I did not explain our technical debt, so we never got time to fix it.

My best engineers were the most self-sufficient, so they got the least of my time. My weeks went to fixing problems, the struggling project and the struggling person, while my top performers ran on autopilot. Then my two best engineers left within four months of each other, and both exit conversations had the same theme: I stopped growing here. I had confused no complaints with no problems.

High performers are the least likely to ask for help and the most likely to leave without warning. They get my attention first now: stretch assignments, visibility, sponsorship, and honest conversations about where they want to go, even when that path might eventually lead them off my team. I also learned to hire for slope rather than speed. A brilliant engineer who makes everyone around them worse is a net negative, and one toxic hire once cost me two good ones.