Small teams are dramatically more efficient than large teams

http://spin.atomicobject.com/2012/01/11/small-teams-are-dramatically-more-efficient-than-large-teams/

by gvb • 15 years ago

226 83 15 years ago

spin.atomicobject.com

Brajeshwar• 15 years ago

"Small, highly focussed, dedicated and independent team are more efficient than large, mis-managed, teams."

zizee• 15 years ago

I initially opened this article thinking it wouldn't have much meat, but the author has provided some interesting statistics with this article.

Whilst I think there is more than just increased communication overhead involved, I know in my gut that I much prefer working with a team of 3-5 than a team of 20. Things just happen so much quicker!

machinagod• 15 years ago

Not panning this, but isn't this Mythical Man-Month's observation? That the communication overhead increase in adding team members grows -exponentially- quadratically with the number of developers?

(This does match my experience. 40+ teams simply accomplishing less and less than a very small, co-located or constantly in contact team).

jcromartie• 15 years ago

This is exactly what The Mythical Man Month laid out 35 years ago. I doubt anything will come along that could ever really compensate for the network effect of large teams; nothing new under the sun...

ec429• 15 years ago

Open source (decentralised Linux style) seems to have compensated for the network effect of large teams. Hence why Linux is 3.0 and HURD still hasn't shipped ;)

points at CatB http://catb.org/~esr/writings/cathedral-bazaar/

I think part of the poor performance of large teams is because as soon as the business is big enough to have large teams, it's big enough that it starts having middle managers and PHBs. Large teams are only bad because of the conventional commercial software development practices (waterfall, anyone?)

nickik2• 15 years ago

With a big team managers enforce something like waterfall and that why it dosn't work. Nice.

Large teams should be more decentralised like Linux, Order emerges out of chaos adding manager that enforce correct use of waterfall want be good.

chalst• 15 years ago

Another contributing factor for the efficiency of smaller teams is that effective role assignment is much easier with small teams than large teams, unless the project is naturally highly modular.

mbesto• 15 years ago

In case anyone is interested in a more in-depth analysis of this phenomenon, there is:

Mythical Man Month[1]

Peopleware[2]

Very highly recommend you read both. The MMM is amazing because it's held true for over 35 years now.

[1]http://en.wikipedia.org/wiki/The_Mythical_Man-Month

[2]http://en.wikipedia.org/wiki/Peopleware:_Productive_Projects...)

arethuza3• 15 years ago

I seem to remember reading somewhere that the "best" team size for maximizing productivity was three or four - enough so that you have some people to bounce ideas of off and have complementary approaches without introducing the communications overhead that you get with larger teams.

Can't remember where I read that - might have been the MMM.

ebaysucks• 15 years ago

Would be interested in where you read that if you find it again - below is a link to an article that says the optimal team size is 5 to 8 based on a Dunbar analysis.

3 in unstable as too often 1 person feels left out, 4 is an even number so risk of split vote.

http://www.lifewithalacrity.com/2004/03/the_dunbar_numb.html

ken2• 15 years ago

Probably not MMM -- he proposes a "surgical team" for programming which has (I think) nine people, though they aren't all programmers, and some are fractional-jobs which can be shared between teams.

ken2• 15 years ago

I'm coming to believe that the single most important problem in the field of computers is how to get managers to read (and understand) DeMarco and Lister's book.

ww520• 15 years ago

Sometimes it's not enough for line managers to understand these books. Executives and investors need to understand these as well. Often shit flows from the top. Line managers have little say, either be in the program or not.

leoedin2• 15 years ago

I had the fortune of spending a year studying in another country. I study aerospace engineering, and so there's a lot of teamwork. Last year (in Canada) we worked on a project with 20+ undergrads. We had 3 hours of meetings a week, made up of presentations, discussion etc. This year (in the UK) I'm working in a team of four people. I've achieved significantly more this year than I did last year.

Perhaps the biggest reason is that when you have a team of four, every hour you spend meeting involves approximately 15 minutes talking about the problems you're having, and discussing the solutions to your problems. In the team of 20, I'd go to a meeting, spend three hours there and 2 of them would be taken up by a particular aspect of the project. I wasn't working on it, and how they implemented that problem had absolutely no bearing on my work.

