"If you were launching a technology or developing a product, would you rather have five great engineers rather than 1,000 average engineers?"
The 5, in a heart-beat. If you were painting a mural on the ceiling of a large structure that you want to be admired for generations to come- do you hire 5 brilliant painters or 1000 average painters? Even happily ignoring the exponential communication overhead that diminishes returns significantly as he does in the original article, there are leaps of imagination that a small brilliant team are more likely to make than any-sized average team.
Edit: Also, his case examples are not coding related. Obviously a non-software-technologist not knowing or understanding the unique background behind the comments in the context of software development and, particularly, software startups. 100x productivity is of course a generalization and has received valid criticism, but examples from sports and trading are irrelevant.
"Also, his case examples are not coding related. "
Nor are they even correct. In fact they can easily be made to prove the opposite of what he claims.
Only someone completely ignorant of soccer/football would claim that this year's FC Barcelona lineup is one of the greatest ever because of their team-based approach - their best player is Lionel Messi, who at 23 is already being considered as one of the greatest players to ever play the game, right up there with Pele, Maradona, etc. He's so much better than not just the average, but even the closest competitor in the Spanish league. Cristiano Ronaldo leads in statistical categories like most goals scored but it's from beating up on weaker teams and he routinely chokes in big games, whereas Messi plays even better, like when he dribbled past half of the Real Madrid team in the Champions League semifinal to score the winning goal. You could've benched Ronaldo and it wouldn't have mattered - benching Messi would've dragged the match back down to more equal terms.
I don't want to transform HN into a sports-related forum, but since The Economist has also written on the subject, I guess I can give it my 2cents...
> Lionel Messi, who at 23 is already being considered as one of the greatest players to ever play the game, right up there with Pele, Maradona, etc
He can dribble, all right, but I'm not the only one who isn't regarding him as "an all time best", simply because he hasn't help his country winning a World Cup final (or even helping it to get there). At 17 Pele was winning the World Cup in Sweden, while Maradona almost single-handedly won the Mexico '86 World Cup for Argentina and helped them reach the final again, 4 years later (not to mention winning the scudetto with Napoli, against possibly the best club-team of all times, Van Basten's AC Milan).
And remember that Barcelona's lineup also includes Andres Iniesta, the man who scored the only goal against the Netherlands in last year's World Cup final, Xavi, Spain's bets man when they won the Euro 2008 Final Tournament, Pedro, David Villa, Alves (one of the best players on his position) ans so on and so on.
I agree that we shouldn't turn this into a sports flame thread, so let's just compromise and say that it's a team-based sport and that individual talent matters, not one or the other (unlike the OP). After all, the same argument about supporting players could be made for Pele and Maradona as well.
I couldn't agree more that his sports analogy is WAY off base. These athletes are all at the top of the top of the top of the top of the world in their sport. And they are getting paid millions. That model runs COMPLETELY against everything he is trying to prove.
However, to what order of magnitude you want to take the discussion can be looked at, 1,000 youth hockey players vs. 5 pros on the ice would be kinda hard to sort though....
As for his investment firm example, I think the who you know, and your firms institutional knowledge play a larger part in that game. So much so that it's not a valid analogy.
I disagree. I don't think there's a technology company in the world that can identify talent reliably enough to make the argument that they can find a team of 5 who will outperform 1,000. Even if the 1,000 people are average.
Painting is largely a solo occupation, and you can reliably judge the talent of a painter by looking at their past work. But it's basically impossible to judge the talent of a software engineer by looking at their past code -- there's too much context required. I think the sports analogy is better in this respect, because it's much harder to separate the the record of a sports superstar from the team that they're on. So it is with non-trivial software.
And also: five "brilliant" painters might be so socially dysfunctional as a team that you'd rather take the 1,000 average guys who can take direction well. You wouldn't automatically get a great work of art if you told Van Gogh, Matisse, Monet, Munch and Seurat to collaborate on a mural -- but you see all sorts of great murals that were painted by teams of less-talented artists.
In the early stages of a company, where you need creative thinking, new ideas, rapid iteration, and are building the technical foundations of the company, you need the 5 brilliant engineers, and wouldn't have anything to do with the 1,000.
In the later stages of the company, when you have 500 enterprise customers creating support requests and you have internal payroll systems etc., then you need the 1000 engineers.
And in technology, if you don't have the 5 at all times, you're on borrowed time. Look at what Steve Jobs, Jonny Ive, and pals did to Nokia.
> But it's basically impossible to judge the talent of a software engineer by looking at their past code -- there's too much context required.
I'm not really sure how this is true. I find that I can judge a software engineer very accurately based on his previous work, and intuit from the code a great deal of the context.
In fact, if I can't determine an engineer's talent without having more context, they are likely an average to below average engineer.
> I think the sports analogy is better in this respect, because it's much harder to separate the the record of a sports superstar from the team that they're on. So it is with non-trivial software.
I think what you're actually doing here is elucidating the difference between a 'superstar' and a 'team of average'. A senior high-quality engineer will have a considerable amount of new code that they've architected and implemented, whereas a team of average will have a considerable amount of code they have maintained.
Like most software organizations, our projects are divvied up into components and subcomponents, and individual engineers own components/subcomponents individually, with conformance to a broader set of development standards. The more junior an engineer, the more likely that they'll be assigned maintenance or improvement work rather than writing a component from scratch.
It would be very easy to evaluate the senior engineers by evaluating their components, whereas the junior and/or average engineers can only really be evaluated in context by the senior ones.
"I'm not really sure how this is true. I find that I can judge a software engineer very accurately based on his previous work, and intuit from the code a great deal of the context."
To each their own, I suppose. Applicant-submitted code samples don't correlate strongly with hiring decisions, in my experience. They're too easy to fake, and don't capture the things you want to know about interpersonal communication, thinking style, etc.
Crass Generalization: I think people who strongly emphasize code samples over everything else are sacrificing a chicken to the hiring gods. It smells very cargo-cult.
"It would be very easy to evaluate the senior engineers by evaluating their components, whereas the junior and/or average engineers can only really be evaluated in context by the senior ones."
Nah, it's always really hard. Some senior engineers don't write a lot of code, but are superb at managing and mentoring teams. Others hole-up in their geek caves, churn out code of varying quality, but are dismal leaders.
My point is: once you've got more than a few people, team dynamics matter at least as much as "rock-star" coding ability (probably more), and you can't tell anything about this from code samples.
> To each their own, I suppose. Applicant-submitted code samples don't correlate strongly with hiring decisions, in my experience.
We evaluate their open source code or paid challenge project, not applicant-submitted code samples of unknown origin.
> They're too easy to fake, and don't capture the things you want to know about interpersonal communication, thinking style, etc.
All of those skills are important, but they're moot if an engineering applicant can't actually code.
> Nah, it's always really hard. Some senior engineers don't write a lot of code, but are superb at managing and mentoring teams. Others hole-up in their geek caves, churn out code of varying quality, but are dismal leaders.
You're conflating quite a few areas of responsibility here. Some people are good leaders, but leadership is also where poor engineers will run to if they can't actually code -- this is not something you want to occur in your organization unless they actually belong in management, and even then, you risk those individuals pushing for poor engineering decisions from a position of authority.
If a senior engineer isn't actually designing and writing software, they're not an engineer anymore, and should be evaluated by a distinct criteria. If you require non-coding engineers to provide a small engineering team with direction, then you likely either have an overly junior team, or too many directionless/mediocre engineers.
> My point is: once you've got more than a few people, team dynamics matter at least as much as "rock-star" coding ability (probably more), and you can't tell anything about this from code samples.
Nobody (least of all me) ever used the term "rockstar". There is simply an enormous difference between the efficiency and code quality of great engineers as compared to mediocre ones.
Most of what you're saying sounds like the standard bandaid approaches to big-enterprise engineering management with mediocre teams.
Applicant-submitted code samples don't correlate strongly with hiring decisions, in my experience. They're too easy to fake, and don't capture the things you want to know about interpersonal communication, thinking style, etc.
Yes, by themselves they're not much good, but if you explicitly ask for a recent piece of code that they're proud of, you can ask them questions about it: "Why did you use data structure X?", or "How does function Y work?" Much, much harder to fake.
The key untested question then, I think, is whether you can successfully identify the 5 vs 1000 when recruiting. I think it would be pretty easy to show that there exist teams of 5 that outperform teams of 1,000 (certainly teams of 20 outperforming teams of 4,000). (be grateful you haven't had to work for any of the latter)
A secondary open question would be whether an existing team of 5 who currently outperform some larger number tend to continually outperform them after being acquired. I would bet that the performance gap would be close to the same. At the very least I would suggest that the cases from other industries give us next to no insight for software development.
"I think, is whether you can successfully identify the 5 vs 1000 when recruiting."
Hm...I think the question is, can you do it reliably? Anyone can get lucky once, but we're talking about acquihires for tens of millions of dollars. You've gotta have a pretty high degree of confidence in your decision to shell out that kind of cash for the promise of the future productivity of a team.
"A secondary open question would be whether an existing team of 5 who currently outperform some larger number tend to continually outperform them after being acquired."
If the research cited in the article is to be believed, most super-stars cease being super-stars after acquisition. Maybe the odds get better for teams, but it sure seems like a lot of brilliant product teams get acquired by big companies (even "good" companies, like Google), never to be heard from again.
This line of reasoning has always sounded like Valley Conventional Wisdom to me. Take a small, high-performing team and stuff it into a big bureaucracy, and the culture of the bureaucracy is going to win.
5 great vs 1,000 average, it depends on the technology and the application they are working on, and the stage of the product.
First, the logic in the original article is not valid. Sports and software engineering are basically incomparable. What they share as team activities don't justify the reasoning in the article. A simple counter example. In professional soccer games (like in the top leagues in Italy, Spain, Egnland, etc.), a second-tier team of ll players could quite possibly beat a top-tier team of only 9 players (the other two players are kicked out for whatever reasons). In software engineering, it is quite safe to say that 5 great engineers can outperform 30 average engineers.
Back to my original point, it depends on the technology and the application they are working on. If the technology and the application require high creativity and innovation, 1000 average engineers cann't lead it long. Most probably, it will lead to a mess that has to be cleaned up and rewritten later. On the other hand, if the application is already well designed and well-established, and the primary jobs are to add new features within the architecture, 1000 average engineers may deliver more than 5 great ones.
In reality, a good combination of both types might be the best scenario.
I would take the 1,000 and come up with 199 other projects, five of which would be oversight of the other 194, and two of them would be to come up with crazy new ideas. Monitor the progress and I guarantee I can find another 5 brilliant programmers in there. Meanwhile, I'll iterate over 1000 projects and blow your socks off with 5.
No, what I'm saying is I have a bit more faith in humanity. How extraordinarily pessimistic to think people couldn't be more productive in other circumstances. It does tend to fly in the face of anyone who ever moved to California.
Agree with you, but he has a point about the "talent acquisition" hires. They do tend to underperform when acquired (perhaps they feel 'accomplished' + there 's no pressure since they no longer work on a startup). Can someone name a few developers who did better after they were 'acqhired'?
The article totally misses a critical point: communications and coordination, which goes up exponentially with the number of players.
Group Intercommunication Formula: n(n − 1) / 2
1000 developers give 1000 * (1000 – 1) / 2 = 499500 channels of communication.
[edit] All Bill has established with his sports analogy is a team of 5-6 players that communicate effectively is better than a team of 5-6 players that don't communicate. That is a total strawman, it doesn't map to 1000 (software) players. [/edit]
In hockey, there are six or fewer players on the ice at one time. Would 1000 hockey players all on the ice at one time be better than six? Not a chance! They would not be able to move the puck because they would be tripping on each other. Even if the ice rink were expanded to hold them all, they still would suck as a team because their communications and coordination would be totally broken.
The same problem happens with software developers: 1000 developers working on one problem will trip over each other too. The only way 1000 developers will succeed at all is to decompose one big problem into 100-200 smaller problems that teams of 5-10 (funny how that works out) can then solve.
In addition to number of communication channels on a team, the article neglects the complexity of communication.
Creating economic value through code is currently an extremely complex process. When you consider what goes on between the ears of a basketball player, it is not trivial, but it can be transferred from one player to the next in a straightforward way.
Engineers must think beyond what is able to be communicated. Complex mental models of code and user experience that would take the best engineers longer to communicate than to instantiate.
What you're missing is that the 1000 player hockey team would completely dominate the 5 hockey all-stars. 998 of them would check 4 stars into oblivion while 1 guy spent the rest of the period making hundreds of shot attempts per period until the game was won.
n(n-1)2 is a strawman itself: a 1000-person organization will probably have 3 levels (900,90,9) with each person communicating mainly with team members or the level above or below, so O(nlogn) communications channels, probably.
The problem is that each set of middle managers cannot represent the bandwidth required to express the problem to their subordinates or the solution to their superiors.
At the top, you have a board of 10 people. Each one of these is making decisions and receiving orders for 100 people. This sort of structure is going to have some serious communication latency and a loss of data as it traverses the company heirachy.
The article does dance around that concept a little bit, in an aside about the difference between Barcelona and other football clubs. But he never gets around to drawing an exact parallel to primadonna coders.
And that's a strong argument to make. I might rather have five exceptional developers than 1000 average ones, taking into account communication latency and overhead, but if they're five surly, haughty, egotistical asshats who are engaged in a never-ending pissing contest, then no thanks.
Yes. It goes in a different direction than it starts. I think the parent stopped reading at some point. Did you read it all, and the articles it cites?
I didn't read the cited articles, but I did read it all. It may have (as a sibling of yours pointed out) "danced" around that conclusion, but it was far from clear that's where he was going with it. It was just a bunch of poorly-thought-out analogies that made no sense (and in many cases were factually incorrect; e.g. the stuff about FC Barcelona is just wrong).
The gap between exceptional developers and average developers was proven in some planned experiments, as described in Peopleware.
This article, on the other hand, contains lots of philosophy, imagining and wishful thinkings - but not an ounce of proof.
The only fact is about analysts - not developers. The financial field does not make a good comparison - random chance plays a much bigger role in wall-street than in software development.
I recall reading in "Random Walk Down Wall-Street" that it has been shown that even the best managed funds don't do better than well-diversified random stock selection. Taking the high impact of chance in the investment sector into account, if someone was a star analyst at one place, it is likely that he'll perform worse at his next assignment due to regression to mean.
Personally, I think that the data in Peopleware is somewhat weak, and I'd like to see updated studies. However, surprisingly what Peopleware says (iirc) is that the #1 way to increase productivity of developers is to improve the working conditions.
Not a surprising line of thought, considering the source. I have worked with some of HBRs products -- Harvard MBAs -- and found them to be arrogant and severely lacking in common sense. I don't know if Mr. Taylor is a graduate, but the attitude sure does sound familiar. To the Harvard MBAs I worked with, developers were viewed as janitors (making sure the software didn't stink too much) and completely interchangeable. Thy were incapable of distinguishing bad from good from stellar developers, and were therefore unable to recognize what a 100x developer brings to the table. Google and Facebook are not similarly disabled, and need to pay what the market will bear.
The choice between "a small number of superstars" and "a well-assembled team that may not dazzle with individual brilliance, but overwhelms with collective capability" is a false one. A "well-assembled team" will have a small number of stars and a larger supporting cast. A badly assembled team will have a huge number of leaderless, mediocre developers. This team will undoubtedly have "managers", who have little or no understanding of what they manage. Having spent many years in software startups, I have seen how one kind of group turns into the other. The stars build something. It becomes successful. Maybe its a startup that gets acquired. The B players and PHBs arrive. The stars get fed up and leave (to build something else from scratch), and what's left is a stagnant, rudderless, politicized, mediocre group that can no longer do anything innovative.
Mr. Taylor says "I'm not sure I'd make the same choice as Mark Zuckerberg -- especially if those 100 pretty good people work great as a team." That's why he's not Mark Zuckerberg.
The choice between 5 great engineers and 1000 average engineers is, of course, an utterly false dilemma. No-one gets paid 200x average salary for being 'great'.
The choice should be between hiring 5 great engineers PLUS 100 good engineers in support of these guys (and maybe 20 ancillary staff to answer the phones, and keep all the other distracting stuff out of the hair of the 55 engineering staff) vs 1000 average engineers. Maybe a few high-quality managers to make sure that 'greatness' is actually staying on schedule rather than just sitting around being really awesome, too. :-)
Everyone has a different skill-set, and using your great engineers to do stuff outside their area of expertise is like using a oscilloscope as a hammer.
This also leads to another corollary: that is, given 2 'great' engineers, if engineer A is a little less brilliant than engineer B, but can make effective use of a team of 20, while engineer B insists on doing everything 'his way' and can't work effectively with others, you're going to want engineer A.
I used to scoff at the idea of the super-developer who is orders of magnitude more productive than anyone else. Mostly it was me protecting my own self-esteem.
Then I met one and actually had to re-assess my ability as a developer, not just as to how good I am now but how good I'm _ever going to be_. I've now come to terms with my fate.
While I will put a lot of hard work into being as technically thorough, well-read and well-practiced as I possibly can, I no longer compare myself to these ultra-productive developers who can walk into a dev team and pick up more domain knowledge than I did in a year in a couple of months.
The other thing is that the "100x" number isn't really applicable. Yes, your super-developer that you met may do the same task 5x faster than somebody else, but the real thing that sets him or her apart and makes them valuable is the set of things that they can do that a mediocre or inexperienced developer simply can't do, at all. It's hard to use the "times better" metric to measure that.
And when you look at it that way, I think it's easier to "see" the super developers out there. There's a lot of people who are faster, but still mediocre. While I can put that to good use, I don't think it's the same thing.
You might surprise yourself. It isn't necessarily all about speed. Continuous deliberative practice can take you a long way. You may never bash out code at warp speed, but you might find you can still step up into the "doing things few other people can even do at all" domain.
> but the real thing that sets him or her apart and makes them valuable is the set of things that they can do that a mediocre or inexperienced developer simply can't do, at all
What are the sort of things that a great developer can do that a mediocre developer simply can't? (Not sarcasm. Just curious)
Take a piece of technology like memcached which has gotten really popular in the last few years. It's an incredibly simple piece of technology really, a server with a simple protocol that allows you to set or get bytearrays by a key, and smart clients that deterministically map a key to a server. Together, you get a lineraly scaling global cache.
I've worked with web technologies for 15 years now, and I've worked with some pretty smart developers, but not smart enough to piece something like memcached together. We've done lots of different cache systems, but not as good.
But once we saw memcached, the great developers I worked with instantly got the brilliance of it, and went "Duh, why didn't I think of that?".
These aren't all equally difficult, but if anybody at work proposed putting a fresh-out-of-college employee on them, I'd scream in terror:
Design a complicated system, mostly correctly, in their head, and create a plan for getting to MVP as quickly as possible, and incrementally advancing to the complete system without ever having to really rip anything out (unless it was part of the plan). You can imagine how this is valuable to a business. It also takes a lot of experience, because even if you can mouth mantras like DRY and "separation of concerns" there's a lot of room left to screw up in exactly how you separate concerns. (And many developers aren't even familiar with those terms.)
Design a non-trivial web site with various user roles, which is actually secure even if you fully control the incoming HTTP requests from top to bottom. Sounds easy. Evidence suggests that the skills to pull this off are not found in every developer, though.
Correctly program a concurrent program with a significant UI, using only the tools readily available in traditional UI environments like Windows or Java. (It shouldn't be rocket science and I believe someday it won't be. But it is today. Arguably, this isn't even something a master developer can do, it's just something it takes a master developer to even come close to getting away with.) Think something like being someone who writes the game engines, like the Unreal engine. There's a kernel down in the core of the engine that you can throw as many mediocre developers at as you like, it will never work.
There's even things like "knowing which paradigm to apply to which part of the problem" which groking knowing several paradigms in the first place. A programmer who has never heard of "logic programming" isn't going to recognize an opportunity to literally replace tens of thousands of terrible lines of code with hundreds of good ones. A programmer who doesn't understand compilers or interpreters isn't going to recognize the place where they can provide a DSL to a user and save unbounded amounts of lower-level code. A programmer who has only gone to school and has no outside experience isn't going to know that memcached even exists, let alone that it is wildly better than anything they could possibly write.
If it sounds like some of these things aren't that rare, well, I'm mostly not trying to describe things that only the top 0.01% of developers could do. I'm looking more in the top 25%-ish on most of these, maybe top 5% at best. But there's definitely a bottom 50% that these things are out of the question. (Many of them, of course, will grow and move up, everyone starts a bottom-1% developer.)
I'd take 5 rockstars supported by 1000 average devs. You need the rockstars to do some of the heavy algorithmic / visionary lifting and the 1000 people to make sure that the software is well tested, well documented, very well polished, etc. And also, you need the 5 rockstars to support the 1000 average devs by getting them past hurdles, etc. And you need a little bit of management in between to ensure the average guys aren't dissapointed by the salary differences, and the rockstars aren't frustrated by how long it takes to polish.
At Facebook it's probably worth it to get those few rockstars so they can make a drastic impact on the average guys. It's probably even worth it to give them $4 million a piece.
I'm not sure that the 1000 really will make sure the software is well tested, etc. Given that I haven't seen things on that scale, but the scales I have seen, the non-superstars don't seem to get why they should do any of that work or how to do it effectively. Maybe 5 rockstars and 30 very much above average. 1000 average won't get anything done and won't know what they have done.
For the less glamorous software tasks, you want to hire people who are in the B range (not outstanding, but notably above-average) for software talent but have an interest in advancing into project management or executive roles. Get a 25-year-old who's strong, but knows he's not going to be a CS luminary in 20 years, and who will look at tasks like documenting APIs as a learning experience and a way to get a sense of the company as a whole.
The point that I think everyone is missing here, is that there are different kinds of "talent." The mythical "5x more productive developer" is almost certainly not 5x more productive at all imaginable tasks, and would almost certainly be completely miscast if assigned to doing some jobs... jobs that probably need to be done (depending on what the project is). IOW, I don't believe there is such a thing as a (universally) "5x more productive developer". What there are, are people with certain talents and strengths, that - when aligned with what is being asked of them - result in great productivity.
IOW, the person who's a guru at coding machine-learning algorithms in Java, is probably not also the person who is a guru at writing OS kernels in C, who is not also the person who's a guru at writing web applications in Python, who is not the person who's 5x more productive at writing automated tests, etc., etc.
My personal belief (which I'll freely admit is based on no scientific research) is that the best scenario is to have a team where the members of the team are each as talented as possible, respective to what their role on the team is. And it's entirely possible that the ideal team will not look - at first blush anyway - like a team of "5 rockstar developers" as people might imagine it.
To go back to sports analogies... there isn't one universal "rockstar football player" talent. The talents needed by a Quarterback are different from that needed by an Offensive Tackle, which are different from those of a Wide Receiver, or a blocking Fullback. And to win games, you need people who have the requisite skills at each position. But you can't judge all of them by one generic metric.
I think a lot of you guys also underestimate the value of chemistry on a team. A team that has been together for a while, where the members have learned each other's strengths and weaknesses, and where the members truly work in harmony, can accomplish a lot even without "superstars."
I'm not sure why journalists (in this case, the co-founder of a magazine) feel qualified to criticize immensely successful Tech companies.
There was a recent article stating that Google should push the Android Platform towards—guess what—an Apple way of doing things. As if Android hasn't gotten a huge piece of the market by doing things different from Apple. Android is appealing precisely because it has things the iPhone doesn't. And this comes from a lifelong Apple and iPhone user.
And here's Facebook, a player that entered a quite mature market with well established players and just crushed them into oblivion through sheer talent. In the face of fast growth, Facebook hasn't been through the pains of Reddit or Twitter; they just effortlessly introduce highly sophisticated technology that works on a massive scale.
And yet a clueless journalist comes along and says "hey, you're doing it wrong!". Baffles me every time.
Yes, of course everyone is entitled to an opinion. I'm not saying they should shut up, I'm saying I'm baffled as to why they pick the core strength of the fastest growing companies and say "this is wrong".
Perhaps it's that they are in the business of trolling, they get more eyeballs if they state very counter-intuitive things, like John Dvorak from PC Magazine.
You know what Twitter is doing wrong? Limiting its users to 140 characters. People need more characters to express their thoughts. Twitter needs to be more like Wordpress, a vehicle to really transmit your deepest thoughts and not meaningless chit-chat. And embedded pictures for those who like sharing their thoughts in a non-text medium. That would capture lots of market share from WP and Tumblr.
That's true about everything else too, not just technology. We just happen to be agitated because that's what we know best. Opinions are a dime a dozen.
If you were launching a technology or developing a product, would you rather have five great engineers rather than 1,000 average engineers?
The former...
What's interesting to me is that the author makes statements like this apparently based solely on his intuition, which seems to be completely uninformed by any experience with programming, and dubious analogies to sports and investment banking.
Not to mention inexplicable assumptions that (1) great programmers are, on average, less likely to be able to work well on teams and (2) the ability to work on teams is encapsulated in the evaluation of a programmer (at least in the minds of Zuckerberg and Andreessen).
I read this article and cringed. After 30+ years of building software products and organizations I am 100% with Zuckerberg on this. A really great engineer or designer is far more valuable than dozens of average ones.
Of course, an organization must have the culture to support such super-stars.
Which is where the focus of our discussions and energy should be as leaders. Not on the super-stars, but creating the atmosphere in which super-stars can excel.
I'm kind of an outlier, but I really believe that context places a huge, huge part in the "superstar developer" mythos. We're very quick to overlook a lot of contributing factors in the rush to declare some developers legendary. "Outliers" does a pretty good job outlining the argument, which I happen to agree with.
This isn't to say that you can plop anyone in the right context and get a "superstar", and I think some people are more resilient to contextual changes that might make other devs crumble.
"If you were launching a technology or developing a product, would you rather have five great engineers rather than 1,000 average engineers?"
I also think that this is a straw-man argument, in the sense that the kind of person who can work well on a 1,000 person team may be different than the five great engineers who can develop and bootstrap a new product. There is overlap, but honestly I think there's an argument that some situations call for "1,000 solid engineers".
There is a lot wrong with this article but I will take the rare opportunity to talk about football on hacker news
Being able to play as part of a team is one of the very major factors in someone being "great" I dont think many of the people who argue for quality over quantity in the hiring process are arguing that they want people who cant work with anyone else, they are arguing for the best set of people who can work very well together.
FC Barcelona is not an example of mediocre players who form a good team, they are the best collection of footballers who compliment each other and work together to form one of the greatest teams ever, Valdes, Iniesta, Puyol, Villa are the best players at their respective positions right now, Messi is very close / has become the best football to ever kick a ball. Using them as an example seems strange as they very much counter the point.
Or maybe they are underrated and this article is propaganda.
The main problem is that he is criticizing the claim that brilliant people in tech are considerably better than average, way out of proportion with their pay.
To attack this, he brings up the known and uncontested fact that wall street analysts are BS artists who provide no value because their entire field is a scam.
It's not surprising to read on a site devoted to hackers that 5 is better than 1000. Everyone wants to believe they're special. But if all companies followed this mindset, there'd be many people here out of work.
That said, I don't think either side is the ideal. I'm also a big believer that brilliant people make a huge difference. But what you want is an structure that allows those five brilliant people to oversee a sea of average workers. Like a factory; some things just work better when you can plug any warm body into the position.
But it takes 5 brilliant people to design that system...
Would you rather hear the music of a thousand mediocre musicians or four great ones?
I'm not trying to draw an analogy between musicians and hackers -- just providing an example to show that productivity ratios vary hugely depending on the endeavor, so comparing software to soccer or investing is fruitless.
I am amazed at all these viewpoints (in the article and in comments) in favor of 1000 mediocre programmers versus 5 great ones. Have you actually seen big software development departments at work?
1000 mediocre developers is like a huge battleship (an old, clunky, unarmed one). You can't get everyone one the same page. You can't change directions. You have to dumb everything down and cut your ambitions in half just to hope to get a working product out.
5 great programmers would absolutely beat the hell out of 1000 mediocre programmers, every single time. I can't believe anyone even thinks it's a contest.
I think it isn't about the engineers' skill, but more on how they work together as a team. 5 superstar pricks will get you nowhere. 1 superstar plus 4 average engineers that work and take directions well, and you have a team. Even with just 5 average engineers, as long as they get the job done and take to instructions well, you're better off. The problem with superstars is that they usually have huge heads, and would rather prove a point than make things work. A superstar with a great work ethic and is a team player, now that is worth the money.
Those were some horrible examples. Its not surprising that star ANALysts make no difference. Studies show that monkeys perform just as well at investing.
His other example are teams in professional sports. This is also horrible because even the "average" professional athlete represents the cream of the crop (.01%). Scotty Pippen, Steve Kerr, and Dennis Rodman were no Michael Jordan but surely they're stars by any other metric.
I think if you attempt to hire 1000 pretty good programmers, it is likely you'll end up with a least one exceptional programmer.
If you were to divide up the 1000 pretty good programmers into 200 teams of 5 people each, and give them the same high level of difficulty task as a team of 5 exceptional programmers. What are the odds that the exceptional team produces the best result?
The ratio in developer ability is a bit hard to get a handle on. The study seems to show that for analysts the environment can also play a big role in individual performance. That is also true in software development. Good leadership, strong peers, and the right cultural fit can probably make at least a 2X improvement in individual performance over tyrannical leadership, mediocre peers and a corrosive culture. Domain expertise is another element in performance, often just in avoiding obvious but still costly mistakes.
Some companies thinks they've hired superstars, but really only hired a bunch of arrogant pricks.
It's interesting to me that the author is writing an article with a slant against the modern "winner-take-all" economy and has chosen as an example, computer programming and technology. i.e. one of the best illustrations for the basic rationale behind "winner-take-all" structures.
In my opinion, programming provides such a tremendous amount of leverage that a super-star developer can have an impact that greatly eclipses a super-star financial analyst or basketball player. In my experience, one great developer multiplies not only her own efforts but also the efforts of all the developers around her, by being knowledgeable about technologies, algorithms and system architecture and being able to quickly steer the team in a productive direction.
So yes, Facebook is 100% correct in trying to get those 5 developers, because one brilliant idea can affect millions of people and might be something that was put together in a weekend.
Maybe some companies prefer 100 mediocre employees working together in perfect harmony over just a few superstars.
The problem this article doesn't address is that it is REALLY HARD to get 100 programmers (or workers in any profession really) to work in perfect harmony towards a goal. The underlying problem is that engineering doesn't scale well. If you already have 10,000 engineers, hiring another 10,000 will not make you twice as productive, but hiring a handful of very good programmers might.
I do agree however that some talent acquisitions are more outrageous than others.
As a startup I'd prefer having 100 mediocre programmers instead of only one superstar, but it is harder to get 100 mediocre people to work in perfect harmony than to pay a superstar millions of dollars. More people introduce more overhead and are likely not to work together in perfect harmony. One person works
Here's a pretty good analogy: You're playing chess. Each move must be made in 10 minutes or less. Do you want 1000 mediocre chess players on your side, all conferring and required to reach majority consensus, to decide your moves? Or would you rather have 5 great chess players conferring to decide your moves?
Trying to say that two NHL teams are comparable to Exceptional v.s. Mediocre is simply ridiculous and the point at which I stopped reading.
The Bruins and the Canucks are both filled with Exceptional players, most making over a million dollars a year. Neither team has players anywhere close to the mediocre level.
Now if a team in my pick-up league plays the Bruins... well then you'll see the difference between exceptional and mediocre. I.e. "skating with pylons".
That being said, I do think that eventually diminishing returns kick in. That the difference between an amazing and a great developer is significantly less than the difference between that great developer and a mediocre developer. Most of all I think experience counts as much as raw talent most of the time.
"Nobody would suggest the Bruins had the best individual players in the NHL — throughout the year, the stars of the Vancouver Canucks shone much more brightly."
Both teams have some of the best hockey players in the world, not mediocre hockey players.
Software is a creative endeavor. As in most creative endeavors there are dis-economies of scale in the form of communications and management overhead, differences of opinion and perspective, etc. What group writes a better novel, a group of 5 or a committee of a 1,000? The same thing applies to software. Generally speaking the smallest group that can get the work done will do the better job. More so if the smaller group is on average more talented.
How do you ensure the average talent of a group of 1,000 people? It's a hard problem. How do you do so for a group of 5 people? That's an easy problem.
"Have we become so culturally invested in the allure of the Free Agent, the lone wolf, the techno-rebel with a cause, that we are prepared to shower millions of dollars (maybe tens of millions) on a small number of superstars rather than a well-assembled team that may not dazzle with individual brilliance, but overwhelms with collective capability?"
Who said it was about free agents? Those 5 aren't going to code alone, they're going to be working with 4 other people. And they're going to be much better at that too.
Would you rather read 1000 science fiction novels, each by a completely mediocre author, or read 5 science fiction novels, each by a great author?
(Or, more fairly -- if you have one great author on staff, it is possible that you might produce a great novel. If you are unable to find any great authors at all, how many mediocre ones will you need to hire to make up for that fact? If you go so far as to hire 1000 mediocre authors, will they somehow "add up" to greatness?)
The people in those companies that Facebook bought are not just engineers, they are also people who can see a gap in a market and create a good product to meet the need.
They are not typically the people that apply to for jobs, especially at facebook or respond to head hunter requests.
I can see why facebook needs to buy companies to get those people.
I can also see why they often leave again, since they can't get things done that they want to, in big organisations.
The first big problem is how do you select the 5 great engineers. To be able to judge a level of talent you need to be at least 1 or 2 levels below that. Otherwise, you just cannot know tell if someone is good or if someone is really good.
This is a big problem in many companies because they don't have anyone to judge. The problem extends further because if you want to hire the judge you can't judge the judge.
There's a straw man here. Nobody said that those 5 great programmers are necessarily prima-donnas. When they're described as great it isn't in the idiot savant sense of the word, it's in the all-around sense. Nobody said those 1000 other programmers are good team-workers.
He's also forgetting something that's pretty painful: the average programmer can be a net loss in better teams.
Question also is, what happens when you put 10 good creators in a hyper-engaged creative environment with 10 great ones? Are good performers simply good because of their innate capabilities or can regular interaction with greatness help tease out capabilities that were previously buried?
It depends on the difficulty and complexity of the problem that the person is hired to solve. I wouldn't want an 'average' engineer designing a multi-billion dollar company's backup infrastructure if by average we mean someone who doesn't bother to learn a lot about their field.
Assume that the superstar=100*average_programmer is true, then tell me: How many of these superstars are there in the world and how likely is it that they want to work at your startup?
It seems that many people here have experience with these superstars? Maybe they are not so rare after all?
The fact of the matter is not everyone can hire amazing programmers. Average is average; this isn't Lake Wobegon.
Most startups would be better off figuring out how to get the best out of the average programmer, than investing in the search costs of that diamond in the rough. If you find one, awesome, but the plan shouldn't revolve around it.
The main prize in the Friendfeed acquisition was Paul Bucheit, who invented and implemented both AdSense and Gmail, which together now bring Google over $10 billion in annual revenue.
If (generously) an average developer adds $100k in revenue, that makes Paul 1000x better.
"Star analysts who change firms suffer an immediate and lasting decline in performance."
This sounds a lot like "regression to the mean", that is, people performing better than their "mean" performance level for a time but longer term trending back to it.
Do you want to listen to songs written and performed by 1000 mediocre individuals, or would you rather be limited to music from just 5 absolute musical geniuses?
Facebook, according to the Times, is the pioneer of this new phenomenon, acquiring a slew of companies, killing their products, but keeping their developers.
If Zuckerberg thinks that's a good strategy, then he's an idiot. When companies pull that stunt, morale at the acquired startup turns to shit and people only stay because of their golden-handcuff earnouts (note to all: never take a deal with an earnout; you will probably be fired 1 day short of the cutoff). Usually, what happens is that the acquiring company finds a way not to make good on the earnout, firing the original founders for "performance" three days before they could earn out, so then they rightfully get pissed and talent-raid their ex-employer for their next venture.
If you were launching a technology or developing a product, would you rather have five great engineers rather than 1,000 average engineers?
I'd ask for 3 brilliant engineers and 400 mediocre ones. The 400 mediocre ones would be able to support an enterprise system that might be ugly but would bring in lots of money: far more money than a small startup could bring in except with a lot of luck. I'd hire a half-decent MBA to make (and run) a profitable company out of these 400 mediocre engineers and spend maybe an hour a week actively managing it. With the surplus, I'd fund a 4-person startup (the three brilliant people, plus me as a relative hanger-on) and do something awesome.
All that said, the relationship between size and effectiveness is weird in technology. Friction and integration difficulty grow faster-than-linearly in terms of the number of people on a software project. There are some types of projects where a few good developers can do very well, but where an arbitrarily large number of mediocre ones just won't be able to do it. For example, you can throw 400 mediocre engineers at an enterprise product and make billions per year, but if you throw 400 mediocre engineers at the design of a concurrent programming language, you're going to get nothing.
After examining the careers of more than 1,000 star analysts at Wall Street investment banks
If you're talking about performance and not political luck, there's no such thing as a "star analyst". It's a braindead, utterly subordinate job with no room for creativity or ingenuity. By the way, "analysts" don't analyze anything; it's just the default title given out of college.
The 5, in a heart-beat. If you were painting a mural on the ceiling of a large structure that you want to be admired for generations to come- do you hire 5 brilliant painters or 1000 average painters? Even happily ignoring the exponential communication overhead that diminishes returns significantly as he does in the original article, there are leaps of imagination that a small brilliant team are more likely to make than any-sized average team.
Edit: Also, his case examples are not coding related. Obviously a non-software-technologist not knowing or understanding the unique background behind the comments in the context of software development and, particularly, software startups. 100x productivity is of course a generalization and has received valid criticism, but examples from sports and trading are irrelevant.