Early Impacts of a Zero Bugs Policy
Some of our teams at Redgate have adopted a Zero Bugs Policy.
We’ve already shared some of our lessons learnt from this approach, but people have asked about the quantifiable impacts of the change.
So far we’ve seen two.
Impact on the teams
Of our two trial teams, one was effectively taking a Zero Bugs approach already while the other was faced with a significant change in how they work.
The team have already freed up 20 hours of time that would have been spent in various triage meetings.
This time has been spent engaging in better user research, investing in the architecture and behaviour of our products, and (unsurprisingly) fixing bugs.
Impact on the customer
That’s all well and good, but our greatest concern was negetively impacting our customers. Saving time wouldn’t be worthwhile if customers were unhappy with the support we were offering them.
We measure that happiness through Customer Satisfaction ratings (often called CSat). We kept a close eye on our CSat where the Zero Bug Policy was trialled.
We were initially worried by a slight (and seemingly-stable) drop in Customer Satisfaction. This led to some iterating on our internal process, reconsidering how we made the fix/no-fix decision and how we communicate this with customers.
After those teething problems we saw a significant rise in CSat, leading to our first ever month of 100% Customer Satisfaction.
What comes next?
We’ve very encouraged by early feedback, but can’t leave it there. We’ll continue to monitor Customer Satisfaction and see how it stabilises (staying at 100% would be wonderful but seems a little optimistic).
Unless there are more twists and turns, we’ll surely see more of our teams adopt a Zero Bugs Policy in the coming months.
