Growing a Future Leader

The hardest transition in any career is the one from doing the work to multiplying others, and the very thing that made someone a great engineer is what holds them back at it. A brilliant IC is fast, precise, and gets things done. Left in that mode, they cap out: they become the best individual on a team they can’t scale. Grooming that person toward Lead, Principal, or one day CTO isn’t about giving them a title and reports. It’s about rewiring how they think, and that takes deliberate work over months. This doc is the plan for it.

Use it when you’ve spotted someone with the raw signal, ownership, curiosity, the instinct to lift others, but who’s still operating at the task level. The goal is not to make them a manager overnight. It’s to walk them, step by step, out of the doer’s mindset and into a leader’s.

The Rewiring#

What’s expected: The future leader can name the shift they’re making and catch themselves on the wrong side of it.

Four shifts define the whole transition. A future leader who’s still stuck on the left will plateau; your job is to move them, deliberately, to the right.

The deepest of these is the second. A doer asks what needs doing and how to do it, that’s an execution lens, and it’s the right one for an IC. A leader asks who (who’s affected, who should own this, who needs to grow) and why (why does the team behave this way, why does this keep happening, why does the stakeholder actually want this). The move from what/how to who/why is the move from managing tasks to understanding people and systems, and it’s the one your future leader will resist most, because the tasks feel more concrete and more urgent. Push them there anyway. It’s the whole game.

Why People Behave the Way They Do#

What’s expected: The future leader is developing genuine curiosity about people and motivation, not treating “the team stuff” as a distraction from real work.

An IC’s core skill is the system, the code, the design, the data. A leader’s core skill is people: why someone is disengaged, what actually motivates a particular person, why two teammates keep clashing, what a resistant stakeholder is really afraid of. This is a real skill, learned the same way as any other, by paying attention and forming and testing hypotheses, and most technical people have spent zero reps on it. A future leader who still thinks “I just want to write code, the people stuff is noise” is not ready. The ones who make it start to find people as interesting a system as any codebase, because it’s the system they now work on.

Guardrails, Not Micromanagement#

What’s expected: The future leader sets an outcome and boundaries, then lets people own the how, instead of hovering or doing it themselves.

The default failure mode of a new leader who was a great IC is to micromanage, because they know how to do it and it’s agonizing to watch someone do it differently or worse. So they hover, correct every step, or quietly redo the work. That doesn’t scale and it stunts everyone under them.

The alternative is guardrails. A guardrail is a boundary and a checkpoint, not a set of instructions: you define what the outcome must be, the constraints it must respect, and where you’ll check in, and inside that, the person is free. You review at the seams (the plan, the milestones, the result), not over the shoulder (every keystroke). Guardrails scale because they let ten people run at once without ten times your attention; micromanagement can’t, because it’s bottlenecked on you. Teaching a future leader to trust the guardrail, to let someone deliver it imperfectly and coach the gap, rather than seize the keyboard, is the single hardest and most important habit in this whole transition. The principles underneath it, find what depends on you, remove yourself from the path, and open capabilities instead of hoarding them, are worth internalizing on their own: Multiplier, Not Bottleneck.

Two things keep this from tipping into recklessness. First, guardrails still get checked, the checkpoint is a real review, not a hands-off pass, and the leader stays on the hook for the outcome; delegating is not abandoning. Second, the person has to feel safe to miss: a delegated stumble has to land as a lesson, not a mark against them, or they’ll never take the reach that grows them. Autonomy without that safety isn’t trust, it’s just being left to fail in public.

The Self-Assessment#

Before you build the phased plan below, have them fill this out. It’s a short, honest self-read, in the same spirit as the weekly report: plain text, prefilled by the person, ~30 minutes, honesty over polish. It surfaces the three things you need to shape the plan: what the team currently depends on them for, where they’re blind, and what they’re confident and shaky about, in their own words before you add yours.

The value isn’t the form; it’s what the act of filling it forces. Most strong ICs have never once written down what depends on them or where they’re weak. Doing it is the first rep of the whole transition: seeing yourself as a node others rely on, not just a person doing tasks. Their answers become the raw material for the plan below; your job is to read them honestly and turn them into the phased stretch.

The template#

Numbered points, each answered in a sub-point. Plain text so it pastes into a doc or a message. Honesty over polish: a blunt blind-spot is a great answer, a tidy one is a wasted form.

Future Leader Self-Assessment · [name] · [date]     (~30 min, honest over polished)

1. What people depend on ME for
   a. Decisions that wait for my approval:
   b. Knowledge or context only I have:
   c. Work the team routes to me by default (they push it to me):
   d. Access, keys, or accounts only I hold:

2. Where my time actually goes (rough split)
   a. Doing my own work: __%
   b. Making others better (coaching, unblocking, reviewing, documenting): __%

3. What I grab that I could hand off
   a. Work I do myself out of habit or "it's faster if I do it," though someone else could own it:
   b. Why I haven't let go of it yet (honest reason):

4. My bench
   a. People I could hand real things to today:
   b. Someone I could start growing, and in what:
   c. Where I have no one to hand things to yet:

