Great People Are Overrated
blogs.hbr.org
blogs.hbr.org
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
That is quite normal :-)
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.
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.
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 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.
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.
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.
What are the sort of things that a great developer can do that a mediocre developer simply can't? (Not sarcasm. Just curious)
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?".
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.)
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.
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."
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.
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.
Just wrote Fast Co's next article.
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).
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.
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".
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.
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.
So what. The two things are totally different.
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...
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.
The situation in programming is more akin to comparing the Miami Heat's roster to that of a mediocre college team.
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.
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.
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.
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.
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
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.
Both teams have some of the best hockey players in the world, not mediocre hockey players.
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.
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.
(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?)
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.
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.
He's also forgetting something that's pretty painful: the average programmer can be a net loss in better teams.
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.
-Warren Buffett
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.