6 ms·

Kayak.com co-founder Paul English on this topic (2010): "The engineers and I handle customer support. When I tell people that, they look at me like I'm smoking

Kayak.com co-founder Paul English on this topic (2010): "The engineers and I handle customer support. When I tell people that, they look at me like I'm smoking crack. They say, "Why would you pay an engineer $150,000 to answer phones when you could pay someone in Arizona $8 an hour?" If you make the engineers answer e-mails and phone calls from the customers, the second or third time they get the same question, they'll actually stop what they're doing and fix the code. Then we don't have those questions anymore." https://www.inc.com/magazine/20100201/the-way-i-work-paul-english-of-kayak.html https://www.inc.com/magazine/20100201/the-way-i-work-paul-en... (This is of course a bit different thing, probably he's not suggesting to having those engineers take the calls middle of the night).

wink 8y ago
This sounds so nice in theory. All those pesky developers refusing to fix their horrible code. While in reality at least in my experience the developer would be very much happy to fix the code, it's just that you don't get any time to do that. It's only new features and new products.
- WrtCdEvrydy 8y ago
  Bug fixes don't sell your software unless it's a heavy customer product.
  - stevoski 8y ago
    In a SaaS business, bug fixes can help reduce churn. A simplistic description is, "sales and marketing increase MRR, a quality product decreases churn". Often a company becomes financially viable by fixing churn.
  - mamcx 8y ago
    Not..exactly. Maybe is only a local thing in my country, but you will surprise what is called "features" and "bugs" from non-developers. (features: Everything including bugs bugs: Everything that is annoy and not allow to continue... but sometimes also called features) I mean, are intermixed ALL the time. I literally this week was working in a feature (that was, in reality, a bug) meanwhile only talking to my partner that give support and see him ignoring a red modal windows with a error message (oh, that is not a bug, it allow to work(???)). You can turn the bugs and anti-features of the competence in your own selling points (our product sync the offline database without the need to have a operator that restart the service and click on "sync" in the dashboard!!!) and stuff like that...
- Cthulhu_ 8y ago
  That's exactly a reason why a company should consider having their engineers do support - by the sound of it, there's a support department who - MAYBE - accumulate common questions and send them to a product owner, but in practice they won't and in practice the PO ignores it because there's more important things - in his/her mind - that have precedence.
  - dboreham 8y ago
    Pro tip: have your managers do customer support .
    - icedchai 8y ago
      That would be nice, except most are simply incapable. They forward the requests to the dev team, causing interruptions, distractions, and aggravating engineers.
      - bobwaycott 8y ago
        Sounds like those managers need to be replaced. A manager ought to foremost protect the dev team from interruption, distraction, and aggravating or time-wasting requests.
        icedchai 8y ago
        I agree. That's why I moved on from that place.
- btschaegg 8y ago
  > This sounds so nice in theory. All those pesky developers refusing to fix their horrible code. This might be the niche I'm working in, but that does not sound all that unreasonable to me; I certainly know the type. At first, there is a debate whether there really is a bug (instead of giving a trained user and the according support staff the benefit of the doubt), then there is a debate whether the bug should really be fixed or the thing is delayed at nauseam ("need more information" without even having skimmed the damn code at least once). And when the business side finally puts their foot down, the defect is "fixed" with some minimalistic, ad-hoc duct-tape solution that guarantees that five other bugs will pop up in the future because of it. So while I agree with your second point, that doesn't invalidate the first. These kinds of devs actually do exist (with various degrees of intensity, of course). I'm not sure if the archetype is really fit support work, though.
