Every few months, a new framework, database, or orchestration tool arrives with the promise of solving all your problems. The pitch is always compelling: faster development, better scalability, cleaner abstractions. The conference talks are inspiring. The blog posts are persuasive. And the teams that chase these promises consistently spend more time fighting their tools than building their product.
I've watched this pattern repeat across dozens of organizations. A team adopts a cutting-edge data store because the benchmarks look incredible. Six months later, they're the only company at their scale running it in production, they've hit three undocumented failure modes, and their best engineer spends half their time operating infrastructure instead of shipping features. Meanwhile, the team down the hall, running PostgreSQL and a straightforward deployment pipeline, has shipped twice as much with half the headcount.
The difference isn't talent. It's technology selection.
Innovation Tokens
Dan McKinley articulated this idea better than anyone: every team has a limited number of innovation tokens. These tokens represent the total budget of complexity, risk, and learning curve your organization can absorb at any given time. They are finite. They are precious. And most teams spend them on the wrong things.
Your innovation tokens should go toward your core business differentiator. If you're building a real-time bidding platform, spend your tokens on the bidding engine. If you're building a machine learning product, spend them on the model pipeline. If you're building a logistics platform, spend them on route optimization.
Do not spend your innovation tokens on your database. Do not spend them on your deployment pipeline. Do not spend them on your message queue. These are solved problems. Pick the boring, well-understood option and move on. The companies that win are the ones that channel their capacity for complexity into the things that actually differentiate them in the market.
Think of it like a budget. You wouldn't spend 80% of your engineering budget on a custom-built office chair when you need to ship a product. Yet teams routinely burn their complexity budget on infrastructure decisions that have perfectly good off-the-shelf answers, leaving nothing for the problems that actually require original thinking.
The Hidden Cost of New
New technology carries costs that don't show up in benchmarks or feature comparisons. These costs are real, they compound over time, and they are almost always underestimated.
- Fewer people know it. Your hiring pool shrinks. Onboarding takes longer. When the person who set it up leaves, institutional knowledge walks out the door.
- Fewer production war stories exist. When you hit a problem at 2 AM, there's no Stack Overflow answer. There's no blog post from a company that hit the same issue at scale. You're the one writing the war story, in real time, during an outage.
- Documentation has gaps. New tools are documented for the happy path. The edge cases, the failure modes, the operational gotchas -- those only get documented after enough people have suffered through them.
- Edge cases are undiscovered. Software that's been running in production at thousands of companies for a decade has had its sharp edges filed down. Software released last year has sharp edges nobody has found yet.
When you adopt new technology, you're paying for someone else's learning curve with your uptime. That's a trade you should make deliberately, not accidentally.
What Boring Actually Means
Boring doesn't mean old. It doesn't mean bad. It doesn't mean lacking in capability. Boring means well-understood. It means battle-tested. It means the failure modes are known, and the solutions to those failure modes are also known.
PostgreSQL is boring. It's also one of the most capable databases ever built. It handles JSON, full-text search, geospatial queries, time-series data, and pub/sub. Teams reach for specialized databases to solve problems that PostgreSQL has solved for years.
Linux is boring. It runs virtually everything. Nginx is boring. It serves a significant portion of the internet. REST APIs are boring. They're understood by every developer on earth. These technologies aren't exciting at conferences, but they are exceptional in production.
Boring technology gives you predictability. You know how it breaks. You know how to fix it. You know how to scale it. You know how to hire people who can operate it. That predictability is not a limitation. It's a competitive advantage. While your competitor is debugging a novel distributed systems issue in their cutting-edge data store, you're shipping features.
When to Choose Exciting
This isn't an argument against ever adopting new technology. Sometimes the new thing is genuinely the right call. But the bar should be high, and the reasoning should be specific.
Choose the exciting option when:
- Existing tools fundamentally cannot solve the problem. Not "it would be slightly harder" but "it is architecturally impossible." If you're building a globally distributed system that requires strong consistency with single-digit millisecond latency, yes, you might need something beyond your standard relational database.
- The new tool is 10x better, not 10% better. A marginal improvement doesn't justify the operational overhead. The improvement needs to be transformative enough to pay for the learning curve, the operational unknowns, and the hiring challenges.
- You have the team and time to absorb the risk. Adopting unproven technology with a team that's already stretched thin is not bold. It's reckless. You need experienced engineers with the time and interest to become experts in the new tool, and you need organizational patience for the inevitable rough patches.
If you can't clearly articulate why the boring option is insufficient, you haven't justified the exciting one.
The Resume-Driven Development Problem
There's a force working against boring technology decisions, and it's worth naming directly: engineers want to work with exciting tools. This is human and entirely valid. People want to grow, learn new things, and work on interesting problems. Nobody puts "operated a PostgreSQL cluster for five years" at the top of their conference talk submissions.
But the solution to this tension is not to run your production systems on technology nobody on the team has operated before. That's optimizing for individual resumes at the expense of organizational outcomes.
The solution is to create legitimate spaces for experimentation. Hackathons where engineers build with whatever tools they want. Internal tools that can tolerate higher risk. Side projects and proof-of-concepts that let people evaluate new technology without betting the business on it. R&D sprints with explicit charters to explore emerging tools.
When you separate the desire for learning from the pressure of production, you get better outcomes for both. Engineers get exposure to new tools. Production systems get the reliability they need. And when something truly promising emerges from experimentation, you adopt it with real knowledge instead of optimism.
Boring at Scale
Look at the most reliable large-scale systems in the world. They're built on remarkably boring foundations. The companies operating at massive scale didn't get there by chasing every new tool. They got there by using well-understood technology in sophisticated ways.
There's an important distinction here: using boring technology in sophisticated ways versus using sophisticated technology in basic ways. The first approach gives you deep operational expertise and predictable failure modes. The second gives you a system that nobody fully understands and failure modes that surprise everyone.
A team that deeply understands PostgreSQL -- its query planner, its vacuum behavior, its replication topology, its connection management -- will build more reliable systems than a team running a cutting-edge distributed database they learned from the getting-started guide. Depth of understanding beats novelty of tooling, every time.
Sophistication should be in the architecture and the operational practices, not in the technology choices themselves. The most impressive engineering isn't visible in a dependency list. It's visible in how a system handles load, recovers from failure, and evolves without breaking.
Starting Point
If you want to apply this thinking to your own organization, here's a practical exercise:
- List your tech stack. Every database, framework, language, message queue, orchestration tool, and infrastructure component.
- Mark each item: boring or exciting. Boring means your team deeply understands it, has operated it in production for years, and can troubleshoot it under pressure. Exciting means it's relatively new to the team, has fewer than two years of production history in your organization, or requires specialized knowledge that only one or two people hold.
- For each exciting item, ask: is this our differentiator? Is this the technology that directly enables the thing our customers pay us for?
- If not, evaluate a boring alternative. Not hypothetically. Actually spec out what it would take to migrate. You might find the boring option is not only sufficient but superior for your use case.
- Budget your innovation tokens deliberately. Decide as a leadership team where you want to spend your complexity budget. Make it an explicit, documented decision. Revisit it quarterly.
This isn't about eliminating all risk from your technology choices. It's about concentrating risk where it creates the most value and eliminating it everywhere else. Most organizations don't fail because they were too conservative. They fail because they spread their complexity budget so thin that nothing worked reliably.
The best technology choice is the one your team can operate at 3 AM, half-awake, without panic -- and recover from by morning without heroics.
Exciting technology makes for great conference talks. Boring technology makes for great businesses. The teams that build lasting, reliable systems aren't the ones with the most impressive tech stack. They're the ones who made deliberate, unglamorous choices and then executed on them with depth and discipline. Choose boring. Ship faster. Sleep better.