Creating an Evolving Process to Address Customer Issues

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.