As first engineer, I've been at Olark for a while (three years this March!), and support has been one of my roles since the beginning. When it was just the five of us (and the odd intern here and there), that just made sense--nobody wanted to burn out on our support volume. It helps that all of us were, to some degree, "people who like people," but as time went on and the team grew and grew, it stopped being something we had to do, and started being a part of our culture.
We started seeing it as a natural outgrowth of our personality as a support company, and we kept the tradition--even now, on any given day, you might find any of our Olarkers on chat, whether it's a co-founder or our newest hire. And we will probably never take that away. We've gotten a lot of benefit out of putting everyone on the front lines and we encourage you to do the same.
Support is a technical problem
Support is actually a lot of things--it's expectation management, it's communication, and its problem solving. In a lot of teams, the first line is mostly responsible for the first two of those, but when you get right down to it, the source of the problem is probably a technical issue, and who better to solve a technical issue than the engineer whose fault it is in the first place?
I've spent a lot of my time at Olark communicating directly with the stakeholders and discovering their pain points. There's no ticketing system in the world that can really convey a customer's emotions like a one-on-one chat, and being live to ask questions and get feedback really helps move the process along. I get a personal investment in seeing the problem solved. It's more likely to come to my mind when I'm figuring out what projects to tackle next and the customer is going to feel more secure knowing that, at the very least, an engineer has been notified of the issue.
The customers aren't the only ones feeling the love. Some of our staff work support as their main concern, and having an extra conduit for empathy with them is a great benefit. Communicating about issues and transferring knowledge is easier, because we all have this same starting point--we might have even both talked to the same customer who reported the issue. A little common ground goes a long way to communicating, and we all appreciate the value of easy communication.
But I could be engineering!
There's no question that the time I spend on chat, or responding to tickets, or guiding one of our many international users through installation over a language barrier (thank you, Google Translate!) is time I could spend building the next generation of Olark's back-end.
But we've found that this equation isn't completely straightforward, and it's certainly not a zero-sum game. Part of going forward in engineering is being able to clean up what is already there, and anyone reading this who's ever done some dev work knows that sometimes it takes a little kick in the pants to get that cleanup done when there's more "exciting" work around. Actually having a stake in customers' problems might even make us more motivated to make software that doesn't have those problems in the first place!
While I might be able to point to a time or two where a project I was working on would have been released earlier without my support responsibilities, I can point to even more times where early intervention caught an issue that would have taken many more engineering cycles to fix later on.
It's hard to be concrete about this without also getting a little technical, but suffice to say that customer problems and Olark's future are closely intertwined, and solving one doesn't come at the expense of the other, not by a long shot. If you're making Something People Want(tm), the technical support you do will directly reflect how those people are using your product, and keep your feet on the ground as you go forward.
Great! Should we do the same?
All-hands support is great for any team that can do it, whether you're mining hockey game viewing data for advertising insights, building an app store for the security conscious, or coordinating knitters of hand-knit koala sweaters. Ultimately, feedback from your users is what drives your product forward--you have to build a mechanism for collecting that feedback, so combining that process with solving their problems is a logical step.
It will personalize your features--you know exactly how Bob wanted that UI widget to work, and maybe he'll even thank you in person the next time he sees you on chat. It will motivate you to think of your development process as a way to make other people happier, more engaged, more in love with your product. Personally, I wouldn't have it any other way.
