Growing managers out of engineers

Promoting the best engineer on the team into management is the most common personnel decision in our industry and it works about half the time.

Half is a terrible rate for a decision that costs you an excellent engineer, hands a team a manager who might not want the job, and is socially near-impossible to reverse.

Especially when there's a cheap way to get much better odds. Hand the job over in pieces first, and watch what they do with each one.

The pieces are separable. Most companies never exploit that.

Management gets treated as an atomic promotion. One day you're an engineer, the next you have six reports and a comp cycle.

In fact it's a bundle of about six distinct responsibilities, and they can be handed over one at a time across a year.

The apprenticeship, in order

Start with mentoring one person. A mentee, never a report. Weekly, real, with an outcome you both name.

What you're watching for is whether they take satisfaction from somebody else's progress, or find it a distraction from their own work.

Both answers are fine. Only one of them is a manager.

Then project leadership.

Give them a piece of work with three or four people on it, accountable for the whole outcome instead of their own contribution.

That's where you find out whether they can hold a plan in their head that isn't code, and whether they'll chase the thing nobody has picked up.

Then the uncomfortable conversation.

Have them deliver a piece of difficult feedback they own, with you as a rehearsal partner beforehand and a debrief afterwards.

Plenty of people opt out here, quietly, by softening the message until it doesn't land. That's the single most predictive moment in the whole sequence, and finding it now beats finding it later.

Then hiring. Let them run a loop end to end. The bar, the interviews, the debrief, the offer conversation.

Fastest way to learn that management is mostly judgment about people under incomplete information.

Then the parts of the job that never look like leadership from outside.

The status update nobody reads. The escalation from another team on a Friday. Absorbing a decision they disagree with and representing it honestly anyway.

This is where the romance of the role dies, and it should die before the promotion instead of after it.

Each piece is reversible on its own. That's the design.

By the end you both have real evidence, and the promotion becomes recognition of something already happening instead of a bet.

The signs someone shouldn't take the job

Some of these look like enthusiasm, which is what makes them dangerous.

Wanting the title, or the pay, or the seat in the room, while finding the actual work of the role uninteresting.

Fixable. By fixing your ladder, though, never by promoting them.

Being unable to let something be done worse than they'd do it. The classic technical-excellence trap.

A manager's output is the team's output, and somebody who can't watch a suboptimal implementation ship without taking the keyboard will either burn out or hollow out the people around them.

Conflict avoidance. Shyness is a separate thing entirely and it doesn't matter here.

Avoidance looks like hoping problems resolve themselves, softened feedback, hard conversations scheduled and rescheduled.

Management is largely a sequence of unpleasant conversations held early. Somebody who can't do that does enormous damage slowly.

And the one people miss, which deserves proper framing because the usual framing is both wrong and insulting.

Some excellent engineers are genuinely uninterested in what motivates other humans. That gets called a soft-skills gap, as though something were missing from them.

Nothing is missing.

Management is problem solving. The problems happen to be people, and human-problem-solving is not the class of problem some very good engineers want to spend their days inside.

A preference about problem domains. And it will make the job miserable for them and for everybody reporting to them.

The counter-sign is worth naming too.

The person quietly doing half the job already, unpaid and unasked, is usually your answer. They notice the new hire is struggling. They write the thing down so the next person doesn't have to ask. They tell you something is wrong before it becomes a problem.

The door swings both ways or it isn't a door

I won't promote somebody into management unless there's a real senior IC track they could have chosen instead.

Real meaning it goes as high, pays comparably, and has visible respected people standing on it.

Same principle going back.

The move from management to IC has to be genuinely available and genuinely unpunished, and it only counts as genuine once it has happened to somebody people can name.

Until then everybody assumes the return trip is a demotion, whatever the handbook says. Rationally so.

Which means the first person to do it matters enormously.

Announce it as a decision. Keep their comp intact if the level supports it.

And say the true thing out loud. They tried the job, it wasn't the right fit, that's information, and we'd rather have an excellent engineer than a reluctant manager.

The tryout framing helps upfront too.

Say at the start that the first year is a two-way trial, and mean it. Somebody who knows they can step back will tell you the truth at month eight, which is exactly when you'd want to hear it.

Plenty of people have made that return trip on my watch, and it has consistently been a good move.

What makes it work is that the level and the authority survive it. Same standing in the org, minus the people-management part.

If the trip costs somebody either of those, nobody takes it, and you keep an unhappy manager instead.

The pattern underneath is almost always the same, and it's rarely that they were bad at managing.

They wanted bigger, gnarlier problems, and management was the only label the company had for "more."

Give them the staff level and something genuinely hard, and you've answered what they were actually asking for, without both of you spending a year finding out the expensive way.

Managing managers is a different job again

Worth flagging. The second transition arrives faster than people expect, and nobody warns them.

When you manage engineers you can see the work.

When you manage managers, everything you see is filtered through the person you're evaluating, and you find out about problems from the same person whose handling of them you're assessing.

Structurally awkward information position. The fix is independent inputs. Skip-levels on a real cadence, the 360 feedback everybody gets anyway, and your own presence in enough of the work to hold a view.

The other shift is that your feedback loop gets much longer.

An engineer knows within days whether a change worked. A manager of managers makes decisions whose results surface two quarters later.

Which makes the temptation to intervene directly, where the feedback is fast and satisfying, more or less constant. Every hour you spend there is an hour of your manager's job that you took and didn't give back.

The mistake I'd warn a founder about

Don't hire your first engineering manager because the team hit a headcount number.

Hire one when you can name the thing that's actually breaking without one, in a sentence that has nothing to do with span of control.

The version that goes wrong: twelve engineers, somebody says twelve is too many for one person, an EM gets hired from outside, and now there's a layer between you and the work at exactly the stage where your judgment about the work is the company's main asset.

Push it later than feels comfortable. And when you do add it, prefer the person already doing half the job over the impressive outsider. Most of the time.