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.
"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.
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...)
Yes, you're going to have some culture differences, but so what? Every company I've worked for has made it's own culture.
The notion that a great team has good communication seems pretty obvious. But drawing people from the exact same pool of talent is not necessarily a good thing to do at all -- in fact, it can be down right detrimental to the team. But to be clear, I am not saying that diversity is a cure either -- having too many opinions on how something should be done is also problematic.
I agree with the main premise of the article that you need a team of complimentary individuals. I think this touches on something that is similar to the notion of 'how to hire someone who is smarter than you are.' So hiring people that are like you, or the rest of the team, could be a mistake. Hiring people that compliment the current team is, IMHO, the right way to build a team.
I have experienced both sides of this coin: one team that on paper was probably not all that impressive, but came together and made a brilliant team. And the opposite, where the team was a collection of brilliant individuals from the same school who were unable to function effectively as a team because there was no leader and everyone thought their approach to a given problem was best.
So while communication is hugely important, I think that it is also essential to avoid hiring people who are like you or who you feel comfortable around simply because of a shared background.
(This is a company of 5k+ employees)
Of course, adding new member(s) to such a team should not require "PhD from UIUC". Rather, the team must also be able to absorb a member and teach him the vocabulary required to collaborate and contribute effectively.
Personally, I work as a technology/security expert in a team that consists of PhD, machine-learning experts. I've been taught enough vocabulary to understand and follow the conversation and be able to contribute and feel purposeful and innovative from my - very different - perspective.
(Sorry, couldn't resist.)
Having people who like hanging out with each other is very important for teams, especially small teams at startups.
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 hold that a team is always strictly less than the sum of its parts. Productivity is lost in communication between team members.
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.
Agreed.
> I hold that a team is always strictly less than the sum of its parts.
But this does not follow.
For example, suppose you are trying to build something that requires solving two hard problems. Moreover, suppose that no individual in the world has the skill and insight to solve both problems, but that for each problem, there is one person in the world who can solve it.
In this situation, a team consisting of either person alone plus anyone else you like could never succeed in building what you set out to build. If you like, its total value is still zero. However, a team consisting of both key people can finish the build, and thus has a total value greater than zero.
Communications overhead within a team is usually a multiplicative effect, which means if the positive contribution is only a summation effect then your reasoning works. However, often the positive side of a team's productivity is also a multiplicative effect as well.
In that case, you can improve a team's performance by introducing even a single significantly above average contributor, but you can also improve the team's performance quantitatively by improving a below-average contributor's performance and improve it qualitatively by introducing an extra contribution where something important was missing entirely.
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.
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.
Do you mean this ? http://en.wikipedia.org/wiki/Team_Role_Inventories#Belbin_Te...
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.
Birthdays and cookies are worth it!
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.)
And all the really good engineers want to work for Audi.
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.
Not sure we need to have more hypothetical theories to balance personality archetypes when we have simple things we could do right away.
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?
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.
Step 1 is probably the hardest. You'll need a lot of charisma to convince talents to join
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.
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.