Engineering Leadership · Chapter 1 of 9
What actually changes at each level
The most common leadership failure is doing the previous job well. This is what the new one is.
Every step in a leadership career changes what your output is and how long it takes to find out whether you were right. Almost every struggling leader is executing the previous level competently.
The specific traps at each step
| Step | The trap | What it looks like from outside |
|---|---|---|
| Senior → EM | Still writing the critical code | You are the bottleneck, and your team is not growing |
| EM → Director | Managing managers as if they were engineers | You skip-level into decisions, and your managers stop deciding |
| Director → VP | Holding on to what should be delegated | You are in every room and none of them properly |
| Any → any | Keeping the last job as a comfort blanket | You do the familiar work well and the new work not at all |
The question that tells you whether you have made the transition
“What did you do last week that only you could have done?”
If the honest answer at EM level is ‘I fixed the hardest bug’, you have not made the step. If at director level it is ‘I ran the sprint planning for one team’, the same. The answer should get progressively less concrete and more consequential, which is uncomfortable and is the point.
What actually changes, level by level
| Transition | What the job becomes | What people carry over that they should drop |
|---|---|---|
| Senior IC → team lead | Your output is the team's output. You are still writing code, but it is no longer what you are paid for | Being the person who takes the hardest ticket. It feels like leading by example and it starves everyone else of the interesting work |
| Team lead → manager of a team | Hiring, performance, and the health of a system you now only see through other people | Reviewing every pull request. It reads as involvement and functions as a bottleneck and a signal of distrust |
| Manager → manager of managers | You manage a system — how decisions get made, how information moves, who is developing whom | Skip-level problem-solving. Fixing something two levels down teaches your managers that you will, and they stop |
| Director → executive | Allocation. What gets funded, what gets stopped, and what the organisation is shaped to do | Having a favourite team. At this level attention is the scarce resource and it is visibly allocated |
The measurement problem nobody warns you about
Every one of these transitions makes your work less visible and slower to verify, and both effects arrive before the results do.
As an engineer you had a feedback loop measured in hours: the tests pass or they do not. As a manager the loop is measured in quarters — whether a hire works out, whether a reorganisation helped, whether someone grew.
The predictable failure is filling that gap with visible work: taking a ticket, doing the review, writing the design yourself. It relieves the anxiety and it is the exact behaviour that keeps you stuck.
What actually helps is deliberately collecting second-order evidence, because nothing surfaces it automatically: what shipped because of a decision you made? Whose design changed after your review? What did the team stop doing? Who can now do something they could not do six months ago?
Write those down as they happen. You will not remember them at review time, and they are the only evidence that the job is being done.
And a decision worth making explicitly rather than drifting into: how much do you intend to stay hands-on? The honest answer for most first-line managers is enough to keep judgement, not enough to be on the critical path — which in practice means small, deferrable work: tooling, tests, documentation, the unglamorous fix. The moment your code is load-bearing for a deadline, you have two jobs and you will do the manager one badly, because the code has a due date and the people do not.
Check yourself