The job changes four times

The unhappiest engineering leaders I've watched weren't bad at their jobs.

They were excellent at the job they'd had two years earlier, and still doing it, with more people watching.

There are four versions of this role. They share a title and almost nothing else.

Moving between them isn't a promotion in any meaningful sense. It's a career change. And nobody saying so out loud is exactly why the transitions go badly.

One: builder

Somewhere between one and eight engineers.

You write code. Probably most of it. You also do everything else, which at this size means recruiting, architecture, the customer call where something is on fire, and the decision about which database.

The leadership content of this job is small. Mostly it consists of not being a bottleneck for two other people.

Nothing about this stage prepares you for the next one. First cruel thing about it.

Two: multiplier

Roughly eight to thirty.

Your output stops being what you produce and becomes what the group produces. Everybody has heard about this transition. Roughly half of people manage it.

The habit that has to die: being in the room for every decision.

At eight people you genuinely can be, and it genuinely helps.

At twenty-five it makes you the slowest component in the system. Work backs up behind your calendar, and because you're busy, and being busy feels like contributing, it takes a very long time to notice that the constraint is you.

The tell is specific.

Look for decisions in your organisation that waited more than three days on you. Not decisions you made badly. Decisions that were fine, and late.

The other tell is emotional, and less comfortable. If the most satisfying part of your week was the one afternoon spent fixing a bug, you probably haven't found the thing in this job that replaces it.

It does exist. Watching somebody you coached run a hard incident well is genuinely better than fixing the bug yourself.

But it operates on a much slower clock, and the gap between the two is where a lot of people quietly stall.

Three: architect of the machine

Thirty to somewhere north of a hundred.

You manage managers now. You can't know everyone's name, and you certainly can't know their work.

Your unit of work is no longer a decision, or a team. It's a mechanism.

The hiring loop. The planning cadence. The on-call rotation. The promotion process. The way information moves.

You design the thing that produces the decisions, and then mostly leave it alone.

The habit that has to die: running the process yourself.

Most people arrive here having personally run a good version of every process in the building, and the temptation is to keep running them, one level down.

It looks like diligence. It reads to your directors as a statement that you don't trust them. And that reading is correct, because it is one.

The specific skill here is writing things down. Not documentation for its own sake.

Decisions, standards, the reasoning behind a call, so that people three layers away can act consistently without having to ask anybody.

Netflix used to call this context rather than control. Good phrase for something that takes years to actually get good at.

Four: steward of the strategy

A hundred and fifty plus. Multiple product lines, probably multiple sites, definitely more history than you personally have.

You're now mostly working on three things.

The technical strategy and whether it still matches the business. The quality of your leadership team. And the small number of decisions that genuinely can't be delegated.

Everything else you touch, you distort.

The habit that has to die: having an opinion on everything.

At this level your casual opinions aren't casual.

A remark about a library choice in a Slack channel becomes a directive by Thursday, and you'll never hear about the two weeks of rework it caused.

Leaders here have to develop an unnatural discipline about when to speak. Which is hard, because the thing that got them here was frequently having good opinions quickly.

How to tell you're stuck in the previous job

General symptom: you feel useful and the organisation feels slow.

More specifically.

You're the person who unblocks things. Your calendar is full of other people's problems and you're solving them rather than fixing why they arrived. Your directs bring you decisions they're perfectly capable of making themselves. You're the only one who knows something important.

Or, cleanest signal of all, the organisation runs noticeably better during the week you're on holiday.

Worth taking that last one seriously rather than as a joke.

Staying credible without staying in the code

Standard advice is to keep coding.

Mostly wrong past stage two, I think, and the version that does work is narrower than people want it to be.

You can't be on the critical path. A leader who owns a service is a leader whose service gets neglected the month there's a reorg.

But you can read pull requests without commenting on most of them. You can sit in incident reviews and ask questions rather than supply answers. You can keep one small internal tool nobody depends on. You can go through your own onboarding once a year and feel exactly how bad it is.

The purpose isn't to contribute.

It's to keep your model of the system accurate enough that you can tell when somebody is describing a problem inaccurately. That's the actual technical skill stage three and four require.

The part the ladder metaphor gets wrong

Calling these four a progression implies the later ones are better, and that people who stay in the earlier ones have failed somehow.

Plenty of very good engineering leaders are at their best somewhere in stage two and get worse in stage three.

That isn't a deficiency. It's a different job.

The industry handles this badly, because the only recognised path upward runs through org size, so people who were excellent at running a group of twenty end up running a group of ninety. Unhappily. For money.

If you're deciding whether to take the next step, the useful question isn't whether you can do it.

It's whether you'd enjoy a week made mostly of designing mechanisms and having careful conversations, with nothing shipped at the end of it.

Some people read that sentence and feel a small dread. Believe it.