Why We Do All-Hands Support at Olark
olark.com
olark.com
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.
You have summed the standard customer support experience so distinctly.
When implementing an "everyone does tech support" system, though, remember that at least some of your employees won't have much trouble leaving if they find themselves hating the experience. When they have to deal with customer complaints, but can't do anything to fix them, they may well move to a company where that's not the case.
I think #1 is a feature, though. One of the ways a growing company can go bad is to make it hard for most people to solve customer problems.
The megacorp customer support model is basically just to put all the disempowered support people in Nowheresville, so that nobody "important" knows how much the customer experience sucks. Which is part of what allows startups to come in and savage their business.
But there's another path: you can also avoid the customer and staff frustration by empowering them to fix problems, and working hard to keep it that way as the company grows.
Here's where we see "culture fit" is arbitrary.
They do this for a few reasons from what I understand. It helps indoctrinate newhires to the NI culture. It also helps the people figure out what department they will enjoy and be a good fit into, as they will get exposure to a large part of the companies product portfolio.
> 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."
Having an engineer respond to level-1 support is actually incredibly expensive. Especially, given that you could hire someone else who had a job specifically to respond to those issues.
In the cases where companies do choose to put engineers on frontline (once they've scaled to the point they can afford to hire dedicated support), they need to make a choice about the kind of organization they want to build.
The organizations Jeff is talking about and the one you are alluding too sounds like a pretty horrible place to work, where people are overworked, and resources are not allocated where they need to be to move the product forward.
Building a great organization is a challenge, and we choose to build an organization where everyone on the team has a strong connection to the customer. We do this with a strong understanding of how our team wants to grow and specialize. When done right, all hands customer service can work really well to align the team around the customer.
But you point is well taken, at many startups this idea that engineers should be doing "one more thing", when they are already responsible for "all the things" could be overkill. My advice would be to first figure out how to divide up responsibilities so people could focus, and then have teams interact with their customers every once in a while to remember what it's like to use their product.
I think you'll be surprised at how many engineers actually enjoy talking to the people they are building their product for.
If you're a developer who is oriented around building products that sell and are loved by customers, it's pretty addictive to talk to customers to find out what they think of what you built.
In fact, this is one of the things that Steve Yegge cites in his famous essay [0] about how Google, organizationally, is better than Amazon:
And their operations are a mess; they don't really have SREs and they make
engineers pretty much do everything, which leaves almost no time for coding -
though again this varies by group, so it's luck of the draw.
It's not about asking engineers to do support because you don't have any support capacity. At Olark, we also have a dedicated customer support team. Same thing at FreshBooks where I used to work that also does all hands support. These teams are professionals, and are responsible for ensuring we have world class support practices.
So, we don't ask the engineers (or marketing or design) to be on support because no one else will do it. It's just the way we keep everyone close to the customer.
The Jeff Bezos story in Steve Yegge's post is exactly the reason why I like working at companies that keep engineers close to the customer. It cuts down the BS of opinionated product people thinking they know what customers want when they don't have real experience with customers.
I find you get a different perspective on what customers find easy and hard and this helps me develop my projects in a way that our customers will understand.
You could fix this by partitioning who supports what, but even that won't work completely. Is your accountant going to do support for your enterprise or consumer products?
Engineers at Zappos do support for just a few hours a year doing peak season after that onboarding. With a program called "Holiday Helpers" - http://blogs.zappos.com/blogs/zappos-family/2011/12/20/holid...
The problem with this is geeks are generally not business people and do not know if the client is up-to-date on their billing or if they are notorious for trying to get free work and need to be kept in check. When I do take personal interest in solving a clients issue I risk promising things I should not be promising them or putting way more time and effort into a client who is already behind on billing than I should be.
I also have a very hard time quoting a client an appropriate amount. I work for a interactive and design agency and when you work with us you have a team of individuals working for you including but not limited to an account manager, producer, designers, art directors, user experience, strategy, front end developers, back end developers, system administration in some cases. Having a team of 5-10 specialists working for you is expensive. Just having a 1hr meeting with everybody is probably going to get billed at around $1000. I feel really weird giving clients numbers like this and responding to the sticker shock.
-As an eng I was frustrated by it because I felt it got in the way of "real work" (I don't know if this was right or wrong - it just felt frustrating at the time).
-As a manager, I was frustrated by it because my engineers were constantly disappearing for customer support rotations.
But then I watched one of my friends literally eliminate 400+ hours a month of customer support time (as well as the less measurable corresponding customer frustration) by writing a small tool in an hour only because he had that first person experience with the issue.
I had no prior experience with Salesforce when I first requested access. I'm no Salesforce Architect, but I have a great grasp on the internals of it now all because my boss had a little faith in me.
More importantly, it's essential to understand the difference between the problem you head about today, verses the problem that customers have been facing for a long time. (I do think that support rotations cause a bit of a recency affect in prioritization for better or worse)
In the long run my argument is the closer you are to your customers the better insight you'll have in general. Because we all make a ton of decisions that aren't clearly specified, and we want everyone on the team to have the best intuition for the customer when they make those decisions.
The most interesting thing is that they gave every engineer time to fix the $#@! they heard on support. 30% of their effort was on internal tools.
Disclaimers. I also work at Olark. I also think Kevin Hale is (almost) perfect.
Introverted doesn't mean anti-social or shy.
I do agree that it is a great hiring filter though: we definitely want to work with people that can maybe step out of their comfort zone a little and get a new perspective on the product they build, and the people that use it. You don't have to be a social butterfly, but you shouldn't need to wall yourself off from your customers, or the rest of the company for that matter.
Some customers are just incredibly stupid. That's who Tier 1 support is precisely for: the kind of people who would suffocate in a wet paper bag. I walked into my manager's office one day and said enough. I developed 10 products used by over 250k users and I was the only developer at the company. Never again was I going to reset another password. I followed best practices and made it as easy as possible. Any further difficulty on the part of a user was not my problem.
One thing to consider is an inverse of customer support. Have your dedicated customer service rep handle only repeatable issues with a script.
Then you just say, "I'm going to escalate your issue to our Solutions Department, who are responsible for that type of issue. They will be able to walk you through the process."
But really, whatever you do, if you do email/chat support I'd be feeding every chat session/email exchange into an expert system, and trying to generate responses when possible.
Some kind of reality check.
(disclaimer: i work at olark)
However, I've seen companies use this to stretch the responsibilities of the development team to include customer support..and not hire anyone for customer support.
It was a disaster and I hated it...and eventually quit because of it.