Creating an Evolving Process to Address Customer Issues
11 January, 2021

VP of Engineering at Ockam
Problem
My team was growing rapidly and at the same time, our product -- in terms of customers and practitioners using it -- was also growing rapidly. As a result, the number of issues we were getting from Support as well as from our community and GitHub in the form of questions was also increasing. The problem was that these issues spanned different areas; we were engulfed with GitHub issues, online forum questions, Support issues, internal questions from our Slack channel, etc.
While our engineers would work on their large feature work, they would get pinged to address some of those issues and that would be disruptive to their normal workflow process. I wanted to create a process that would allow my engineers to address those issues without being disrupted by them.
Actions taken
I created a community engineer role that was rotated throughout the team every week. One engineer would serve as a community engineer for a week, then pass the baton to another engineer, etc., and they would keep round-robin through.
The responsibility of a community engineer was to front-face and handle all ad hoc issues and requests. They would check forums, GitHub, Slack channels, customers support tickets, and during that week, they would be spared to work on any large features. That would allow my other engineers to focus and entirely dedicate themselves to their work according to the plan.
This worked well for quite a while, but as the team increased, so did these issues and one engineer who was on a community role was unable to handle them all. In our retros -- that we do every two weeks -- we came to the conclusion that it was too much for one engineer to handle. We decided to decrease that role and have a community engineer only do customer support issues, Slack questions and triaging GitHub issues (and putting them in our backlog).
Alongside that, we also decided to evolve the whole process. As a community engineer was triaging GitHub issues in our backlog, we were able to assign these issues during the sprint planning to specific teams/engineers. For example, one engineer would be assigned a large feature to work on and two or three issues that came through our community.
What helped us evolve the process was my commitment to ensuring that every voice is heard in retros. One of the engineers brought up that a community engineer is overwhelmed during their week of service, which instigated a discussion. Other engineers also agreed that it was taxing and hard to handle, and their concerns resulted in a solution that structured and solidified our process of dealing with issues.
Lessons learned
- The importance of having processes within the team is often underestimated. It implies that processes should not only be created but changed when needed.
- Most engineers prefer a “maker’s schedule” and are most productive when they can work undistracted and in continuity. Your job as a manager is to enable them to have the possibility to be focused and work in the most appropriate setting for them.
- As a manager, I wanted to encourage everyone to share their thoughts and not-fully-formed ideas. They need regular reassurance to propose ideas and I would do additional encouragement speech before every retro. My retros are never about what went well or didn’t go well; they are about what you would like to discuss. That helps hesitation go away.
Discover Plato
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Related stories
6 February
Internal Hackathons invite team spirit and collaboration which are critical whether an engineering org is co-located or operating remotely spread across 20 times zones. Hackathons give employees the opportunity to connect and network while they solve fun & relevant challenges.

Balki Kodarapu
Senior Director of Engineering at SupportLogic
5 December
Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.

Jaroslav Pantsjoha
Google Cloud Practice lead at Contino
25 October
Mrunal Kapade, an Engineering leader, based in Silicon Valley, shares tips that helped reduce attrition in the remote engineering teams while leading multiple teams from startups to Fortune 500 companies.

Mrunal Kapade
Director of Engineering at Inspire Energy
26 June
Individual Contributors are familiar with a technical development framework that helps them with building products. Managers, especially new managers can leverage a parallel framework to help them build their teams while drawing analogies from an already familiar framework.

Viswa Mani Kiran Peddinti
Sr Engineering Manager at Instacart
13 June
Roland Fiala, Senior Vice President of Engineering at Productsup, raises an interesting issue about autonomy in teams: does it hinder collaboration opportunities that lead to better problem-solving? He shares his system for promoting teamwork in engineering departments.

Roland Fiala
Senior Vice President of Engineering at Usergems