The HŪMNZ Element: Issue 35 - The Software Every CEO Buys Twice

The first tool was going to fix the handoff. The second was chosen properly. Neither worked, for the same reason.

Author

Tim Dennis
October 13, 2026

💡 Editor's Note

Almost every growing company buys the same thing twice.

The first tool was going to fix the handoff between sales and operations. It didn't. Eighteen months later a better one was chosen — demo, scoring matrix, reference calls, the full process.

That one didn't fix it either.

Nobody buys the same thing twice on purpose. It happens when the thing being bought was never the problem.

Before the next tool goes on the roadmap, find out where the work is actually stuck.

Five questions, 90 seconds, a read on your own operation straight away. No call to book, no gate.

Executive Brief

Bottom line: Software bought to fix a process inherits the process. Skip the redesign, and the second purchase fails for the same reason the first one did.

Michael Hammer made this case in Harvard Business Review in 1990, under a title that outlasted almost everything else written about technology that decade: Don't Automate, Obliterate. Companies were spending heavily on technology and getting nothing back, because they were speeding up work that should not have existed.

Automate a broken handoff and you own a faster broken handoff. You also own a harder one to see, because now it has a dashboard.

Thirty-six years on, the budget moved from projects to monthly subscriptions. The failure mode didn't move at all.

In 30 seconds

  • A tool cannot fix a process nobody designed. It runs that process faster and hides it behind an interface.

  • Before the next purchase, answer two questions in writing: what outcome should this work produce, and who owns it. Software supports those answers. It cannot supply them.

  • 36% of software licenses go unused. That is what buying ahead of a decision looks like on an invoice.

  • If you cannot name the person accountable for the process, you are not buying software. You are buying a place to put the problem.

⚠️ Four signals leaders should be watching this week

1. Why doesn't the second tool fix it either?

Signal: The post-mortem on the first tool concludes it was the wrong tool.

Evidence: Hammer's 1990 argument was that technology laid over an existing process leaves the design intact. The job definitions, handoffs and approvals all survive. Speed changes. Shape doesn't.

Implication: If the first tool failed because the process was never designed, the second is being selected against the same undiagnosed problem. A rigorous evaluation aimed at nothing is still aimed at nothing.

Action: Before shortlisting anything, write down what the process actually is — not what the org chart says. Usually that document is the deliverable, and the software question answers itself.

2. What has to be true before you buy anything?

Signal: The requirements document lists features, not outcomes.

Evidence: Two of Hammer's redesign principles do most of the work here: organize around outcomes rather than tasks, and capture information once at its source. Both are decisions about how work is arranged. Neither can be bought.

Implication: A feature list describes what a vendor built. An outcome describes what you need to happen. Swap one for the other and you end up comparing products that solve slightly different problems, none of them yours.

Action: Replace the feature list with one sentence: "This is done when ___ happens, without ___ having to chase it." If that sentence is hard to write, the process is the problem.

3. Why does the stack keep changing without improving?

Signal: The number of tools stays flat, so the spend looks controlled.

Evidence: Zylo's 2026 SaaS Management Index, published in January and drawn from more than 40 million licenses, found application counts roughly flat year over year even as organizations kept adding tools. The stack isn't growing. It's churning.

Implication: Flat tool counts look like discipline and are often the opposite — a steady cycle of replacing software that disappointed with software that will. Nothing accumulates except switching cost and retraining.

Action: List what you replaced in the last three years and the problem each replacement was meant to solve. Anything that appears twice is a process issue in a procurement costume.

4. Who is actually making this purchase?

Signal: The tool is bought by the department that complained loudest.

Evidence: Another Hammer principle: put the decision where the work happens, and build the control into the process rather than bolting it on. Departmental buying does the reverse. It routes around a process nobody owns instead of assigning the ownership.

Implication: Whoever feels the pain is rarely whoever can fix it. A purchase made by the first group quiets a symptom, which is why it works for about a quarter.

Action: For the next tool anyone asks for, name the person accountable for the process before you approve the budget. If that name doesn't exist, create it instead of buying anything.

Stat of the Week

36%

The average share of software licenses left unused, in Zylo's 2026 SaaS Management Index, published January 2026 across more than 40 million licenses and $75 billion in managed spend.

More than a third of what gets bought is never opened. That isn't a negotiation problem.

Sources: Michael Hammer, "Reengineering Work: Don't Automate, Obliterate," Harvard Business Review, July–August 1990. Zylo, 2026 SaaS Management Index, January 2026.

The Core Question

Software is attractive in a way process work never is. It has a start date, a price, a vendor who returns calls, and a demo showing the problem already solved.

Redesigning the work has none of that. No launch, no logo, nobody to blame if it stalls. It is also the only one of the two that changes the outcome.

If this tool arrived tomorrow and worked perfectly, who would have to change how they work — and have we told them?

The VALŪE lens: A stack bought to cover undocumented process is a cost line that grows every year and a question you can't answer in diligence. The same work done properly once produces a lower bill and a business somebody else could run.

The second purchase is rarely a buying mistake. It is the first diagnosis arriving late.

Know a CEO about to approve another tool? Send this on.

Until next time,

The HŪMNZ Element — Weekly Pulse

If this was useful, forward it to one person: a CEO with a software renewal coming up, or whoever signs them.