2 ms·

Reporting bugs is an act of faith. It takes effort, and you have to believe that the effort will be rewarded. If people aren't doing it, it may be because their

Reporting bugs is an act of faith. It takes effort, and you have to believe that the effort will be rewarded. If people aren't doing it, it may be because their faith hasn't been rewarded in the past. But, I think customer support people are also trained (somewhat rightly) to shield the rest of the organization from complaints. They view it as part of their job to be the ones who handle stuff so other people can concentrate on other things. Sometimes they just get confused and take that too far. If you're in support, sometimes the people who maintain the product need you to run interference for them. Sometimes they need you to hold them accountable. The line can be a little non-obvious at times.

Faark 7y ago
Yes, good vs bad shielding is what it all comes down to. Some examples I remember from my struggles in the past: Working hard to remove duplicates is great, but frequent reports have to be signaled as urgent to the devs. Then there is the tendency to only forward stuff that is somewhat reproducible, especially for unique reports. This makes entire classes harder to get through. Sure I could find more... so yeah, many structural aspects of the job are set us up to break the link between customers and devs unless everyone is mindful.
- adrianmonk 7y ago
  I once worked with a pretty good customer support manager. They had two mechanisms for trying to handle that. Both were based on having the support people categorize issues. (Presumably based on error messages, some manual review, symptoms, etc.) They'd then compile a weekly-ish report of (1) top 10 most common issues they were seeing, and (2) issues that were new this week or went up a lot from previous weeks. That information as pretty easily digestible for the development team, and it helped us understand the size of the impact of known issues. And ones we didn't recognize, we could request more information on. The support manager also made a point that if a new issue came up and seemed to be particularly prevalent or major, they would proactively contact dev instead of waiting for someone to read a weekly report.

Faark 7y ago

Yes, good vs bad shielding is what it all comes down to. Some examples I remember from my struggles in the past: Working hard to remove duplicates is great, but frequent reports have to be signaled as urgent to the devs. Then there is the tendency to only forward stuff that is somewhat reproducible, especially for unique reports. This makes entire classes harder to get through. Sure I could find more... so yeah, many structural aspects of the job are set us up to break the link between customers and devs unless everyone is mindful.

adrianmonk 7y ago
I once worked with a pretty good customer support manager. They had two mechanisms for trying to handle that. Both were based on having the support people categorize issues. (Presumably based on error messages, some manual review, symptoms, etc.) They'd then compile a weekly-ish report of (1) top 10 most common issues they were seeing, and (2) issues that were new this week or went up a lot from previous weeks. That information as pretty easily digestible for the development team, and it helped us understand the size of the impact of known issues. And ones we didn't recognize, we could request more information on. The support manager also made a point that if a new issue came up and seemed to be particularly prevalent or major, they would proactively contact dev instead of waiting for someone to read a weekly report.