Summarizer

Innovation Tokens and Boring Technology

← Back to Lessons from 14 years at Google

The prevailing sentiment among engineers is that innovation acts as a high-interest loan, where novelty in tech stacks creates "incidental complexity" that must eventually be repaid through outages, difficult hiring, and increased cognitive overhead. While many practitioners advocate for the reliability of "boring technology" to minimize unknown production behaviors, others argue that strategic novelty is essential to solve fundamental architectural flaws or achieve the kind of breakthroughs that built companies like Google. This tension is often managed through a balanced "one novel thing per project" rule, which seeks a middle ground between stagnation and the risks of "Resume Driven Development." Ultimately, the discussion emphasizes that complexity is rarely eliminated but merely shifted—often onto the person on call—requiring a disciplined management of "innovation tokens" to ensure both system stability and long-term career sustainability.

13 comments tagged with this topic

View on HN · Topics
I first learned about the "innovation tokens" idea in "Novelty is a loan you repay in outages, hiring, and cognitive overhead" from this, still one of my favorite essays on software architecture: https://boringtechnology.club/ Likewise, "Abstractions don’t remove complexity. They move it to the day you’re on call." made me think of this 23 year old classic from Joel Spolsky, the Law of Leaky Abstractions: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
View on HN · Topics
I think this is true for essential complexity. And indeed it's one of the best reasons to release early and often, because usage helps clarify which parts of the requirements are truly required. But plenty of projects add quite a lot of incidental complexity, especially with technology choices. E.g., Resume Driven Development encourages picking impressive or novel tools, when something much simpler would do. Another big source of unneeded complexity is code for possibilities that never come to fruition, or that are essentially historical. Sometimes that about requirements, but often it's about addressing engineer anxiety.
View on HN · Topics
> I first learned about the "innovation tokens" idea in "Novelty is a loan you repay in outages, hiring, and cognitive overhead" from this, still one of my favorite essays on software architecture: https://boringtechnology.club/ I don't think this is consistently true - in particular, I think that a lot of current well-known practices around writing code result in code that implicitly relies on assumptions in another part of the system that can change without warning; and novelty is necessary in order to make those assumptions more solid and ultimately result in software that is less likely to break unexpectedly.
View on HN · Topics
I don't follow. Following the robustness principle doesn't necessarily introduce novelty. Perhaps a bit more complexity, but just how much depends on how clever you try to be. What did you mean?
View on HN · Topics
My former boss had a rule of “One novel thing per project”. This was both an upper and lower limit, which ensured that he was “always learning”. I’ve followed that rule for decades and always regretted it when I couldn’t: projects were either too boring or too stressful except at the magic level of novelty.
View on HN · Topics
That's fine ... only have to size your projects accordingly!
View on HN · Topics
That actually sounds brilliant!
View on HN · Topics
Every engineer should read this. It's a wonderful collection of heuristics that might seem banal, but which are shimmeringly true. The two that stand out are > Novelty is a loan you repay in outages, hiring, and cognitive overhead. and > Abstractions don’t remove complexity. They move it to the day you’re on call. as a warning against about being too, too clever.
View on HN · Topics
There's rarely a bullet point advantage that some new language or tech stack can offer me that would outweigh ten years of observation of how a familiar setup behaves in production, such that the space of unknown unknowns is reduced to almost nothing.
View on HN · Topics
My personal rule is that the new technology stack item needs to either make is possible for me to build something that I couldn't have built without it, or needs to provide a productivity boost significant enough to overcome the productivity lost by straying from the more familiar path - even harder for team projects where multiple people need to learn the new component.
View on HN · Topics
And google wasn't founded by people who just kept their heads down and employed the simplest, most direct solution to the problem. If they had done that, google search would have been done on a super-fast server or mainframe using an RDBMS.
View on HN · Topics
Lesson 11 (Abstractions move complexity) and Lesson 20 (Time > Money) are two sides of the same coin. In engineering, we talk about "leaky abstractions" in our code. But the biggest leaky abstraction is often our own health. We treat our bodies as a "boring dependency" that will always work, but burnout and RSI (Repetitive Strain Injury) are essentially the ultimate system outages. Just as "Novelty is a loan" (Lesson 5), neglecting your physical "hardware" early in your career is a high-interest loan that you end up repaying in your 40s. Real seniority isn't just about navigating people and politics—it's about managing your personal energy so you actually have the health to enjoy the "compounding" (Lesson 21) that comes at the end.
View on HN · Topics
> Novelty is a loan you repay in outages If you personally build all (or most) of the stuff, you are in an extreme vertical integration benefit situation. You can make huge system wide changes in ways that would not be possible without having done so much novel work.