Skip to main content
Daniel J Glover
Back to Blog

Why Boring IT Infrastructure Wins

10 min read
Article overview
Written by Daniel J Glover

Practical perspective from an IT leader working across operations, security, automation, and change.

Published 25 December 2025

10 minute read with practical, decision-oriented guidance.

Best suited for

Leaders and operators looking for concise, actionable takeaways.

There is relentless pressure on IT leaders to innovate. Every vendor pitch promises transformation. Every conference keynote celebrates disruption. The technology press champions the newest, shiniest solutions. But here is a contrarian truth that experienced IT leaders understand: boring IT infrastructure reliability beats innovation almost every time.

The most successful technology organisations do not chase every new trend. They build stable, well-understood systems and invest their limited innovation capacity where it truly matters to the business.

The Boring Technology Philosophy

Dan McKinley, formerly of Etsy, articulated this principle in his influential essay Choose Boring Technology. His core insight remains as relevant today as when he first wrote it: every organisation has limited capacity for novelty. He calls these "innovation tokens" - and you only get a few to spend.

The argument is straightforward. New technology comes with unknown unknowns. When you adopt something proven - MySQL, PostgreSQL, Python, Linux - you inherit decades of collective learning about how these systems fail and how to recover. With cutting-edge alternatives, you are the one discovering failure modes, often at the worst possible moments.

This does not mean avoiding all new technology. It means being strategic about where you spend your innovation budget. As McKinley puts it, the "best tool for the job" thinking takes a myopic view. Your actual job is keeping the business running, and the best tool is often the one that causes the least operational burden across all your problems.

Why Reliability Matters More Than Features

Google's Site Reliability Engineering team has spent two decades learning how to run systems at scale. Their SRE principles offer hard-won wisdom that applies to organisations of any size.

A central insight from SRE is that reliability is a feature - often the most important one. Users do not care about your elegant architecture or cutting-edge stack if the service is unavailable. The most sophisticated AI-powered feature is worthless during downtime.

The AWS Well-Architected Reliability Pillar reinforces this principle. Reliability encompasses a workload's ability to perform its intended function correctly and consistently. This includes recovering from failures, scaling to meet demand, and handling configuration errors gracefully.

None of this requires novelty. It requires discipline, understanding, and investment in the fundamentals.

The Hidden Costs of Chasing Innovation

The allure of new technology is understandable. Vendors make compelling promises. New frameworks claim to solve problems that plagued previous generations. The fear of missing out drives adoption of unproven solutions.

But the costs of early adoption are often invisible until they materialise.

Operational burden multiplies. Every new technology in your stack requires monitoring, alerting, backup procedures, security patching, and incident runbooks. Your team must understand failure modes and recovery procedures. This knowledge takes time to build and is costly to maintain.

Hiring becomes harder. Exotic technology stacks limit your talent pool. Engineers with deep experience in niche tools are rare and expensive. Meanwhile, developers skilled in boring, widely-adopted technologies are easier to find and ramp up quickly.

Integration complexity compounds. Each new component must integrate with existing systems. Novel technologies often lack mature integration patterns, forcing custom development and ongoing maintenance.

Knowledge silos form. When only one or two engineers understand a cutting-edge system, you have created a critical dependency. Their departure leaves you exposed.

Support resources are limited. Boring technology has Stack Overflow answers, documentation, and consultants who have seen your problem before. Bleeding-edge tools often lack these resources when you need them most.

These costs rarely appear in the initial evaluation. They emerge over months and years, accumulating into what becomes technical debt that demands strategic attention.

When Boring Is the Strategic Choice

This is not an argument against all innovation. It is an argument for strategic allocation of your limited capacity for novelty.

Consider where boring technology makes sense:

Core infrastructure. Your databases, networking, authentication systems, and monitoring tools should be rock-solid and well-understood. Innovation here creates risk across your entire operation.

Commodity functions. Email delivery, file storage, logging, and caching are solved problems. Using proven solutions frees capacity for work that actually differentiates your business.

Compliance-sensitive systems. Auditors, regulators, and security teams prefer established technologies with known risk profiles. Novel tools in these areas invite scrutiny and increase compliance costs.

High-availability requirements. Systems that must not fail need failure modes that are thoroughly documented and tested. You want to inherit twenty years of production experience, not discover edge cases yourself.

Reserve your innovation tokens for areas where novelty creates genuine competitive advantage - customer-facing features, business-specific capabilities, or processes where existing tools genuinely cannot meet requirements.

As highlighted in my analysis of IT trends for 2026, the organisations that thrive will be those who deploy technology most effectively, not those who adopt the most. Strategic restraint is a competitive advantage.

How to Evaluate New Technology

When genuinely novel technology appears compelling, apply rigorous evaluation before adoption. Here is a practical framework.

The Operational Readiness Test

Before adopting any new technology, answer these questions honestly:

  1. Do we have production experience? Has anyone on the team run this in production, at scale, under pressure? If not, who will build that expertise, and how long will it take?

  2. What are the known failure modes? Can you list the five most common ways this technology fails and how to recover from each? If the answer is unclear, you are inheriting significant risk.

  3. Is there organisational commitment? Does the vendor or open-source community have a track record of long-term support? Will this technology exist and be maintained in five years?

  4. What is the migration path out? If this technology proves unsuitable, how do you exit? Technologies without clear exit strategies create lock-in that may become untenable.

  5. Does the team want this? Novel technology adopted against team preferences creates resentment and maintenance burdens. Consensus matters.

The Total Cost Assessment

