The exciting new database, the hot language, the framework everyone's tweeting about: they're seductive, and reaching for them is one of the most common ways startups sink their own engineering. Dan McKinley's 2015 essay "Choose Boring Technology" made the case that stuck: novelty is a budget, and most teams blow it in the wrong places.
Key Takeaways
- Every team has roughly three "innovation tokens" to spend on novel technology, and the supply is fixed (Dan McKinley).
- Boring technology (Postgres, MySQL, Cron) is boring because it works, with known failure modes and decades of docs (Dan McKinley).
- Spend your scarce novelty on the product that differentiates you, not the plumbing.
- New tech carries hidden costs: unknown failure modes, thin docs, a small hiring pool.
The Innovation Token
McKinley's central image is the innovation token (Choose Boring Technology). Imagine your company gets about three of them, total, for a long time. Each genuinely new, unproven technology you adopt spends one: a brand-new database, a language nobody on the team knows, a framework that's a year old. Three tokens is not many, and the reason to hoard them is that every token spent on novel infrastructure is a token not spent on the thing that actually makes your business special.
"Boring" in McKinley's sense is a compliment. Postgres, MySQL, cron, a well-worn web framework, these are boring because their capabilities and, crucially, their failure modes are deeply understood (summary). When a boring database breaks at 3am, someone has hit that exact problem before and written it up. When your exciting new datastore breaks, you're debugging alone at the frontier.
Why New Tech Costs More Than It Looks
The appeal of new technology is the shiny feature it does better. The cost is everything you can't see yet. A mature tool has known failure modes, thousands of Stack Overflow answers, battle-tested libraries, and a large pool of engineers who already know it. A new tool has none of that, so you pay for it in outages nobody's seen before, features you have to build yourself, and a hiring pool of dozens instead of thousands. Those costs land later, which is exactly why they're easy to underweight when the tech is new and exciting.
| Boring technology | Exciting new technology |
|---|---|
| Known failure modes | Unknown failure modes |
| Decades of docs + answers | Thin, changing docs |
| Large hiring pool | Tiny hiring pool |
| Predictable | Surprising, often at 3am |
A Concrete Version
A Series A team picks a trendy new database because it benchmarks beautifully for their use case. Six months later they've hit three undocumented edge cases, written their own tooling to work around missing features, and can't find anyone to hire who's used it. The exciting database became a full-time job. A boring Postgres setup would have handled their actual scale for years and freed that engineering time for the product. They spent an innovation token on plumbing and had none left for the thing customers pay for.
The Honest Counterpoint
Boring by default does not mean never innovate, and a company that only ever picks the safe option builds nothing new. The point is deliberate spending. Sometimes the new technology is the product, or it solves a problem that's genuinely core to your differentiation and boring tools truly can't, and then spending a token is exactly right. McKinley's rule is simply this: know you only get about three, so spend them where novelty wins you the business, not on infrastructure a boring tool would handle fine.
What This Means for Teams
Choosing boring technology is a mark of engineering judgment, the same wisdom about what not to do that shows up in resisting premature microservices and big rewrites. Senior engineers who've been burned by a trendy choice tend to reach for the boring, reliable option and save the team months. That judgment about where to spend novelty is exactly what we screen for in how to verify a senior engineer. See available engineers.
Frequently Asked Questions
What does "choose boring technology" mean?
Dan McKinley's argument that teams should default to familiar, well-established tools (like Postgres or cron) and save novelty for where it truly differentiates the business, because every team has only a few "innovation tokens."
What is an innovation token?
A metaphor for your limited budget of novel technology choices, roughly three per company. Each unproven tool you adopt spends one. The point is to spend them on your product, not your infrastructure.
Why is boring technology better?
Because its capabilities and failure modes are deeply understood, with decades of documentation, battle-tested libraries, and a large hiring pool. New tech carries hidden costs that surface later, often as outages nobody has seen before.
When should I use new technology?
When the novelty is core to your differentiation and boring tools genuinely can't do the job. Spend an innovation token deliberately, where it wins you the business, not on plumbing a mature tool would handle.
The Bottom Line
Novelty is a budget, and most teams blow it on infrastructure. Dan McKinley's innovation-token idea is a discipline: default to boring, well-understood technology for the plumbing, and save your few tokens for the product that actually differentiates you. Boring tools are boring because they work, and that reliability is worth more than the thrill of the new.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
