I watched a $12M company almost die when their lead engineer quit. Not because he was brilliant. Because he was the only person who understood how billing worked.

The CEO kept saying "He's irreplaceable." Turns out that was the problem.

Most founders think having star employees is an asset. You've got the designer who ships perfect work, the engineer who holds the entire system in their head, the salesperson who closes every big deal.

You brag about them. You pay them more. You build your roadmap around what they can do.

Then they leave. Or get sick. Or just take a vacation.

And your company stops working.

Here's what actually happens: Companies that run on hero employees can't scale past 15-20 people. The heroes become bottlenecks. Everything waits for them. And when they're gone, nobody knows how to do their job because the job only existed in their head.

I started documenting who knew what

Pulled up our org chart. Listed every major function. Then wrote down how many people could do each one if the primary person disappeared tomorrow.

Payroll: One person

Customer onboarding: One person

Deploy process: One person

Pricing decisions: One person

We had seven single points of failure. Any one of them could take a vacation and we'd be scrambling.

So I changed the question. Instead of "Who's good at this?" I started asking "Could someone new do this in three weeks?"

If the answer was no, we didn't have a job. We had a dependency.

The difference between a job and a dependency

A job has a clear input and output. There's a process. You can write down the steps. Someone new can learn it in a reasonable timeframe.

A dependency is different. The person who does it makes a hundred tiny decisions based on context they've built up over months. There's no documentation because "it's not that complicated." They just... know.

When you ask them to document it, they write three paragraphs. When you watch them do it, it takes two hours and involves checking seven different places and making judgment calls they don't even notice they're making.

That's a dependency. And dependencies don't scale.

Companies that survive vs companies that plateau

I've seen two patterns with companies that hit $5-10M in revenue.

Pattern one: They keep hiring specialists. Each person owns something completely. The founder is proud of how much autonomy everyone has. Everyone's great at their job. The company plateaus because coordination costs spike and nobody can cover for anyone else.

Pattern two: They hire for the system, not the seat. New people shadow the existing person for two weeks. Everything has a runbook. Decisions have frameworks. The company keeps growing because adding people makes you stronger, not more fragile.

The difference isn't talent. It's whether you're building jobs or dependencies.

How to convert a dependency into a system

Take whatever your most critical person does. Watch them do it for a week. Not to critique. Just to see what actually happens.

You'll notice they do things in an order. They check certain things first. They have rules for edge cases, even if they've never said them out loud.

Write those down. All of them.

Then have them review what you wrote. They'll say "Yeah but it depends..." 47 times. Every time they say that, that's a decision rule you're about to capture.

"It depends on whether they're a new customer or expansion" becomes "New customers: process A. Expansion: process B."

"It depends on how urgent it is" becomes "If they need it in 24 hours, escalate to manager. Otherwise, standard queue."

Those dependencies? They're just undocumented decision trees.

The test run

Once you've got the process documented, have someone else do it. Not the expert. Someone who's never done it before.

Sit with them. Watch where they get stuck. Every place they ask a question is a gap in your documentation.

Don't answer their question. Update the documentation. Then have them keep going.

If they can complete the task in three tries without asking questions, you've got a system. If they need the expert to intervene, you've still got a dependency.

Why founders resist this

There are three objections I hear every time.

"We move too fast to document everything." You move slow every time that person is unavailable. Documentation speeds you up.

"Some jobs require judgment that can't be systematized." Then train the judgment. Create frameworks for decisions. Make the implicit explicit.

"My best people will leave if we systematize their work." The people who leave when you document their job are the ones who knew their value came from being irreplaceable. Let them go. Keep the ones who want to scale.

The hiring shift this creates

Once you've got systems, your hiring changes completely.

You stop looking for the person who can figure everything out. You start looking for the person who can follow a system and spot where it breaks.

You stop asking "Are they senior enough?" You start asking "Can they execute this process and improve it?"

Your interviews change too. Instead of "Tell me about a time you solved a hard problem," you ask "Here's our current process for X. Read it. What's missing?"

The people who thrive in this environment aren't the heroes. They're the ones who like building systems more than being needed.

Reply

or to participate

Keep Reading

No posts found