Economies of Speed

Digital organisations win by how quickly they can learn and change, not by how big they are.

Digital organisations win by delivering and learning in small, frequent steps, not by waiting to release at scale.

To an executive

Size no longer guarantees an edge. Whoever turns ideas into customer value fastest tends to win, so approvals and shared processes that save money may cost more in lost time.

To an engineer

Measure how long an idea takes to reach production and find where it waits. Favour small, frequent releases and remove hand-offs and approvals that add delay.

The idea

Traditional enterprises are built for economies of scale: standardise, centralise, and spread cost across volume. Hohpe argues that much of IT is still optimised this way, while digital competitors play a different game, economies of speed, where the ability to deliver and learn quickly dominates. He notes that the transition between the two is a difficult one.

Optimisations for scale, such as lengthy procurement, central approvals and shared everything, often directly slow an organisation down. Digital rivals are often not slightly faster but an order of magnitude faster. Architects must know which game they are playing in each area.

Why it works

Uncertainty rewards learning. When you do not know what customers want, the organisation that runs the most experiments learns fastest. Speed of feedback beats cost per unit.

Waiting dominates lead time. Much of the time between idea and production is spent queuing for approvals, environments or other teams, not working. Removing waits speeds things up far more than making each activity more efficient.

Scale optimisations have hidden costs. Centralising and de-duplicating save money that is easy to see, while the delay they add is spread across every change and rarely measured.

Slow decisions are poor decisions. In a fast-moving market, a decision that takes months can be wrong by the time it is made.

Where it applies

Cloud and platform strategy, where the real benefit is often speed rather than cost.
Governance and approval processes designed for a slower era.
Procurement and sourcing, where long contracts trade flexibility for a lower unit price.
Shared services, where a central team becomes a queue that every project waits in.

How to apply

Measure lead time and feedback speed alongside cost, so the price of delay becomes visible.
Map where work waits, not just where it is done, and remove the longest waits first.
Automate governance so control is built into pipelines rather than imposed through tickets and meetings.
Use cloud and platforms to buy speed, and judge them on how fast teams can change, not only on the bill.
Keep scale where it pays, and say explicitly which areas play which game.

Example scenario

A bank signed a cheaper long-term hosting contract that required six-week change requests for new environments. A fintech rival could create environments in minutes and was shipping monthly features that took the bank a year.

The bank's architects showed leadership the cost of the waiting, not just the hosting bill. New products moved to self-service cloud environments with automated policy checks, while the stable core stayed on the existing contract. Lead time for the new products fell from months to weeks.

Questions to ask

In this area, are we optimising for scale or for speed, and did we choose that on purpose?
How long does it take an idea to reach production here, and where does it wait?
Which cost saving is quietly adding weeks to every change?

When not to use it

Commodity, high-volume workloads, where unit cost really is the deciding factor and change is rare.
Regulated core processing, where stability and control matter more than how fast it changes.

How it misleads you

Ignoring scale where it genuinely matters, such as regulated core processing or high-volume commodity workloads. Speed is also not the same as haste: moving fast without fast feedback just produces mistakes faster.