5. My blind spots
   a. Feedback I keep hearing but haven't really acted on:
   b. Where I suspect I'm weaker than I let on:
   c. What I avoid because I'm not good at it:

6. Confidence check
   a. As a leader-to-be, I feel CONFIDENT about:
   b. I feel NOT confident about:

7. Where I want to go
   a. The kind of leader I want to become:
   b. What worries me about leading, or about letting go of the hands-on work:
   c. Honestly, how much do I want this? (leading vs. going deeper as an IC, both are real, respected paths here)

Filled example#

Future Leader Self-Assessment · Sam · 24 Jul     (~30 min, honest over polished)

1. What people depend on ME for
   a. Approval: every schema change and any deploy touching billing waits on my review.
   b. Only I have: the whole payments integration is in my head; no doc exists.
   c. Routed to me: anything "hard or risky" gets handed to me by default.
   d. Access: I'm the only one with the Stripe prod keys and the migration runner.

2. Where my time actually goes
   a. Doing my own work: ~80%
   b. Making others better: ~20% (mostly quick code reviews, little real coaching)

3. What I grab that I could hand off
   a. Billing changes, I reach for them myself because it's faster and I trust my own review.
   b. Honestly? I'm nervous someone breaks billing and it's on me.

4. My bench
   a. Today: Dana could take code reviews for the team; Raj could own the smaller migrations.
   b. Could grow: Priya, into owning the whole payments area over a couple of quarters.
   c. No one yet for: incident command; I'm always the one who runs them.

5. My blind spots
   a. Feedback I keep hearing: "you take over in reviews instead of letting me fix it."
   b. Weaker than I let on: giving feedback. I avoid hard conversations.
   c. What I avoid: anything ambiguous with people; I retreat into code.

6. Confidence check
   a. Confident about: technical judgment, architecture, shipping under pressure.
   b. Not confident about: delegating without hovering, coaching someone worse than me at the thing, saying no.

7. Where I want to go
   a. A lead people trust, who grows strong engineers, eventually own eng direction.
   b. Worried I'll be slower and less useful if I stop being the one who does the hard parts.
   c. I think I want it, ~70%. Part of me would happily stay deep in payments forever, and that's worth being honest about.

Notice how much of the plan is already visible: a dangerous single-point-of-failure (payments, undocumented, one set of keys), a lopsided time split, a real bench to grow into (Dana, Raj, Priya) and one gap with no one (incident command), a named avoidance (hard conversations), and honest ambivalence about the path itself. That’s not a weak report, it’s a great one, because it gives you exactly what to work on, and flags early that the want isn’t a certain yes.

Turning it into the plan#

Read the answers and map them onto the phases below. The self-assessment isn’t graded; it’s the source material.

Then bring it to a 1:1: you’ve read it, they’ve written it, and the plan gets built together from what’s actually true, not from your guess about where they are. Re-run the self-assessment at day 90 or 180 and the deltas, fewer things depend on them, a healthier time split, a blind spot they’ve owned, are the clearest evidence the transition is taking.

The 7-30-60-90-180 Day Plan#

What’s expected: You run this as a real, shared plan with the person, not as a vibe. Each phase has a focus, concrete moves, and a signal that they’re ready for the next.

Build it from their self-assessment above, the short intake they prefill on what depends on them, where they’re blind, and what they’re confident about, so the plan starts from what’s actually true rather than your guess. This is a roughly six-month arc to rewire a strong IC into a leader. Move at their pace, the days are markers, not deadlines, but don’t let them stall in the comfortable early phases. Each phase deliberately pulls them further from the task and closer to leverage.

When the Bet Doesn’t Pay#

Not every future leader becomes one, and betting on someone is not a promise that it works. Sometimes the raw signal was there but, given an honest run, the person finds they don’t want it, they miss the craft, or the people side never clicks. Watch for it: months in and no delegation that sticks, energy draining rather than rising, the who/why questions never coming. Name it early and kindly, the same no-surprises rule as any feedback.

And if the honest answer is that leadership isn’t their path, moving them back to strong IC work is a redirection, not a demotion. An excellent engineer who tried management, learned it wasn’t for them, and went back to building is not a failure; they’re someone who now knows themselves better, and great ICs are prized here, never pushed into management to “progress.” Treat it as the good outcome it is. Your coaching budget is finite: spend it where the bet is paying, and free the person to do what they’re genuinely great at.

The Test#

You’ll know the transition has taken when one thing is true as a pattern: their default is to make the team better, not to do the work themselves. They still ship hands-on when a crisis or a real gap calls for it, that’s not a relapse, it’s a good leader pitching in, but their instinct is to unblock and clarify rather than always grab the hardest ticket; they measure the month by their people’s output, not their own commit count; they ask who and why before what and how. That’s the person you can keep growing toward Principal, Head of, or CTO, because multiplying others has a far higher ceiling than any single pair of hands.

Related: Multiplier, Not Bottleneck, Growing People, Spotting the Right People, Equipping People, Leading People, Growing Your Reports, Weekly Report