Back to resources

Creating an Evolving Process to Address Customer Issues

Users
Team Processes

11 January, 2021

Sabeen Syed
Sabeen Syed

Senior Engineering Manager at HashiCorp

Sabeen Syed, Senior Engineering Manager at HashiCorp, explains how she initiated a process to address customer issues by creating a community engineer role that further evolved over time.

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

The Art of Asking Why: Narrowing the Gap Between Customers and Users

24 May

Jord Sips, Senior Product Manager at Mews, shares his expertise on a common challenge for product managers – finding root causes and solutions.

Customers
Innovation / Experiment
Product
Personal Growth
Leadership
Stakeholders
Users
Jord Sips

Jord Sips

Senior Product Manager at Mews

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

The Optimization and Organization of Large Scale Demand

4 May

Kamal Qadri, Senior Manager at FICO, drives the importance of setting expectations when optimizing large-scale requirements.

Managing Expectations
Delegate
Team Processes
Prioritization
Kamal Qadri

Kamal Qadri

Head of Software Quality Assurance at FICO

Combining User Research with Testing to Build a Successful Product

20 April

Waldo Vanderhaeghen, VP of Product at 3YOURMIND, details an experience in product discovery, analyzing user research, and testing.

Innovation / Experiment
Product
Conflict Solving
Feedback
Users
Waldo Vanderhaeghen

Waldo Vanderhaeghen

VP Product at 3YOURMIND

The Importance of Slow Rollouts in Product Development

13 April

David Pearson, Sr. Engineering Manager at Square, explains the importance of slow rollouts for launching new product features.

Product
Feedback
Strategy
Design
Users
David Pearson

David Pearson

Sr. Engineering Manager at Square

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.