TECH Signal 514
2015 essay advocates limiting innovation tokens to prioritise boring but proven technology
↗
A widely cited 2015 essay formalises the idea that most engineering teams have only a few innovation tokens to spend and should reserve them for core business problems rather than infrastructure novelty
The essay crystallises an operational mindset that many mature engineering organisations already follow implicitly. By quantifying the cost of novelty as “innovation tokens,” it gives engineers a concrete framework to push back against shiny new tools that add operational overhead without advancing the company’s mission. The argument remains relevant in environments where reliability and maintainability are valued over cutting-edge features
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
Each technology choice consumes one of a limited number of innovation tokens, forcing trade-offs between novelty and stability
Boring technologies are defined as those whose failure modes are well understood, reducing unknown unknowns in production
The “best tool for the job” heuristic fails when it ignores the global cost of operations and cognitive overhead across the entire stack
THE READ
What the cluster adds up to.
The essay introduces the metaphor of “innovation tokens” to quantify the finite capacity any engineering team has for adopting new technologies. Each novel component, language, database, service-discovery layer, consumes one token. Once the tokens are spent, further novelty risks destabilising the system without delivering proportional business value. The model is deliberately simplistic, but it provides a memorable way to frame discussions about technical debt and operational overhead.
By advocating “boring” technology, the author does not mean outdated or poorly designed tools. Instead, he highlights technologies whose failure modes are well documented and whose edge cases have been explored by thousands of other teams. MySQL, Postgres, PHP, Python, Memcached, Squid, and cron are listed as examples. The key advantage is that when something breaks, engineers can rely on existing playbooks rather than inventing new ones under pressure.
The essay critiques the common advice to “use the best tool for the job” as myopic. It argues that the true job is keeping the company in business, and the best tool is the one that minimises the total cost of ownership across the entire stack. Adding a new language or database may solve a local problem but introduces monitoring, testing, deployment, and on-call burdens that scale with the number of distinct technologies in use.
While the essay is framed as a personal reflection, it resonates because it codifies practices already followed by mature engineering organisations. Teams that have experienced outages caused by immature tooling or that have struggled to hire engineers familiar with niche technologies often adopt similar constraints. The innovation-token model gives junior engineers a concrete argument to use when senior leadership or external hype cycles push for unproven solutions.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER