4 ms·

Hi, Support Engineering Manager here. This is an okay approach. But let's talk about where it breaks down: Bugs. Some premises: - The majority of Support Req

by lbotos 7y ago

Hi, Support Engineering Manager here. This is an okay approach. But let's talk about where it breaks down: Bugs. Some premises: - The majority of Support Requests are around bugs or administration. - Product teams are incentivized to ship features. - Bugs are often de-prioritized or "balanced" with feature requests. Solution: Embed an engineer (or build engineers out of support -- who will focus on support problems) and let them fix the bugs that are most important to support (and have full access to pair/partner with greater eng if the bug is gnarly.) This will reduce Product's backlog, and product can then focus on feature requests of which are usually ~15-20% of requests. Let that support engineer Build the tooling needed to make support more efficient. This is often a problem in orgs (getting eng resources for cost-centers) because it's not "product features". This process allows bugfix to circumvent the product planning and prioritization process and ultimately make for a better customer experience (where the bug can be solved quickly.) Product can still get customer feedback and focus on building new features, support solves their problem, and everyone is happier.

anon73044 7y ago
>Solution: Embed an engineer (or build engineers out of support -- who will focus on support problems) and let them fix the bugs that are most important to support (and have full access to pair/partner with greater eng if the bug is gnarly.) I suggested that once and Risk said it was a "Segregation of Duties" SOX violation. When asked if Support could prioritize bugs to the Dev teams responsible, I was laughed out of the meeting.
- lbotos 7y ago
  My understanding is that Support Engineers following CI/CD & Code Review process can't be a "lone ranger" so it follows the spirit of Segregation of Duties. But that laugh out of the meeting is real. I've experienced it too.
brettcvz 7y ago
It’s a neat idea! We have an “internal products” team at Clever that is tasked with building tooling for our support team (and all our other teams too!) that makes them more efficient. They are definitely worth the investment, and I’d encourage the approach to other companies. Re. Bugs - I actually really like the “top 2 things” approach for exactly this reason. It’s very illuminating when you as the PM are like “look at all these exciting things we have on the roadmap!” and your support counterpart responds with “my #1 request is that you fix this bug.” This is why I think that the customer facing teams can sometimes be better at doing this prioritization - even with lots of data about the size of a problem and anecdotes the pain, it’s still easy as a PM to not give it the appropriate attention, whereas the support team that lives with the pain will fight for it.

by lbotos 7y ago

anon73044 7y ago

>Solution: Embed an engineer (or build engineers out of support -- who will focus on support problems) and let them fix the bugs that are most important to support (and have full access to pair/partner with greater eng if the bug is gnarly.) I suggested that once and Risk said it was a "Segregation of Duties" SOX violation. When asked if Support could prioritize bugs to the Dev teams responsible, I was laughed out of the meeting.

lbotos 7y ago
My understanding is that Support Engineers following CI/CD & Code Review process can't be a "lone ranger" so it follows the spirit of Segregation of Duties. But that laugh out of the meeting is real. I've experienced it too.

brettcvz 7y ago

It’s a neat idea! We have an “internal products” team at Clever that is tasked with building tooling for our support team (and all our other teams too!) that makes them more efficient. They are definitely worth the investment, and I’d encourage the approach to other companies. Re. Bugs - I actually really like the “top 2 things” approach for exactly this reason. It’s very illuminating when you as the PM are like “look at all these exciting things we have on the roadmap!” and your support counterpart responds with “my #1 request is that you fix this bug.” This is why I think that the customer facing teams can sometimes be better at doing this prioritization - even with lots of data about the size of a problem and anecdotes the pain, it’s still easy as a PM to not give it the appropriate attention, whereas the support team that lives with the pain will fight for it.