You can read the original blog post here: https://www.nicereply.com/blog/control-quotient/
I used to notice and wonder how engineers are always crazy about maintaining their GitHub profiles. Its because that is where they show the work that they have been part of or have contributed to. But being in Support we have limited work related to Pull Requests etc.to use GitHub as our work graph or timeline.
So, I used to think of the alternatives where I could talk about the work that I have been doing in Support. It was never a question on whether I should blog about work or career, it was more about how do I take my work out there?
I wanted to start small and build interest in writing before I invested in maintaining my own blog. So, I started writing for Kayako’s blog. It worked well and helped me to build confidence. I learnt the art of blogging while working with our Growth and Marketing team. Later on,I signed up for Medium account and started writing there about my work experiences and general topics.
The passion for writing kept on growing. I wrote for Support Driven’s writing challenge, guest blogs for Freshdesk and Nicereply, and also thanks to Supported Content which provides me even more diverse topics to write on. By now, I was ready to have my own blog too where I wanted to list all my work and career related experiences through blog posts. There were two reasons why I wanted to go for it:
Some of the reasons why I think we should all write about our work and career is because:
I’d say that I can’t stress enough on the importance of writing about work or career related topics. It not only shows a timeline of how you have improved over time in your career but it also helps other people.
I wrote a blog for Freshdesk based on my experience of Onboarding a remote colleague in Support.
You can read the original blog here: https://blog.freshdesk.com/onboarding-remote-support-agents/
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:
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
I’ve always wanted to have a website listing all my work. This has been a dream since the days when I hadn’t even written any blogs or attended conferences. Then came a point when I thought that I’ve got enough stuff hosted at different places and its about time that I put it all together. But I still didn’t cross the finishing line to get started. And, finally one day I signed up for a domain name and a WordPress account to get started…..because when you start paying for a subscription you start making time to put things together.
After giving it a lot of thought I decided that it’s best to link all my existing work as it is and use this to be the place for writing new stuff going forward. So, here we go with the list of blogs that I’ve written so far and the webinars that I’ve given.