Focus on building 10x teams, not on hiring 10x developers

Lot of interesting material, but I take exception to this:<p><pre><code> For example, alums of a university tend to use the same jargon, think similarly, know the same programming languages, etc.. They will communicate naturally and are free to focus on higher order problems. It’s not a surprise that Paypal was mostly UIUC, for example. At Spool we’ve consciously hired mostly Stanford alums because Curtis and I are Stanford grads. </code></pre> Hiring people exactly like you isn't a wise approach either. Making a choice especially on the dimensions the article mentions (same programming languages, same universities) is especially dangerous. E.g., if you work in a team of all Java programmers (versus a team working in Java, because it's the right tool for the job) you'll miss crucial perspective.

The true 10X individual does all of those things.<p>They are the technical brains and set the standard and can give a mean interview. They will make things happen even if the rules are a little annoying. They absorb data from everywhere. They don't take crap even from the people who can hire and fire, even risking their own job to do it.<p>They work so hard they break themselves if the rest of the team isn't up to it. And they remember birthdays and bake cookies.<p>It is possible to find all of these qualities in one individual.<p>It's just not very common. It's rare, even. But they do exist.

I think only relatively small teams can be 10x teams. With big teams, people can easily underperform and not get noticed, while the contributions of the true team players are often overlooked. This leads to declining morale. With small teams everybody knows what everybody else is currently doing and you get credit for being a team player and working on unpopular tasks etc.

Great essay, Avichal. Totally agree on 10x teams being the real differentiator.<p>On "shared culture", I want to point out that a shared monoculture can be just as big a disadvantage for some companies as it was an (likely) advantage for Paypal. If you don't need to communicate because of existing shared assumptions, that can make you efficient, or it can make you blind because you completely miss better solutions or other problems.<p>I'd love to see a follow-up on just the complementary personality-type diagram-- it's already a sort of Myers-Briggs for startups. Almost every category would work for non-engineers too. (I'm not saying it would have real diagnostic value, but it'd at least be fun.)

You read about all these companies that are having issues hiring great engineers, yet when I check their product it seems to be just another DB driven site with social sprinkled around it.Please enlighten the non-engineers like myself, what is it that great engineers do at companies that are working on a website (ecommerce, social network, social media tools etc...)

