I've spent the better part of two decades watching engineers make the same mistake in different packaging. Somewhere around 2015, I started noticing a pattern at the tech conferences I covered—the standing ovations always went to the teams demoing real-time ML pipelines or event-sourced architectures with CQRS, never to the database admin who'd kept PostgreSQL humming through Black Friday without a single dropped transaction.
That imbalance bothers me more now than it did then.
The Innovation Token Economy Nobody Talks About
Dan McKinley's 2015 essay on "choosing boring technology" has aged like a fine Barolo. When he introduced the concept of innovation tokens at Etsy—the idea that engineering organizations have roughly three chances to bet on unproven tech before institutional chaos sets in—most people nodded politely and went back to rewriting their APIs in whatever framework had hit the front page of Hacker News that week.
The logic is brutally simple: spend a token on Node.js, burn another on MongoDB, maybe splurge on Kubernetes, and suddenly you're out of budget when the payment processor needs replacing or your search infrastructure starts buckling. McKinley wasn't being cute when he called MySQL, Postgres, PHP, and cron "boring." He was pointing to their most valuable feature—predictable failure modes that someone, somewhere, has already debugged at 3 AM on a Sunday.
I've watched this play out in war rooms. The company that picked boring won. Every time.
When the Network Died From Papercuts
Take Cloudflare's outage on November 18, 2025. No zero-day exploit. No nation-state attack. Just a routine permissions change during their authentication migration that doubled the size of a configuration file. The proxy code had a hard limit nobody remembered. File bloated past the threshold. Network collapsed globally.
I reached out to a former Cloudflare engineer I'd interviewed for a previous story. Off the record, they told me the real lesson wasn't technical—it was cultural. "We'd gotten so good at handling sophisticated threats that we stopped sweating the simple stuff," they said. "Turns out a 2x multiplier on file size is just as fatal as any APT when you're serving 20% of web traffic."
The postmortem Cloudflare published was admirably transparent, but reading between the lines reveals something McKinley warned about a decade ago: newer technology carries vastly larger unknown-unknowns. Cloudflare's stack is anything but boring—they build at the bleeding edge because their business model demands it. But even they learned that a tiny config tweak can cascade into catastrophe when you haven't stress-tested the mundane paths.
That outage cost them. Financially, sure, but also in trust capital with enterprise customers who'd been promised five-nines reliability.
The Monolith That Refused to Die
Shopify's architectural decisions fascinate me because they violate every trendy playbook. While competitors were splitting Ruby on Rails apps into microservice meshes circa 2018-2020, Shopify doubled down on what they called a "modular monolith." One repository. One CI/CD pipeline. One shared Postgres instance.
I spoke with a Shopify engineering lead in early 2024 for a different piece, and they were unapologetic. "We ship faster than teams ten times smaller because we don't spend half our sprint managing service-to-service contracts," they told me. The math checked out—fewer deployment pipelines meant fewer points of failure, which meant less time firefighting and more time building features merchants actually wanted.
Their approach worked so well that when I checked back in mid-2025, they were still running the monolith for core checkout flows, handling billions in GMV. The only services they'd extracted were genuinely independent domains—fraud detection, inventory allocation—that needed different scaling characteristics or compliance boundaries.
Compare that to the wreckage I've seen elsewhere. A Shopify partner called Littledata nearly imploded in 2019 when their clever Docker-based event pipeline hit a traffic spike. No proper metrics. Node.js event loop stalled. Servers leaked memory silently. Their founder later described it as "driving blindfolded"—a phrase that stuck with me because it's so viscerally accurate.
Their recovery plan? Boring as hell. AWS SQS for queuing. CloudWatch dashboards everywhere. Circuit breakers on every external call. The new system wasn't going to win any architecture awards, but it delivered 99.99% uptime and saved the business. I check their status page occasionally out of morbid curiosity. Last outage was 18 months ago, lasted four minutes, and they posted a root cause analysis within hours.
That's the difference between engineering theater and engineering craft.
The Great Rewrite Casino
Joel Spolsky's 2000 essay arguing you should never rewrite from scratch gets cited constantly but ignored religiously. I've lost count of how many CTOs have told me, "Yeah, but our situation is different." It never is.
Herb Caudill's analysis of six major rewrite attempts should be required reading in every computer science program. Netscape's browser team threw away a working codebase in 1998 to build something "cleaner." Three years later, Netscape 6.0 shipped with a one-minute startup time and was missing basic features like print preview. Internet Explorer, which had been incrementally improving its existing engine, devoured their market share in months. The rewrite didn't just fail—it ended the company.
Even Netflix, everyone's favorite microservices success story, only pulled it off because they'd spent years building operational infrastructure most companies can't afford. Chaos Monkey. Spinnaker. Hystrix. A whole constellation of open-source tools to manage the fragility they were deliberately introducing. A former Netflix engineer I interviewed in 2023 put it bluntly: "We had 200 people working on developer productivity and platform reliability before we split anything up. If you don't have that, stay monolithic."
Most don't have that. They try anyway. Then they hire consultants to untangle the mess, and I end up writing about it.
The Quiet Path to Staff Engineer
Here's what nobody tells junior developers: the fastest route to senior leadership isn't launching the shiniest project. It's being the person other engineers trust when production is on fire.
I've interviewed dozens of engineering VPs over the years, and they all describe the same archetype—the developer who refactored the authentication system to eliminate an entire class of security bugs, who automated the deployment pipeline so thoroughly that releases became boring, who documented the legacy payment code well enough that new hires could contribute safely in week two.
These people get promoted. The ones chasing every framework fad? They build impressive side projects and pivot to DevRel.
Stripe's database team embodies this ethos. Their blog posts about hitting 99.999% uptime while processing over a trillion dollars aren't marketing fluff—they're credibility signals to the market. I know engineering managers who specifically hunt for "Stripe infra" on resumes because those teams are legendarily risk-averse. They've made boring into a competitive advantage.
McKinley's framing resonates here: your job isn't picking the best tool in isolation. It's picking the least-worst tool for your company's context. The long-term costs of operating unreliable systems dwarf any short-term development velocity gains. I've seen that equation play out in countless postmortems.
Redefining Engineering Excellence
The industry's incentive structure is backward. Conference talks reward novelty. Promotion committees love "impact," which somehow always means launching new things rather than keeping old things running. We've gamified the wrong metrics.
The best engineers I know are pathologically risk-averse. They instrument everything. They write runbooks. They fight for boring solutions because they've been paged at 2 AM too many times to trust cleverness under pressure.
This doesn't mean never innovating. It means treating each innovation as a finite resource you're borrowing against future stability. It means asking "is this worth the operational burden?" before every architectural decision. It means celebrating the team that went twelve months incident-free, not just the team that launched the splashy redesign.
I think about this every time I see another startup announcing they're "modernizing" their stack. Half of them will quietly roll it back within 18 months. The other half will become cautionary tales I'll write about in 2027.
The Stakes Keep Rising
As I write this in late 2025, the margin for error is tighter than ever. AI companies are discovering that training runs require ungodly levels of infrastructure reliability—one bad disk can waste $50,000 in compute. Fintech startups are realizing that regulatory compliance doesn't care how elegant your event sourcing is. Healthcare platforms are learning that boring, synchronous API calls are preferable to eventual consistency when lives are on the line.
The future belongs to teams that build sturdy rockets, not fast ones. That's not a platitude—it's a pattern I've watched repeat for 15 years. The companies still standing five years from now will be the ones that treated stability as a feature, not a tax.
So the next time someone pitches you on rewriting the monolith or adopting the hot new database, ask them how many innovation tokens they think the company has left. If they don't know what you're talking about, you have your answer.
Boring isn't a compromise. It's a superpower disguised as humility. And in an industry that's finally starting to price in operational risk, that might be the most valuable realization of all.