By the time a technology decision reaches the executive team, it usually arrives pre-diagnosed: the system is too old, the platform is wrong, the tools don’t talk to each other. Sometimes that’s true. Often it’s the most visible symptom of something the software can’t fix.
Here is how to tell the difference before you spend anything.
Trace one real piece of work, end to end
Pick a single, concrete case — one customer issue, one order, one deal — and follow it through the organization from start to finish. Not the process as documented; the path it actually took. Talk to each person who touched it and ask what they were trying to accomplish, what they needed, and what slowed them down.
Then watch where it stalls.
- If it stalls because a tool is genuinely incapable of a task people have clearly defined, you may have a real technology problem.
- If it stalls because no one agreed who owns the next step, what “resolved” means, or which system holds the authoritative answer, you have an operating-model problem. New software will inherit the same ambiguity.
Most of the time, it stalls at the second kind of gap.
The tell-tale signs it’s not the technology
A few patterns reliably indicate that the software is taking the blame for something else:
- Every team behaves rationally, and the outcome is still bad. People are working hard, following their own incentives, and the case still falls through the cracks. That’s a sign no one agreed what success looked like — not that anyone lacked a tool.
- The data is “wrong,” but no one can say what right would be. Inconsistent data usually means an undefined process, not a broken database.
- Experts describe screens, not outcomes. When your most experienced people explain their work as fields and clicks rather than the result they produce, expertise has migrated into the tool. Fixing the tool optimizes the wrong thing.
- The requested fix is “the same, but smoother.” Genuine technology constraints block a capability entirely; adoption and configuration problems just feel like friction.
Why good teams and good tools still fail
The uncomfortable truth is that capable people and competent software routinely combine to produce poor results. It happens whenever the organization hasn’t agreed the boundaries between roles, the definition of “done,” or the point at which a problem is actually solved. Each team optimizes its own part; no one owns the whole; and the seams are exactly where customers feel the failure.
Software cannot resolve that. It executes rules; it does not write them. This is the same principle behind should we replace our CRM? — and the reason so many replacements disappoint.
Once you’ve found the real constraint
If the trace points to a genuine tool limitation against a clearly defined need, you have a sound basis for a technology decision — and you now know exactly what the tool has to do.
If it points back at the organization, start there instead: define ownership, decision rights, hand-offs and the information each decision needs. It’s cheaper than any platform, it’s the highest-leverage work available to you, and it’s the difference between technology that reinforces the business and technology that amplifies its confusion.
This question was earned the hard way in Don’t automate ambiguity — where the platform wasn’t failing at all. The operating model was.