Why "Innovation Culture" Is Often an Excuse for Not Fixing the Basics

TL;DR. The organizations with the most genuine capacity for innovation are the ones with the most boring operational fundamentals. You cannot experiment at speed when deployments are risky, feedback loops are slow, or a failed experiment triggers a multi-day incident. The causal arrow runs from operational excellence to innovation capacity — not the other way around. Hackathons and 20% time have real value, but only after the deployment pipeline is trustworthy, not instead of fixing it.

The CTO had a reputation for being innovative. His team ran hackathons. They had a "20% time" policy. They gave talks at conferences about their AI experiments. The engineering organization deployed to production twice a month, had a change failure rate over 30%, and was losing senior engineers at a rate that should have been alarming.

The innovation theater was running at full capacity. The engineering fundamentals were neglected.

This pattern is more common than most engineering leaders would like to admit. And it is worth examining carefully, because the organizations that get trapped in it tend to invest more in the narrative of innovation than in the infrastructure that makes genuine innovation possible.

Why reliable delivery is a prerequisite for genuine innovation — not a trade-off against it

There is a specific mechanism by which organizations substitute innovation narrative for engineering investment. When the fundamentals are broken, slow deployments, unreliable tests, poor observability, long lead times, fixing them requires admitting they are broken and making unglamorous investments to address them. Running a hackathon is easier. It produces visible excitement, creates shareable moments for social media and employer branding, and avoids the uncomfortable conversation about why the deployment pipeline takes 45 minutes and fails 30% of the time.

The problem is that genuine innovation in software systems requires a solid operational foundation. You cannot experiment at speed when deployments are risky. Every experiment that requires a production deployment carries the risk of an incident, which means teams run fewer experiments because each one is costly. You cannot iterate quickly when feedback loops are slow. If validating whether a new approach works takes three days from code complete to feedback in staging, the number of iterations that fit within a sprint is severely limited. You cannot take meaningful technical risks when the system is fragile enough that small changes produce cascading failures.

The teams with the most genuine capacity for innovation are the ones with the most boring operational fundamentals. They deploy frequently because they trust their systems. They try new things because trying something and having it fail is not a crisis but a recoverable event with a clear resolution path. Their innovation is possible precisely because their reliability is excellent. The causal arrow runs from operational excellence to innovation capacity, not the other way around.

What the DORA research shows about which organizations actually innovate

The DORA research provides a useful corrective to the innovation narrative. The organizations that score highest on delivery performance measures, high deployment frequency, low change failure rate, fast recovery, are not the ones with the most conference talks about innovation. They are the ones with the most systematic investment in delivery infrastructure.

The high-performing organizations in the DORA research tend to share certain characteristics. They have strong automated testing that runs quickly and catches most regressions before they reach production. They have deployment pipelines that can be executed reliably and repeatedly with minimal manual intervention. They have observability infrastructure that gives engineers immediate feedback when something goes wrong. And they have organizational practices around postmortems and on-call that treat incidents as information to learn from rather than failures to blame someone for.

None of these are innovation initiatives. They are operational investments. And the organizations that have made them are the ones that can deploy at high frequency and actually use that frequency to experiment, learn, and improve. The innovation comes from the operational foundation, not instead of it.

What "we have an innovation culture" actually signals about your delivery metrics

When engineering leaders describe their organization as innovative, the useful question is: what evidence would exist in the system if the claim were true?

Real engineering innovation shows up in the DORA metrics over time. Teams that are genuinely experimenting and improving their delivery processes deploy more frequently over time. Their change failure rate improves as they learn from failures and improve their practices. Their lead time decreases as they identify and remove bottlenecks. These are the fingerprints of an organization that is actually learning and changing, rather than one that holds hackathons.

The organizations I have encountered that have the strongest legitimate claim to an innovation culture are typically the ones least likely to describe themselves that way. They are too busy making specific, measurable improvements to write blog posts about their innovation culture. The observable result of their work is in the delivery metrics, not in the conference talk program.

The correlation between how much an organization talks about innovation and how much genuine delivery improvement they achieve is, in my experience, negative. The engineering teams with the most compelling innovation narratives tend to be the ones where the delivery fundamentals are most in need of attention. The ones with the strongest fundamentals tend to be quieter and more focused on specific, measurable improvements.

Hackathons have real value — just not before the deployment pipeline works

Hackathons, innovation labs, and 20% time policies all have potential value in the right context. They also have an opportunity cost. When an engineering organization with broken deployment processes spends two days on a hackathon, it has spent two days not fixing the deployment process. When an engineering leader invests in an AI experiment program for teams that cannot reliably deploy new features, they have invested in experimentation capacity that cannot be exercised reliably.

This is not an argument that morale-building activities have no value. They do, and the social and creative benefits of well-run hackathons are real. The argument is that innovation investments should follow operational investments, not replace them. The organization that fixes its CI pipeline and then runs a hackathon is in a fundamentally different position from the one that runs hackathons while the CI pipeline degrades. In the first case, the hackathon produces ideas that can actually be tested and iterated on. In the second, the ideas from the hackathon compete with everything else for the limited deployment capacity and may never get validated at all.

The sequencing matters in a way that is easy to observe but difficult to act on, because the innovation narrative is visible and exciting while the operational investment is invisible and unglamorous. Engineering leaders who understand this dynamic and choose the operational investment anyway are making a harder decision than it might appear from outside.

The compounding cost of deferred operational investment — why the math is worse than it appears

There is a financial dimension to deferred operational investment that tends to be underestimated when innovation programs are prioritized over fundamentals. Each decision to defer a platform improvement has a compounding cost that shows up in several places.

Slower delivery velocity means that every product feature takes longer to ship. If your deployment process adds two weeks to every feature's time-to-production because of manual steps and unreliable tests, the cost of that delay across everything your team ships over a year is substantial. At 50 features per year, each delayed by two weeks, the compounding effect on the product roadmap is measured in months, not days.

Higher change failure rate means that a significant fraction of your deployments create problems that require engineer time to diagnose and resolve. If 25% of deployments trigger incidents, the engineering hours spent on those incidents are not available for anything else. The opportunity cost of those incidents, measured in features not shipped and platform improvements not made, compounds over time.

Engineer attrition driven by poor tooling has a direct financial cost in recruiting and onboarding, and an indirect cost in the institutional knowledge that leaves with each departing engineer. Senior engineers who leave because the development environment is painful take with them understanding of the system that is difficult to reconstruct. The cost of rebuilding that understanding, distributed across the team that remains and the new hires who replace them, is rarely accounted for in the analysis of platform investment decisions.

When you add up the compounding cost of slow delivery velocity, high change failure rate, and attrition driven by poor tooling, the financial case for operational investment is typically stronger than the case for innovation programs. The return on fixing the fundamentals is not glamorous, but it is real and measurable.

If you want more innovation, invest in the conditions that make experimentation safe

If you want your engineering team to be genuinely more innovative, to try more things, to improve more systematically, to build capabilities that did not exist last year, the most effective investment is in the conditions that make experimentation safe.

That means deployment processes fast and reliable enough that rolling back a bad experiment takes minutes rather than hours. Engineers will run more experiments if they know that a failed experiment has a low cost of recovery. If each failed experiment takes a day to diagnose and roll back, the team will run fewer experiments. If it takes five minutes, they will run more.

It means test coverage strong enough that engineers can change things confidently without fear of breaking hidden dependencies. The fear of breaking things is one of the most significant inhibitors of experimentation in legacy codebases. Improving test coverage reduces that fear in a way that nothing else does.

It means observability good enough that when an experiment causes unexpected behavior, the team finds out quickly rather than when a customer reports it three days later. The feedback speed from a production experiment is a direct function of your observability infrastructure. Better observability means faster learning from experiments, which means more iterations in a given time period.

These are infrastructure investments. They do not feel innovative because they are not novel. They are often described as "maintenance" or "technical debt" work, which makes them easy to deprioritize in favor of new feature development. But they create the headroom in which genuine novelty becomes possible. They change the risk profile of experimentation from something that requires months of preparation to something that can happen in a sprint.

What happened when the next CTO spent 18 months fixing the fundamentals instead

The CTO with the hackathon culture eventually left the company. His successor spent the first 18 months fixing the deployment process, improving test reliability, and investing in observability. There were no hackathons during this period. There were no conference talks about innovation culture. There was unglamorous, systematic work on the delivery infrastructure.

By month 24, the team was deploying 40 times per week instead of twice a month. The change failure rate had dropped from over 30% to under 5%. Engineer attrition had decreased significantly. And the team was genuinely experimenting with new capabilities, because each experiment could now be deployed quickly, measured accurately, and rolled back if it was not working.

The innovation that followed was quieter, more consistent, and more valuable than anything produced by the hackathons. It was also invisible from outside the organization, because it showed up in delivery metrics and engineer satisfaction data rather than conference talks. That invisibility is, in some ways, the truest indicator of genuine operational health.

How to make the case for operational investment when the board wants to see AI experiments

For engineering leaders who recognize their organization in the pattern described here, the decision is a hard one. Innovation programs are visible and create organizational momentum in a way that operational investments do not. The board wants to see AI experiments and hackathon outcomes, not CI pipeline improvements.

