Every Organization Has a Sarah (And Why That's a Problem)

"Only Sarah knows how that system works."

Every organization has a Sarah. The developer who built something critical, wrote very little of it down, and slowly became the single point of failure for an entire part of the business.

Sarah isn't the problem. Sarah is usually one of the best people you have. That's exactly how it happens.

How someone becomes indispensable

It rarely starts with a decision. It starts with success.

• Sarah is brilliant and solves problems faster than anyone else
• Leadership loves her, because she always delivers under pressure
• She becomes the go-to person for anything complex or urgent
• Over time, she builds up knowledge that exists nowhere else
• Eventually, she's running systems the business can't live without - and nobody else could

At no point did anyone choose this. It just kept being the fastest way to get things done.

Why it feels good - for a while

For everyone involved, it works:

• Problems get solved quickly, with no lengthy handoffs or explanations
• Sarah feels valued and essential
• Management feels confident, because Sarah can handle anything
• Projects move faster without the "overhead" of documentation and sharing

That's what makes it so hard to spot. It looks like a high-performing team. It is a high-performing team - balanced on one person.

Why it becomes dangerous

• Sarah becomes a bottleneck. Everything flows through her, so everything waits for her.
• Sarah can't really take a vacation. Or she can, with her laptop, answering messages from the beach.
• Nobody else can contribute. New team members can't get into her systems, so they never learn them.
• The business depends on one person's availability - and happiness. A resignation, an illness or a better offer becomes a business-continuity event.
• It's a security risk too. One person holding all the passwords and admin access is one compromised account, or one bad day, away from a serious problem.
• Sarah burns out. Being constantly needed is exhausting, even for people who love their work.

And the Sarah problem isn't always a person. It can be a contractor who built your core system and has since moved on, a vendor that's the only one who understands your configuration, or - increasingly - code generated with AI tools that works, but that nobody on the team actually understands. The risk is the same: something critical that only one source can explain.

It's a leadership failure, not a people problem

This is the part leaders don't love hearing. Sarah didn't create this situation. We did.

We rewarded speed over sharing. We sent the hard problems to the same person because it was easiest. We let documentation slide because the deadline mattered more. We praised the hero and didn't notice we'd built a team that needed one.

Which means fixing it is a leadership job too - and it's much cheaper to fix before Sarah hands in her notice.

How to find your Sarahs

A few questions that surface them quickly:

• The vacation test: if this person were completely unreachable for two weeks, what would stop?
• Where do the hard tickets go? If the answer is always the same name, you've found one.
• Who holds the keys? Whose personal login, phone or password manager is the only way into something important?
• What would we struggle to explain to an auditor, a buyer or a new hire?

Ask the team, not just the managers. They always know.

How to fix it

• Pair people on critical systems. Sarah works alongside at least one other developer on anything only she understands - not as a one-off handover, but as normal practice.
• Make documentation part of "done." It's part of every code review and every project close-out, not a separate task that never gets scheduled.
• Rotate the urgent work. Let someone else take the next incident, with Sarah as backup rather than first responder. It'll be slower the first time. That's the point.
• Get the keys into a shared vault. Credentials and admin access belong to the company, with more than one person able to use them.
• Use vacations as a test. When Sarah's away, notice what breaks or waits - that's your to-do list.
• Reward sharing, not just heroics. If promotions and praise only go to the person who saved the day, you'll keep getting people who make themselves the only one who can.

The conversation with Sarah

How you frame this matters. Done badly, it sounds like you're preparing to replace her.

Try something like: "You've built something really valuable. Now we need the team to be able to support it, so you're free to take on bigger things - and so you can take a real vacation."

She may resist at first. Being indispensable can feel like job security. Your job is to show her that being a force multiplier - the person whose knowledge makes the whole team stronger - is worth more, to her career and to the business, than being the only one who knows.

The bottom line

The best developers I've worked with build systems that don't need them to run. The ones who struggle build systems that can't run without them.

Indispensable people aren't a strength. They're a single point of failure that hasn't failed yet - and they deserve better than to be one.

Related reading

• The "Later" Tax: What Deferred Technology Decisions Really Cost
• The Security Questions Every Executive Should Be Able to Answer

Worried about how much your business depends on one or two people? Let's talk. Finding and fixing key-person risk is one of the fastest ways to make a technology team more resilient.