Meetings, or at least irrelevant unproductive meetings, are a huge time sink. At least half of the time spent in those meetings could have certainly been spent doing other, productive, tasks.

AndrewDucker• 15 years ago

Less than 10% of your time being spent in meetings doesn't sound like it should slow you down that much.

leoedin2• 15 years ago

When you're doing 4 other courses, you don't generally have more than 30 hours a week to spend on a project.

fab13n2• 15 years ago

Also, the larger the team, the bigger the incentive to be a free loader, because individual contributions become harder to assess.

Free loading includes plain slacking, doing things the fun way rather than the good-enough way, playing politics, keeping yourself busy with unnecessary management/coordination, etc.

techdmn• 15 years ago

This is one of the things I love about small companies. There is literally nowhere to hide. Either you're helping to get things done, or you're creating barriers. Of course small groups can be pathological too, but the visibility of BS is so much higher.

rdtsc2• 15 years ago

Agreed. Larger companies can try to simulate this effect to a large extent by creating smaller teams. So visibility within a team is good. This can be taken to an extreme and lead so silo-fication so these teams are run almost like smaller companies, have their own hiring policy, budget, etc.

brudgers7• 15 years ago

While I agree with your point, the author's argument does not allow for rockstars and slackers - all programmers have been reduced to the mythical $10k/month level (i.e. man-month is the measure of all things).

PaulHoule• 15 years ago

Actually, the large differences in individual productivity have more to do with the slackers than with the rockstars.

Some programmers, in some environments, are negative net productivity programmers. If some programmers literally get nothing accomplished at all, then you can easily say that "some programmers are 10^3 or 10^6 or 10^100 times more productive than others"

Another factor in "rockstar" productivity is that you need to get all the bull out of the requirements gathering process. I've seen so many places where it takes six hours of time working with "customers" to figure out the requirements for something that takes 6 minutes to implement. Tasks that are absolutely trivial can stretch on for weeks if your organization can't be decisive about getting them done.

Of course, in large teams there's a lot more bull to go around.

bh422223• 15 years ago

Oh if only it was just free loading at large companies!

The reality is much more complicated. I worked with some great people at a huge company, a lot of them had families, one had a child with very severe asthma, and one time only a helicopter could get to the hospital fast enough.

Others had perfectly healthy children... in college, and a huge mortgage on the family home.

They all engaged in counter productive job preservation strategies. The easiest of which is simply to not aggressively share knowledge. At very large companies you really have to actively push your knowledge onto people or a shared knowledge repo.

The next level is to put a very small bit of effort into actively avoiding the sharing of knowledge. Give less than the best answers you can give when asked for information. You don't have to lie or hide, just don't be quite as eloquent as you could be.

At yet another level are things like writing custom wrappers around things that didn't need wrappers, or that already were wrappers themselves.

People were doing this because if they lost their jobs they would lose their homes, the children's heath insurance which can pay for things like helicopters, etc.

Then there's personality conflicts. At very large companies you work with a lot of people and this increases the probability you'll meet your worst match. That is the personality that just happens to clash with your personality. The most common I've seen is very confrontational vs. very passive. The very passive then often becomes as passive aggressive as the other is openly aggressive. And boy can smart people like hackers be incredibly good at passive aggression. The point here is that either of those people would be good on their own. It's the combination that's toxic for them and anyone caught up with them.

And then there's anything other than stellar management. Organizing any large group of people so that communication is effective is not easy. If that large group is programmers and the information is highly complex... you don't have to be bad to mess it up, just not being a great manager is enough.

And there's even more, I could write a large book about this.

Splines• 15 years ago

The easiest of which is simply to not aggressively share knowledge.

When you're stack ranked against your peers, I wonder if people ask themselves, "why should I help you, when all I'm doing is making it harder for myself to get a bonus next year"?. I don't indulge in such behaviour, but I've wondered if others have thought and acted upon it.

