Bugs in Trust

While some software teams have instituted expensive zero-tolerance policies, most teams try to balance the priority of each bug against a mountain of other worthwhile demands. Both absolutist and pragmatist policies can be perfectly appropriate depending upon the nature of the software–for instance, I’d like the software that keeps my plane aloft to work 100% of the time thank you very much. But, if a gif of a panda rolling around in the grass pauses half-way through, it’s not the end of the world. For “system of record” software like Greenhouse, we’ve found our own tolerance level sits closer to “keep the plane in the air” than gif-stuttering consumer site, but we don’t bring everything to a halt if a button is 3px left of where it should be in IE10.

To bring clarity to how we prioritize our work, we have developed a new term that has found its way into our day-to-day conversations at Greenhouse, so I am writing this short article to share this term with the broader community. While we do make trade-offs in prioritizing certain issues, we have recently instituted a zero-tolerance policy for what we call trust bugs. Let’s define the term.

Trust bugs are distinct from other bugs, in that they cause the user to either:

1. not believe that the data as presented are correct, or
2. not believe that an action taken will reliably occur

Bugs in this category are distinct because they don’t just cause frustration, they harm the relationship between a company and its customer. Trust bugs create skepticism every time a button is pressed, or a list appears, and this eventually leads to customer churn.

Trust is much harder earned than it is lost, so don’t let trust bugs sit in the backlog.