This is another question I have received a lot in my coaching sessions, and, similar to the question about the team dedicated to innovation, I believe its answer can also be of interest to more people. In this case, the short answer is “no,” and we will see that this topic does not leave room for a “it depends” type of response. Let’s dive deeper.

Your code, your bugs

If you build something, you are solely responsible for the quality. If what you built is not working as expected, you are responsible for fixing it. It’s as simple as that. It doesn’t make sense to have a different team fixing bugs created by different people. The individuals most capable of fixing a bug are the ones who created it. In fact, this is the best incentive for people to create fewer bugs.

What about legacy systems?

In a legacy system, the team inherits code they didn’t write. Usually, the individuals who wrote the code are no longer with the company. In this case, does it make sense to have a dedicated team to fix its bugs? Ideally, no. The responsibility for the legacy system should fall on a team that will address the bugs but will also work on improving and evolving that legacy system. A common strategy for dealing with legacy systems is the strangulation strategy: slowly drain the life out of a legacy system by gradually replacing parts of it with a modern implementation.

Another important aspect of a legacy system is that it’s not always necessary to fix its bugs. Sometimes, fixing a bug in a legacy system can be costly because no one has enough knowledge to debug the system. In some cases, instead of fixing the bug, we can address its root cause by applying some alternative fix that makes the legacy system deliver the expected result.

In such cases, a strategy called “monitor and apply workaround” can be applied. Once we discover a workaround for a particular bug, likely developed outside the legacy system, we monitor the undesirable behavior, and when the behavior occurs, we automat- ically apply the workaround. It’s the idea that, depending on the overall health of the patient, some illnesses are better treated with medications than with surgery.

Should we dedicate part of our time to fixing bugs?

Again, the answer is a simple “no.” We should deliver products of good quality. Any user prefers to use a high-quality product that behaves as expected. This is a necessary condition to provide a good user experience.

In addition to the user experience, there’s another important aspect to consider when it comes to quality and bugs. Whenever someone has to work to resolve a bug found in a digital product, that person needs to stop working on whatever they were doing at the moment to fix the bug. This is an interruption in the workflow. If that person could deliver the software without that bug, they could continue working on new things without interruption, making them more productive.

In a team I managed, we tracked the percentage of new items de- ployed and deliberately created OKRs to increase that percentage. In 2 years, we managed to go from 50% of new items deployed to 90%:

Percentage of new items implemented.

In my experience, instead of fixing the amount of effort dedicated to bug fixing, it’s more productive to focus on creating bug-free, quality code. To do this, we should track the percentage of work spent on bug fixes and actively manage to decrease that number.

Digital transformation and product culture

This article is another excerpt from my newest book “Digital transformation and product culture: How to put technology at the center of your company’s strategy“, which I will also make available here on the blog. So far, I have already published here:

• About the book
• Part 1: Concepts
  • Chapter 1: The so-called digital transformation – Project and Product
  • Chapter 2: Uncertainty and digital transformation
  • Chapter 3: Types of company
  • Chapter 4: Type of company vs digital maturity
  • Chapter 5: Business models
  • Chapter 6: Agile, digital and product culture
• Part 2: Principles
  • Chapter 7: Deliver early and often – Measuring and managing the productivity – Case study: Dasa Group – Case study: Itaú Unibanco
  • Chapter 8: Focus on the problem – The Famous Product Discovery – Why the “business demands => IT implements” model does not work – Case study: Magazine Luiza
  • Chapter 9: Result delivery – Outsource or internal team? – Case study: Centauro
  • Chapter 10: Ecosystem mindset
• Part 3: Tools
  • Chapter 11: Product Vision – Product vision examples
  • Chapter 12: Product Strategy
  • Chapter 13: Team Structure – Structuring effective product development teams – Structural teams – Team structure spreadsheet – Downsizing and layoffs – CTO + CPO – Internationalization – Outsourced team – Tuckman model – Dependencies between teams – Should we have a dedicated innovation team? – Should we have a team dedicated to fixing bugs?

Scale your customer research

In a world where AI levels the playing field, deep customer knowledge is the one asset your competitors can’t copy. ReveLumi was built exactly for that. Learn more at revelumi.com.

Workshops, coaching, and advisory services

I’ve been helping companies and their leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) bridge the gap between business and technology through workshops, coaching, and advisory services on product management and digital transformation.

Gyaco Podcasts

At Gyaco, we believe in the power of conversations to spark reflection and learning. That’s why we have “Product in Focus” (Produto em Pauta in Portuguese), a podcast that explores the world of product management from different angles:

• Mentoring Sessions: In this series, I share real mentoring conversations with product people. One person’s questions are often the questions of many. Together, we explore concrete challenges and turn experience into practical insights you can apply to your own context.
• Beyond the Buzzwords: In this series, Felipe Castro and I demystify product terms with real examples from our clients.

Available on YouTube and Spotify. Recorded in Portuguese, with English subtitles on YouTube.

Digital Product Management Books

Do you work with digital products? Do you want to know more about managing a digital product to increase its chances of success, solve its user’s problems, and achieve the company objectives? Check out my Digital Product Management books, where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Digital transformation and product culture: How to put technology at the center of your company’s strategy
• Leading Product Development: The art and science of managing product teams
• Product Management: How to increase the chances of success of your digital product
• Startup Guide: How startups and established companies can create profitable digital products