When the Person Who Built It Has Left the Building
Making sense of the mess they left behind.
There’s a moment in every growing business when a key person leaves, and with them goes the context behind a critical part of your operation.
A warehouse integration. An email automation flow. Someone’s labyrinthine spreadsheet held together by nested IF statements and optimism. The challenge is universal.
The tool still works (sort of). Reports still run. Notifications still ping. But when something breaks? Good luck.
You log in. You look around. And it feels like stepping into a half-built IKEA wardrobe with no instructions, a few screws missing, and a random Allen key left behind.
Now what?
Step 1: Accept the Fog
You’re not clueless. The issue isn’t intelligence, it’s context. Most systems grow organically, shaped by the habits, quirks, and workarounds of the people who built them. You’re not inheriting a tool. You’re inheriting someone else’s worldview.
So start there. Accept that it’ll feel messy. Your goal isn’t instant mastery. It’s understanding what matters most, and keeping those parts from falling over.
Step 2: Track the Gaps
Start with what people actually use and need. Not everything. Just the bits that make the biggest impact.
Keep a simple list of:
Reports or outputs people rely on
Numbers that regularly get questioned
Terms no one can define but everyone references
At this point, it's more about business value rather than technical accuracy. Prioritise accordingly.
Step 3: Trace the Source
Pick one critical or confusing element, and trace where the data (or logic) actually comes from. Shopify? NetSuite? A form someone fills in on Tuesdays?
You’re not fixing anything yet. Just drawing a map. The goal is to understand how data or actions move from A to B, and where things might be going sideways.
Step 4: Talk to the End People
Every tool ultimately touches someone’s workflow. Maybe it’s finance checking month-end numbers. Maybe it’s customer service trying to find the right order. Maybe it’s marketing pulling performance metrics.
Whatever system you’ve inherited, talk to the people who rely on it. Ask what they trust, what confuses them, what they have to fix manually. You’ll quickly see where the gaps are, and where the tool has drifted from how the business actually runs.
This isn’t just about technical fixes. It’s about alignment. Find out how the tool impacts real work, and use that insight to guide what gets rebuilt, renamed, or retired.
Step 5: Rebuild the Narrative
These tools shape how people interpret performance and make decisions. When teams don’t trust what they’re seeing, they work around the system. That’s when mistakes creep in.
The fix usually isn’t technical. It’s editorial. Strip it back. Make it understandable. Then build it up again, in a way that matches how the business actually operates.
Rebuild the key bits from scratch if you need to
Use plain language, not internal jargon
Add just enough context to stop people guessing
You’re not polishing a tool. You’re making it usable. For the people who depend on it.
Step 6: Document As You Go
Don’t wait to "finish" before writing things down. Every bit of clarity you find should live somewhere shared. Even rough notes are better than nothing.
Because one day, someone will inherit this from you. And when they open that baffling tool, they deserve a better start.
Inheriting a system isn’t just about fixing what’s broken. It’s about understanding what people rely on, and why they stopped relying on it. The logic is only half the battle. The real work is rebuilding confidence, so teams stop second-guessing the tools that are supposed to support them.
And that starts with understanding what you’re looking at. Even if you don’t. Yet.