When a transformation programme stalls, the post-mortem usually names a technology. The platform was wrong, the integration was harder than expected, the vendor underdelivered. Occasionally that is true. More often the technology was a symptom.
The actual constraint
Delivery speed is governed by how quickly a decision can be made and how many people can block it. A team that ships weekly and a team that ships twice a year frequently use the same stack. The difference is upstream.
Signals worth watching
- How long from identifying a change to someone being allowed to start it.
- How many approvals a reversible decision requires.
- Whether the people closest to the problem can choose the solution.
Separate reversible from irreversible
Most organisations apply one approval process to every decision. That makes irreversible choices appropriately careful and reversible ones absurdly expensive.
Reversible decisions should be delegated and made quickly. Irreversible ones deserve the committee. Treating them identically is how a two-week change becomes a two-quarter change.
What technology genuinely contributes
Good architecture widens the set of decisions that are reversible. Feature flags, decoupled services, migrations that run both ways — each converts a one-way door into a two-way one, and the governance can then be lighter without being reckless.
That is the honest case for engineering quality in a transformation: not elegance, but optionality.
Where we would start
Pick one workflow that matters, measure the elapsed time from idea to production, and find where the waiting actually happens. It is almost never in the writing of the code.
