The Cost of Not Knowing What You Need
I keep a small note to myself: the cost of not knowing what you need. Most of what I want to write about today sits underneath that one line.
Go-live is not the goal.
Every ERP program I’ve been near treats the go-live date like the finish line. Steering committees track it, vendors get paid against it, executives report it upward as the win. And then three months later, the same organisation is drowning in workarounds, shadow spreadsheets, and a help desk that never stops ringing.
The date was never the goal. A smooth transition into a system people actually use, month after month, was. An on-time go-live followed by six months of chaos isn’t success delayed — it’s the same failure wearing a green status report.
More money is not the factor.
Give a struggling team a bigger budget and watch what happens. Sometimes it buys clarity — better people, better tools, room to fix what’s broken. Sometimes it just buys a longer runway to keep doing the wrong thing, at greater expense. The money isn’t the variable that predicts the outcome. What the organisation does with it is.
This is worth sitting with before the next budget request lands on your desk. The question isn’t “how much do they need.” It’s “what do they actually intend to do differently with it.”
Losing weight is not staying healthy — and the business equivalent is everywhere.
A number can drop while the underlying condition gets worse. Revenue can rise while the business gets more fragile. Headcount can shrink while capability quietly leaves the building. We chase the number that’s easy to measure and assume it stands in for the thing we actually care about. Sometimes it does. Often it doesn’t, and we don’t find out until later.
Strength is not what you can carry — it’s what holds when the load doesn’t let up.
We tend to size people up by output under normal conditions — how much they can carry when things are going fine. But the more useful measure is what happens to their judgement and their standards when the pressure doesn’t ease for a long stretch. Some people carry a lot and fray quickly. Others carry less at any given moment but hold their shape indefinitely. In a long program, or a long downturn, it’s the second kind you need — and the one that’s hardest to spot in advance.
Automation is not efficient by default.
This is the one I see most often in my own work. A process gets flagged for automation, and everyone treats that as progress. Nobody asks the prior question: does this step need to exist at all? Some of what gets automated should have been eliminated. Some should have been outsourced to someone who already does it well. Some only survives because nobody has looked closely enough to understand why it’s there.
Automating a step you didn’t need doesn’t make you efficient. It makes you fast at something pointless.
Where this leaves us
The pattern across all five is the same. We generalise on a scale that’s easy to read — the date, the dollar figure, the number on the scale, the load someone can carry, the task list marked “automated” — and we assume that scale tells us whether we’re winning or losing.
It rarely does on its own. What actually moves us toward the goal is defining, specifically, what we need — not what’s easiest to track. Understanding what really gets us closer, not what looks like progress. And measuring it with enough honesty to notice when the number and the outcome have quietly stopped agreeing with each other.
None of this is complicated. It’s just easy to skip, because the proxy is right there and the real thing takes more work to see.
What’s the number you’re tracking right now that might not be telling you what you think it is?
