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.
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.
"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.
I agree. I work in a team with alumni from many different universities and I think the differences between the schools add to the diversity of the team and increases the number of angles at which we tackle problems. A good fit is important, but preferentially hiring your own university's alumni seems like a good way to prevent building the best team you can.
Yes, you're going to have some culture differences, but so what? Every company I've worked for has made it's own culture.
As with many other things in life, this seems to be an area where the Goldilocks principle applies. In other words you want to avoid extremes (too similar, too diverse) and strike a perfect balance.
Skipping the experiences that lead to this conclusion:
A _team_ from the same uni will be extremely productive if they focused on that type of project in their courses. If the team only has undergrad degrees, look at the undergrad projects, of course. But their strength will be in bootstrapping such a project, not maintaining it. (Work done for courses is perpetually being re-invented and never maintained, by its very nature.)
And the flip side of the coin is: break up that team and mix them up in your other teams, and they will learn a lot about the real world. As long as they're closeted together, they'll have that laser-focus and high productivity, but lack the real-world perspective.
If you only have one team of developers, you need the diversity! My small company really benefits from the variety of backgrounds we bring.
Then there are those 10x players who may have gone to the uni but worked outside the uni as well. They aren't vulnerable to this kind of thinking, but will work really well with other guys from their alma mater.
I agree with your point - I feel that having too many engineers from the same school leads to a sort of echo chamber. Everyone takes the same classes, does the same projects, has the same professors. But even worse, I feel like alums all gravitate towards the same level of technical expertise - being Generic University Engineer #27 was good enough for the previous 26 hires so its good enough for me.
I agree, I think this is aspect of the article is a huge mistake (although I generally agree with the rest of it).
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.
Absolutely, I currently work with a Ruby guru, the Walking iOS Documentation, Mr Java, a security expert, and Ms Mobile. Personally, my background is robotics. I've never seen a group of people that can tackle a problem better. We are all from different backgrounds as developers, most of us are from different universities too. Age ranges span 22-35 range with a cluster in the 22-25 range. We work really well as a team because we were hired for our ability to communicate effectively and understand problems. I know during my interview I was shocked to see 3 of my team members and 2 of my team leaders in individual interviews (I talked to 14 people that day). These interviews were not so much technical as they were "soft skills" tests to see if I was a fit for the team.
A better example would be something like this: most PhDs of UIUC in the field of Science use the same vocabulary, despite having PhD in different fields. Hence, a team of PhDs in different, adjacent fields of Science, from UIUC, might be able to both complete each other and hit the ground running faster.
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.
Comments
Lot of interesting material, but I take exception to this:
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.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.
"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...)
I agree. I work in a team with alumni from many different universities and I think the differences between the schools add to the diversity of the team and increases the number of angles at which we tackle problems. A good fit is important, but preferentially hiring your own university's alumni seems like a good way to prevent building the best team you can.
Yes, you're going to have some culture differences, but so what? Every company I've worked for has made it's own culture.
As with many other things in life, this seems to be an area where the Goldilocks principle applies. In other words you want to avoid extremes (too similar, too diverse) and strike a perfect balance.
Skipping the experiences that lead to this conclusion:
A _team_ from the same uni will be extremely productive if they focused on that type of project in their courses. If the team only has undergrad degrees, look at the undergrad projects, of course. But their strength will be in bootstrapping such a project, not maintaining it. (Work done for courses is perpetually being re-invented and never maintained, by its very nature.)
And the flip side of the coin is: break up that team and mix them up in your other teams, and they will learn a lot about the real world. As long as they're closeted together, they'll have that laser-focus and high productivity, but lack the real-world perspective.
If you only have one team of developers, you need the diversity! My small company really benefits from the variety of backgrounds we bring.
Then there are those 10x players who may have gone to the uni but worked outside the uni as well. They aren't vulnerable to this kind of thinking, but will work really well with other guys from their alma mater.
I agree with your point - I feel that having too many engineers from the same school leads to a sort of echo chamber. Everyone takes the same classes, does the same projects, has the same professors. But even worse, I feel like alums all gravitate towards the same level of technical expertise - being Generic University Engineer #27 was good enough for the previous 26 hires so its good enough for me.
I agree, I think this is aspect of the article is a huge mistake (although I generally agree with the rest of it).
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.
Absolutely, I currently work with a Ruby guru, the Walking iOS Documentation, Mr Java, a security expert, and Ms Mobile. Personally, my background is robotics. I've never seen a group of people that can tackle a problem better. We are all from different backgrounds as developers, most of us are from different universities too. Age ranges span 22-35 range with a cluster in the 22-25 range. We work really well as a team because we were hired for our ability to communicate effectively and understand problems. I know during my interview I was shocked to see 3 of my team members and 2 of my team leaders in individual interviews (I talked to 14 people that day). These interviews were not so much technical as they were "soft skills" tests to see if I was a fit for the team.
(This is a company of 5k+ employees)
A better example would be something like this: most PhDs of UIUC in the field of Science use the same vocabulary, despite having PhD in different fields. Hence, a team of PhDs in different, adjacent fields of Science, from UIUC, might be able to both complete each other and hit the ground running faster.
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.
He said "think similarly"; you said "think exactly alike." Those perspectives are similar but not exactly alike.
(Sorry, couldn't resist.)
Having people who like hanging out with each other is very important for teams, especially small teams at startups.