Boring technology, deliberately chosen

Dan McKinley wrote "Choose Boring Technology" in 2015, out of what he'd seen at Etsy, and the essay's central device has outlived most of the specific technologies it was arguing about. You get roughly three innovation tokens. Spend one on a new database, that's a token. A new language, a token. A novel deployment model, a token. When they're gone, everything else is PostgreSQL and a queue.

The number is arbitrary and McKinley says so. The scarcity is not.

Boring does not mean old

The most common misreading of this idea is that it's an argument for whatever was popular ten years ago. It isn't. Boring means the failure modes are known, published, and searchable.

PostgreSQL is boring not because it's from 1996 but because when it breaks at 4am you will find a Stack Overflow answer written by someone who had exactly your problem in 2019. Kubernetes is, at this point, arguably boring for the same reason: enormous surface area, but a very large body of people who have already hurt themselves on it and written it down.

Something released last year with two thousand GitHub stars and one company using it in production is exciting. Not because it's bad, possibly it's better than the boring option in every dimension you can measure, but because you will be the person discovering its failure modes, at a time of its choosing.

That's the actual trade. Not old versus new. Known unknowns versus unknown unknowns, priced in outages.

What a token really costs

The cost of adopting an unfamiliar technology is not the adoption. It's everything that follows, and most of it lands on people who weren't in the meeting.

Every new datastore adds a backup story, a restore story that you must actually test, a monitoring story, a capacity model, an upgrade path, and a set of things that only go wrong under load you don't have yet. Every new language adds a build pipeline, a dependency scanner, a formatting argument, a hiring filter, and a group of people who can now only be on-call for part of your system.

None of this appears in the evaluation. Evaluations are done by enthusiastic engineers over a weekend, on a laptop, with no traffic. The run cost arrives eighteen months later and gets attributed to something else.

A useful discipline: when someone proposes a new component, ask who is on call for it and what they'll do when it's down. Not rhetorically. Get a name.

That test has developed a hole, and the AI tooling layer is where you'll fall through it. A name on the pager is worth nothing if the product stops existing. Vendors in this category are being acquired and folded into somebody else's roadmap fast enough that the second question now has to be asked out loud: what happens to this if the company behind it is bought inside twelve months. Whoever is on call cannot maintain a discontinued product, and no amount of operational readiness substitutes for the thing still being there to operate.

The résumé argument, taken seriously

The uncharitable framing is résumé-driven development, and it's a satisfying phrase that has probably damaged more engineering cultures than it's saved.

The engineer proposing the new thing is usually not building their CV. They're bored, or they've hit a genuine limit in the current stack, or they've watched the industry move for three years while their skills sat still, and they're worried about what happens to them if this company ends. That last worry is entirely rational and dismissing it is how you lose good people.

So the answer is not to win the argument. It's to meet the need somewhere it costs less. Internal tooling is a fine place to try an unfamiliar language. So is a genuinely isolated new service with no upstream dependencies. So is a conference budget, a rotation onto the hardest problem you have, or a Friday where someone builds a prototype nobody promises to ship.

What you're protecting is the load-bearing middle of the system. You are not obliged to protect all of it equally.

Where to spend the tokens

The rule follows from the point of a company. Spend them where your product would be worse if you used the standard thing.

If you're building a search product, an unusual search stack is your business. If you're building an accounting tool with search in it, use whatever everyone else uses and go argue about ledgers instead. The tokens go into whatever a customer would notice.

Almost every early-stage company gets this backwards at least once, usually on infrastructure, because infrastructure is legible and fun and the product is ambiguous and hard.

Variety has a new cost

There's a version of this argument that only became true recently, and the old framing misses it.

Agentic tooling looks like a place where variety is cheap. Let people use what they prefer, the reasoning goes, it's basically an editor and everyone is productive in different ways. That was a reasonable position about editors. It isn't one about agents.

The reason is that the valuable part isn't the tool. It's the accumulated context around it: your rules, your patterns, the files that tell an agent how this codebase actually works. Those artefacts are tool-specific. Run four different agentic tools across an engineering org and you're maintaining four sets of them, badly, and nothing an engineer learns about getting good output from one transfers to the person sitting next to them.

Consolidating on a single tool, and genuinely removing the alternatives rather than merely recommending one, is the boring-technology move applied to a category most people assume is exempt from it. What it buys isn't licence savings. It's that patterns, rules and hard-won knowledge circulate instead of pooling inside individuals, and that the context maintenance burden, which almost nobody resources properly even once, gets paid once rather than four times.

I've run both sides of this one.

At CircleCI we consolidated the entire engineering org on Claude Code and removed the alternatives outright. Zed. Cursor. Codex. Windsurf. All of it.

What came back was more cross-pollination of ideas, patterns and rules than any of us expected, and it arrived quickly, because everybody was finally working the same surface.

The other side is a vendor question the innovation-token test doesn't cover.

At Ada we'd chosen Ona as our agentic plane. On 11 June 2026, OpenAI announced it was acquiring them.

Nothing about the original choice was wrong when we made it.

And the test I've spent this lesson describing wouldn't have caught it either, because that test asks whether a technology is well understood and widely operated. It says nothing at all about whether the company behind it will still be independent next quarter.

The cost to us was time. Which is the currency that matters most when a load-bearing component moves underneath you.

So the test needs a second half in this category.

Today's AI market moves very fast, and a load-bearing component has to be very well thought through. That now includes asking what happens to it if the thing underneath gets acquired inside the next twelve months.

The same question belongs in any build-or-buy decision. In AI tooling it has stopped being hypothetical.

When boring is the wrong answer

I used to apply this rule harder than I do now, and the correction came from watching what happens to a stack where nobody has adopted anything for six years.

The dependencies drift out of support. The security scanner starts producing findings that can't be fixed without a major upgrade nobody has budgeted for. Hiring gets harder, and the people you do hire are not the ones you wanted. Worst of all, the engineers who are good enough to work anywhere start leaving, and the ones who stay are the ones who are comfortable, which is a slow and almost invisible way to lower your own bar.

Zero adoption is a decision with compounding costs, exactly like too much adoption. It just fails on a longer timescale, so nobody is blamed for it.

Three more cases where the boring option is genuinely wrong. When the standard technology cannot do the thing (rare, and you should be suspicious of the claim, but real). When the boring thing is itself dying, in which case its known failure modes stop being useful. And when the new technology has become boring while you weren't looking, which happens more often than anyone updates their opinions for.

The practical version

Once a year, write down what your three tokens are being spent on. One page. Circulate it.

The exercise does two things. It makes adoption an explicit decision with a named owner rather than an accretion, and it gives you a clean, unemotional way to say no in March: we've spent them, here's what on, let's talk in January.

Most of the value is in the second one.