Calculate the true cost over a multi-year horizon:

  • Ramp-up time - How long before the team is productive?
  • Training investment - Courses, certifications, learning time
  • Integration work - Custom development to connect with existing systems
  • Operational overhead - Monitoring, alerting, runbooks, on-call procedures
  • Support contracts - Vendor or consultant costs
  • Exit costs - If you need to migrate away, what is the effort?

Compare this honestly against extending or improving your existing boring solution. The calculus often favours the known quantity.

The Innovation Token Budget

Ask explicitly: is this worth one of our innovation tokens? If you are already investing heavily in AI capabilities, a new container orchestration platform, and a major cloud migration, adding a novel database technology may exceed your organisation's capacity for change.

Spreading innovation too thin means none of your new initiatives get the attention they need to succeed. Concentration beats diversification when it comes to organisational learning.

A Practical Framework for Technology Decisions

Apply this decision framework when evaluating technology choices:

Category 1: Default to Boring

For these use cases, choose established, well-understood technology unless there is a compelling reason otherwise:

  • Databases (relational and key-value stores)
  • Web servers and application frameworks
  • Authentication and authorisation
  • Logging, monitoring, and alerting
  • CI/CD pipelines and deployment tooling
  • Version control and collaboration tools

The burden of proof is on novelty. You need a strong, specific reason to deviate from proven solutions.

Category 2: Evaluate Carefully

These areas may justify innovation, but require rigorous assessment:

  • Machine learning infrastructure
  • Real-time data processing
  • Customer-facing interactive features
  • Specialised performance requirements

Apply the operational readiness test and total cost assessment. Proceed only with clear eyes about the investment required.

Category 3: Innovate Intentionally

Reserve genuine innovation for areas that create competitive advantage:

  • Core business differentiation
  • Novel customer experiences
  • Proprietary capabilities that competitors cannot easily replicate

Even here, build on boring foundations. Innovation should happen at the edges, not in your core infrastructure.

Building an Organisation That Values Reliability

Embracing boring technology requires cultural alignment. Engineers often prefer novelty - new tools are interesting, resume-building, and break the monotony of maintenance work. Leaders must create incentives that value operational excellence alongside feature delivery.

Celebrate reliability achievements. Recognise teams that maintain high availability, reduce incident frequency, or improve recovery times. These accomplishments deserve the same visibility as feature launches.

Make operational costs visible. Track the time spent on different technologies. When exotic tools consume disproportionate support effort, the data makes the case for simplification.

Create space for experimentation. Provide low-stakes environments where engineers can explore new technologies without production risk. This channels the desire for novelty constructively while keeping production systems stable.

Invest in deep expertise. Reward mastery of your core stack. Engineers who deeply understand your boring technologies are more valuable than those with shallow knowledge of many trendy tools.

These principles align with the strategic approaches reshaping IT management - focusing on outcomes, measuring impact, and building sustainable capabilities rather than chasing every new trend.

Quick Reference: The Boring Technology Checklist

Use this checklist when evaluating technology choices:

Before Adopting New Technology

  • Have we exhausted options with our current stack?
  • Do we have production experience with this technology?
  • Can we articulate the specific problem this solves better than existing tools?
  • Have we calculated total cost of ownership over three to five years?
  • Is this worth one of our limited innovation tokens?
  • Does the team have capacity to learn and operate this effectively?
  • What is our exit strategy if this choice proves wrong?

Signs You Should Choose Boring

  • The problem is well-understood and solved by existing tools
  • Reliability matters more than raw performance
  • The team lacks experience with the novel alternative
  • You are already investing innovation capacity elsewhere
  • The technology will be touched by many team members
  • Compliance or audit requirements favour established solutions

Signs Innovation May Be Justified

  • Existing tools genuinely cannot meet requirements
  • The capability creates significant competitive advantage
  • You have organisational capacity for the learning investment
  • The team has relevant expertise or strong desire to build it
  • Clear success criteria and timeline for evaluation exist

Red Flags

  • Adopting technology primarily because it is new or interesting
  • Vendor pressure or fear of missing out driving decisions
  • No clear answer to "what happens when this fails?"
  • Only one team member understands the technology
  • No exit strategy if the choice proves unsuitable

The Strategic Wisdom of Restraint

In a technology landscape that celebrates disruption and innovation, there is strategic wisdom in restraint. The best IT leaders understand that their job is not to adopt the newest technology - it is to deliver reliable, cost-effective capabilities that enable business success.

Boring infrastructure fades into the background. It simply works, day after day, without drama or heroic recovery efforts. This invisibility is a feature, not a bug. When technology becomes invisible, the business can focus on what it does best.

The organisations that outperform their competitors rarely do so through exotic technology choices. They succeed by executing brilliantly on fundamentals - reliable systems, efficient operations, and strategic investment of limited innovation capacity where it truly matters.

Choose boring technology. Spend your innovation tokens wisely. Build systems that work, and keep working, for years to come.


Building Reliable IT Infrastructure

Making strategic technology decisions requires experienced guidance and a clear framework for evaluation. My IT management services help organisations build robust technology strategies - from infrastructure assessment to vendor evaluation and operational excellence programmes.

Whether you are rationalising an overcomplex technology stack, evaluating a major infrastructure decision, or building a culture that values reliability alongside innovation, a structured approach makes the difference between reactive firefighting and sustainable operational excellence.

Get in touch to discuss how boring technology principles can strengthen your IT infrastructure and free capacity for innovation where it truly matters.

Share this post

About the author

DG

Daniel J Glover

IT Leader with experience spanning IT management, compliance, development, automation, AI, and project management. I write about technology, leadership, and building better systems.

Continue exploring

Keep building context around this topic

Jump to closely related posts and topic hubs to deepen understanding and discover connected ideas faster.

Browse all articles

Let's Work Together

Need expert IT consulting? Let's discuss how I can help your organisation.

Get in Touch