I have found this to be incredibly true. I work with teams of scientists, and a lot of people have incredibly different backgrounds. Some people are incredible hackers: Implement anything on a Cray machine? No problem. Some people can visualize data more beautifully: turn a table into a meaningful visual product? Already on it. Some people are good at bringing disparate groups together, and asking the right questions. Those are the people I want to work for, who inspire me personally, whether they came from a tech background or not ( I've worked for people who came from both ).<p>Leadership is hard. I've noticed that the best leaders not only respect the talents brought from the tech and design sides equally, they get their team members to do the same.<p>I guess a greater question is how you recognize that quality in a leader. We all want leaders who will bring our talents into a more coherent product/outcome, but how do I know beforehand that a particular boss will be able to realize that goal?

One thing that I think is quite important to building a good, productive team is personal similarities. The article touched on it, but I think it deserves more emphasis. In my experience, I work far better with people who share my interests, have similar values, etc. Being able to relate to the people you work with on a level outside of work is a huge boon to forming a good working relationship and mutual trust. It is also something that is often not taken into account enough in the hiring process, and I think this is one common reason you find a group of individually smart people that don't work effectively together.<p>Clearly this is only one factor among many, but I think having a team of shared, external interests is even more important than this article implied.

There is actual empirical evidence for what makes a team perform better: <a href="http://singularityhub.com/2011/08/26/mit-unravels-the-secrets-behind-collective-intelligence-hint-iq-not-so-important/" rel="nofollow">http://singularityhub.com/2011/08/26/mit-unravels-the-secret...</a><p>Not sure we need to have more hypothetical theories to balance personality archetypes when we have simple things we could do right away.

I think most good leaders instinctively know this - but few take the time to articulate it.<p>Bill Walsh, former coach of the San Francisco 49ers, was exceptionally good at formalizing and applying these principles. He turned the franchise around by putting the team above all else, sometimes ruthlessly so. He focused particularly on the myriad of daily details that shaped the team's self-esteem. When you are actually proud to belong in a team, and are constantly pressuring yourself to not disappoint your teammates, <i>ever</i> - then you will win.<p>If you've worked in such a team, you know the feeling: in the middle of a conversation you will be struck by an overwhelming high of awe and gratitude: <i>I can't believe I'm working with these guys!</i>.<p>That feeling alone makes up for all the hardships of a startup.

1. hire 1-2 star developers 2. build your team culture around them 3. hire other talents around this culture 4. other solid developers will want to join 5. there you have a star team<p>Step 1 is probably the hardest. You'll need a lot of charisma to convince talents to join

Make sure you are at least getting 1x developers though. While I agree, a solid team is incredibly valuable, if your A-Team is made of folks with zero ability, your team will have zero ability.

I really hope this becomes the norm when hiring. I'm graduating soon and going into the work force, and I would love to work in an environment as described here - on a diverse team where team members complement and motivate each other. I don't consider myself a rockstar programmer or 10x developer, yet it seems this is what most high profile companies are looking for.

Very interesting post. I found i could instantly relate to it, instead of all the posts about uberhacker-only teams. (I haven't worked in such an environment yet)<p>Peopleware matters.<p>I find myself fitting into <i>The Teacher</i> and <i>The Anti-Pinocchio</i> roles a lot, wherever i work. And i try hard to be <i>The Heart</i>.<p>I have great respect for <i>The Hustler</i>. A great team needs them all.

Sorry, I don't really buy this one.<p>For projects that depend on solving simple problems, that is, those which any competent developer could solve well, then sometimes communication and teamwork are probably the limiting factor. Of course, even then, it is possible that a "10x developer" (a crude simplification, but it will do) could do the work of 10 1x developers and without the overhead: one such person will be 100x more efficient at internal communications and 10x more efficient at external communications <i>by default</i>, so your "10x team" members will each need to be 10x more efficient based on their better communication skills <i>just to break even</i>. Unless your 10x developer is particularly bad at communicating -- and in my experience, the opposite is frequently true, because that is a big part of how someone <i>becomes</i> the mythical 10x developer -- I'm not sure you'll ever hit that.<p>Then you have to look at projects that depend on solving hard problems, those where developers below a certain level of skill and/or insight will not be able to find an acceptable solution. Here your overall performance is at least partly determined by how many developers you have above that threshold and how well <i>they</i> communicate. This is why having a crude 1x vs. 10x approximation isn't very helpful in my view: it's always a sliding scale, and maybe a couple of 3x developers in the mix is all you need for the team as a whole to get over a tricky hurdle.<p>In the limit, for projects that depend on solving a really hard problem, your bound may simply be the maximum skill/insight level of any individual on your team. If you don't have anyone good enough, you can't solve the problem at all.<p>On top of that, in the real world, few products and services depend on solving a single problem with a single monolithic team. You are going to have multiple problems to solve, possibly by different groups of people, which then need to be co-ordinated in some way. In other words, your overall team is going to have cliques, possibly on several levels of nesting, and you need to worry about the performance of each clique, which in turn depends on the talents and the team-working within that clique as set out above. And on top of all of that, you have to worry about communication between cliques, integrating their work to produce the overall product or service. And then you have the fact that membership of cliques is not constant: staff will come and go, sometimes people will change role to make better use of their skills and experience or simply to keep their interest level up in a long-running project, etc. This is why <i>good</i> managers, co-ordinators like software architects, and technical leaders are so valuable.<p>In short: I think the whole premise of this article is a gross over-simplification based on some dubious basic assumptions, starting with the fact that those people who lift the team in various ways aren't actually the very 10x developers you're talking about. If all you do is develop software that solves simple problems with small teams then maybe the premise is true to a point, because you don't take much advantage of the stronger developers. Plenty of real world projects are like this, of course. However, I expect few people reading HN want to work on them, and plenty more real world projects need more. No amount of hiring chummy people with mediocre skills is going to make those projects succeed.

1 + 1 should always equal 11 when it comes to teams AND their team members.<p>If there's not a magnification it's not worth it. Everyone has to be as crazy about/at their work as you are about yours, whether it's development, design, business, marketing, or whatever.

I thought it was interesting the author used the word "she" in the list under "What sorts of people make other people better?" It looks like a conscious choice, I'm curious why they made it.

Great read.<p>In my experience, tech companies focus entirely too much on minutia and completely ignore critical aspects of personality. They hire people instead of building teams. The closest thing to personality testing I've seen is going out for a beer. Given the number of people I've known who are pleasant at a bar and passive-aggressive and backstabbing at work, I think this is a pretty miserable test.