Dan McKinley’s Choose Boring Technology is one of the best essays on engineering decision-making. The core argument: every company has a limited innovation budget and you should spend it on things that differentiate your business, not on replacing Postgres with something newer.
It’s good advice. But in high-stakes systems (payments, infrastructure, anything where failure has real consequences) the argument is even stronger. And the failure modes are different.
When failure is expensive
Most software fails gracefully. A bug in a content app means someone sees the wrong thumbnail. Annoying, fixable, forgettable.
High-stakes systems don’t get that luxury. A bug in a payment system might mean money moves to the wrong place. A bug in infrastructure might take down dependent services. A bug in a trading system might mean positions you can’t unwind.
The cost of failure changes how you think about technology choices.
Boring technology fails predictably
The best thing about boring technology isn’t that it doesn’t fail. Everything fails. The best thing is that it fails in ways people have seen before.
Postgres has failure modes. But they’re documented. Teams have hit them, written about them, built tooling around them. When something goes wrong at 3am, you’re not the first person to debug it.
New technology fails in new ways. The documentation doesn’t cover your edge case because no one has hit it yet. The failure mode isn’t in anyone’s mental model. You’re exploring unknown territory during an incident.
In high-stakes systems, novel failures are the most dangerous kind.
The ops burden compounds
Every technology in your stack has an ops surface area. Monitoring, alerting, backup, recovery, upgrades, security patches. Someone has to understand how it works well enough to fix it when it breaks.
Boring technology has smaller ops surface area. Not because it’s simpler, but because the problems are solved. The runbooks exist. The dashboards are standardized. The failure patterns are known.
New technology adds ops burden that scales with unfamiliarity. You’re not just running the thing, you’re also learning how to run it. In high-stakes systems, that learning often happens during incidents.
The team dimension
Boring technology is hireable. Most experienced engineers have used Postgres, Redis, Linux. They can be productive quickly. They have intuitions about failure modes.
New technology requires ramp-up. Sometimes that’s worth it. But in high-stakes systems, the cost of someone not understanding how something works is higher. The blast radius of inexperience is larger.
This doesn’t mean never adopt new things. It means the bar should be higher and you should be honest about the knowledge gap you’re creating.
When new technology is worth it
The boring technology argument isn’t “never use new things.” It’s “have a good reason.”
Sometimes new technology genuinely solves a problem boring technology can’t. Sometimes the performance characteristics matter enough. Sometimes the old thing is actually end-of-life and the risk of staying is higher than the risk of moving.
The question is whether you’re adopting something because it solves a real problem, or because it’s interesting.
In high-stakes systems, interesting is not a good enough reason.
The compounding effect
Here’s the thing about boring technology: the benefits compound over time.
Year one, you’re slightly less productive because you didn’t use the hot new thing. Year three, you have a system that’s stable, understood and maintainable. Your on-call rotations are calmer. Your incident retrospectives are shorter. Your new hires are productive faster.
The teams running the most reliable high-stakes systems aren’t usually using the newest technology. They’re using well-understood technology, operated well.
The bottom line
McKinley’s essay frames boring technology as an innovation budget problem. In high-stakes systems, it’s also a risk management problem.
Novel technology introduces novel failure modes. Novel failure modes are hardest to debug, hardest to recover from and most likely to cause cascading problems. When the cost of failure is high, predictable failures are a feature.
Boring technology isn’t about being conservative. It’s about choosing where to take risk. In high-stakes systems, the technology stack usually isn’t where you want to be taking it.