Technical Decisions Are Cost Decisions

There is a recurring scene in organisations that have both a technical team and a business leadership team. The engineers propose a solution. Leadership asks how much it will cost and how long it will take. The engineers give a technically accurate answer that doesn’t answer either question. The decision gets made on instinct, or delayed until someone feels confident enough to proceed, or pushed to someone senior who also doesn’t fully understand the trade-offs.

This is not a communication failure. It is a translation failure. And it is far more expensive than it looks.

What the decision actually involves

Every significant technical decision involves a set of trade-offs that are, at their root, financial. The choice between building and buying a component is a choice between one-time development cost plus ongoing maintenance burden versus recurring licence cost plus vendor dependency. The choice between investing in infrastructure automation and continuing to manage things manually is a choice between upfront engineering time and ongoing operational cost plus error rate. The choice between a more complex, scalable architecture and a simpler one that will need rebuilding later is a choice between paying now or paying more later.

These are financial decisions. They belong to the people who are accountable for the business finances. But they are almost never presented in a form those people can evaluate.

The translation problem

The technical framing of a decision is accurate and complete. A senior engineer can describe the trade-offs between two architectural approaches in precise and correct terms. The problem is that the correct terms are not the useful terms for someone who owns the budget and the growth targets.

Useful terms are time, headcount cost, and operational burden. How many months of engineering time does each option require? At what seniority level, and therefore at what cost? What does each option cost to operate per month at current scale? At 10 times current scale? What breaks first under each option, and what does fixing that cost?

These questions have answers. They require some estimation and some uncertainty, but engineers are perfectly capable of producing ranges (“two to four weeks of senior engineer time, depending on integration complexity”) that are far more useful than architectural descriptions.

The translation is not about oversimplifying. It is about finding the form in which the decision becomes genuinely evaluable by the people who have to own the consequences.

What this looked like at AWS

At Amazon Web Services I worked on infrastructure that served enterprise and public sector clients across Europe. The decisions that mattered most were rarely purely technical. They were questions about how to deploy classified infrastructure in a way that met regulatory timelines, or how to reduce the operational overhead that was consuming engineering capacity that should have been going elsewhere.

In one case the team had a provisioning process for new regions that took an engineer three to five days per occurrence. It was manual, documented but fragile, and dependent on tribal knowledge. The technical case for automating it was clear. The business case required different framing: automation would cost approximately six weeks of engineering time, after which the three-to-five-day process would become a four-hour automated run requiring no senior engineer involvement. At the current rate of new region provisioning, the break-even was under four months. After that, the benefit compounded.

That framing made the decision easy. “We should automate the provisioning process because the architecture will scale better” would have produced a different conversation.

The decision belongs to the business

The thing that changes when technical decisions are translated into cost and time terms is not the decision itself. The same trade-offs exist regardless of how they are framed. What changes is who can genuinely participate in making it.

Engineers should not make financial decisions on behalf of the business. Not because they are untrustworthy, but because they are not accountable for the financial consequences in the way that business owners are. The person who owns the P&L has information the engineers don’t have: the competing priorities, the capital position, the strategic bets being made, the constraints that aren’t visible in the technical context.

Good translation means that person can engage with the decision using that information, rather than approving or vetoing something they can’t fully evaluate.

A side effect worth noting

The translation process also has a side effect that compounds over time. When a technical team consistently frames decisions in cost and time terms, the business leadership team starts framing questions the same way. “If we do X commercially, what does that mean technically, and what does that cost?” becomes a normal question instead of an afterthought.

That is a different kind of organisation from one where commercial and technical run on separate tracks and discover their interdependencies at the moment of collision. Getting there requires someone to do the translation work consistently until the habit forms on both sides. It is not a difficult habit to build. It is just one that rarely gets built deliberately.