Not having to deal with customers is a huge perk for a developer.
Personally I enjoy it and consider it the best thing to happen to my career. Couldn't do it all day every day but doing support on the side is rather enjoyable IMO.
Why We Do All-Hands Support at Olark
41–50 of 50 posts
Re: Why We Do All-Hands Support at Olark
#42That's neat, but when you've already optimized your password reset as well as you possibly can, now you're just throwing time and money out the window because of a dumb company policy and probably pissing off your most talented developers too. 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 off…
Some customers need hand holding.
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.
Re: Why We Do All-Hands Support at Olark
#43Highly doubt this scales past 30 employees unless your customer base is really small. Customer service should really be summarizing concerns, and you should verify the concerns by looking at data to see if it's really a concern worth alleviating.
Etsy does this (or did while I was still there) at 500+ employees. While they have dedicated CS reps, they also rotate everyone in the company. My experience with it was (literally) mixed. -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 con…
I had an inverted experience like this at my job. My job title is Technical Support. I do internal and external support for our company. We use Salesforce. By sheer luck I convinced my boss to allot me full system admin access to our Salesforce instance. I've gone to town improving our customer support workflow for our 100+ phone and e-mail reps by creating small tools and tweaks using Apex/VF Pages among other things.
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.
Re: Why We Do All-Hands Support at Olark
#44This is in pretty stark contrast to yesterday's article about devops: > 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 (whil…
My experience says that if you're responsible for building a product, it's way cheaper to be directly in touch with the end customer so you can fix what you're building. It's better than having a legion of product managers, sales people, business owners in between you and the user. 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 cus…
I disagree quite strongly. In theory it works like you suggest - developers see problems, and they're motivated to fix them in a permanent fashion so they won't ever have to deal with them again. In practice, there are multiple equilibria. The good equilibrium is what you describe and what I've summarized above. The bad equilibrium is that the team is short staffed and developers are too busy putting out fires to actually implement the architectural changes required to prevent the fires from starting in the first place. If you're building an organization where developers are expected to do operations work, you have to think about the latter case. If you don't, you can very easily fall into a trap where your core infrastructure stagnates because developers are too busy coming up with the next hack to fix the ongoing outage to step back and think about broader changes that will make the entire system less painful in the future.
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.
Re: Why We Do All-Hands Support at Olark
#45my company did this (out of necessity) back when there were ~10 of us. As a young developer, I didn't know any better, but I dreaded it. I was SO glad when we moved to a dedicated support team. Also, in my experience, if you are hiring good people, a dedicated customer support person is going to give your customer a MUCH better experience.
Obviously, but being exposed to real issues first hand will certainly give you a better insight on why it should be fixed.
Some kind of reality check.
Re: Why We Do All-Hands Support at Olark
#46This sounds like it works well for 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.
Re: Why We Do All-Hands Support at Olark
#47Earlier quoted context omitted.
My experience says that if you're responsible for building a product, it's way cheaper to be directly in touch with the end customer so you can fix what you're building. It's better than having a legion of product managers, sales people, business owners in between you and the user. 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 cus…
I disagree quite strongly. In theory it works like you suggest - developers see problems, and they're motivated to fix them in a permanent fashion so they won't ever have to deal with them again. In practice, there are multiple equilibria. The good equilibrium is what you describe and what I've summarized above. The bad equilibrium is that the team is short staffed and developers are too busy putting out fires to act…
As they say, there are an infinite ways to fail but only a few paths to success. If your engineering is so out of control you're constantly in crisis mode, you have more important problems than customer empathy. I think that's an orthogonal issue.
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.
Re: Why We Do All-Hands Support at Olark
#48I love this talk by Kevin Hale about their all hands support at Wufoo. https://www.youtube.com/watch?v=fAnl8ZGHVXU (alternate. https://www.youtube.com/watch?v=wYIH2qTizUU ) 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.
I love the talk. It's too sad to see Wufoo these days. All their great ideas about support disappeared after selling it to SurveyMonkey.
Re: Why We Do All-Hands Support at Olark
#49National Instruments does something interesting with their customer support. NI is one of those companies that hires mostly college grads then tries to keep people around forever. If you are a college grad hired into NI, will will spend 6-12 months in their customer support division. This applies to almost everyone regardless of degree. They do this for a few reasons from what I understand. It helps indoctrinate newh…
The MathWorks (makers of MATLAB & Simulink) do this too. For their new hires coming from an MSc/PhD, you spend the first 12-24 months in the Tech Support group as a Tier I with a rotating schedule of 1 week of phone/email support and the next week spent working on a project of your choice with one of the many Dev/QA/BaT/doc/etc groups. The idea is that once you've completed a handful of different projects, you've had…
As Mathworks customer, I've come to hate this, since this involves talking to clueless people with superficial information. Every question that involves something slightly more complex is dispatched to deeper support levels and regurgitated in a more or less screwed up way to me by the tier one guy/gal.
Re: Why We Do All-Hands Support at Olark
#50Earlier quoted context omitted.
The MathWorks (makers of MATLAB & Simulink) do this too. For their new hires coming from an MSc/PhD, you spend the first 12-24 months in the Tech Support group as a Tier I with a rotating schedule of 1 week of phone/email support and the next week spent working on a project of your choice with one of the many Dev/QA/BaT/doc/etc groups. The idea is that once you've completed a handful of different projects, you've had…
As Mathworks customer, I've come to hate this, since this involves talking to clueless people with superficial information. Every question that involves something slightly more complex is dispatched to deeper support levels and regurgitated in a more or less screwed up way to me by the tier one guy/gal.
I'm sorry your experiences have been less than positive. When I worked there I followed the path that I described above, and the other Tier I folks I worked with were nearly all smart and helpful. And whenever the customer had complex support questions and it was clear they were clued-in themselves, we usually were able to hand them over to the Tier IIIs to work things out directly between them.