21–30 of 50 posts
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 worked at a SaaS startup that did this, and found pretty similar benefit: quicker fixes, and a better understanding of real customer needs. 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 valua…
You have summed the standard customer support experience so distinctly.
I worked at a SaaS startup that did this, and found pretty similar benefit: quicker fixes, and a better understanding of real customer needs. 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 valua…
>" 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." 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.
This 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…
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.
Highly 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.
Not having to deal with customers is a huge perk for a developer.
(disclaimer: i work at olark)
It means you hire folks who can do customer support. That's definitely not an introverted engineer. Sounds like the benefits might even be worth the extra hiring filter.
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.
Not having to deal with customers is a huge perk for a developer.
well, depends. i like having to deal with customers since that makes me able to build a better product -- dealing with customers makes you realize what they want. (disclaimer: i work at olark)
Highly 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…
It means you hire folks who can do customer support. That's definitely not an introverted engineer. Sounds like the benefits might even be worth the extra hiring filter.
Introverted doesn't mean anti-social or shy.