- tristor 8y ago
  It's actually more complex than that, even. I'm speaking from being an engineer for some time (~13 years) and a product manager now. The issue is that Customer A, B, C, D, and E want Feature A to behave in one way, and Customer N, M, O, P, Q, R, S, T, U, V want Feature A to behave in another way, and those two ways are mutually exclusive insofar as it can't merely be configurable, since Features B-F rely on Feature A behaving in one way or another. So which set of customers do you please? How do you ensure that customer requests for behavior changes, or customers being surprised by application behavior doesn't result in a scope creep that expands the requirements of your application to an unsustainable level? How do you ensure that your business doesn't get coopted by BoM (Buckets of Money) to basically be a contract development house and eventual acquisition target by your largest enterprise customer while ignoring/harming all your other customers who were earlier adopters? There's a lot of jokes about bugs actually being features, but at some point if an application behaves in a certain way long enough and that behavior is relied on elsewhere, changing it is a new feature with all the consequences that come along with that, even if the new behavior is strictly more correct. All of these factors need to be balanced in determining what the best path is to tread in your software. At a certain scale, most of these questions can be addressed organically, maybe by the developers themselves, but at a certain scale it's just not feasible to interface customers directly with developers. You are working on "new features and new products", because customer issues get turned into identification of new markets to solve those issues, which are serviced by new features and new products rather than by "fixing" the old products and features, which would break it for other customers.
  - stevoski 8y ago
    That's a great description of the subtleties of product development, especially within a small team. Many books and articles make it seem like a simple procedure, but actually you often face decisions which will leave some people unhappy, no matter what you decide.
    - Novashi 8y ago
      You basically have to get into supporting extensions or custom code and supporting an API if you run into enough of these customers and that’s when you declare that you only have so much responsibility for the customer’s code (and it quickly turns into another support revenue stream).
- lbotos 8y ago
  > While in reality at least in my experience the developer would be very much happy to fix the code, it's just that you don't get any time to do that. It's only new features and new products. I agree. At GitLab, I'm trying to build our "Support Engineering" group into people that have the time and mandate to fix the things that spring up leaving product devs to focus on new features. It's been working pretty well: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16511 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16511 (40% view speedup) https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name[]=support-fix https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope...
- user68858788 8y ago
  I've worked as a developer oncall, and as dedicated support engineer oncall. You're absolutely right - management will absolutely refuse to allot time to improvements and bug fixes when there are features to make. It's frustrating being a Dev and knowing how to fix an issue, but not given the time to fix it. It's equally frustrating to cut tickets and mail reports on issues to see them sit forever in the backlog.
- rconti 8y ago
  I bet the developer's a lot happier to fix the code when the impact is more severe than yet another ticket.
brobdingnagians 8y ago
I agree (conservatively). I don't like taking customer calls, and doing it a lot seems like it could waste valuable time, but I think it is important for engineers to at least occasionally interact with customers so that they understand what this darn piece of software is _actually_ supposed to do. We can sometimes get caught up in feeling like we know what it is supposed to do and implement it, only to find out (or even worse not find out) that people use it entirely differently. The other thing is that you get familiar with the "type" of problems that arise. This helps you communicate with customer support when they call, or know what questions to ask to get to their issues. I've had customer support complain about an issue or feature request they have never told us about but have had pain points and customer requests for months. It is always a trivial change. Improving communication between customer support staff developers is hugely valuable however it happens.
- notyourday 8y ago
  I subscribe to Tom Siebel's view of taking customers calls -- unfortunately I have to paraphrase it as I don't remember the exact quote: << If they pay us enough money for me to notice when they no longer do, I will take their call at any time and so will you >>
