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."
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.
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
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.
He lives this. I once sent in some feedback via Kayak's web form, and got a (brief) personal reply from Paul English within 24 hours.
> "We developed our own customer support software. One of the things it does is randomly select an employee response to a customer and send that response out to the entire company and to all of our investors each day. It keeps us on our toes."
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.
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.
> I didn't intend to say the method is fascist, just that it reminds of practices that were and are employed by fascist regimes.
Fascists also wore pants, drove cars, ate sausage, drank beer, etc.
While customers may have privacy concerns and expectations regarding their interaction with a company, employee interaction with customers is not an employee-privacy issue.
Remember, employees are being paid to interact with customers. The company is liable and responsible for those interactions so it's absurd to argue that the company has limited access to those interactions because of employee privacy.
BTW - The purpose of a company is NOT to keep employees happy. Doing so may be useful, but that's different.
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.
"On any given day, you might find him tracking down potential hires, going for a run with his software engineers, or personally answering calls to Kayak's customer hotline." <- what is this? software engineers don't run ;)
Honestly, he seems very down to earth and genuinely happy. I also like how he doesn't have a problem constantly checking his email unlike all these productivity blogs and such saying its the worst thing you could ever do. I feel my behavior is somewhat vindicated in being one of those differences that doesn't really make a difference.
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.
I welcome the idea and practice so wholeheartedly that I feel the use of word "make" in the title is inappropriate.
It implies that the developers at Kayak.com are forced to do something outside of their responsibility -- it certainly would sound stupid to say "XYZ.com Makes Developers Do Proper Coding", however, both practice lead to the same outcome -- better product.
Cool article! Although for me what stood out in the article was not that he made his developers do customer support, it was his work ethic and his outlook on life.
I like it that he advocates "work really hard for 40 to 45 hours a week, but we believe in people having strong personal lives". Makes for a more balanced life and ultimately a more sustainable company.
Rather than hoping that employees recognize patterns in customer communications, it might be better for a group of employees to review a sampling of emails and figure out some common root causes. Perhaps they already do this...
"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."