Past a certain size, an engineering manager’s job quietly changes from “manage the engineers” to “manage the leads who manage the engineers” — and those are not the same skill. The shift catches a lot of managers off guard, because nothing about the transition is announced; the org chart just gets one layer deeper, usually without anyone calling out that the job itself needs to change with it.
Why direct management stops scaling Link to heading
With a smaller team, a manager can reasonably keep a pulse on every engineer’s day-to-day work — what they’re blocked on, how a PR review is going, whether a QA cycle is slipping. Past a certain size, trying to hold onto that level of detail across 20+ people doesn’t make a manager more effective, it makes them a bottleneck. Every decision ends up routing through one person who can’t actually be in every conversation.
The shift that actually works is giving team leads real ownership of their functional areas — not just delegated tasks, but the authority to make the calls that would otherwise land on the manager’s desk: how to sequence a sprint, when to push back on a deadline, how to handle an underperforming team member on their first pass. The manager’s role moves from making those decisions to making sure the leads have the context and judgment to make them well.
What actually gets delegated — and what doesn’t Link to heading
Day-to-day execution decisions can be handed off almost entirely: sprint planning, task breakdown, code review standards within a team, first-line performance conversations. Those are decisions that need proximity to the work to be made well, and a team lead sitting with their developers and QA engineers every day has better information than a manager one level up ever will.
What’s worth keeping close: cross-team prioritization when dev, DevOps, QA, and PM functions have competing needs, headcount and structural decisions, and anything that touches roadmap commitments made upward. Those decisions need someone with visibility across every team and into the business side — a view a team lead focused on their own area doesn’t have, and shouldn’t need to have.
The part people underestimate: managing the leads themselves Link to heading
Team leads need a different kind of 1:1 than individual contributors do. An IC 1:1 is often about unblocking a specific piece of work. A team lead 1:1 is about whether they’re making good calls when the manager isn’t in the room — which means the conversation should spend more time on how they arrived at a decision than on what decision to make. A manager who only ever corrects a wrong call after the fact teaches leads to escalate everything to avoid being wrong, which defeats the entire point of delegating.
It also helps to make sure leads talk to each other as much as they talk to their manager. A lot of the friction in a multi-function org — dev vs. QA priorities, DevOps capacity vs. feature deadlines — resolves faster horizontally between leads than if every disagreement has to route up and back down.
Where this model breaks Link to heading
This only works if leads have enough standing authority that people below them stop routing around them to reach the manager instead. That means actively redirecting questions back to the right lead, even when answering directly would be faster in the moment — because every time a manager answers instead of redirecting, they undermine the structure they’re trying to build.