kyle-rb 8y ago
>the second or third time they get the same question, they'll actually stop what they're doing and fix the code. This is great for actual issues, but what about the genuinely stupid questions? Or the customers who basically just refuse to read the Help section before contacting customer support? From my experience working in support, there are a fair amount of those. And those just seem like a waste of the engineers' time.
hinkley 8y ago
My very first job was tech support and then QA (because fewer bugs means less email) for a small team working on a popular product. I started informing the developers every 2nd (or maybe it was 3rd) time I saw different people experiencing the same problem. So by the time we'd had around 8 people reporting the same issue they'd gotten tired of seeing my face and fixed the bug. It's the feedback that's important. A little friction in the path could be a good thing, as long as the people providing the friction have an incentive to do the right thing. I sat one room over from the devs, I was friends with one of them, (had designs on switching teams) and we all went to the same planning and status meetings, so my head was in the right place for this. I recall many many years ago Dell cancelled a plan to move front-line QA overseas because they realized that there was a perverse incentive for an external team to keep quiet about frequently asked questions (because they're cheap to answer and you get paid by the call). Those people in Arizona won't give a damn about how many people can't figure out the app, so long as users keep calling (ie, just good enough that you retain customers).
OnlyRepliesToBS 8y ago
sadistic sociopaths willingly wire up a pain pathway directly to the people doing the building of the software. that's really messed up. why the fuck would you want to add public facing inhibitory pathways to the ones literally creating your software.. and then delude yourself into thinking that's a net positive? like a public facing ms sql or telnet server, it ain't a good idea. people who don't give a shit about the sheer amount of negativity of that inhibitory pathway as it goes to infinity on a sinking ship destroy the creation pathways through shit like this.. and then parachute away.
mikeash 8y ago
The trouble is that 90% of your calls will be due to user error, and the vast majority will be something you just can’t improve, like people misspelling their own names.
- cco 8y ago
  Neither one of these problems are, "things you cannot fix".
partycoder 8y ago
That's what PMs are supposed to be for.

wink 8y ago

This sounds so nice in theory. All those pesky developers refusing to fix their horrible code. While in reality at least in my experience the developer would be very much happy to fix the code, it's just that you don't get any time to do that. It's only new features and new products.

WrtCdEvrydy 8y ago
Bug fixes don't sell your software unless it's a heavy customer product.
- stevoski 8y ago
  In a SaaS business, bug fixes can help reduce churn. A simplistic description is, "sales and marketing increase MRR, a quality product decreases churn". Often a company becomes financially viable by fixing churn.
- mamcx 8y ago
  Not..exactly. Maybe is only a local thing in my country, but you will surprise what is called "features" and "bugs" from non-developers. (features: Everything including bugs bugs: Everything that is annoy and not allow to continue... but sometimes also called features) I mean, are intermixed ALL the time. I literally this week was working in a feature (that was, in reality, a bug) meanwhile only talking to my partner that give support and see him ignoring a red modal windows with a error message (oh, that is not a bug, it allow to work(???)). You can turn the bugs and anti-features of the competence in your own selling points (our product sync the offline database without the need to have a operator that restart the service and click on "sync" in the dashboard!!!) and stuff like that...
Cthulhu_ 8y ago
That's exactly a reason why a company should consider having their engineers do support - by the sound of it, there's a support department who - MAYBE - accumulate common questions and send them to a product owner, but in practice they won't and in practice the PO ignores it because there's more important things - in his/her mind - that have precedence.
- dboreham 8y ago
  Pro tip: have your managers do customer support .
  - icedchai 8y ago
    That would be nice, except most are simply incapable. They forward the requests to the dev team, causing interruptions, distractions, and aggravating engineers.
    - bobwaycott 8y ago
      Sounds like those managers need to be replaced. A manager ought to foremost protect the dev team from interruption, distraction, and aggravating or time-wasting requests.
      - icedchai 8y ago
        I agree. That's why I moved on from that place.
btschaegg 8y ago
> This sounds so nice in theory. All those pesky developers refusing to fix their horrible code. This might be the niche I'm working in, but that does not sound all that unreasonable to me; I certainly know the type. At first, there is a debate whether there really is a bug (instead of giving a trained user and the according support staff the benefit of the doubt), then there is a debate whether the bug should really be fixed or the thing is delayed at nauseam ("need more information" without even having skimmed the damn code at least once). And when the business side finally puts their foot down, the defect is "fixed" with some minimalistic, ad-hoc duct-tape solution that guarantees that five other bugs will pop up in the future because of it. So while I agree with your second point, that doesn't invalidate the first. These kinds of devs actually do exist (with various degrees of intensity, of course). I'm not sure if the archetype is really fit support work, though.
tristor 8y ago
It's actually more complex than that, even. I'm speaking from being an engineer for some time (~13 years) and a product manager now. The issue is that Customer A, B, C, D, and E want Feature A to behave in one way, and Customer N, M, O, P, Q, R, S, T, U, V want Feature A to behave in another way, and those two ways are mutually exclusive insofar as it can't merely be configurable, since Features B-F rely on Feature A behaving in one way or another. So which set of customers do you please? How do you ensure that customer requests for behavior changes, or customers being surprised by application behavior doesn't result in a scope creep that expands the requirements of your application to an unsustainable level? How do you ensure that your business doesn't get coopted by BoM (Buckets of Money) to basically be a contract development house and eventual acquisition target by your largest enterprise customer while ignoring/harming all your other customers who were earlier adopters? There's a lot of jokes about bugs actually being features, but at some point if an application behaves in a certain way long enough and that behavior is relied on elsewhere, changing it is a new feature with all the consequences that come along with that, even if the new behavior is strictly more correct. All of these factors need to be balanced in determining what the best path is to tread in your software. At a certain scale, most of these questions can be addressed organically, maybe by the developers themselves, but at a certain scale it's just not feasible to interface customers directly with developers. You are working on "new features and new products", because customer issues get turned into identification of new markets to solve those issues, which are serviced by new features and new products rather than by "fixing" the old products and features, which would break it for other customers.
- stevoski 8y ago
  That's a great description of the subtleties of product development, especially within a small team. Many books and articles make it seem like a simple procedure, but actually you often face decisions which will leave some people unhappy, no matter what you decide.
  - Novashi 8y ago
    You basically have to get into supporting extensions or custom code and supporting an API if you run into enough of these customers and that’s when you declare that you only have so much responsibility for the customer’s code (and it quickly turns into another support revenue stream).
lbotos 8y ago
> While in reality at least in my experience the developer would be very much happy to fix the code, it's just that you don't get any time to do that. It's only new features and new products. I agree. At GitLab, I'm trying to build our "Support Engineering" group into people that have the time and mandate to fix the things that spring up leaving product devs to focus on new features. It's been working pretty well: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16511 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16511 (40% view speedup) https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name[]=support-fix https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope...
user68858788 8y ago
I've worked as a developer oncall, and as dedicated support engineer oncall. You're absolutely right - management will absolutely refuse to allot time to improvements and bug fixes when there are features to make. It's frustrating being a Dev and knowing how to fix an issue, but not given the time to fix it. It's equally frustrating to cut tickets and mail reports on issues to see them sit forever in the backlog.
rconti 8y ago
I bet the developer's a lot happier to fix the code when the impact is more severe than yet another ticket.

brobdingnagians 8y ago

I agree (conservatively). I don't like taking customer calls, and doing it a lot seems like it could waste valuable time, but I think it is important for engineers to at least occasionally interact with customers so that they understand what this darn piece of software is _actually_ supposed to do. We can sometimes get caught up in feeling like we know what it is supposed to do and implement it, only to find out (or even worse not find out) that people use it entirely differently. The other thing is that you get familiar with the "type" of problems that arise. This helps you communicate with customer support when they call, or know what questions to ask to get to their issues. I've had customer support complain about an issue or feature request they have never told us about but have had pain points and customer requests for months. It is always a trivial change. Improving communication between customer support staff developers is hugely valuable however it happens.

notyourday 8y ago
I subscribe to Tom Siebel's view of taking customers calls -- unfortunately I have to paraphrase it as I don't remember the exact quote: << If they pay us enough money for me to notice when they no longer do, I will take their call at any time and so will you >>

kyle-rb 8y ago

>the second or third time they get the same question, they'll actually stop what they're doing and fix the code. This is great for actual issues, but what about the genuinely stupid questions? Or the customers who basically just refuse to read the Help section before contacting customer support? From my experience working in support, there are a fair amount of those. And those just seem like a waste of the engineers' time.

hinkley 8y ago

My very first job was tech support and then QA (because fewer bugs means less email) for a small team working on a popular product. I started informing the developers every 2nd (or maybe it was 3rd) time I saw different people experiencing the same problem. So by the time we'd had around 8 people reporting the same issue they'd gotten tired of seeing my face and fixed the bug. It's the feedback that's important. A little friction in the path could be a good thing, as long as the people providing the friction have an incentive to do the right thing. I sat one room over from the devs, I was friends with one of them, (had designs on switching teams) and we all went to the same planning and status meetings, so my head was in the right place for this. I recall many many years ago Dell cancelled a plan to move front-line QA overseas because they realized that there was a perverse incentive for an external team to keep quiet about frequently asked questions (because they're cheap to answer and you get paid by the call). Those people in Arizona won't give a damn about how many people can't figure out the app, so long as users keep calling (ie, just good enough that you retain customers).

OnlyRepliesToBS 8y ago

sadistic sociopaths willingly wire up a pain pathway directly to the people doing the building of the software. that's really messed up. why the fuck would you want to add public facing inhibitory pathways to the ones literally creating your software.. and then delude yourself into thinking that's a net positive? like a public facing ms sql or telnet server, it ain't a good idea. people who don't give a shit about the sheer amount of negativity of that inhibitory pathway as it goes to infinity on a sinking ship destroy the creation pathways through shit like this.. and then parachute away.

mikeash 8y ago

The trouble is that 90% of your calls will be due to user error, and the vast majority will be something you just can’t improve, like people misspelling their own names.

cco 8y ago
Neither one of these problems are, "things you cannot fix".

partycoder 8y ago

That's what PMs are supposed to be for.