What skipping the first four conversations actually costs, and the question to ask before anyone says "we need a new tool."
Most organizations I walk into are full of half-implemented solutions and baskets of spreadsheets.
There's a system that's mostly used. Next to it, a spreadsheet somebody built for the cases the system doesn't handle well. And a weekly meeting whose real job is to reconcile the two.
Nothing is broken. There's no incident. Nobody escalated anything. And everyone involved can honestly tell you their own part is fine. The system works. The spreadsheet works. The meeting happens.
Look at the file names, though. Tracker_v2_FINAL. Exceptions (do not delete). Finance version. Copy of Copy of Q3. And my personal favorite, Mine.
Every one of those is somebody solving a real problem, on a real afternoon, with the tool that was in front of them.
We were brought in once to improve a system that had been running for about ten years. It wasn't badly built. It was a bundle of trade-offs. Somebody needed a number by Thursday. Somebody's team didn't have a field they needed, so they used a different one. Every one of those calls was reasonable when it was made. A lot of the old processes had to stay, because you can't stop a business for a quarter while you redesign how it works, so we built around them. And the moment the new system tried to read everything consistently, it exposed gaps in the data that had been quietly patched for years.
The improvement didn't create any of that. It was just the first thing in a decade that could see it.
Nothing is broken. Everyone's part is fine. That's the problem.
Every workaround is a loan
Somewhere back in the history of that system, a decision didn't get made. What counts as done. Who approves an exception. Which system owns the number leadership looks at.
Nobody decided, usually because nobody had the time or the standing to decide in that meeting. So somebody worked around it. Reasonably. They were trying to get the work done that afternoon, and they did.
That workaround is borrowed time, and the metaphor actually holds. The decision nobody made is the principal. The effort of living without it, every week, is the interest.
And it compounds. The next person who hits the same gap doesn't go back and make the original decision. They build their workaround on top of the last one. Now you're paying interest on the interest.
That's what I mean by operational debt. It's the interest on decisions nobody made.
It isn't technical debt
People hear "debt" and assume I mean code.
Technical debt is real, and engineering teams are pretty good at it now. It's shortcuts in how a system was built. Somebody can see it, it lives in a backlog, and it's somebody's job to pay it down, even if they never get enough time to.
Operational debt is shortcuts in how the work happens. It doesn't live in the system. It lives in spreadsheets, in recurring meetings, and in people's heads. And it's nobody's job to see it. No backlog, no owner.
That's why it gets so big. Nobody's careless. It's invisible by design, because every piece of it was a sensible local choice and nobody has a vantage point to add them up.
Technical debt has a backlog. Operational debt has a meeting.
Where the interest gets paid
Four places, and you'll recognize every one.
The spreadsheet beside the system. Started as one person's workaround. Now four people use it, and it's never appeared in anyone's plan or budget.
The meeting that reconciles. Two teams, two numbers, and a recurring hour to decide which one is true this week.
The person everyone asks. The one who knows which exceptions are real and which are just habit. Their calendar has quietly become part of the process.
The exception handled by hand. Once a month somebody does something manually, because that's how it's always been done, and nobody remembers why.
None of these shows up as a cost on anyone's report. Every one of them is one. Time nobody logs (they just come in early). Trust, once leadership has seen two numbers for the same thing twice. Speed, when an afternoon's change takes three weeks because four other things depend on it and nobody wrote down which. People, because the knowledge sits in someone who can leave.
And the next implementation. This is the one that surprises people. When you buy the next system, it inherits all of it on day one. Poor execution transfers.
One project, three identities
Here's what it looks like from the owner's seat.
Take a project number. It should be the simplest thing in the business. Last number, plus one.
Except finance can't use it on its own. Finance needs the number plus the team the project benefits, because that's how cost gets attributed. And reporting can't use either version, because nobody in a leadership meeting recognizes a number. Reporting needs the pillar and a friendly name.
So one project has three identities. Every team is right, and it works fine for years.
Then there's a migration. Or an acquisition. Or someone asks for one view across the whole portfolio. Now you've got three exports, three different keys, and nothing to match on, and somebody spends weeks deciding by hand which rows are the same project.
That's the bill arriving all at once, on the day you can least afford it. If you own the business, or you're thinking about buying one, that isn't an operations detail. It's capacity the business can't get back.
"We need a new tool"
Eventually somebody says it.
I get why. When the debt gets heavy enough, a new tool sounds like relief. A clean start. No spreadsheets, no reconciling meeting, no chasing the one person who knows.
And for a few months it usually is cleaner. Then the spreadsheet comes back, because the case it was handling didn't go anywhere. The meeting comes back, because two teams still count the same thing two different ways. And the person everyone asks is now the person everyone asks about the new tool.
None of that is anybody's fault. The debt was never in the tool. It was in the decisions nobody made, and those don't migrate out. They migrate over.
Listen to the request itself. We need a new project management tool. It sounds clear. It names a category, and you can put it in a budget.
But it doesn't say what the software is supposed to solve. Underneath it there's usually a stack of questions nobody has answered. Who decides what gets worked on? What counts as done? Who can approve an exception? Which number does leadership actually trust?
Those aren't software questions. They're questions about how the organization works, who has authority, and who gets to say no. And the new tool will have to answer them anyway. Every status, every required field, every approval step is an answer to one of them. Either you answer them on purpose, or somebody answers them in a setup screen on a Tuesday afternoon.
Three tools, one missing row
So instead, people run an evaluation. To be fair, it's usually thorough. Three tools, a spreadsheet, a row for every feature. Boards and timelines, automations, dashboards, integrations, the mobile app. Everything gets a check.
Every tool gets every check. At this point they're more alike than different, which is exactly why the comparison feels so hard. You're choosing between three good answers to a question nobody wrote down.
The missing row is the only one that would separate them: what do we need it to solve?
Without it, you pick on price, or the best demo, or whatever someone used at their last job. Then you set it up to look like the old one, because that's the only definition of the work anyone has.
The comparison covers everything except the job.
What is this system doing to begin with?
That's the question I'd actually ask. Not what it was bought for. What it's doing.
The project tool was bought to track projects. That's the job on the purchase order. A few years in, it's also taking in requests, hosting the argument about priorities, routing approvals, producing the status report leadership reads, maybe holding the numbers finance uses, and serving as the record of who promised what to whom.
None of that was in the original brief. Most of it wasn't assigned to anyone. It arrived one job at a time, because the tool was there and the work needed somewhere to go.
That's what happens to every system that gets used. But it means the tool you want to replace is doing a lot more than the tool you'd buy to replace it, and nobody's written down the difference.
Now line up everything you've got. The project tool, the CRM, the finance system, the shared inbox, and if you're honest, the spreadsheets and the person everyone asks. They're doing work too. Across the top, the jobs: taking in work, setting priorities, approvals, status, cost.
Two things jump out almost every time. Some jobs are being done by two or three systems at once, and wherever that happens there's a meeting reconciling them. Some jobs aren't being done by any system at all, so they live in a spreadsheet and somebody's head.
Where two systems do one job, you get a meeting. Where none does, you get a spreadsheet.
Which means you can go back to those file names and read them differently. Every spreadsheet is a job description. Tracker_v2_FINAL is doing status, because nobody trusts the system to hold it. Exceptions (do not delete) is handling the cases the process never decided. Finance version is attributing cost the way finance needs it. Copy of Copy of Q3 is reporting in words leadership recognizes. And Mine is somebody tracking their own work, because the shared view doesn't show them what they need.
None of those people is being difficult. Each one picked up a job no system was given. If the new tool doesn't take those jobs on purpose, the spreadsheets come right back. Same names, probably. Maybe a v3.
Behind every job is a decision
Intake sounds like a form. It's really a decision about who decides what gets worked on, and in what order. Exceptions sound like edge cases. They're really a decision about which exceptions are real and who can approve one. Status is a decision about what counts as done. Cost is a decision about which number is the real one.
That's the principal again. The spreadsheet is just where the interest gets paid.
A new tool doesn't let you skip those decisions. It forces them. If nobody makes them on purpose, whoever sets up the tool makes them by default, and now the technology is making organizational decisions by accident.
The build is the receipt for the decisions.
Paying it down
You pay it down by going back and having the conversations you skipped. The same four from this series, held late, for the systems you already have.
- Role. What is each system for? Give every system a job, on one line, and say it out loud. Including the ones you'd rather not admit are systems.
- Decisions. What have the workarounds been deciding? Settle those on purpose, with somebody who has the standing to.
- Resourcing. Who should do this work? Not builders, not yet. They need something defined to build against, and that hasn't changed just because the system is old.
- Ownership. Whose job is it to notice? Somebody owns the outcome, not the software, so the next workaround gets seen while it's still a workaround.
None of this starts with a demo. Most of it starts with the right people in a room and an honest list.
And if someone's already asking for a new tool, ask three things before anyone books a demo.
- What is it supposed to solve? The problem, not the category, in a sentence someone outside the team would understand.
- What's doing that job today? The current tool, a spreadsheet, a meeting, a person. Something is.
- What decision would the new tool have to make for us? It'll make at least one. Better to know which one going in.
Then compare tools. Now the evaluation works, because you finally have the row that separates them.
Sometimes the answer really is a new tool. The work has changed, or the current one genuinely can't do the job. That happens. Just as often, you find out you didn't need a new tool. You needed a decision, and the tool you had was fine. Features are the last question, not the first.
Four reasons to switch that aren't reasons
You're going to hear these. They all sound reasonable.
Everybody hates the current tool. Often what they hate is a process it's holding. The approvals nobody agreed on. The status nobody trusts. That comes with you.
The new one does more. It probably does. More features for a job nobody's named yet, and every feature without a job is one more thing somebody has to decide how to use.
Nobody uses the old one properly. Then ask what they use instead, because that's where the real process lives. That spreadsheet is the most honest requirements document you'll get.
It'll be cleaner. It will, for a while. Then the spreadsheets come back, because the jobs never left.
All four are reasonable. None of them says what the software is for.
Sometimes the right answer is a new tool. It should never be the first question.
This is the fifth and final briefing in the first Operational Systems Briefing series: role, decisions, resourcing, ownership, and cost. Watch the recording: [link]`