tomjen3• 15 years ago

Being passive aggressive is something smart people have to learn -- we can't go up against the bully, but we can make him fall into a trap the next day.

And you shouldn't allow confrontational people on your team anyways -- they can't be in a group (but would properly be awesome on their own).

wr1472• 15 years ago

I'd say it was more inefficiency than freeloading.

SkyMarshal• 15 years ago

There's also something Fred Brooks observed in The Mythical Man Month - at some point, the marginal productivity of adding an additional programmer to a team is outweighed by the marginal increase in communications overhead and complexity.

In cases like that you can improve productivity by actually cutting the team's size and pairing less important features.

marcusf• 15 years ago

Good to see an article with some justifications and data instead of random assertions. Usually articles like this are filled with platitudes in lieu of real research, and the whole 'preaching to the choir' thing can get tiresome even if you're part of the choir.

Though I'm not sure the QSM article is strong proof of much anything, really. They don't seem to test for e.g. language or problem domain, and while SLOC has a relationship to the defect rate I'm not entirely sure I agree it's a good comparison metric, nor does it say anything about the success rate of the projects.

That said, one obvious reason for having a 30 man team to develop something is because it's composed of a multitude of disciplines. A software/hardware project might require people with deep skills in digital electronics, analog electronics, software development not to mention domain experts for what they're interfacing. Assuming the thing has an interface you might want a UI guy, then there's the supply chain and manufacturing to take in to account.

It's not hard to see that it could swell to thirty people quite quickly.

brudgers7• 15 years ago

The author's measure of efficiency, cost per line of code, is the first clue that his claims require further research. From a business standpoint, the relevant metric would be the economic value of the code produced and assuming rational actors (as the author's argument must) then the value of the code produced by each team must on average be roughly proportional to its size - else, the allocation of resources be irrational.

Computational efficiency also tends to correlate with cost per line of code in a the man month model the author requires wherein all programmers are of the interchangeable 10k a month type.

Finally, large teams are likely to operate in environments where large teams are required due to bureaucratic overburden, the very environments where $1.8 million dollar coding expenses are both justified and common.

raganwald3• 15 years ago

assuming rational actors

With great respect, I find this approach flawed in analyzing the behaviour of large companies. Assuming rational actors, the thinking goes, every company is providing value and acting efficiently.

For starters, actors may be “rational,” but they suffer from information inefficiencies, so they are doing the best they can with what they know. Sometimes, they proceed “rationally” from flawed assumptions.

For example, they may believe that Waterfall is how to get a project done. Often this is not correct, so the “rational actors” produce waste.

Another problem is that rational actors in the small don’t necessarily produce rational behaviour in the large. Rationally, it is often in an actor’s best interests to do something that harms a team in exchange for providing a personal benefit.

This is how turf wars and silos competing with each other arise even with “rational” actors.

So in summary, I suggets it’s very dangerous to advance an argument that since the actor are rational, the results must somehow lack waste.

I would argue the opposite: That the larger the team, the more likely that rational actors will face situations where being rational means producing waste.

brudgers7• 15 years ago

I agree that assuming rational actors in regards to economics is utterly flawed.

However, economic rationality is one premise of the author's argument. Otherwise, there is no reason to care about efficiency.

Having worked in organizations both large and small, turf wars and petty behavior is hardly confined to large organizations and on the level of the production worker it is my experience that it creates far more drag in small organizations than large ones - in general, thirty person teams more easily replace a resigning worker than five person teams.

The term "waste" is as suspect as "dollars per line of code." A team of thirty is more likely to be dealing not only with an overburden of bureaucracy, but with an additional constraints such as systematic compatibility and legacy code bases - e.g. IE6 - while small teams of $10k per month programmers are probably more likely to produce code worthy of The Daily WTF e.g.

  "True" = true
  "true" = true
  "TRUE" = true
  "tRue" = true
  "TRue" = true
  "TrUe" = true
  ...[etc]

roc• 15 years ago

> "large teams are likely to operate in environments where large teams are required due to bureaucratic overburden"

