I’ve been meaning to write this post for a long time. The comment that sparked it (left by Tom Hudson on my Zero Defect Policy post) is from July of last year.

It has been sitting in my backlog, staring at me. But frankly, acknowledging that I prioritised other work over this blog post is perhaps the perfect introduction to the topic at hand.

Tom asked a crucial question about the reality of new feature development versus the aspiration of Zero Defect Policies:

“I can’t imagine the stance of fixing everything would work in most places… what about new features with defects? What stance do you recommend then?”

It’s a valid challenge. In a perfect world, we would never knowingly release a defect. But as I explored when asking “but which one is of higher perceived quality?”, technical perfection does not always equal customer value.

This tension between “doing the right thing” and “getting things done” is where Engineering Leaders earn their money. It requires a trait that can feel uncomfortable to a perfectionist: Pragmatism.

Zero Defects is an Aspiration, Not a Dogma

As I mentioned in my reply to Tom, I view a Zero Defect Policy as an aspirational commitment. It is the “North Star” that guides our structure and processes, ensuring we have a clear view of our quality debt.

However, aspiring to zero doesn’t mean delaying a release indefinitely for a cosmetic issue. There will always come a time when the commercial pressure to release a new feature outweighs the potential impact of a known defect.

Active Pragmatism: Managing Risk, Not Just Bugs

So, how do we handle this without becoming reckless? We move from being “Gatekeepers” to Risk Managers.

When we identify a defect in a new feature but the deadline is looming, “Pragmatism” isn’t just shrugging and saying, “Oh well.” It is a structured process of assessment:

  1. Quantify the Risk: Does this defect block revenue? Does it damage trust? Or is it just a bit jarring?
  2. Inform the Stakeholders: Ensure the Product and Commercial teams understand exactly what is broken. No jargon—just business impact.
  3. Plan the Recovery: If we ship this, how do we mitigate the fallout?

The “Disaster Recovery” Mindset

This is where Modern Quality Leadership shines. Instead of blocking the release, we advocate for resilience.

If we are releasing with known risks, we need a safety net. This might mean:

  • Feature Flags: Wrapping the new feature so we can turn it off instantly if the defect causes more noise than expected.
  • Gradual Rollouts: Releasing to 5% of users first to assess the real-world impact of the defect before a full launch.
  • Mitigation: Can we make a small change to the feature or UI so the defect is less jarring, even if it’s not entirely fixed?

Summary

In Quality, we often need to have strong opinions around “doing the right thing.” But we also need to be problem solvers.

If a bug doesn’t impact the customer’s ability to derive value, and fixing it delays that value, then shipping isn’t a failure of quality. It is a calculated commercial decision.

Pragmatism isn’t about lowering your standards. It’s about ensuring that your standards serve the business, not just your engineering pride.

Join the flock

Subscribe to get the latest posts on the messy reality of software delivery sent directly to your mailbox. I regularly share new thoughts on leadership and strategy —zero spam, just value.