Leadership & Team Building

How to Build a Leadership Pipeline in a Startup That Scales

office

How to build a leadership pipeline in a startup (without a single HR hire)

The first time someone quit on me, it was a Friday. She was my second engineer, she'd been with me eleven months, and she told me in the stairwell because we didn't have a meeting room. I spent the weekend realizing I had no idea who could take over her work. Not because nobody was capable. Because I had never once thought about it.

That's the moment most founders start thinking about a leadership pipeline. Not before. Never before.

Here's the thing though: by the time you're in the stairwell, you're already late. A pipeline isn't a succession plan you dust off when someone walks. It's a habit of growing people faster than you need them, and in a company of fifteen people with no HR function and no budget, that habit has to be almost embarrassingly simple.

Key Takeaways

  • Start your pipeline somewhere between 10 and 15 employees. Below that, you don't have enough roles to promote into.
  • You will not hire a dedicated HR person to run this. You'll run it yourself in about two hours a month.
  • The build-vs-buy question is real, and the honest answer changes as you scale.
  • Promoting your best individual contributor to manager too early is the single most common way startups break their own pipeline.
  • A pipeline is a list of names, a list of gaps, and a recurring conversation. Nothing more elaborate survives contact with startup reality.

Why startups get this backwards

Every framework I've read on this topic assumes something a startup doesn't have: layers. The classic leadership pipeline model — the one that shows up in every book with "pipeline" in the title — describes six transitions, from managing yourself up to managing an entire enterprise. It's a good map. It's also written for a company where each layer already exists and needs filling.

Why startups get this backwards

You have one layer. Sometimes two, and the second one is you, squinting at a spreadsheet at 11pm.

So the Instituut-style thinking has to be compressed. Instead of six passages, you're managing two questions:

  1. Who can run a function in twelve months if I need them to?
  2. What are they missing right now, and can I fix that in my spare time?

That's it. That's the whole pipeline at your stage.

When should you actually start?

Ten to fifteen people. That's the window. Below ten, everyone wears four hats and there's no role to grow into. Above twenty, you've already had your first "oh no" resignation and you're improvising under pressure.

I missed that window. Between employee nine and employee sixteen, I promoted nobody and hired four people from outside. Two of those hires worked out. One left after seven months. One I had to let go, which cost me roughly six weeks of my own attention I should have spent on customers.

The two hours a month that actually matter

Once a month, I block two hours. Calendar invite, no agenda, phone in a drawer. I open a plain doc with five names on it.

For each name, three lines: what they're excellent at, where they'd struggle if I promoted them tomorrow, and one thing I could hand them this month to close that gap. The third line is the only one that produces anything.

Real example: my best frontend developer was drowning as a de facto team lead because she'd never had to give critical feedback. Not a training course problem. I gave her the job of running our code reviews for six weeks and told her explicitly that part of the job was telling people no. She hated it for a month. Then she got good at it.

Build vs buy: the honest math

Here's the uncomfortable part nobody puts in a framework.

Build vs buy: the honest math

When you have fifteen people, your internal bench is thin. You might have one plausible candidate for a role, which isn't a pipeline. It's a hope.

So you buy. That's fine. But buying has a cost that doesn't show up on the offer letter: external senior hires arrive without context, and in a startup, context is most of the job. A VP who's spent a decade in a company with dedicated ops, legal, and finance will spend their first quarter just figuring out how little infrastructure exists.

Approach Time to productivity Real cost Best used when
Promote internally Fast on context, slow on skills Your time as a coach, plus the risk they fail in front of peers You have someone at 70% of the role and a real coach available
Hire externally Slow on context, fast on skills Recruiter fees, higher salary, roughly a quarter of ramp The role requires experience you cannot manufacture in six months
Hybrid: promote + external peer Mixed Two salaries for one function, temporarily You need the function to actually work while someone grows into leading it

In my experience, the hybrid row is the one founders skip and later regret. If you promote someone into a role they're not ready for and give them nothing to lean on, you've set up a failure you'll have to manage in public.

The conversation nobody wants to have

Ask your best people, directly, whether they want to manage. Not in a performance review. In a normal conversation, over coffee, with no agenda attached.

The conversation nobody wants to have

Roughly a third of them will say no. Some will say it apologetically, like they're letting you down. They're not. A senior individual contributor who is genuinely excellent is worth more to you than a reluctant manager who is mediocre at both jobs.

I learned this the hard way with a backend engineer I'll call Tom. Brilliant. Deeply respected. I promoted him to lead the platform team because he was the obvious choice, and within four months he was miserable, his team was confused, and we'd lost the most productive engineer in the building to meetings. We reversed it. He went back to writing code, we hired a lead from outside, and everyone was better off. The mistake cost us about five months of momentum.

The lesson: ask before you promote. Not after.

The frameworks, and how much of them to believe

You'll run into three named rules when you start reading about this. Here's what each one is actually worth at your size.

What is the 70-20-10 rule for leadership?

The 70-20-10 rule says leadership development should split roughly 70% from challenging on-the-job experience, 20% from relationships and mentoring, and 10% from formal training. For a startup, the 70% is basically free — you have more hard problems than people to solve them — and the 10% is where most founders overspend. Sending someone on a two-day course feels like progress. Handing them a messy problem and checking in weekly is progress.

What are the 5 C's of leadership?

You'll see slightly different versions depending on who's writing, but the common five are communication, confidence, courage, commitment, and character. Some lists swap in competence, or compassion. The exact wording matters less than the test it gives you: when you're deciding between two candidates for a stretch role, you're usually not comparing skills. You're comparing whether one of them will say the hard thing in the room. That's courage, and it's the one that's hardest to teach.

What is the 30-60-90 rule in leadership?

The 30-60-90 rule is a structured onboarding plan: the first 30 days for learning, days 30 to 60 for contributing, and days 60 to 90 for leading. I use a version of it for every internal promotion, and the most useful part is the first phase. Newly promoted managers almost always skip the listening and jump straight to changing things, because they want to prove the promotion was earned. Write the plan down. Share it with the person. Revisit it at day 30 and actually be honest about what you're seeing.

How to build a strong leadership pipeline: the short version

Everything above collapses into four habits. Do them badly if you have to. Do them.

  • Keep a live list of five names. Five is enough. If you have more than five plausible future leaders in a company of twenty, you're flattering people.
  • Hand out stretch work deliberately. Not more of the same work. Work that requires a capability they don't have yet.
  • Ask the management question out loud. Before you promote, not after.
  • Accept that some of them will leave anyway. A good pipeline doesn't retain everyone. It means that when someone leaves, you're surprised by the timing, not by the fact that you have no one.

And one more, which I'd argue is the actual point: your pipeline is not a document you maintain. It's a set of relationships you keep warm. The doc is just where you write down what you noticed.

What this looks like eighteen months later

Two years after that stairwell conversation, I sat in a different stairwell with a different person, and this time I wasn't scrambling. We had a name ready. The transition took three weeks instead of three months, and the team barely noticed.

Nothing dramatic happened. That's the point. The measure of a working pipeline isn't a heroic save. It's the absence of a crisis you never had to have.

Which raises the question you should sit with for a minute: if your best engineer told you tomorrow that they're leaving in thirty days, how many names are on your list right now?

If the answer is zero, you know where your next two hours go.

Share:
Edward Carter

Edward Carter

Edward Carter is a journalist with over twelve years of experience covering business and finance, focusing on the entrepreneurial mindset, funding and investment, and innovation and strategy.

See all articles