Live data from Hacker News

Kayak.com Makes Developers Do Customer Support

inc.com

11–20 of 21 posts

Re: Kayak.com Makes Developers Do Customer Support

#11
As a developer, I'm not so sure that I buy this. I mean, I get it, developers are going to know how to deal with the bugs much quicker than a customer would. But does it scale well? If I was constantly interrupted by a loudly ringing code I can assure you that my code is going to be a poorer quality than if I had been able to work on it undistracted. So distractions lead to bad code leads to more distractions... that could be a really vicious cycle.

As someone else pointed out, you have to judge the process by its fruits. It looks like it's working for them, but it would drive me crazy.

Re: Kayak.com Makes Developers Do Customer Support

#12
post #10
post #9

Earlier quoted context omitted.

I see the idea, but you can take everything too far. To the entire company and to all investors? Every day? Really? That's borderline fascist surveillance regime.

The proof is in the pudding. Is Kayak keeping their customers happy. Are the investors happy and of course are the employees happy? If the answer is yes, then the approach works. Fascism is a strong word for a novel approach to customer service. If this approach stops working then they will try something else. This is not an ideology, you know.

I didn't intend to say the method is fascist, just that it reminds of practices that were and are employed by fascist regimes. If everyone's happy, then there's of course no reason to complain. I just don't see how employees could be happy under a system like this, but to each his own.

Re: Kayak.com Makes Developers Do Customer Support

#13

Great find, thanks! My favorite quote from this was: "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."

that works as long as the company encourages this.

i.e. at my mom's job(she is also a programmer) she used to do these little fixes for the users, and they all loved it. Then new management came in, and now to do a little fix a user has to send in a request, which the programmer needs to get signed off by 3 bosses.

And here is the funny part, the fix takes literally 5 minutes to do, boss #1 will say..."better tell the next boss it takes a few hours to give us some breathing room', boss #2 will say..."better tell the next boss it takes a few days, to make it seem like we are doing a lot of work" and boss #3 will say "better tell the user it'll take a week, we want them to know that we are doing major code for them"

So this tiny 5 minute code fix, that literally just required a change in a few lines of code that used to be done in 5 minutes, now gets expanded into a 2 week "project"

THAT's the difference between a startup and corporate culture

Re: Kayak.com Makes Developers Do Customer Support

#14
post #13

Great find, thanks! My favorite quote from this was: "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."

that works as long as the company encourages this. i.e. at my mom's job(she is also a programmer) she used to do these little fixes for the users, and they all loved it. Then new management came in, and now to do a little fix a user has to send in a request, which the programmer needs to get signed off by 3 bosses. And here is the funny part, the fix takes literally 5 minutes to do, boss #1 will say..."better tell th…

It's a two-way street. Bosses demand sign-offs because someone at some time deployed something that didn't work. Signoff processes are there as a pain avoidance technique.

If you are positive about the quality that goes out, you can have a corporate culture that encourages this sort of thing. If you're in a company that feels like it has to fill seats you get a combination of people who are good at their job who have to deal with bureaucracy and people who aren't good at their jobs who are saved by it.

Re: Kayak.com Makes Developers Do Customer Support

#15
post #10

Earlier quoted context omitted.

The proof is in the pudding. Is Kayak keeping their customers happy. Are the investors happy and of course are the employees happy? If the answer is yes, then the approach works. Fascism is a strong word for a novel approach to customer service. If this approach stops working then they will try something else. This is not an ideology, you know.

I didn't intend to say the method is fascist, just that it reminds of practices that were and are employed by fascist regimes. If everyone's happy, then there's of course no reason to complain. I just don't see how employees could be happy under a system like this, but to each his own.

Part of their job is to write reasonable responses to customer inquiries. That's the output of their working time, for which they are paid.

Saying that should be private is like saying someone's code check-ins should be private.

And if we assume people are good rather than bad, it's a chance to show off, without ego, a particularly good response and/or responder. That gives them a morale boost from knowing their boss and co-workers saw them doing a good job in a natural environment, and it motivates co-workers to do a similarly admirable side.

Re: Kayak.com Makes Developers Do Customer Support

#18
post #8

Great find, thanks! My favorite quote from this was: "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."

It requires a very fine balance, however. When building a big system you need uninterrupted hacking time to make sure you can keep all that state in your head. That won't happen if there's a loud ringing phone or your CEO bouncing around having loud conversations in the office. That's why Joel has private offices, and pg differentiates a maker's schedule with that of a manager.

"When building a big system you need uninterrupted hacking time to make sure you can keep all that state in your head."

I think that this is wrong. Or at least it should be wrong. I used to think it was true.

State is another way of saying 'Number of things I have to hold in my head'.

So what you are saying is that because you have a too many things to hold in your head at one time, you need uninterrupted hacking time. Otherwise something gets forced out and you make mistakes.

But another option here would be to increase the amount of abstraction within the code. If you increase abstraction, you reduce the amount of state, and reduce the chances of something important getting pushed out.

A side benefit of this would be to increase the readability of the code. If it is very well abstracted, it will be easy to understand when you come back to it.

Re: Kayak.com Makes Developers Do Customer Support

#19
post #13

Great find, thanks! My favorite quote from this was: "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."

that works as long as the company encourages this. i.e. at my mom's job(she is also a programmer) she used to do these little fixes for the users, and they all loved it. Then new management came in, and now to do a little fix a user has to send in a request, which the programmer needs to get signed off by 3 bosses. And here is the funny part, the fix takes literally 5 minutes to do, boss #1 will say..."better tell th…

Fascinating story, short, descriptive, vivid.

Re: Kayak.com Makes Developers Do Customer Support

#20

This page seems to randomly show the feedback phone number: http://www.kayak.com/feedback Hit refresh a few times. Perhaps they don't like the phone ringing that much after all?

This is clever. You want to have some amount of personal feedback to learn about customers, but you also want to be efficient about handling he bulk of the support issues.
Post reply on HN