Every engineering team gets a limited number of “innovation tokens.” Spend them wisely.
The Innovation Token Budget
Dan McKinley coined this idea: you get about three innovation tokens per project. Each unfamiliar technology you adopt spends one. Use them on things that give you a genuine competitive advantage — not on your database or message queue.
The cost of a technology isn’t just learning it. It’s debugging it at 3 AM when it breaks in a way the docs don’t cover.
What “Boring” Actually Means
Boring technology isn’t bad technology. It’s technology where:
- The failure modes are well-documented
- Stack Overflow has answers for your edge cases
- You can hire people who already know it
- The community has solved your problem before
PostgreSQL is boring. It’s also incredibly powerful, handles 90% of use cases, and has decades of battle-testing. That’s not a weakness — it’s a superpower.
When to Be Exciting
There are valid reasons to adopt new technology:
- The boring option genuinely can’t solve your problem — you need real-time sync, and polling won’t cut it
- The new tool is 10x better, not 10% better — marginal improvements don’t justify the learning curve
- It’s core to your product — if you’re building a search engine, innovate on search, not on your auth system
A Practical Example
I recently needed a static site for my personal blog. The exciting options:
- Next.js with ISR and edge functions
- SvelteKit with adapters
- Some new Rust-based SSG
What I chose: Astro. It’s not the newest or most exciting, but it’s well-documented, purpose-built for content sites, and I spent zero time fighting the framework.
The boring choice let me focus on what actually mattered — the content and the design.
The Long Game
Exciting technology becomes boring technology if it survives long enough. React was exciting in 2015. TypeScript was exciting in 2018. Both are boring now — and that’s exactly why they’re reliable choices.
Pick boring defaults. Save your innovation tokens for where they matter.