4 ms·

Unless the dev team is super responsive, and well resourced, reporting bugs can soon feel futile for support. Then they become susceptible to internal fake new

by abraae 7y ago

Unless the dev team is super responsive, and well resourced, reporting bugs can soon feel futile for support. Then they become susceptible to internal fake news,e.g "I heard someone in Dev say they'd never fix that, it's too hard to test". Or "Dev seem to have a policy of only working on new features". As well, support knows that many bugs go unfixed for years/months, and/or the issues that do get fixed don't seem to make sense (to them anyway). So eventually they stop reporting or pushing for bugs. The next stage after that is that this world view gets propagated outside the company - support (maybe subconsciously) lets customers know that there's really not much chance of this issue being fixed. Then customers get the vibe that the product is not being maintained/ the company's priorities lie elsewhere. In turn the customers talk about themselves and perhaps move that little bit more towards going elsewhere. IMO it's a very dangerous situation and companies should take extremely strong measures to keep a positive mindset in the support team, whatever that takes.

adrianmonk 7y ago
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.

by abraae 7y ago

adrianmonk 7y ago

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.