The case for boring technology in regulated industries

One of our principles is “boring technology,” and prospective clients occasionally read it as a lack of ambition. It is the opposite. Choosing boring technology is the most ambitious thing an engineering organisation in a regulated industry can do, because it is a bet that your differentiation lives in your product — not in your infrastructure’s novelty.

Innovation tokens are real, and audits tax them

Dan McKinley’s framing is now twenty years of folk wisdom old: every company gets a small number of innovation tokens, and most teams spend them on infrastructure nobody asked about. In a regulated environment the exchange rate is worse, because every novel component is something you must now explain — to your auditor, your regulator, your operational resilience review, and the unlucky engineer holding the pager at 3am.

PostgreSQL has thirty years of documented failure modes. The exciting new database has a Discord. When an FCA-regulated firm asks us to assess its third-party risk, “our ledger depends on a database whose company is two funding rounds old” is a finding. Not because the database is bad — it may be excellent — but because nobody can yet know how it fails, and regulated industries run on known failure modes.

Boring is a property of knowledge, not age

The distinction worth making: boring does not mean old, and it certainly does not mean bad. It means the failure modes are catalogued. Kubernetes was exotic in 2016; it is boring now — not because it stopped evolving but because a decade of production incidents at every scale has been written down, conference-talked, and runbooked. Go is boring. Kafka is boring. Terraform is boring. This is the highest compliment we pay technology.

The corollary: you can make a boring choice exciting by using it in an exotic way. A PostgreSQL schema only one person understands is not boring technology; it is novel technology wearing a reassuring logo.

Where we do spend the tokens

Spending zero tokens is its own failure mode — the estate full of ten-year-old Jenkins jobs is not boring, it is neglected. The discipline is spending tokens where novelty buys a measurable outcome. Policy-as-code was a token we spent early: OPA was young when we first deployed it in a bank, but it converted weeks of manual change control into milliseconds of pipeline time — a return worth explaining to an auditor. That is the test. Not “is it interesting?” but “is the outcome worth the explanation?”

The compounding payoff

Boring estates compound quietly: hiring is easier because the skills are common; incidents are shorter because the answers are searchable; audits are calmer because the components are known quantities; and senior engineers spend their judgement on the problems that are genuinely yours — your domain, your data, your risks — rather than on debugging the infrastructure’s adolescence.

Excitement is a cost. Pay it only where it buys something.