How Support Teams can support Engineering Teams!

2018-06-22 10.30.33-1

I’m going to summarise my talk at the SD Expo 2018 in this blog. The purpose was to share different ways in which Support can help the Engineering team in being more efficient and effective. (I’ve also attached the Slides at the end.) #supportforengineering.

I’m pretty sure at one point or another you would have heard your engineering team complain that X, Y, and Z information is missing from the JIRA ticket. Or, the fact that Support tries to get almost every bug prioritised as an important one. All these things lead to frustration and lack of productivity because you’re chasing each other for information and prioritisation.

I’m going to talk about some of the things which can help both the teams in terms of productivity and getting things done asap.

Make use of API responses:

We’ve learnt over time that it helps engineers to understand the problem quickly and easily if you add the API response when logging an issue.

Its simple: Right Click -> Inspect Element -> Network tab: Click on the API response to see the details (as shown in the example image below.

 

Log bugs with all the required details:

Its always a plus point to have a sample bug or feature request template but even if you don’t want to force your support team to use one, they should still cover all the handy information in it.

It should include but not limited to:

  • Exact steps to replicate the issue.
  • Any API errors/response as shared in the first point.
  • Exact environment details in which the issue was replicated. Eg: Browser, OS etc.
  • Actual Result that you get as of now following the replication steps.
  • Expected result from the functionality in question.

All these details in the ticket means you can avoid a lot back and forth communication for requesting details, not only between Support and Engineering but also between Support and the Customer.

Pro-Tip: Try to add some emojis and humour to the Jira tickets. It can have psychological impact 😉

Having a dedicated Bug Basher to prioritise bugs:

Well, yes, everyone’s reported bug is important to be fixed. But the next question is which one is more important among all the important ones. Having a dedicated bug basher means this gets prioritised (based on your selected metrix) , chased and done in a timely manner.

This will also ensure that the bugs get triaged before reaching the engineering team. I’m sure that you will agree that sometimes there are chances that the bug marked is not actually a bug.

Handling such exceptional cases at a triage stage can not only help you save your engineers’ time but it can also help you highlight where you need to train your team on….which brings us to the next point.

Develop in-depth product knowledge:

Along with general product training it’s also important that your support team is kept up to date with all the changes happening with regards to your product, be it rolling out new feature or a bug fix.

You need to ensure that your support team is the first to use any new product change that is going to be rolled out to the customers. This will not only help you with QA’ing but will also ensure that your Support team is able to answer any questions related to the change and can handle it independently.

Have Engineering<> Support meeting once a month:

This can help you bring more collaboration between both the teams. You can use this discuss things which can allow both the teams to compliment each others’ work. This is because you will get to hear from someone else’s perspective on how your work is impacting theirs and from there you can work on making things better.

In addition to all this it’s important to have brainstorming sessions with them. It will help you understand their way of thinking and working. Go for it even it means arranging them on your own.

While these things can make your Engineering team more productive, this also means better turnaround time for your customers which is a win-win for everyone involved.

 

Link to Slides: SD Expo

 

By sandeepkaur

Happiness Engineer @Automattic, previously @HackerRank and @Kayako. When I'm not day dreaming or binging, I'm working on writing something about customer service or reading a (Auto)Biography. When at work, I keep thinking of streamlining processes and connecting dots between things to simplify them.

%d bloggers like this: