Early in my career I judged technical decisions by how clever they made me feel in the design review. Eight years and four companies later, the metric I actually trust is duller: how does this decision look at 2 a.m., eighteen months from now, when the person dealing with it isn't me?
By that metric, boring wins with embarrassing consistency.
The relational database beats the fashionable store you'd never run before. The queue everyone on the team already understands beats the one with the better benchmark. The synchronous call you can reason about beats the elegant event choreography that turns "what happened?" into a research project. Not always — but often enough that the burden of proof should sit on the interesting option, and in most rooms it sits on the boring one instead.
Dan McKinley wrote the canonical piece on this years ago — his framing is that you get a small number of innovation tokens, and you should spend them where you genuinely need the novelty. What I'd add after some time in platform work is why the tokens are so scarce: the price of an interesting choice isn't paid at build time. It's paid in operations, and operations is compound interest. Every exotic component is a separate on-call runbook, a separate upgrade treadmill, a separate thing the new hire has to learn before they can be trusted with a pager. None of those costs show up in the demo.
Two clarifications, because "choose boring" gets misread as "never change anything":
Boring is not the same as old. A crusty internal framework that nobody understands is not boring — it's exciting in the worst way. Boring means predictable failure modes. Postgres is boring because when it breaks, the answer is usually on the first page of results, written by someone who broke it the same way in 2016. That's the property you're buying.
Some problems deserve a token. The whole point of hoarding novelty is having it available when the problem is genuinely new. Right now, in AI infrastructure, some problems really are — nobody has ten years of runbooks for multi-agent systems. So spend there, deliberately. And then surround that one interesting bet with the most boring architecture you can stomach, so that when the novel part misbehaves (it will), it's the only suspect in the room.
The hard part isn't knowing any of this. Everyone nods at it. The hard part is that boring decisions are socially expensive: nobody gets a conference talk out of "we used the obvious thing and it worked." Choosing dull technology means accepting that the value you added will be invisible precisely when it's working — which, if you think about it, is the job description of infrastructure.
I've made systems worse by being interesting. I don't think I've ever made one worse by being careful. That asymmetry took me the better part of a decade to believe, and it's the closest thing to a career lesson I can offer: correctness and performance outlast whatever the architecture of the year happens to be. Save the excitement for problems that have earned it.