Exactly. A four-person team may be far more efficient on-task, but requirements-gathering and politicking at a large company could swamp them for months. There do exist problems so large that simply defining them exceeds the capability of a four-person team.

Furthermore, a small team's ability to bring in a project for less money ignores that time is a business-critical aspect of development. In many cases it is worth far more to a company to get a solution out the door in 12 months at greater expense than to wait for a more cost-efficient team to finish in, say, 24.

Lastly, I take issue with the entire idea of efficiency being definable as cost-per-line-of-code. If we as a profession are going to dismiss SLOC as a useful measure of productivity, we certainly can't turn around and allow it to be the basis for an efficiency argument.

raganwald3• 15 years ago

In many cases it is worth far more to a company to get a solution out the door in 12 months at greater expense than to wait for a more cost-efficient team to finish in, say, 24.

I ask whether we can just take it as a given that large teams can get a given piece of software done more quickly than a small team. It may happen some of the time, it may not. But I have trouble granting it as axiomatic, for reasons that would require a blog post to list:

http://weblog.raganwald.com/2007/08/bricks.html

tomelders3• 15 years ago

"Too many cooks spoil the broth."

It's getting tiresome going over the same point that we've known for decades, if not centuries.

Or should I say, it's getting tiresome having to explain and/or defend a position that's so obviously correct, you'd have to close your eyes, put your fingers in your ears and go "whaaa whaaaa whaaa" till you're blue in the face not to see it.

padolsey• 15 years ago

"Many hands make light work"

tomelders3• 15 years ago

"light", but not "good".

virmundi• 15 years ago

A mentor of mine is apt to say that most large companies, those that need large teams, think that you can have a baby in one month if you have 9 women. I find this to be more true as I continue in the field.

The small team works as long as there is good group cohesion. Unfortunately, if there is a morale issue with one person, it can quickly spread to the remaining 3 or 4 people on the team. Such an effect is at least slower in larger groups. It might not occur at all if the organization is such that there are silos for protection.

tashnosh• 15 years ago

Interesting article, but coming from a personal experience of having worked for a large CPG corporation, it's shown me that once a company is scaled to a certain size, employing small working groups outside the usual corporate hierarchy becomes an utter nightmare. Internally, the small working groups I've encountered start weighing the making of small and big decisions equally since they began to believe that any decision they made carried a reputational risk for them within the co context, and in the end any efficiency we had hoped to be gained, was ultimately lost.

matwood3• 15 years ago

So funny this comes up today as I have spent the last 3 days trying to get access to a machine in order to troubleshoot a bug. It's a machine that my team is supposed to control, yet no one wants to grant me access. The network group sent me to the DBAs and the DBAs have sent me back to the network group and back.

Large teams also allow people to hide out which I think kills morale for the rest of the team. I still don't understand how the entire team can realize a person is ineffective yet management somehow misses it and keeps them around. At a minimum if management wants to keep a person around they should explain they are not cutting it and need to improve.

I'm starting a new job soon and cannot wait to get back into a small company.

brudgers7• 15 years ago

So long as a mediocre worker is contributing something to the bottom line, it often is significantly more cost effective for a large company to keep them than to go through the expenses entailed in the hiring and training processes.

If one's idea of how to deal with personnel issues is to just fire people, one may not have the temperament for management in a large organization.

matwood3• 15 years ago

If one's idea of how to deal with personnel issues is to just fire people,

I don't really think that's what I said. People who show time and again that they are ineffective at their jobs should not be there. I'm certainly not advocating firing someone for a single mistake or even for many mistakes as long as it's not the same one over and over again. Hell, making mistakes means the person is actually working and trying to get things done. That's not the kind of worker I'm talking about here. I'm talking about the worker who does little and consistently gets in the way of everyone else who is trying to push the boulder forward.

I also blame management because they need to be proactive in explaining to people that they are not cutting it and need to step up or will eventually be let go. I know if I was not meeting the needs of my job, I hope my manager would tell me.

it often is significantly more cost effective for a large company to keep them than to go through the expenses entailed in the hiring and training processes.

