Engineering
Getting support from a software company can be a painful experience. It's not unusual to spend 20 minutes on hold only to talk to somebody who is clearly reading from a script. They have no idea how to use the software they are supporting, let alone how to fix your issue. At HubTran, we want our support staff to be able to solve your problem quickly. That's why we've decided to have our development team provide our customer support.
I first started thinking about having developers provide support a few years ago. At the time, I was consulting with a company that had a dedicated support team. Developers did get sent support tickets, but by far the vast majority of support was handled with no developer intervention. One day, I happened to be walking by the support team and I heard somebody give a long series of instructions on how to work around a problem. After the call, I asked the support rep about what was going on. They told me that there was a certain situation that caused the software to get stuck. Apparently this was a frequent issue and the support team was great at walking customers through the workaround.
I was shocked! As a developer, I had never heard about this problem. In fact, it turned out to be an incredibly simple bug in the system. It took me less than 30 minutes to find, fix and test the solution. That 30 minute fix would go on to save hours and hours of both customer and support time. If I hadn't happened to walk by the support team, I never would have heard about this issue. When left alone, customer support teams become experts at working around bugs in software.
With HubTran, the development team provided support right from the start. We were building a minimum viable product and constantly had to push features off until later releases. By performing support, we were able to see how our decisions impacted real users. There were features that we had deemed nice to have that turned out to be critical to our users. When a user called and showed us how much extra work they had to perform due to our decision, we were able to quickly re-prioritize. Over time, we became much better at making these tradeoffs. The end result is that our developers have empathy for our customers. When we design features, we're better able to understand how it will impact real users. We no longer need user personas when discussing features, instead we can talk about how prospective changes will impact the real world users.
When developers provide support, it also forces them to work outside their area of expertise. For example, I spend most of my time working on the back end of HubTran. When I do support, however, I might need to investigate a UI issue or answer a question about customer invoicing. That pushes me to know more about parts of the system that I otherwise might not be exposed to. Of course, I'm not all alone. I can always ask for help from the people with more experience. Still, by providing support for the whole application, I get a broader perspective which helps me think about our application as a whole.
In some ways, developers providing support is similar to Test Driven Development. When doing TDD, you get quick feedback on the design of your code. If code is hard to test, the design is not quite right. When providing customer support, we get quick feedback on the usability of software. If a user asks how to perform a certain task, we probably have a design issue that needs to be addressed. If performance is slow in certain functions, we'll hear about it quickly.
Having your development team provide support isn't a silver bullet. For one, it's not cheap. A good developer typically costs more than a support person. In the short term, having a developer provide support reduces the number of features built per week. Longer term, I believe it leads to building the more valuable features earlier. By being better able to understand your customers, we have found that our team builds features that help our users without over engineering. Additionally, by thinking about support during the build phase, we make sure that new features are intuitive and easy to use.
Another drawback to using developers for support is that it is a source of constant interuption which can make it hard for a developer to do their day to day work. To deal with the interruptions, we have a rotating support person. Each developer takes a one week shift on support. During that time, their primary responsibility is customer support. If they have extra time, they might work on improving application performance or on improving support tooling, but that's just a bonus. If they find bugs or other issues in the software, they are responsible for triage. By carving out time for just support, we let our developers focus on solving our customers' issues.
Finally, effective customer communication is an under developed skill for many developers. Many developers communicate heavily using jargon and have a hard time putting themselves in a less technical user's shoes. We address this issue in two ways. First, we try to hire people with strong communication skills. As a remote company, our main interactions with each other are in writing. Anyone who can't communicate well in that medium will struggle in our environment. Second, we practice our customer communications. I frequently review our responses to tickets to make sure we're communicating effectively. Communication is like any other skill. With intentional practice, you get better.
One question I'm frequently asked is how does having developers provide support scale? So far, it's scaled incredibly well. In fact, over the last few months we've doubled the volume of business we handle. During that time, our customer support burden has been cut in half. We're finding that by fixing the confusing parts of the system and thinking more about the support impact of each feature, we're spending less time providing support as our business grows. Of course, that doesn't mean it will work for us in the long term. For now, I can't imaging providing support any other way.