The framing that tends to work is to connect the operational investment to the business outcomes that matter to leadership. "We are investing in our deployment infrastructure so that we can ship features faster and respond to market changes more quickly" is a different conversation than "we need to fix our technical debt." The former connects the operational work to business outcomes. The latter sounds like maintenance.

Engineering leaders who make this connection clearly, and who can measure the delivery improvements that result from operational investments, tend to get more organizational support for the work. The numbers tell the story better than the narrative does.

What sustainable innovation looks like in organizations that do it year over year without exhaustion

The organizations that innovate consistently, year over year, without the cultural exhaustion that follows innovation theater, share a set of operational characteristics that are rarely discussed in the same breath as innovation.

They deploy frequently enough that experimenting is not an event. When a team wants to test a new capability with a subset of users, they can do it without a multi-week deployment process. Feature flags and canary deployments mean that experiments are running continuously in production, providing real data about user behavior. The barrier to starting an experiment is low because the deployment infrastructure makes it low.

They have observability comprehensive enough to measure the impact of an experiment clearly. An experiment that cannot be measured is not an experiment. It is a change. The difference between an engineering culture that learns from experimentation and one that does not is whether the instrumentation exists to provide a clear signal about what the experiment did.

They have a culture of stopping experiments that are not working. Innovation theater accumulates because organizations are better at starting experiments than stopping them. The partially-built prototype that has been "almost ready for production" for six months is one of the most common forms of innovation debt. The organization that has developed the discipline to declare an experiment failed and archive the work cleanly is the one that can keep experimenting without accumulating the debt of unfinished speculative work.

Psychological safety is the deepest prerequisite — and operational health is how you build it

The deepest prerequisite for sustainable innovation is psychological safety: the organizational condition where engineers feel confident enough to propose ideas that might not work, share findings that are contrary to prevailing expectations, and advocate for technical approaches that differ from the current consensus.

Without this safety, the innovation programs that organizations invest in produce performative rather than genuine experimentation. Engineers propose ideas they believe will be approved rather than ideas they believe will be valuable. Experiments are declared successful because reporting failure feels unsafe. The organization learns nothing from its experimentation budget.

Building psychological safety is the work of engineering leadership over time. It requires consistent signals from the people with power about how they respond when things do not go as planned. When an experiment fails and the team that ran it is treated as having contributed valuable organizational learning, that signal propagates. When a failure produces blame or disappointment, that signal also propagates, and the organization's innovative capacity shrinks accordingly.

The CTO's successor who fixed the fundamentals was also the one who changed the incident response culture from blame to learning. The two changes were connected: an organization that blames people for failures cannot experiment safely, because all experiments risk failure. Operational health and innovation capacity are not separate goals. They are the same capability expressed in different contexts.

Frequently asked questions

Why do companies with innovation cultures often have broken engineering fundamentals?

Running a hackathon is easier than fixing the deployment pipeline. Innovation programs produce visible excitement and shareable moments — conference talks, social media posts, employer branding. Fixing CI reliability, test coverage, and observability produces delivery metrics that most organizations are not even tracking. When the fundamentals are broken, the path of least resistance is the narrative investment, not the operational one.

What does the DORA research say about innovation and delivery performance?

The high-performing organizations in the DORA research are characterized by systematic investment in delivery infrastructure: automated testing that catches regressions before production, deployment pipelines that run reliably with minimal manual intervention, and observability that provides fast feedback when something breaks. These are not innovation initiatives. They are operational investments. The organizations that made them are the ones that can deploy frequently enough to genuinely experiment.

Should engineering leaders stop running hackathons?

No. The argument is not that hackathons have no value. The argument is about sequencing. An organization that fixes its CI pipeline and then runs a hackathon is in a fundamentally different position from one that runs hackathons while the CI pipeline degrades. In the first case, the hackathon produces ideas that can be tested and iterated on quickly. In the second, the ideas compete with everything else for limited deployment capacity and may never get validated at all.

How do you measure whether your organization is actually innovating versus performing innovation?

Real engineering innovation shows up in DORA metrics over time. Teams that are genuinely experimenting and improving deploy more frequently over time, their change failure rate improves as they learn from failures, and their lead time decreases as they remove bottlenecks. Organizations performing innovation describe themselves as innovative; organizations actually innovating rarely do, because they are too focused on specific measurable improvements to write blog posts about their innovation culture.

---

If your engineering organization is investing in innovation programs while struggling with delivery fundamentals, the Foundations Assessment is the diagnostic that tells you where to start. For a broader view of what high-performing engineering organizations share, read what the DORA 2025 research actually tells you about your platform.

For the DORA metrics that show whether innovation programs are producing actual delivery improvement, read the DORA metrics implementation guide.

For the golden path adoption signal that tells you whether the innovation is being absorbed into the platform or staying in individual engineers' heads, read golden paths developers actually choose.