The cost effective you're thinking about is likely only in the short term. If you keep someone who is mediocre and consistently slows down other teams, and burdens other team members to make up their slack, then long term it is cost effective to let them go and get a quality person.

Rockstars may be 10x more productive individually, but anti-rockstars can be a huge minus on the productivity of the entire team. IMHO, it's much more important to not hire (or keep around) mediocrity than it is to hire rockstarts.

51Cards• 15 years ago

Interesting since I just had this exact conversation with a fellow developer yesterday. Last year he moved from a very small shop into a large corporate environment (largely due to a better pay-cheque and a growing family) but he was lamenting to me about how slow things move. He said he spends 8-10 hours a week in meetings or preparing for them. The project they are working on his old team could have knocked out in a month or two, yet 6 months in it's still crawling and falling behind schedule. Nice validation for our conversation to see that almost every item we discussed is in this article.

shawn42• 15 years ago

Having worked in both of these situations, I completely agree with this post. Even with the adoption of "Corporate Agile", our large teams were not able to get near the efficiency of a smaller 4-6 man team.

I think another point to look at would be the level of scrutiny that goes into hiring another member of a dev team of 5-20. A 100 dev team is usually hiring by resume via HR with less focus on culture fit and in-depth technical knowledge.

ohyes• 15 years ago

It would be interesting to see some other metrics with regard to this data.

Cost and schedule are the first things that managers look at, but as a client I would also be looking at stuff like SQA, code quality, completeness of my specification. There's also the 'bus factor' (if one of these guys gets hit by a bus, is there someone else who can work on and understand my code?) What additional documentation am I getting with the code? How is the customer service, is there someone there who I can call and talk to?

We also don't know how this 32 person team was comprised. If it was 4 programmers being supported by 28 other people who worked on the project off and on (management, sqa, marketing, documentation, requirements) these results are not surprising.

As a programmer I want to know things like: how many 16 hour days did the devs work, how maintainable is the code, did the programmer salaries increase commensurate with the additional effort that they seem to have put in? Am I confident in the reliability of this code, or has it been simply thrown over the wall with the promise of support.

I know we all want evidence for 'just Me, Steve and our Emacs buffers, is most efficient. Going it alone like Clint Eastwood and Arnold Schwarzenegger in a buddy comedy about programmers.' But studies in the social sciences like this one are incredibly difficult to get right and should be taken with a grain of salt.

nasmorn• 15 years ago

In our industry million or sometimes even billion dollar projects eventually get cancelled for cost overruns while getting nowhere and people worry about soneone getting hit by a bus. The probability of staff suddenly dying is vastly over rated in my opinion.

SNK• 15 years ago

” large teams took 8.92 months, and the small teams took 9.12 months. In other words, the large teams just barely (by a week or so) beat the small teams in finishing the project! Given that the large teams averaged 32 people and the small teams averaged 4 people, the cost of completing the project a week sooner with the large team is extraordinary: at $10,000 per person-month (fully loaded employee cost), the large teams would have spent $1.8M while the small teams only spent $245k. ”

9 x 32 x $10k != $1.8m, = ~$2.9m; 9 x 4 x $10k != $245k, = ~$360k.

lutorm• 15 years ago

Did you read the entire article? It says that the numbers were made with the actual number of man-months worked, but not everyone was on the project the entire time.

darasen• 15 years ago

I worked as part of a three person tech team. The three of us supported offices in several different counties doing everything from running cables to some programming. The chances to change things up every now and then and be part of such a tight team made it easily my favorite job.

afy• 15 years ago

The whole article hinges on the lines of code metric being an accurate metric for how productive a team is. But how many programmers would be happy if their bosses paid them per line of code?

I would be inclined to agree with the premise of the article, but the evidence given is flawed at best.

Killah911• 15 years ago

No kidding. Sure feels like bending the statistic to fit your argument. I will concede that larger teams are less cost effective and the cost goes up exponentially compared to productivity as the team gets larger (per Steve McConnell: "Software Estimation: Demystifying the Black Art"). BTW the "Software Estimation" book is really awesome and in my opinion a must read for anyone in a tech company with a leadership role. It's true smaller teams are more efficient. But I feel like it trivializes the complexity, comparison, especially when a lot of good detailed works on the subject already exist.

