
Focus on building 10x teams, not on hiring 10x developers - yinyinwu
http://avichal.com/2011/12/16/focus-on-building-10x-teams-not-on-hiring-10x-developers/
======
strlen
Lot of interesting material, but I take exception to this:

    
    
        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.
    

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.

~~~
DarkShikari
Extremely true, and very important from my experience too. Hiring other people
to work with you isn't just about having more bags of meat to write more code,
but about having _other people with different perspectives_. This can be about
ideas in business, design decisions, and even just looking at your code and
spotting problems you missed.

"Diversity in thought" is incredibly important to success in a project of non-
trivial size, and if everyone thinks exactly the same way, it's all too easy
to make bad decisions as a result of the echo chamber.

I imagine this is a major contributor to the failure of many startups -- we
often laugh at the startups that come up with absurd business models that
could obviously never work, or develop apps that clearly nobody would want to
use, but simply pointing and laughing belies the truth: what _happened_ was
that they didn't have anyone who disagreed, who thought differently.

Sometimes you just need someone to point out that what you're doing is _dumb_
, and that there's better options.

~~~
jt2190
"what happened was that they didn't have anyone [internally] who disagreed,
who thought differently."

I suppose that someone on the team could have "known" that the product
wouldn't succeed with customers before it shipped, but the strategy of knowing
what will work with customers in advance is considered a bit outdated,
especially in software which is now relatively cheap to prototype and get out
in front of customers.

"Teamicide" is also a big reason for startup failures. (For an entertaining
read with an overview of teamicide see:
[http://www.codinghorror.com/blog/2009/01/are-you-creating-
mi...](http://www.codinghorror.com/blog/2009/01/are-you-creating-
micromanagement-zombies.html))

------
rachelbythebay
The true 10X individual does all of those things.

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.

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.

It is possible to find all of these qualities in one individual.

It's just not very common. It's rare, even. But they do exist.

~~~
sounds
At the risk of sounding offtopic, I love the anecdote!

Birthdays and cookies are worth it!

------
mrich
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.

~~~
ansgri
On the other side: a bipolar genius will hate the small team where everyone
knows what he's not doing now, not taking into account that in 1 day out of 10
he deals with 50x the amount of shit that could save the big team where noone
cares.

------
kalvin
Great essay, Avichal. Totally agree on 10x teams being the real
differentiator.

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.

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.)

~~~
mjwalshe
yep look at the German telco system very centrally controlled and they took a
top down position that ISDN was the one true way - and so hampered the rise of
the internet in Germany - which why they only have me to copies at the moment.

And all the really good engineers want to work for Audi.

------
rokhayakebe
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...)

~~~
davidhansen
I can't speak to social networks or social media tools, but I can assure you
that ecommerce has a _lot_ of difficult problems to solve. To a first
approximation, it's easy to throw up a LAMP site and sell random crap. Once
you get beyond this and start trying to squeeze out profits by building and
executing on various optimization problems, things get significantly more
complex. Companies like Amazon and Wal-Mart have invested huge amounts of
money into esoteric research to optimize supply chains, fulfillment processes,
inventory control, promotional returns, energy usage, expected customer value,
etc, etc, ad infinitum.

~~~
rokhayakebe
I do not think Amazon, and Wal-Mart had state of the art infrastructure when
they first started.

------
kevinalexbrown
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 ).

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.

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?

------
bencpeters
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.

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.

~~~
jasonlotito
Having an army of clones won't get you where you want to go. Diversity will
bring new, fresh ideas and perspectives to a project. Don't get caught up in
extra-curricular activities matching. You'll miss out on people that will
teach you so much more.

------
danielharan
There is actual empirical evidence for what makes a team perform better:
[http://singularityhub.com/2011/08/26/mit-unravels-the-
secret...](http://singularityhub.com/2011/08/26/mit-unravels-the-secrets-
behind-collective-intelligence-hint-iq-not-so-important/)

Not sure we need to have more hypothetical theories to balance personality
archetypes when we have simple things we could do right away.

~~~
mjwalshe
Belbin has found what mix of team roles work well.
<http://en.wikipedia.org/wiki/Team_Role_Inventories>

------
shykes
I think most good leaders instinctively know this - but few take the time to
articulate it.

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, _ever_ \- then you will
win.

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 can't believe I'm working with these guys!_.

That feeling alone makes up for all the hardships of a startup.

------
dontbelame
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

Step 1 is probably the hardest. You'll need a lot of charisma to convince
talents to join

------
sliverstorm
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.

~~~
Duff
In my experience, people who agonize over the individual are usually not
thinking about the team. Part of team-building is identifying people with
potential and growing them.

When we engineer systems, we try to avoid or deal with single points of
failure. The same concept applies to people, except that "failure" when
applied to people is often not as easy to define or identify.

~~~
shykes
While I agree that one's contribution to the team can tromp raw individual
performance (all good leaders know this!), I would be careful not to go too
far in the other direction. A bad engineer can sabotage an entire project
regardless of his cheerleading abilities.

------
reledi
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.

~~~
sounds
You may benefit from reading the comments on this HN poll:
<http://news.ycombinator.com/item?id=1444661>

------
vimalg2
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)

Peopleware matters.

I find myself fitting into _The Teacher_ and _The Anti-Pinocchio_ roles a lot,
wherever i work. And i try hard to be _The Heart_.

I have great respect for _The Hustler_. A great team needs them all.

~~~
mjwalshe
does no one else know that hes just ripping off Belbin.

~~~
vimalg2
Thanks for the tip.

Do you mean this ?
[http://en.wikipedia.org/wiki/Team_Role_Inventories#Belbin_Te...](http://en.wikipedia.org/wiki/Team_Role_Inventories#Belbin_Team_roles)

------
Silhouette
Sorry, I don't really buy this one.

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 _by default_ , so your "10x team" members will each
need to be 10x more efficient based on their better communication skills _just
to break even_. 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 _becomes_ the mythical 10x developer -- I'm not sure
you'll ever hit that.

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 _they_ 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.

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.

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 _good_ managers, co-ordinators like software architects, and technical
leaders are so valuable.

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.

------
j45
1 + 1 should always equal 11 when it comes to teams AND their team members.

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.

~~~
AndyKelley
I've heard this often (a team is greater than the sum of its parts) but never
bought into it. Can you justify why it is true?

I hold that a team is always strictly less than the sum of its parts.
Productivity is lost in communication between team members.

~~~
yuliyp
Developing software isn't just a linear stream of ideas to lines of code. If a
5 minute discussion with another team member leads to a design that will save
a week of refactoring later on, then the team with those 2 people is now MORE
than those two people would have done if you cut off all communication between
them. Or in other cases, another set of eye balls will find a bug in 1 minute
instead of half a day.

Heterogeneity, even among very skilled software engineers, exists. Thus you
want people whose skills and weaknesses blend, so that the weaknesses of team
members can get helped out by others on the team, and thus increase
productivity.

------
daenz
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.

~~~
jadc
It has become common in the english language to write "she" instead of "he"
when the gender is undefined. This is presumably also to break the male
stereotype mold.

~~~
mjwalshe
probably to hide hide somthing when he says "At Spool we’ve consciously hired
mostly Stanford alums"

------
georgieporgie
Great read.

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.

