Reducing noise and increasing your team’s focus through automation
Learn about how we streamlined and automated my team’s inbounds process using Slack & Zapier.
Most engineering teams have a someone “on-call”. Apart of handling incidents and pages, they are also the de-facto on handling any inbounds that are coming to your team. In our team, this was thankfully in a dedicated slack channel where folks across the company (developers, customer experience, enablement managers) would post their questions and the person who is on-call would review those questions and provide an answer.
Obviously, this came with a set of high level problems as you would expect
- there were open-threads of conversion which were unresolved or resolved partially
- there weren’t a proper follow-up process that would feed into JIRA or quarterly planning for the team
- and, huge impact on engineering productivity due to context switching which reduces overall developer productivity
Apart from this, we had another set of limitations. Due to the adhoc nature of how we received questions from everyone, we neither had visibility into which areas of the product was “problematic”/unclear to the users nor did we know how frequently similar issues popped up across multiple customers.
So, we took a 6 steps approach to improvise the current situation
- Streamline and structure the process
- Assess and understand problem areas
- Automate responses and next steps
- Leverage the experts
- Evolve your team process/culture
- Invest in product improvements.
Let’s dive in!
- Streamline (using Slack Workflow Builder)
As an Engineering Manager (EM), I am always looking for ways to improve the morale and developer velocity on the team. As someone who is very analytical and obsessed with metrics, I couldn’t fathom the overall hit to the team without being able to quantify the issue.
So I reached out to my IT team to understand the message patterns for my team provided by Slack Analytics.
We used to get around 400+ questions a month!, and that’s a LOT for a small team of 3–5 engineers and 1 Product Manager(PM). This only became worse as the product adoption grew and when we scaled our customer base.
To understand the types of questions and problem areas in product, I added a simple Slack Workflow Builder as follows
Once it is submitted, the workflow not only posted the message in the slack channel, but also wrote these information to a Google Spreadsheets to gather insights on the different dimensions.
2. Assess (using Google Sheets + Pivot Tables)
Regardless of whether your team is product, platform or infra focussed, the general category of questions that come from your customers (be it internal developers or external users), has the following similar flavors:
- How does this feature work?
- Why isn’t something working as expected?
- Can I enable this feature for a customer?
- Can I do this/that? Where can I find documentation on how to do something?
- Can I request a new feature?
Analyzing the trends using Pivot tables in Google Sheets, we realized a whopping ~40% of our inbounds were related to someone asking us about a behavior in the product and another ~15% were feature requests!
3. Automate (using Zapier)
Contrary to the initial approach of having the on-call engineer handle all the questions, the team came up with an idea to automate the requests based on the type of question. For example, a bug needs to be filed with JIRA, a PM needs to be involved for reviewing product behavior questions, all feature requests needs to go to product board, etc.
While I researched the different tools that would integrate not only with slack, but also with other productivity tools we use like JIRA/Product Board/Airtable/Google Sheets etc, Zapier came to my attention. Using Zapier I was able to automate next steps once a question is posted in the slack channel.
Note that with Zapier automation, the on-call engineer is only pinged when there is a urgent customer issue which is only ~5% of the time compared to before!
[Special thanks to my Technical Project Manager (TPM) for sorting out licensing, permissions and debugging connections between JIRA & Zapier.]
4. Leverage your experts
This helped reduce the load on the engineers, but, what about the PM who now needs to take on additional load to help answer product questions? The product team took the lead on this and negotiated having a dedicated Subject Matter Expert (SME) from the Customer Experience team to be embedded with the engineering team. They had a deep understanding of the product and helped answer questions, updated external documentation with help of a technical writer and educated our internal sales representatives on new and existing features of the product.
They also provided feedback on the workflow and automation, highlighted areas where we needed to improve internal knowledge base documentation and also communicated aggregated product feedback.
5. Evolve your processes
Great! Now that we have reduced the day to day noise, we had to have a much better process to triage through the bugs, the documentation requests and new product features that have been filed away in their respective tools. So we had plans to do the following:
- Daily: Add 15mins before our daily stand up time to review the backlog of tickets that are filed in JIRA. The goal is to use this time to triage and assign an explicit priority on the ticket and allocate accordingly. Please note that, what the requester might have seen as high or medium priority might be low based on whether it impacts one user, one customer or a who set of customers. Also, different priority warrants different SLAs (Service Level Agreement).
- Weekly: Hold an office hours every week where anyone could walk in and ask questions.
- Monthly: Dedicate one day a month for the team to make a dent on bugs and UI polish that is in the backlog. This time is also used to write additional documentation for our products.
- Quarterly: Review the list of feature requests and pull them into the product roadmap as part of quarterly planning.
We took on most of the above changes except for the weekly office hours which turned out to be not needed at all with other process in place!
6. Invest in your product
This might seem obvious, but investing in your product consciously is key! It’s a fine balance between building new features vs investing in technical and UI debt and taking out some dedicated time as part of your roadmap to work on them. We started understand two main areas of the product that had low adoption but high inbound rate and worked on rewriting them over the last few months. We also partnered with the Design team to refresh some of the dated and inconsistent UI elements in our products.
Overall, after a year of experimenting with automation, I can now proudly and successfully claim that the team faces less noise and more focus. As far as developer productivity — oh well, you know how that works, when one problem gets resolved, another shows up! 😉 Nah, just kidding! I can confidently say the on-call engineers are no longer dreading to be on-call and I even had one proud moment as an EM where an engineer on my team claimed they are looking forward to being on-call! That’s success, right? 😃
