When One Person Holds Your Reporting Together: The Unicorn Problem

Almost every growing waste company has one — the person who knows the ERP, writes the SQL or the macros, runs the Power BI, and single-handedly holds half the company’s reporting together. They’re indispensable, and they’re also a single point of failure. The fix isn’t to replace them; it’s to give them an architecture — a governed source layer, a model other people can build on, and a clear next step — so reporting no longer lives in one person’s head and the company isn’t one resignation away from a reporting crisis.

Who is the reporting “unicorn”?

The reporting unicorn is the one person who quietly holds a company’s reporting together. They know the ERP inside out. They write the SQL, or the macros, or both. They built the Power BI. And they understand the business well enough to know what every number is supposed to mean. Almost every waste company I’ve worked with has at least one.

They’re genuinely incredible — the person everyone routes questions to when a report looks off or a new number is needed by Friday. The problem isn’t them. It’s that the entire reporting operation lives in their head and on their laptop, which makes them, in plain terms, a single point of failure.

Why does every growing waste company end up with one?

Because the numbers leaders need live in systems that were never built to talk to each other. The ERP runs routes and billing. Payroll lives somewhere else, fuel somewhere else, disposal somewhere else. Nobody planned for one person to become the bridge — it just happened, one urgent request at a time, because they were capable enough to make it work.

So they wired it together themselves: an export here, a macro there, a SQL query nobody else can read, a Power BI model only they know how to refresh. Each fix was rational on its own. Stacked over a few years, they add up to a reporting layer that exists almost entirely as one person’s undocumented knowledge. The company grew; the architecture didn’t.

Why is a reporting unicorn a business risk?

Two reasons, and the second is the one that keeps owners up at night. First, they’ve maxed out. There is a ceiling on what one person can produce without an architecture behind them, and a growing hauler hits it fast — new locations, new questions, new acquisitions to fold in. The unicorn becomes the bottleneck on everything that needs a number.

Second, and more dangerous: the company is one resignation away from a reporting crisis. If that person leaves — or is out sick during close, or simply burns out — nobody else can run, fix, or explain the reports leadership depends on. It isn’t a knock on the person. It’s that no business should have its financial and operational visibility resting on a single point of failure.

Isn’t the fix just to document what they do or hire a backup?

Those help, but they don’t solve it — because the problem isn’t documentation, it’s architecture. Documenting a fragile, hand-built process just gives you a thorough description of a fragile, hand-built process. And hiring a second person into that same tangle means two skilled people are now maintaining spreadsheets nobody else can touch. You’ve added cost, not resilience.

The reason it all lives in one head is that there’s no shared foundation for it to live on instead. Until that exists, every workaround — more documentation, more headcount, a new BI tool — just sits on top of the same one-off extracts. Fix the foundation and the knowledge finally has somewhere to go besides one person’s memory.

What does giving the unicorn a foundation actually look like?

When we get to work with a company like this, the first job usually isn’t to replace what the unicorn is doing. It’s to give them a roadmap and a foundation to build on — so the work they’re already doing well stops depending on them being the only one who can do it. In practice it’s three moves, in order:

• A governed source layer instead of one-off extracts. One place where the data from the ERP, payroll, fuel, and disposal is defined once, with clean lineage — so a route or location number means the same thing whoever pulls it, and nobody is re-exporting by hand.
• A model other people can build on. The definitions and logic that lived in the unicorn’s macros move into a shared model. New reports become a change to something durable, not a favor only one person can grant.
• A clear next step that builds on what they already have. Not a rip-and-replace. The roadmap sequences the build so the first piece delivers value quickly and each step lands on the last — the same reason fixing ERP reporting starts with a roadmap, not a tool.

None of this throws away the unicorn’s work. It takes what they built by hand and gives it an architecture, so it can scale past what one person can hold. It’s the same foundation that lets a growing operator automate month-end reporting or finally see route profitability — capabilities that are out of reach as long as everything runs through a single laptop.

What changes when the reporting has a foundation?

The unicorn doesn’t go away — they get to stop being the bottleneck. Freed from re-running the same extracts and rebuilding the same reports, the most capable person on the team gets to do the higher-value work only they can do: the analysis, the harder questions, the new views leadership has been asking for. That’s usually the work they were hired for in the first place.

And the company stops being one resignation away from a reporting crisis. The knowledge lives in a governed layer and a shared model instead of one person’s head, so reporting survives a vacation, a sick day, or a departure. That’s the real return: not just faster reports, but a business whose visibility no longer rests on a single point of failure.