Why We Do All-Hands Support at Olark

> Somewhere along the way, however, we tricked ourselves into thinking that because, at any one time, a start-up developer had to take on different roles he or she should actually be all those things at once.

> What began as an experiment aimed at increasing software quality has become a farce, where the most talented employees are overworked (while doing less, less useful work) and lower-level positions simply don't exist.

> Large companies love this, as it means they can hire far fewer people to do the same amount of work. In the process, though, actual development becomes a vanishingly small part of a developer's job.

http://jeffknupp.com/blog/2014/04/15/how-devops-is-killing-t...

I certainly wouldn't be happy with a developer position that made me do tier 1 customer support. That stinks more of "absurdly cheap" than "connecting with customers."

Eventually we made it optional though, because we found that a minority of our developers really disliked it. Which I can understand- not everyone enjoys interacting with customers and answering dumb questions like "can you reset my password?"

I personally found it really valuable, though. After the hundredth password reset request, I was pretty motivated to make our password reset function easier to find. :)

Some pitfalls to be aware of, though:

1. This only works when the people doing support feel empowered to improve things, either because they can do it themselves or because they feel they are listened to by whoever can. For example, I can say to our founder over lunch: "People have been complaining about X a bunch this morning. How about we do Y to address that?" Then we'd discuss it, and I could build it that afternoon. For smaller fixes, it was often just posting on our group chat: "Hey, I'm fixing A by changing B" and merging it if no one objected.

Without this ability, though, it could easily get frustrating. If you're being forced to deal with repeated customer issues you have no power to address, it can feel more and more like an unproductive burden.

2. It can have trouble scaling with the complexity of your product. We were targeting small businesses when I started, and I was able to answer most questions about our product by myself. As we got bigger, though, and started introducing more complicated features aimed at the needs of larger companies, there were more and more features that I didn't have a solid grasp on. I probably could have kept the whole product in my head a lot longer if I were a full-time support worker, but as a dev I only did 5-10 emails per day,a nd didn't have the time to devote to learning some of the more esoteric aspects of our product.

3. Not everyone is cut out for customer service. We tried to hire good developers with personalities we wanted to work with. That often, but not always, overlapped with the type of communication skills necessary to be an effective support person. We had a few developers who lacked the patience to deal with slower customers, or weren't really good at explaining things clearly to them.