Why Organizations Keep Buying Software for Systems Problems
When work goes wrong, organizations tend to make a procurement decision where a design decision was needed, because only one of the two fits through the process that has to approve it.
The pattern
The story usually begins when someone notices the work is slow. Requests sit, handoffs stall, and nobody can say where anything is without asking three people. There's a whole category of software built for exactly this, so the organization evaluates vendors, picks one, and rolls it out.
The rollout finishes on schedule and the work is still slow, only now it's slow inside a better interface, with more reporting available about the slowness and a line item to pay for it. The constraint didn't move, because it was never in the tool.
What comes next is what makes the pattern self-sustaining. Nobody concludes the purchase was wrong. The conclusion is that the implementation was incomplete, or the configuration needs work, or adoption is lagging, and each of those comes with a remedy that costs more money and commits the organization a little further to the original diagnosis. Two years later the same complaint turns up in the same words, and it's met by replacing the tool, on the reasoning that the last vendor underdelivered.
A purchase is legible. A redesign is not.
The people making this decision are usually smart, and they're usually right about the symptom. What trips them up is the narrow set of things an organization is structurally able to approve.
A software purchase comes with a price, a date, a vendor, an owner and a comparison matrix, and it can be defended in a meeting by someone who wasn't in the room when the problem was found. A systems redesign starts in ambiguity. There's no vendor, no fixed scope and no obvious owner, and the first honest answer to what it'll cost is that nobody knows yet.
Put those two side by side and an organization will approve the one it can describe. There's nothing cynical in the substitution and it's rarely even conscious, it's simply the only option of the two that fits through the process.
The asymmetry is personal, too. A manager who buys a well-reviewed platform and gets a disappointing result has made a defensible decision that didn't work out, and the vendor absorbs most of the blame. Someone who proposes changing how approvals work, and turns out to be wrong, has spent political capital on their own judgment in front of the very people whose authority was being rearranged. The expected value calculation isn't close, and it doesn't depend at all on which option actually had the better chance of working.
What the purchase does buy is motion: rollout plans, training sessions, a migration, a steering committee, a launch date. All of it is real work done by capable people, and all of it can be measured, which is why it feels so much like progress.
None of that activity changes how the work moves, though, because none of it touched the place where the work was stalling.
The loss lives at the seams
In the operations I've traced, the recoverable loss has sat between functions, at intake, handoff, approval, exception and review, the points where responsibility changes hands and nobody owns the transition.
Inside a function, people are usually competent and the work moves along. At the seam, ownership is ambiguous and status is inconsistent, so the work waits for someone to notice it, and that waiting is invisible in every functional report because no function is failing.
Software gets bought by function, and since seams belong to nobody, nobody procures for them.
The way procurement runs makes this worse than it needs to be. Requirements are gathered from each function, so the specification that comes out is a union of what each side of the seam wants, with the seam itself represented by nobody. Each function then configures the system to suit its own half. The handoff ends up implemented twice, slightly differently, and the gap between the two versions becomes a new category of exception that somebody handles by hand.
The tool inherits the arrangement
A platform arrives with defaults, and nobody's operating model comes in the box. Those defaults get configured to match how the organization already works, because that's the fastest path to adoption and the least disruptive for the people being asked to change.
So the broken handoff is faithfully reproduced in the new system, now with better logging, and the organization has paid to encode the very arrangement it was trying to escape.
A dashboard that reports on a broken handoff gives you a more legible version of the same loss.
There's a particular irony in how this happens. Most platforms ship with an opinionated default flow that embodies a reasonable design, often a better one than the customer is running now. The configuration phase is where that opinion gets removed, one exception at a time, each justified by a real local circumstance, until the system matches the organization exactly. The customization budget goes into reproducing the problem, and the finished configuration is then too specific to upgrade cheaply.
Visibility is the most common version of this and the hardest to argue with, because it's genuinely useful and it really does feel like the thing. Knowing precisely how long work waits at a handoff, in real time, on a screen, turns an unmeasured problem into a measured one, which is worth doing, though the wait is exactly as long as it was yesterday.
What the diagnosis looks like
I spent time on marketing operations reporting at Adobe, across roughly six billion dollars of marketing spend. The complaint was turnaround: reports arrived too late to be useful for the decisions they were supposed to inform, which is the kind of complaint that points straight at a reporting tool.
The intervention involved no new category of software. The reporting and the data flow underneath it were restructured around the decisions they actually fed, which removed most of the manual assembly sitting between the data and the decision. Turnaround fell by 86 percent. The number was the less interesting part, though. What mattered was that the constraint turned out to be the shape of the flow rather than the capability of the tool, and no vendor evaluation would have surfaced that.
It's worth noticing what a vendor evaluation would have surfaced instead. Every serious reporting product on the market could have produced those reports faster than the incumbent, and a comparison matrix would have shown exactly that, accurately. The evaluation would have been right about a step that wasn't the constraint, with no mechanism for finding that out, because a vendor comparison takes the shape of the problem as given.
The alternative
The alternative to buying first is a diagnosis, and a diagnosis is cheap. Trace one real unit of work from arrival to completion, and the distance between the documented path and the one it actually took is your design brief. In my experience it's almost never a feature gap.
The cost comparison isn't close, which is the part that should make this easy and somehow doesn't. A trace is one person for a week or two, where an enterprise platform decision is a year of committed spend and a multi-year contract. The diagnosis is cheap enough to run before every significant purchase and it's almost never run, because it sits before the point where a budget exists, and there's no process for funding the work that decides what should be funded.
What that diagnosis actually involves
When the purchase is right
Sometimes the constraint really is capability. The work is designed well, the seams are owned, and the organization is genuinely held back by not having something it could buy, and in those cases buying is fast and correct and the rollout does exactly what rollouts are supposed to do.
The test is whether anyone traced the work first. An organization that does the diagnosis and then buys software is making a design decision, while one that buys first is making a procurement decision and hoping it turns into one.
If this describes an operation you’re responsible for, the diagnostic is where that conversation starts.
How engagements begin
