Every few months, a new tool captures the collective imagination of the developer community. It's faster, more elegant, more "developer-friendly." Twitter lights up with benchmarks. Blog posts proliferate. And somewhere, a team rewrites their working system to adopt it.

Six months later, they're debugging edge cases that the old tool solved years ago.

Article illustration — 720 × 360

The innovation token budget

Dan McKinley introduced the concept of "innovation tokens" — the idea that every team has a finite budget for new, unproven technology. Spend too many tokens, and you're no longer building a product. You're fighting your tools.

The most effective teams I've worked with are ruthlessly conservative about their technology choices. They ask:

  • Does this solve a problem we actually have?
  • What's the operational cost of adopting this?
  • Who on the team has deep expertise with it?
  • What happens when the maintainer moves on?

If you can't answer all four confidently, the answer is probably "not yet."

Boring compounds

Here's what boring technology gives you: predictability. When your database is PostgreSQL and your language is Python, every engineer you hire can contribute on day one. Every bug has a Stack Overflow answer. Every failure mode is well-documented.

"The best technology is the one you understand deeply, not the one that's trending on Hacker News."

This predictability compounds over time. Less time debugging infrastructure means more time building features. More institutional knowledge means faster onboarding. Fewer surprises means calmer on-call rotations.

When to be exciting

None of this means you should never adopt new technology. Innovation is essential — you just need to be deliberate about where you spend your tokens. The best rule I've found: 

if (technology.solves_core_problem && technology.has_strong_community) {
  consider_adopting();
} else {
  stick_with_boring();
}

Use your innovation tokens on the things that make your product unique. Use boring technology for everything else. Your future self — and your on-call rotation — will thank you.

The quiet confidence of boring

There's something deeply satisfying about a system built on proven foundations. It doesn't need to be defended in architecture reviews. It doesn't require specialized hiring. It just works, day after day, deploy after deploy.

That's not a lack of ambition. That's engineering maturity. And it's one of the most undervalued skills in our industry.