The fallacy of sacrificing quality to build stakeholder trust
Have you ever experienced high pressure on your team?
I guess at some point you had to handle pressure at least from stakeholders. But what do product teams can do to cope with it?
Usually this will drive teams to make decisions that prioritize short-term gains over long-term sustainability. However, the seemingly innocuous act of sacrificing quality to rebuild the trust and let the pressure cool down on the team can have far-reaching and complex consequences.
Let’s leverage system thinking to explore the dynamics at play when using quality as a leverage point.
The easy choice of sacrificing quality
One of the easy option to rebuild this trust is for the team to deliver new features quicker. To do so product teams are sometimes forced to reduce the quality of the software.
Let’s use systems thinking diagram to show this choice. You can read it as the following: the more pressure on the team will bring less quality in the produced software.
How can you reduce quality?
There are many ways to reduce the quality of the software to save time and try to push in production new feature quickly such as:
- Unit testing
- General testing practices
- UI/UX
- Performance
- Security
- Design or architecture — increasing the coupling of the system for instance.
The first quick win is that you will reduce the time to market. Let’s complete our diagram with the time to market. This can be interpreted as : the lesser the quality is, the quicker the time to market will be. Or the other way around the higher the quality the more time it takes to ship a feature.
This leads to the outcome we are looking for, building more stakeholder trust to reduce the pressure on the team. We just identified our first reinforcing feedback loop in our system.
What are the real impacts on the team ?
The truth is that real life is more complex than this model. There is never a single loop describing an entire system.
So what are the other consequences of reducing quality?
By investing less in unit testing (or other kinds of testing practices) you will reduce the confidence that your code is actually behaving as expected. So now bugs are more prone to appear in your product.
So now the team will spend more time fixing bugs which directly impacts the team capacity to work on new features. With less time dedicated to work on new features, the time to market will be longer. We have identify our first balancing loop in the system which will not let the previous model to grow exponentially.
The impact on the surrounding environment and the consequences for the team
The more critical bugs will be introduce in the product the more customer will start to complain. This will impact directly the customer satisfaction. And it will eventually leads to calls directly to the CEO or the product team directly.
That’s another loop impacting the capacity of the team and the time to market ultimately.
Conclusion
At this point we identified the consequences of sacrificing quality. Sure it may help in a very short-term to rebuild your stakeholder trust as you will ship new features faster.
But you will not be protected from the other balancing feedback loops that will kick in the system. As you will produce more bugs this will ultimately impact the team capacity to deliver high quality features at a sustainable pace and increase the pressure from the stakeholders.
So the challenge is to find the way to write high quality feature at a sustainable pace that will both satisfy stakeholder expectations and ensure customer satisfaction.
In the next article we will review our current model to explore ways to tackle this challenge. By studying how organizations often react when pressure increase, we will try to spot potential leveraging points for the team to keep the pressure under control.
You can keep reading on the following article The Planning Trap.
