Many Engineering Managers who look like they’re struggling early in the role aren’t lacking skill. They’re operating without a clear definition of what success in the role actually looks like, and that gap does more damage over time than any single mistake could.
The Symptoms Get Misread
When a new Engineering Manager is struggling, it rarely shows up as an obvious failure. Delivery feels a little slower than it should. Executives stay a little closer to the work than they used to. Decisions that a team should be able to make on its own start escalating upward instead. Individually, none of these look serious, and it’s easy to read them as a skill gap, a motivation problem or a need for more process and oversight.
What’s usually happening underneath is simpler, and harder to see from the outside. As an individual contributor, success was concrete: output, quality, speed, ownership. What changes when that same person becomes responsible for a team instead of a codebase often isn’t made explicit. The priorities shift, the leverage changes and the expectations evolve, but the new manager is left to work most of that out on their own.
What Actually Changes When You Become a Manager
Success as an Engineering Manager gets misunderstood constantly, usually as some version of writing less code, running fewer meetings or keeping everyone happy. Those are easy to observe from the outside, which is exactly why people reach for them, but they don’t actually define success in the role.
What really changes is leverage. As an individual contributor, your impact is what you personally produce. As a manager, your impact becomes what your team can consistently deliver without you standing in the middle of every decision. When that shift is never made explicit, people default to what used to work. They stay close to execution, absorb pressure themselves and push harder, because pushing harder is the one lever they already know how to pull.
Why the Feedback Loop Disappears
Part of why this takes so long to correct is that the feedback loop a strong IC relied on quietly disappears. Code either compiles or it doesn’t. Tests pass or they fail. Features ship or they slip, and you know within hours whether the work was good. As a manager, the consequences of a decision show up weeks or months later. A misaligned priority doesn’t throw an error, it compounds quietly. A missing expectation doesn’t fail a build, it eventually shows up as delivery friction that’s hard to trace back to where it actually started.
Without a clear definition of success, there’s no reliable signal telling a new manager whether they’re focused on the right things. So they default to the one feedback loop that still feels immediate: writing code, getting into the details and proving competence the way they always have.
My Own Version of This
I learned this firsthand a few months into my own transition into management, when a large project kicked off that I wasn’t even supposed to be part of yet. I was asked to sit in on a couple of meetings to help, and that project ended up running seven or eight months, with my team doing roughly half the work on something that was originally scoped for a quarter.
I didn’t know how to lead a team through something that size. I knew how to manage myself and I knew how to code, so for four or five months I did the normal work of running a team and then spent another fifteen to twenty hours a week writing code just to keep things moving. From the outside it probably looked like dedication. From the inside it wasn’t sustainable, and it took getting through that project to understand what my job actually was. It was never to be the extra engineer on the team. It was to build the conditions that let the team deliver without depending on me to write the code. Nobody taught me that directly. I learned it by being dropped into the fire and figuring it out under pressure, which is exactly the pattern I now spend my time helping other Engineering Managers avoid.
The Pattern Shows Up Consistently
This isn’t just my own experience. When I ran an informal poll asking Engineering Managers what felt least clearly defined during their transition into the role, more than half said it was what success actually looked like. Roughly a quarter said they didn’t know who to ask for help or when. Taken together, most of the managers who responded stepped into leadership without either a clear model of success or a clear support path.
The comments underneath that post echoed the same experience over and over, in different words. Managers who were told to define success for themselves. Managers who reverted to writing code whenever they doubted themselves as leaders. Managers who quietly ended up absorbing every gap in accountability that nobody else on the team had been assigned to close.
None of that reads like a performance problem. It reads like a role that was left undefined and then evaluated as if it had never been ambiguous at all.
What This Actually Costs
The cost of leaving this undefined isn’t a dramatic failure. It’s a slow drift: uneven development from one manager to the next, quiet burnout that gets mistaken for a personal limitation and a leadership bench built on personality and tolerance for ambiguity instead of on anything more durable. It takes years to become visible, and by the time it does, it’s already shaped how the team operates.