The CEO Tech Stack Trap / Rob Urban
Before buying software, name the decision it cannot make.
A system can route an approval. Leadership still has to decide who is allowed to approve what.
That distinction sounds obvious until a company spends six months implementing a platform to resolve an argument nobody wanted to have in the first meeting.
A software complaint is a useful starting point.
“The CRM is terrible.” Perhaps it is. Perhaps the sales team cannot find information, the system loses work or a routine task takes twenty unnecessary steps. Replacing it may be sensible.
But the same complaint can conceal a different problem. Nobody agrees on when an inquiry becomes an opportunity. Two managers give different discount instructions. Delivery learns about a promise only after the customer has accepted it. Those are operating decisions with a software interface attached.
I would ask the people doing the work to show me the failure. Not a presentation about the platform. One actual task, from the request arriving to somebody being able to finish it. Where does it wait? What information is missing? Who makes the exception? Which part would still be unresolved in a better application?
Fictional example / A distributor’s quote queue
The quote is waiting for an answer, not an app.
Imagine a distributor where quotes routinely sit with a sales manager. Leadership wants an automated quoting system. The proposed benefit is faster turnaround, but nobody has separated the cases in the queue.
Routine quote
Current price, available product, ordinary terms. If staff are retyping the same details, automation may remove useful work. First establish where the authoritative information lives and how errors are caught.
Commercial exception
The buyer wants a discount outside the usual range. The software can send a notification. It cannot settle the disagreement between sales and finance about acceptable margin.
Missing information
The request lacks a product specification. Sending it faster to three departments does not make it complete. Better intake questions may prevent the delay earlier.
Unavailable reviewer
Only one manager may approve the exception, and that manager is traveling. A defined deputy or revised approval authority may matter more than another reminder.
The investigation could still justify new software. It would produce a much better brief: automate routine quotes from verified data, route exceptions under agreed rules and make missing information visible. The purchase now has a defined job.
Ask for the ordinary Tuesday demonstration.
A vendor demonstration shows that a capability exists under the conditions presented. Your evaluation needs to show whether it helps your people with the work they actually receive.
Bring an ordinary case, an incomplete case and an exception. Ask the proposed users to follow each one. Watch the handoffs, corrections and recovery steps. If the demonstration requires perfectly prepared information your company never has, record the preparation work as part of the project.
Include the current system in the comparison. Could a clearer rule, a configuration repair or a simpler form address the main problem? Keeping an unsuitable platform indefinitely is expensive. Replacing a suitable one because nobody configured it properly can be expensive too.
Do not require every process to become perfect before improving the technology. Some systems genuinely prevent sensible working practices. The useful question is which operational change and technical change must happen together.
The license is the easiest cost to find.
Budget for the work needed to make the proposed system usable: data preparation, configuration, integration, training, migration, review, support and the period when old and new processes overlap.
Separate cash spending from internal effort. Both matter, but reclaimed employee time is not automatically a cash saving. The benefit might be faster response, additional capacity or less frustration. Name it honestly.
A twenty-minute saving spread across interrupted days can be harder to use than a full day removed from a recurring task. Ask employees what the change would let them complete. That conversation can improve the business case more than assigning a larger hourly rate.
Write the purchase case in sentences people can challenge.
Bring this to the decision meeting
- The problem: which recurring task fails, for whom and with what consequence?
- The operating change: which rule, responsibility or handoff must change?
- The capability gap: what can the current setup not reasonably provide?
- The evidence: which representative cases show the proposed approach works?
- The commitment: who supplies time, information, training and ongoing ownership?
- The review: which outcome would justify continuing, changing direction or stopping?
Leave unresolved questions visible. A candid “we have not established that yet” is more useful than a confident number assembled to win approval.
If AI is part of the proposal, my AI pilot approval guide goes deeper into the experiment and its evidence. If the concern is dependence on a provider, the AI vendor exit guide addresses continuity and a usable handoff.
This article concerns the buying decision before a commitment. Auditing a large existing stack for overlapping subscriptions is a separate assignment. Do not cancel a lightly used system until you understand the business obligation or dependency it serves.
Questions the sponsor should be comfortable asking
Does low adoption mean we bought the wrong software?
It is evidence to investigate. Adoption can be affected by poor fit, weak training, conflicting incentives, duplicate work or a process nobody agreed to follow. Examine the task and the reasons people avoid the system before choosing the remedy.
Should we keep a manual process instead?
Sometimes, particularly for infrequent work or unresolved exceptions. Manual work has costs and risks too. Compare the actual alternatives, including a simpler process and a better use of existing capabilities.
What should the executive own after approval?
The intended business outcome, the operating decisions and the assignment of accountable owners. Technical specialists should own their technical responsibilities. A sponsor cannot delegate the business purpose to a vendor and expect implementation to discover it.