The "Shiny Object" Syndrome
Engineers love new technology. This is not a character flaw — curiosity is what makes someone good at engineering in the first place. But curiosity without discipline is expensive. When starting a new project, the temptation to reach for the newest JavaScript framework, the trendiest database, or the hottest cloud-native service is overwhelming. We justify it by saying "it's modern," "it scales better," or "Google uses it."
But Google has 25,000 site reliability engineers. You have four people and a deadline.
Every new technology introduces Unknown Unknowns — failure modes nobody has documented yet, operational quirks that only surface under production load, and integration gaps that the README never mentioned. It introduces hiring difficulty (try finding a senior Haskell developer in Des Moines), immature tooling (no Terraform provider, no Datadog integration, no Helm chart), and community gaps (the GitHub Issues tab is the documentation).
Dan McKinley, a former engineer at Etsy, proposed a mental model to manage this tension: treat innovation as a limited currency. You have a fixed budget of complexity you can absorb. Spend it wisely, or drown in operational overhead before you ship anything meaningful.
This concept is sometimes called "Resume-Driven Development" when applied negatively — engineers choosing technology because it looks good on their LinkedIn profile rather than because it solves the problem at hand. The Innovation Tokens model gives you a framework to push back against this pattern constructively, without being the person who says "no" to everything.
The model does not ask you to be a Luddite. It asks you to be a strategist. The question is never "is this technology good?" The question is always "is this the right place to absorb the cost of this technology?"