Apparently the founder of Kayak.com does this, in an attempt to not only prevent poisonous people from destroying teams, but to go in the other direction and create exceptional teams.
Last night I went to the Extreme Programming San Diego meeting (it should probably be called "Agile" but I suspect the group is old enough that XP was what started it). A reader knew that I was in San Diego visiting my folks so he suggested it. I thought I'd dip my toe in the water and see if programming was any more interesting to me than the last time I checked. Especially since Agile practices tend to be more focused on people issues, which is where I seem to continue to drift.
The first thing I noticed was the turnout. I'm guessing there are thousands of programmers in San Diego, but we got maybe 10 people to show up. That's probably a condemnation of the profession, where the majority don't read or learn new things. It could also be a number of other issues, the biggest of which is, I think, the fact that user groups cling to the same old approach that everyone else does: get a speaker to come in and give a lecture. The speaker was fine, and had even reduced bullet points in favor of more pictures. But there's something in my brain that says "nap time" whenever a projector gets turned on. The interaction is primarily one-way and scripted, but you can't fast-forward the lecture like you can on the web.
When asked, I related my interest in people issues, where I've come to believe lie the biggest possibilities for improvement. As an example, I talked about building teams, and how difficult it is to do it well within the business structures we currently have. One of the people there mentioned Kayak.com, and how the founder had hired and fired hundreds of people in order to get the 30 or so that he currently employs.
One way to look at the problem of company-building is that it should focus on creating great teams. I've heard numerous people say that the company could be in various kinds of bad shape but they could be happy in it as long as they were on a great team. If the team is indeed the fundamental component of the company, then it would be interesting to make an environment whose primary focus is to be a culture medium for great teams.
One of the biggest problems in team building can be thought of as a version of the "sunk cost" issue. Although it's better to think of lost investment as just that -- lost -- when making decisions, our brains tend to think in terms of what we've already invested. So if you've invested a lot of time and money in hiring someone, you'll tend to hang on to that person until the pain of doing so exceeds your imagination of what it took to get them in that position. This means that a poisonous person can easily be in a team long enough to destroy it before finally being ejected, at which point it's too late. You've thrown a bass into your team of goldfish, and while the bass is eating up your team, you're thinking "maybe he'll get full."
The other big factor is legal. Some people sued companies for wrongful termination, so every company adapted practices to prevent it. You can't just fire someone anymore, you have to give them a couple of 6-month evaluations to show due diligence.
I suspect the Kayak.com founder has everyone sign a contract that allows them to be fired easily. Producing company loyalty in a situation like that might be tough ... but if you get the right people then maybe that goes away. People might become vicariously loyal to their company because they really want to be in their team.
The real problem with hiring someone for a team is that you can't actually know how well they will work out until they're participating on a day-to-day basis. Nothing in an interview really tells you this. So apparently Kayak.com decided that most of the "interview" would go on by putting the person in the real situation and seeing how they worked out. Perhaps a little unsettling and brutal -- although looking for a job is never a great experience, and maybe having one, even if just for a short period, might be better than a long period out of work and looking -- but from the standpoint of the company it could produce some excellent results.
Does anyone have links to stories about Kayak.com's approach? What other types of practices might help solve the problem of team-building?
I'm the CTO/Co-founder of KAYAK, and I want to correct some information you have in your blog post.
Over the past 20 years, at five different companies, I have hired hundreds of engineers. And across these five companies, I've fired dozens. Thus probably 1 out of 10.
At KAYAK, I've probably fired 1 out of 5. (During certain intense periods, at was probably as high as 1 out of 3.)
During interviews, I do tell people about this, and that they should not join if they are risk-averse in their confidence about themselves.
I hate firing people.
But I'm obsessed with trying to build the best team in the software industry.
If you are awesome, and I leave you with a peer who is only average, you will have to pull their weight, and, you will not learn from them.
The best way to keep industry-leading talent is to surround them with a team of industry-leading talent. And to do this with people who are not only incredibly quick, but also, incredibly fun.
When I do fire someone, I give them a generous severance package, and I spend as much time as they want helping them find another job. And as odd as it might sound, I've remained friends with several of these folks, and many of them continue to call on me for advice.
Other companies I admire for obsession with top talent include Netflix and Zappos.
Here's a recent article which will tell you a little more about my management style...
> If you are awesome, and I leave you with a peer who is > only average, you will have to pull their weight, and, you > will not learn from them. > > The best way to keep industry-leading talent is to > surround them with a team of industry-leading talent. And > to do this with people who are not only incredibly quick, > but also, incredibly fun. >
I am curious, do you see value in bringing on less experienced but obviously talented and teachable engineers? I am thinking in terms of building a pipeline of internal talent and being able to hire and promote from within. Or, is this in your opinion a long term pipe-dream?
'A lot of companies have the "no assholes" rule. So if the greatest programmer ever is also a jerk, he's fired. Our rule is "no neutrals."'
I especially like this because the "no assholes" rule reflects a kind of desperate measure; things have gotten so bad that we actually have to say "no assholes." But "no neutrals" raises the bar: we are not just trying to raise ourselves out of the muck of assholes, but we're shooting to make this place much better than it can be if we just get rid of the assholes.
This expresses more of what I'm trying to accomplish. I'm not just trying to say "how can we make things work better in the existing context of business." I'm saying, "How can we change the context so that business works much, much better."
It is esentially a philosophy that says employees have no value as people. They are merely components in a money making machine. If you can find a better component for your machine you just dispose of the old one, click the new one into place and keep going as if nothing had happened.
The process of getting rid of the unwanted components can be eased my blaming the component. First apply a perjorative label to it - such as "poisonous" or "asshole". Treat the component in a way appropriate to the label and you might even find that the component will dispose of itself! Brilliant! If not, then you may have to do the dirty yourself. But that's OK because nobody wants those pesky "poisonous" "assholes" around anyway. I mean, they just suck, don't they.
This is such a good philosophy for owners that I surprised it isn't more widespread. No management issues (because any component that causes an issue is - by definition - "poisonous"). No training issues since a component that does not know how to do what is required is surplus to requirement and can be disposed of (anyway the best components train themselves, in their own time, at their own expense on open source projects and the like).
So there's the solution. Stop treating components like real people and the "people issues" will just magicaly go away. Put labels on the one you want to dispose of and you needn't feel guilty about sacking them. In no time, you'll be surrounded with a team that consists entirely of components that jump at your every command. Success is around the corner.
As a mediocre programmer I would probably not get hired or if so make it at a place like that, but from a management perspective t would be interesting to see the results of this style of management in practice though. Yeah, all software managers want 10 John Carmacks that work well with others, but then there's reality...with a whole lot of social, non-technical factors involved.
People just have bad days/months too. I've also found that some people can really shine technically on one project, and not so much on other projects.
Kay, you should have probably read Paul King's reply to Bruce's blog before you made such idiotic comments. He makes it clear that he's up front to people about his management style.
Still, it brings up an interesting point: the technique is not isolated from the way it is applied. Some companies could use it as a way to behave very badly. However, those companies would probably behave badly regardless of what technique they are applying. The metric you use to decide whether someone is "poisonous" etc. is what determines how you apply that technique, and the results you produce. If, for example, you define "not a team player" as someone who refuses to put in excessive hours, you'll end up with a team of drones who equate hours served to progress. And if that's your definition of success as a manager, you'll consider yourself successful at that point. Indeed, you can delude yourself in any number of ways until someone applies a more connected metric, such as "your department or division is losing money," and even then, you'll only know you are doing something wrong, but not what it is. This is why most management seems to amount to wandering around in the dark, bumping into things.
I wonder if we might take some lessons from Agile, in particular rapid iteration and feedback, to be able to keep us more on course and in touch with things. Note the use of this at Kayak.com, with the service boards on the wall, and everyone answering customer questions.
> Kay, you should have probably read Paul King's reply to > Bruce's blog before you made such idiotic comments. He > makes it clear that he's up front to people about his > management style.
Some people might have heard that we have a buyers job market right now and if you urgently need a job and someone explains to you that he applies darwinist style management practices with some New Age elements ( employees should energetize each other ) and the employees team shall run like a football team but without a cup to win and without cheerleaders and such fun stuff, you'll probably swallow it and follow the guru without much criticism.
I know I'm an idiot but this smells like bullshit to me.