SD Expo Europe – From the other side!

Sometimes I wonder if being introduced to Support Driven has been one of the best parts of my career life so far!

Last year, I attended SD Expo in Portland. Whenever I become part of community events, my aim is to volunteer and help as much as possible. This is like my way of giving back to the community. Last year, I volunteered as Talk Editor – where I worked with few of the speakers, in terms of helping them with their slides or any other help they needed.

This year I moved to volunteering as Talk Co-ordinator for SD Expo in Belgrade. Wherein I was working with the Talk Editors who were further working with the Speakers. The responsibilities included but not limited to:

  • Helping Talk Editors with anything and everything. They can have questions from Speakers and my job was to help with answers to those questions by finding more details. They can also need your help in contacting a speaker for xyz reasons.
  • I was responsible for co-ordinating things to make sure we had the slides ready by time.
  • I had to make sure the master slide-deck was ready on time.
  • On the day of the Expo, I had to take care of Speaker Orientation and MC Orientation. This was a session to walk the speakers through all the details – in terms of how to find the room where they’re going to give the talk, when to arrive, how to keep track of the time etc.
  • I also took on the role of MC on the Expo day. This is where you introduce the speaker before their talk. You share some personal tidbits about them to break the ice before the talk.
Speaker Orientation Session

Takeaways and Contributions:

  • Volunteering as a Talk Coordinator is a good opportunity to test and improve your organisational skills. You’re literally organising a one whole section of the conference ie. Talks. I’m really grateful to Andrea for giving me this opportunity.
  • A great way to network with community members. I can say I am now good friends with all the Talk Editors that I worked with. We shared great memories while working together.
  • I was able to streamline the process further for future conferences by giving suggestions where I saw room for improvement. They’re added to the list then and there! ✅



This is my achievement. Those Kudos mean a lot to me. I used to dream of being able to contribute to the community and I’m doing it now! 😌

PS – Some other memories!

My connecting flight was delayed big time. I reached the hotel at 1:00 AM in the morning after an almost ~20-22 hours flight. But, I was up again at 6:30AM to start the day. Apparently, the excitement of being part of the conference took over and I wasn’t feeling tired at all. I was probably the only person in flip-flops! But hey-ho! I was enjoying! 😉😂

Speaker Orientation Session

This was the first SD Expo in Europe. I’m looking forward to many more in the future.

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


The Collection so far!

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.