.png){kind=small}
When software projects fail—and many do—the search for someone or something to blame begins. Deadlines slip, costs balloon, and planned features fail to materialize. According to the Chaos Report, 93% of projects are challenged—meaning they ship late, go over budget, or fail to deliver important planned functionality. Even more troubling, over 40% of projects fail entirely, never shipping a 1.0 version to the intended customer and being written off as sunk costs.
When these outcomes occur, leaders, teams, and stakeholders ask the inevitable question: What went wrong?
The answers often fall into three familiar categories:
People problems: “The team isn’t skilled enough, motivated enough, or aligned.”
Process problems: “Our Agile isn’t Agile enough. We need better workflows.”
Technical health problems: “The codebase is an unmanageable mess.”
What’s fascinating is the order in which these causes are blamed: first people, then process, and finally technical health. Yet, in many cases, the root cause lies in the opposite order: technical health drives process issues, which in turn create people problems. Let’s unpack this cycle.
Blame #1: People problems
The first scapegoat is often the team. When a project runs off the rails, we hear complaints like:
“The developers aren’t skilled enough to handle this.”
“The team isn’t working hard enough.”
“The leadership isn’t providing clear direction.”
It’s true that highly skilled people are critical to project success. In his seminal book The Mythical Man Month, Fred Brooks postulates that productivity differences between the top and bottom quartiles of developers can be as much as 10x. My research at MIT confirms that this isn’t just theory—it’s reality. In a firm with thousands of developers, we measured a 10x difference in productivity between top and bottom quartiles. Exceptional developers, project managers, and leaders do make a difference.
But that’s not the whole story.
Even after statistically accounting for differences in developer skill, we found another order-of-magnitude difference in productivity caused by the technical health of the codebase. In other words, no matter how talented your team is, they’ll struggle if they’re working in an unhealthy system. Great technologists and leaders can mitigate some issues, but they can’t overcome the drag created by poor technical health.
Why it matters: Blaming people first misses the root cause. When developers are stuck fighting brittle architectures or untangling spaghetti code, no amount of skill or effort will deliver the outcomes you need.
Blame #2: Process problems
When it becomes clear that the team is trying its best but still failing, the finger often points to the process. Leaders ask:
“Are we following Agile properly?”
“Do we need more meetings, checkpoints, or standups?”
“Should we change how we estimate and plan?”
Process problems are a convenient target because they seem actionable. If the team is struggling, why not improve the way they work? However, process fixes are often just band-aids, addressing symptoms rather than root causes. Worse, they can introduce new friction, as teams struggle to follow rigid workflows while wrestling with more fundamental obstacles.
At Silverthread, I worked with one organization that had a massive codebase and hadn’t been able to ship a new release in more than five years. Leadership’s response? Send everyone to Scrum Master training. The technical team was filled with competent people, yet the process changes didn’t help.
It wasn’t until we used CodeMRI to perform a graph-theoretic analysis of the codebase that the hidden root cause became clear: it was the most architecturally entangled and intertwined codebase we had ever encountered in our time at MIT, Harvard, and Silverthread. The sheer complexity and lack of modularity made even the smallest changes ripple unpredictably through the system, making progress almost impossible.
Fortunately, leadership eventually shifted focus. Instead of blaming the team, they acknowledged the monumental challenge these developers faced. Conversations moved from criticism to recognition, with leaders even joking about needing to pay the team “combat pay” for working in the codebase they had inherited. This shift in mindset allowed the organization to focus on fixing the underlying technical health issues rather than piling more processes onto an already overburdened team.
Why it matters: Processes succeed or fail based on the systems they operate within. Without addressing the root technical issues, no process will consistently deliver value.
The real root cause: Technical health problems
The deeper you dig, the clearer it becomes: the underlying problem in most project failures is poor technical health. Here’s why:
An unhealthy codebase slows everything down. When the architecture is brittle, making even small changes can introduce defects or break unrelated components. Teams spend more time fixing bugs than delivering value.
Complexity overwhelms developers. As systems grow and degrade, they become harder to understand. Developers lose confidence in their changes, leading to delays, regressions, and burnout.
Technical debt drags down productivity. Like a ball and chain, accumulated shortcuts, poor design choices, and lack of testing make it harder and harder for teams to move forward.
In short, a toxic codebase creates a toxic environment. Processes designed for healthy systems fail to deliver, and people become frustrated, demotivated, or blamed for factors outside their control.
The need for a holistic view
While technical health is often the root cause, project failures rarely have a single explanation. All three factors—people, process, and technical health—are intertwined, creating feedback loops that amplify the effects of each problem.
Here’s how these interdependencies play out:
Technical health impacts people:
In one study, I found that developers are 9x more likely to quit or be fired if they spend all their time working in architecturally challenged code. When developers feel unproductive, constantly fight bugs, and are blamed for problems beyond their control, it’s no surprise they leave. Poor technical health erodes morale, damages retention, and makes it harder to maintain a skilled workforce.
Technical health impacts process:
Predictive analytics on one codebase we analyzed showed that technical health issues created so much friction that it was impossible to produce a typical feature in less than 80 days—far beyond the time frame of a typical Agile sprint. No process, no matter how well-designed, can overcome the bottlenecks caused by an unhealthy system.
Process and leadership impact technical health:
Poor leadership and processes contribute to technical health problems. Rushing to deliver features without refactoring or testing leads to architectural degradation. Teams without clear priorities or effective workflows are more likely to introduce technical debt.
These are not independent problems. They are deeply interconnected, and addressing them requires a holistic view. Improving technical health can enhance processes and retain great people, but poor leadership and process decisions can quickly undo those gains.
The true definition of agility
Agility is often misunderstood as being fast, but that’s only part of the story. A cheetah is agile not because it’s fast but because it can change speed and direction at high speed with minimal cost. That’s the dictionary definition of agility: the ability to move quickly and easily in response to changing circumstances.
A cheetah’s agility is what enables it to pivot when an unexpected opportunity—a rabbit crossing its path—appears. Similarly, an agile development process isn’t just about speed; it’s about creating optionality through task independence.
A system with good technical health—one that is modular—also exhibits agility. In a modular system, components are independent, meaning you can modify or swap out parts with minimal impact on the rest of the design. This independence allows organizations to adapt quickly to changing requirements or opportunities.
True agility requires:
Great people: Developers who can work in small, independent teams.
Good processes: Workflows that minimize communication and coordination overhead.
Healthy systems: A codebase where changes don’t trigger unintended emergent properties, avoiding the “emergencies” that derail progress.
Agility, then, is a function of independence—in tasks, teams, and system components. Without technical health, true agility is impossible.
Conclusion: Focus on what matters
The blame game often targets people first, processes second, and technical health last—but the reality is the opposite. Poor technical health drives process failures, which in turn create people problems. To break this cycle, we need to prioritize technical health as the foundation for success, while also addressing leadership, processes, and team dynamics.
Great people deserve great systems. By taking a holistic view and fostering true agility through technical health, organizations can build environments where people, processes, and technology align to deliver extraordinary outcomes. Let’s stop blaming symptoms and start addressing root causes—together.
Kommentare