As a developer, it’s easy to get caught up in writing good code instead of writing good software.
We all love new feature work and the process of creating things, but the reason we show up for work every day is to build a product for our customers. That’s why it’s so important that development and CX work side by side: Without constant communication with the people who are actually talking to your customers, the wrong things get done.
The purpose of a support engineer in a development team is to have someone in place to quickly address the customer-facing product concerns that come up on a daily basis, and serve as the bridge between the support team and the development team.
Whether a customer is having problems because of a bug that’s been in the system forever or because of something that just broke, it helps to have a person on the frontlines who’s ready to respond, and who can harness customer feedback into thoughtful output. By bridging the gap between developers and customers—and having a focused plan for what to prioritize—a support engineer can ensure that the right problems get solved at the right time.
Currently, every member of Nutshell’s development team takes two-day shifts rotating into our support engineer chair. Here’s how we do it, and what we’ve learned along the way.
THE ORIGIN STORY
When we first tested out a support engineer role in late 2014, there were only seven people on our Engineering team, and most of the requests coming in from our Support team were being handled by our senior engineers because they knew the code and could jump in more effectively. But that also pulled them out of the context of whatever they were working on.
A lot of the time when a new issue pops up, all the engineers want to jump on it because it’s a shiny new problem to solve. But if something goes wrong in a part of the product that’s not well-traveled and isn’t necessarily very exciting—customers having problems with their own integrations or setup, for example—engineers tend to avoid it because they know it will be a pain to fix.
Basically, we were running into a situation where our Support team felt guilty asking senior engineers to fix a problem, but they had no other choice. And similarly, since no one was directly responsible for fixing these problems, engineers would feel guilty just letting them sit there, and we weren’t giving the Support team the resources they deserved
Furthermore, since there wasn’t anyone responsible for managing the queue, we’d treat every customer problem equally, which is never a good thing to do.
The idea was, “Let’s specifically dedicate one person per week to handle these requests, on a rotating basis.” This would encourage newer engineers to talk to our Support team more often, and it would also force them to deal with the hairier parts of our code. Looking at old code and finding ways to fix it can be a fantastic learning experience, no matter how long you’ve been on the team.
The rotation helped alleviate the load that was on Support, but we quickly realized that one week was too long for a role like this. For one thing, there was more of an expectation back then that the support engineer could tackle a larger issue during their rotation—something that might take four days to fix, perhaps.
The reality is, bigger projects like that don’t work very well for a single person in isolation. Someone still has to review the code, which requires context-switching from other members of the team. And as great as it is for newer engineers to dig into old code and learn from that process, we don’t want them going into production data or modifying customer information without someone more senior being there to help them along.
A two-day rotation allows us to focus on well-scoped work that a support engineer can handle independently. We eventually decided that if something will require more than two days to complete, it shouldn’t fall on the support engineer’s shoulders.