Spend Your 'Innovation Tokens' Wisely: The Case for Boring Technology

Dan McKinley argues that engineering teams should treat novelty as a scarce resource. Every company gets roughly three ‘innovation tokens’ to spend on unproven technology, and teams routinely overestimate how many they hold. Reaching for NodeJS, MongoDB, or a bespoke database burns a token each — and unless you’re a database or JavaScript shop, that attention is better spent on the actual mission. ‘Boring’ here means well-understood, not bad: MySQL, Postgres, PHP, Python, Memcached, and cron are dull precisely because their capabilities and, more importantly, their failure modes are known. New tech carries a far larger pool of unknown unknowns, and those are what wreck systems in production.

The deeper argument is to optimize globally rather than locally. ‘Best tool for the job’ thinking ignores the operational baggage every new component drags in — monitoring, testing, init scripts, on-call knowledge, cognitive overhead — which compounds across a team faster than any single tool’s marginal benefit. Since the long-term cost of keeping a system running reliably dwarfs the convenience of building it, the truly ‘best’ tool is the least-worst option that covers the most problems at once. Keeping the company in business is the real job.

McKinley isn’t against adopting new technology, but he wants it gated by a deliberate, company-visible process: first ask how you’d solve the problem with what you already run (which often exposes that someone just wants to play with a new toy), write down exactly why the current stack falls short, and commit to a migration timeline when the new thing overlaps existing tools. The payoff of this discipline is freedom — not the illusory freedom of unconstrained polyglot tooling, which buries teams in operational toil, but the freedom to think about bigger problems instead of babysitting infrastructure.