Bugs

Once upon a time I worked for a company. And this company was acquired by another company. The new big company, upon acquisition, set out to conduct a survey of our customers. It was explained to me that this survey was very intense, and very accurate. It would illuminate problems that we would need to fix. And I shouldn’t feel bad when we get a low score, because a low score was expected. This big company had been using this survey for a while, and, I was told, originally scored in the low 50s, but after much work they were very proud of their current score in the low 80s.

The survey was conducted. Our company scored a 96.

They were astounded. Scores this high for companies that had never utilized the survey were unheard of. I was unsurprised at our high score, because the survey was entirely customer service focused, and we were very good at customer service. In fact, most of our customers, if they left us, would come back later and complain about how awful the customer service of our competitor was. If a customer of ours was being forced to switch away from us by management or acquisition, they would lament having to leave us, because they knew we had great customer service.

The new company didn’t understand. Their customer service help desk was run very similarly to ours. So why did we score so much higher? I knew the answer: bugs.

See, the typical manner in which bugs are handled goes like this:

1. Customer runs into an issue and calls customer service.
2. Customer service tries to solve the issue with the methods they know.
3. If the problem cannot be resolved, a ticket is opened with details of the issue.
4. Product management takes the ticket, prioritizes it, and finds a place on the schedule to put it.
5. When the scheduled sprint comes around, the responsible team fixes the bug.

The issue with this process is that it can take months for a bug to get fixed. In fact, at most companies with traditional work sprints and product management, they often have to specify a “bug sprint” once a year where all engineering and development teams sets aside all other work to clear out the backlog of bugs.

At my company, the process went like this:

1. Customer runs into an issue and calls customer service.
2. Customer services tries to solve the issue with the methods they know.
3. If the problem cannot be resolved, customer service immediately consults with engineering.
4. Engineering drops their work and fixes the bug immediately.

Admittedly, my process results is many blown deadlines. We never delivered a new feature “on time”, which is why we never publicized new features until they were done. But, no customer was ever left “broken” until the bug fix could be “scheduled in”. A broken customer was always more important than a future feature. Always.

To me, this is obvious, and is evidence of why, especially if you are a small company, your development team should work closely with customer service. If your company is large, then you can probably afford to have a “bug team” that might only be one or two people whose entire job is to fix bugs as they arise so that your company never needs to have a “bug sprint” to clear the backlog. Backlogs should be for new features, future expansions, new technologies, etc. Fixing broken things should never go on the backlog.

Anyway, to finish the story, the new big company disagreed with me. They put up division between our product’s developers and help desk. They added a ticketing system and product managers who managed deadlines more than the product. They physically moved the engineers to the other side of the building to prevent us from having casual conversations with the help desk. And our scores went down. And our backlog grew. And eventually, I got fed up and left. I’m sure they are fine, still making money, even though I know they’ve lost a number of people. But I also know that the reputation of the company I helped maintain has fallen. And customers wait weeks, months even, to have bugs fixed.