Software development teams are pouring significant resources into improving developer experience and engineering efficiency. Yet many lack a meaningful way to measure whether these investments are actually working. As Chris Westerhold of ThoughtWorks explains, understanding and eliminating waste in software development is particularly challenging due to the creative, human elements involved.
"I think the easiest way to describe it is there is no one way to describe waste. As soon as you inject a human into a process, it becomes exponentially harder," says Westerhold. The complexity increases with team size and project scope, making waste difficult to predict and address.
Why handoffs and over-analysis drive engineering waste
Waste in software development takes many forms - from unclear requirements and handoffs between specialized teams to over-planning and underutilized tools. Identifying waste requires understanding what level of granularity you're examining and what organizational goals you're trying to achieve.
One of the most significant sources of waste is often found in the handoffs between specialized teams. Westerhold illustrated this with a client example: "One of the issues they have is that they don't have full stack developers. And so they have front end developers, they have backend developers, they have database administrators, they have QA, and so they end up with this, 'I'm going to pass it from station A to station B to station C,' and then they just move down the process."
This pattern creates compounding waste, especially when issues arise and work must cycle back through multiple teams for resolution.
He also described a situation where a team spent 15 months in the design phase for a fairly standard software project - not something highly specialized or complex. This kind of over-analysis prevents value delivery and can itself become a source of waste.
Misaligned goals prevent teams from solving the right problems
According to Westerhold, engineering challenges typically fall into three categories: people problems, process problems, and technology problems. Most teams instinctively jump to technology solutions when the underlying issues are usually with people or processes.
He points out that many teams simply aren’t aware of better approaches and lack the metrics needed to clearly define what’s actually wrong.
This misalignment often stems from a disconnect between engineering work and business objectives. Without a North Star to guide prioritization, engineering teams struggle to identify which improvements will provide the most value.
"I see a lot of engineering teams really struggle because they don't have a North star. Like, how do I identify the things that matter? I need to know what our goals are, what are we trying to accomplish as an organization?"
Reducing repetitive tasks increases developer effectiveness
Rather than focusing exclusively on developer productivity, Westerhold advocates for "optimizing for laziness" - creating systems that make repetitive tasks easier or unnecessary.
As a general principle, he aims to make systems easier by reducing the need for repetitive tasks, believing that the most effective developers are those who seek to avoid doing the same tedious work repeatedly. Systems should give them a way to accomplish this.
This approach leads to building platforms with "golden paths" that make the right way the easiest way, while still providing flexibility for specialized cases. Westerhold describes this as "bounded autonomy," a principle of giving developers freedom within reasonable constraints.
Tool fragmentation slows engineering agility and collaboration
One of the most common forms of waste in modern engineering organizations is tool sprawl. Westerhold recounted a client conversation about CI/CD platforms where, upon asking which platform they used, he discovered that different teams relied on a wide variety of tools—including Azure DevOps, Bitbucket Pipelines, TeamCity, Octopus Deploy, Jenkins, and GitHub Actions.
This fragmentation creates a landscape of complexity that makes it difficult for engineers to move between teams and for the organization to be nimble. Rather than standardizing by mandate, Westerhold suggests building platforms and standards "with your community, not to your community."
Treating AI as a coding companion improves code quality
AI tools are transforming software development, but without proper strategy, they can accelerate waste generation rather than eliminate it. Westerhold distinguishes between "tool thinking" and "system thinking" when adopting AI:
"There is a difference between system thinking and tool thinking. If I've heard this once, I've heard it a million times: 'We implemented copilot last year, and we've seen nothing. We've seen almost no impact at all.'"
The problem, Westerhold explains, is that many organizations view AI merely as a way to generate more code faster, rather than as a way to rethink value streams and systems. Instead of treating AI as just a code generator, he recommends using it more interactively - engaging with it as a “coding companion” to ask detailed questions about specific sections of code, not just requesting blocks of code for particular tasks.
This approach leads to higher quality output rather than just more code, which may contain more bugs and complexity.
Incremental improvement delivers lasting transformation
Ultimately, Westerhold's insights reveal that eliminating waste isn't about adopting a single tool or methodology. It's about a fundamental shift in mindset. The journey begins by establishing a "North Star" that aligns engineering efforts with clear business objectives. From there, the solutions flow naturally: breaking down silos with full-stack teams, granting "bounded autonomy" to empower developers, and building standards with your community, not for them.
Even the adoption of transformative technology like AI requires this systemic view—treating it as a collaborative partner to improve code quality, not just a factory for generating more lines of code.
This path doesn't require a massive, disruptive transformation. As Westerhold puts it, the goal is to be "a little bit better tomorrow than you are today." By fostering a culture of continuous, incremental improvement, you can look back in a few years and realize you’ve built a truly efficient, agile, and effective engineering organization.
Listen to Chris Westerhold's Dev Interrupted episode:
