Most technology problems are decision problems
A client came to me a while ago wanting to move off AWS onto Azure. They’d already settled it before we spoke: the bill was too high, Azure looked cheaper, so the plan was to switch, and what they wanted from me was help with the migration.
We didn’t do the migration. They stayed on AWS and cut their bill by about forty per cent, with no loss of functionality and far better control over what they were running.
The bill was a symptom
When I looked at their estate, the cost was a symptom. Underneath it, nobody owned anything. There were no principles for how teams used AWS, no standards for how they deployed, none for security, and nothing governing how data moved in and out, which on AWS is a large part of the bill on its own. Services were duplicated across teams because no one could see what already existed. There was no shared practice on efficiency or FinOps, no accountability for spend, and no one who could tell you which part of the estate was theirs. The high bill was the visible side of an ownership problem, and no amount of supplier-switching would have touched it.
Moving suppliers would have moved the mess
Going to Azure would have carried all of that to a new provider, unchanged, and charged them a painful migration for the privilege, because the mess would have travelled with them. What they’d framed as a decision about cloud suppliers was really a decision they hadn’t made at all: who owns what, and how do we keep control of it.
Fixing what was actually wrong
Getting there took some work, because they’d arrived with the answer already written. I ran workshops to surface the real drivers rather than debate the solution they’d walked in with. That distinction matters. If you accept the solution someone hands you, you spend your time validating a plan instead of understanding the problem. Once we were talking about the actual problem, the case for switching fell apart on its own.
From there the work was structural. We took the quick wins first, an architecture review and some rightsizing, to get costs down and earn a bit of credibility. Then we built an ownership model that lived in two places at once: in the organisation and in AWS itself. A platform team acted as an enabling team, handing defined areas of the estate to product teams who could use them with real autonomy, but inside clear guardrails on spend and standards so that control didn’t drift. We wrote the guidelines that spelled those guardrails out, and we set up forums where teams kept improving the whole thing rather than letting it set hard. A few months, start to finish.
Most failures are decision failures
The specifics were theirs, but I’ve come to think the pattern is general. Organisations rarely fail for lack of engineering skill. The people are usually capable and the technology usually works. They fail on decisions: ones that never get made, ones no one owns, ones made once and never looked at again when the facts change. The AWS bill was all three at the same time. Nobody had decided how the estate should be governed, nobody owned the parts of it, and the single decision that had been made, that they were too expensive and should switch, had never been tested against the evidence.
I’ve seen versions of this everywhere I’ve worked. A team argues for months about which framework to adopt when the real question is whether the project should exist. Elsewhere a deadline slips again and again and everyone blames estimation, when no one has actually decided what’s in scope. A system gets called a technical mess when what’s missing is one person accountable for its direction. The engineering is real and so is the frustration, but the thing that’s stuck is a decision rather than a piece of code.
What good decision-making looks like
This is why I think about technology leadership as, for the most part, the work of making decisions well: what to build, what to stop, who to trust, and when to change course. Not only the big strategic calls, though those matter, but the ordinary discipline of noticing which decisions haven’t been made, naming them, giving them an owner, and revisiting them when the ground shifts. Most of what gets called technical debt or delivery trouble is a decision no one made, or made once and forgot to revisit.
None of this is hard to describe, though it takes discipline to hold. It starts with separating the problem from the first solution anyone proposes. Ownership has to be explicit, so that every significant part of the system has someone accountable for it. Guardrails let people move quickly without moving in dangerous directions. And decisions need to stay open to review, because one that was right last year can be the reason you’re stuck this year.
The client who wanted to leave AWS didn’t need a new supplier. They needed to decide who owned their estate and how it would be run. Once that was settled, and settled properly, the bill took care of itself.
So when you start working on something that looks technical, find the decision missing underneath it before you reach for a technical fix. More often than not that is the actual problem, and the technology was only ever the symptom.