Why a Technology Decision Keeps Getting Delayed

PayPal's CEO recently spoke about slow decision-making at the company. In an October 20 report, Enrique Lores called for fewer management layers, faster decisions, and clearer accountability.

An owner with 20–200 employees has fewer management layers to contend with, but can reach the same impasse: everyone agrees something needs to change, and the decision goes nowhere. Employees keep working around the problem while leadership discusses the same concerns.

Sometimes the owner has authority to approve the work but lacks a convincing explanation of why a recommendation makes sense. That hesitation is reasonable. A technology decision commits the business to ongoing costs, a way of working, and people it will depend on. Better features alone do little to answer those concerns.

What the recommendations leave unanswered

A provider recommending a new platform may have a good product and a sound explanation of its features. A developer proposing custom software may know how to build something that fits the way the company works. An internal manager may have equally valid reasons for keeping the current system.

The CEO is left to judge recommendations that each sound convincing on their own. The differences between them are hard to see because each one covers a different part of the problem. One includes implementation but leaves ongoing support open. Another preserves the way employees work but commits the company to maintaining custom software. A lower initial price can come with responsibilities the business hasn’t accounted for yet.

An experienced technical adviser can lay those differences side by side and explain why they matter. They can also question the premise of the project. The business may not need a new system at all. It may need a connection between systems it already has, a change to a process, or a repair to something it already owns.

A distribution company we worked with had spent most of a year choosing between a new ERP platform and a custom system a local developer had proposed. Both quotes were substantial, and both had supporters inside the company. When we sat down with the people doing the work, the core problem turned out to be much narrower. Orders were being re-keyed by hand from the e-commerce site into the accounting system, and the errors showed up weeks later as billing disputes. The accounting system itself was serving the business well; what it lacked was a reliable connection to the order system. We recommended building that connection, and the replacement decision came off the table. Staff kept the software they knew, and the re-keying stopped.

Finding that takes familiarity with how systems behave in daily use. A demonstration shows a task completed successfully. The business also needs to know what staff will do when information is incomplete, a connection fails, or the software changes. Hosting, maintenance, and access to company data all belong in the decision, and they’re easy to leave out of an early discussion centered on features.

The CEO should get the benefit of that investigation without having to become the technical reviewer. What they need is a clear explanation of what’s being recommended and why.

A list of options can still leave the hard decision unresolved. Someone providing senior technical judgment has to be willing to recommend an approach, state the assumptions behind it, and say what would change their mind. Sometimes there’s a good reason to choose the smaller project, accept a higher operating cost, or keep a system that’s unfashionable but works.

That recommendation also has to fit what leadership is trying to accomplish, whether that’s cutting administrative work, expanding into a new market, or avoiding disruption during a busy season. Once those priorities are connected to the real alternatives, leadership can weigh whether the improvement justifies the cost and disruption, with someone in the room who can explain the consequences of choosing differently.

Responsibility for what happens afterward

A CEO may agree with a recommendation and still hesitate because nobody has explained who will make it work.

Replacing a system involves staff time, providers, records, and established routines. Details fall between contracts. When two providers disagree about a connection, the owner needs someone who understands the issue and takes responsibility for getting it resolved.

A CTO involved in delivery leads the technical work, manages the people doing it, and handles decisions as the project develops. Leadership gets a clear account of progress and problems, without the CEO having to settle every technical disagreement.

The arrangement must cover daily operation too. Connections require maintenance, providers release changes, and the business develops new requirements. Those responsibilities affect the ongoing cost and belong in the discussion while the investment is being considered.

An owner asking how these arrangements will work is asking a reasonable business question. They might be comfortable with the product and unconvinced that the company has the support needed to use it. Experienced technical leadership helps establish that support and, when included in the engagement, manage it.

There is a limit to what another technical review will resolve. A well-supported recommendation still sits waiting if departments want different outcomes or everyone expects someone else to approve it. Leadership has to settle that disagreement.

Security, financial controls, and contractual obligations also require attention. A review stalls when nobody knows who must answer a concern or how approval will be reached. An outside CTO needs a defined role and enough authority to carry out the work the business expects.

Where outside technical leadership fits

A company with capable staff and providers might need experienced advice on one decision. Another needs someone to take charge of the change. The engagement should reflect that difference.

A one-time consulting assessment examines a specific issue or the business and its technology more broadly, then recommends a direction. An advisory CTO stays involved as decisions arise. A more engaged CTO takes responsibility for agreed outcomes, manages the people and providers, and leads implementation and ongoing operation.

Scale Logic works at those levels alongside existing leadership and staff. The scope establishes what the business needs help with and which responsibilities the technical lead will take on. An assessment does not automatically commit the company to an ongoing engagement.

Waiting has costs of its own. Staff spend time on workarounds, the existing system costs money to operate, and improvements remain out of reach. Postponing a change is sometimes the right decision, particularly when the company needs to protect daily operations. Experienced advice helps leadership weigh that choice against the consequences of continuing as it is.

Lores's call for clearer accountability matters here too. An outside adviser needs to know who makes the decision, and the company needs to know who will carry it through. Adding technical experience helps when it gives those people a sound recommendation and a workable way forward.

If a technology decision has been on the agenda for three meetings, contact Scale Logic to discuss what's holding it up.