Chris_Newton• 15 years ago

I've seen discussion of this study before. While it's not surprising that the overheads with a larger team are somewhat greater, the discrepancy here is vast.

However, then you notice that the size of project being discussed here is only 100,000 equivalent source lines of code. Assuming that an "equivalent source line of code" is something like a real source line of code, if you're building projects on that scale with teams containing an average of 32 people then I'd say you're doing it wrong. Such projects are almost certainly simple enough for a single small team to complete inside a year, as indeed the study also found, and an insane proportion of the time spent by the members of your larger team is going to go on management, communication and integration overheads.

If you started looking at projects large enough that a single small team could not complete them within a useful timescale, perhaps an order of magnitude bigger or more, and you still found that teams averaging 32 members took almost as long to complete the work as teams averaging 4 members, that would be interesting. But that's not what this study seems to have considered.

gaius• 15 years ago

100,000 lines of PHP or Java maybe. Probably not 100,000 lines of Haskell.

roguecoder2• 15 years ago

If you start looking at projects significantly larger than that I'd argue that you should be leveraging service-oriented architecture and breaking the complexity up into manageable chunks that can be completed by smaller teams.

Someone• 15 years ago

Devil's advocate:

If small teams _always_ and _unconditionally_ are so much more efficient, why do we still have the likes of, say, IBM, Hyundai, Microsoft, or ant colonies?

I think that it partly is because large teams do a lot of things that small teams deem unnecessary, such as documenting design choices, pre-estimating demand/bandwidth requirements etc, making sure one complies with legislation, etc. Not all of that is necessarily waste.

Another large part of the difference, I think, is due to the difference between programming and engineering. Many small teams, especially at smaller companies, program, while almost all larger teams engineer. Programming produces way more functionality per man month than engineering does (for an example, read GNU's well-engineered hello world source code).

So, I think the main rule should be "only start engineering if you have to". Large team size is, for a large part, just a side effect of the decision to engineer.

gwern• 15 years ago

Lots of reasons. Small efficient companies can be much more easily killed by variance / randomness than huge bloated monsters. Successful small companies tend to become large companies, laying the seeds of doom. Successful small companies may just be bought out by the large companies - you can't buy a large company until you are a large company, but the same is not true of small companies. And so on.

dustingetz• 15 years ago

corollary: large teams have access to markets that small teams don't.

things are the way they are for a reason.

mwd_• 15 years ago

One big difference I have noticed is how much more work seems to matter at a small company. When I've worked for a small company it has always been that the company sells X or desperately needs X, so they hire me to write X.

At larger companies the goals have been more abstract. Work might be to satisfy an ideal created by management ("testing is good! 30% more testing!") which may or may not actually be useful. In the worst case it's entirely possible to do work that nobody actually cares about, which I find demoralizing. I don't think that happens as much at small companies because I don't think they can afford it. Big companies with old cash cow products and lots of inertia can.

pnathan• 15 years ago

Larger companies have other groups you have to work with, processes that must be followed, edge cases that need to be solved before release, massive amounts of coordination.

Cost of change becomes excruciating when dealing with large established systems. New systems must be evaluated, understood, the under-average performers trained on it, functionality exported correctly, etc.

Simply put, there's more to do to release "big-co" number of features, as well as more people to talk to about releasing them.

jacques_chester• 15 years ago

Survivorship bias and small-population variance can affect this result.

Small populations are more variant. Most of the best schools are small. But most of the worst schools are small too. Large schools tend to converge on a median. The most dramatic rates of cancer and absence of cancer are found in rural areas because they have small populations. Cities converge on a median. And so on.

We don't hear about the small, unsuccessful businesses. They don't get on panels because they no longer exist. So the small firms that did well are over-represented.

That said, that smaller projects perform better is a consistent finding in classical software engineering research.

Small teams are dramatically more efficient than large teams

Related Stories