aaron@mccarthy:~/posts/one-guy-system-problem.md
← cd ../blog.md

The “One Guy System” Problem: What Happens When Everything Depends on One Person

Every company has one.

The person who “knows how everything works.”

They built the spreadsheet. They understand the Access database. They know which numbers to trust—and which ones to ignore. They can fix things when they break.

And over time, something dangerous happens: the system stops being software… and starts being a person.

## How It Starts (And Why It Seems Fine at First)

Nobody plans to create a “one guy system.”

It usually starts with a good employee solving a real problem:

  • A spreadsheet to track orders
  • A small Access database to manage workflows
  • A few scripts or macros to automate repetitive tasks

It works. It helps. People rely on it.

So naturally, more gets added. New columns. More logic. Extra files. Workarounds for edge cases. And because one person understands it all, progress is fast.

At this stage, it actually feels efficient.

## The Access/Excel Gatekeeper Problem

Eventually, that helpful system becomes a bottleneck.

Now only one person knows how to update it safely. Only one person can fix errors. Only one person understands the formulas and logic. Everyone else works around the system instead of with it.

You’ll hear things like:

  • “Don’t touch that tab—just ask him.”
  • “If it breaks, we’ll have to wait until she’s back.”
  • “I think this number is right… but I’m not sure how it’s calculated.”

At this point, the system isn’t empowering the team—it’s controlling it.

## Tribal Knowledge and Undocumented Logic

Here’s where things get fragile.

Critical business logic lives in places like:

  • Nested Excel formulas no one wants to read
  • Access queries with unclear relationships
  • Manual steps that exist only in someone’s head

There’s no documentation. No clear rules. No visibility. Just “this is how we’ve always done it.”

The problem is, that logic is often business-critical, financially impactful, and operationally essential. And yet, it’s completely opaque to everyone except one person.

## What Happens When That Person Leaves

This is where things break—fast.

When the “one guy” leaves (or even just goes on vacation), the cracks show immediately.

1. Immediate slowdown

Simple tasks take longer. Reports can’t be generated. Data can’t be trusted. Changes can’t be made. Everything stalls while people try to figure things out.

2. Workarounds multiply

Without clarity, people start improvising. New spreadsheets. Manual tracking. Duplicate systems. Now you don’t just have one fragile system—you have several inconsistent ones.

3. Errors increase

When no one understands the logic, data gets entered incorrectly, formulas get broken, and decisions get made on bad information. And no one is confident enough to say what’s right.

4. Institutional knowledge is lost

This is the real damage. Years of understanding—why things were done a certain way, which edge cases matter, what problems were already solved—all of it walks out the door. And you can’t just “rebuild it quickly” because you don’t fully understand what you had.

## Why This Is More Dangerous Than It Looks

The biggest issue isn’t inconvenience—it’s risk.

When a business depends on one person, there’s no redundancy, no accountability, and no scalability. You’re one resignation, illness, or retirement away from operational disruption.

And the longer the system exists, the worse the dependency becomes.

## How to De-Risk Without Blowing Everything Up

Here’s the good news: you don’t have to scrap everything overnight. You can reduce risk incrementally.

1. Start by making the invisible visible

Before replacing anything, understand it. Document what the system does, the key workflows, inputs and outputs, and known pain points. You’re not aiming for perfection—you’re creating visibility. Even basic documentation is a huge step forward.

2. Extract the business logic

Separate the rules from the tools. Ask: what calculations actually matter? What decisions are being made? What triggers approvals or changes? This is the core of your system—not the spreadsheet itself. Once you understand the logic, you’re no longer tied to the original tool.

3. Centralize the data

If your system relies on multiple spreadsheets, email attachments, and local files—start consolidating. Move toward a single source of truth, even if it’s a simple database at first. This reduces duplication and makes everything easier to manage.

4. Rebuild the workflow (not just the interface)

Don’t just recreate the spreadsheet in a web app. That’s a mistake I’ve seen too many times. Instead, define clear states—draft, pending, approved—automate transitions where possible, and make status visible to everyone. Focus on how work flows, not just how data is stored.

5. Remove the single point of failure

This is the goal. A healthy system can be understood by multiple people, has clear rules and visibility, doesn’t rely on memory, and can evolve without breaking everything. You’re not just replacing a tool—you’re removing a risk.

6. Do it in phases

You don’t need a “big bang” rewrite. Start with the most critical workflow, the biggest bottleneck, or the highest-risk area. Solve that first, then expand. This approach reduces disruption, builds trust with users, and delivers value quickly.

## Final Thought

The “one guy system” isn’t a people problem—it’s a system problem.

That person did something valuable. They solved real business needs with the tools they had. But over time, the business outgrew the approach.

The goal isn’t to replace the person. It’s to build systems that don’t depend on one person to function.

Because a system that only one person understands isn’t really a system at all.