10 ms·

Small teams are dramatically more efficient than large teams

226 points by gvb 15y ago

Brajeshwar 15y ago
"Small, highly focussed, dedicated and independent team are more efficient than large, mis-managed, teams."
zizee 15y 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 15y 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 15y 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 15y 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/ 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?)
  - nickik 15y 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 15y 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 15y 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 http://en.wikipedia.org/wiki/The_Mythical_Man-Month [2]http://en.wikipedia.org/wiki/Peopleware:_Productive_Projects_and_Teams http://en.wikipedia.org/wiki/Peopleware:_Productive_Projects...)
- arethuza 15y 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 15y 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 http://www.lifewithalacrity.com/2004/03/the_dunbar_numb.html
    - gbog 15y ago
      split vote: do you really vote decisions? if it's 50/50, I'd say the real solution hasn't been found yet.
    - arethuza 15y ago
      I read that a long long time ago - but I'll have a think and see if I can recall where it was. I'd agree that a larger team effectively mitigates risks around individuals not fitting in or decision-making being stymied, but in my own personal experience I've definitely preferred, due to a perception of maximising by own personal productivity, that 3 or 4 was best. That is, of course, completely subjective!
leoedin 15y 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 15y ago
  Less than 10% of your time being spent in meetings doesn't sound like it should slow you down that much.
  - leoedin 15y ago
    When you're doing 4 other courses, you don't generally have more than 30 hours a week to spend on a project.
fab13n 15y 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 15y 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.
  - rdtsc 15y 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.
    - fleitz 15y ago
      Silo-fication is good in a large company, you find a good silo and you make sure the rest of the dreck doesn't infect your group. If you've got a decent financial whiz who can end-run the bean counters in your silo even better. Take a look at a farm, what's outside the silo? Rats, rot, waste, what's inside the silo? Stuff you can sell for money that is well protected from the elements. In a large company you need to be a very adept bargainer / barterer to acquire all the resources you need despite the bean counter mentality.
    - fab13n 15y ago
      But in the rest of the large company, there are hordes of pointy-haired bosses who are busy full-time trying to take up as much credit, budget and headcount as they can. They'll be drawn to your success as rats to food. It takes a lot of political savvy and energy to keep these freeloaders out of an effective team.
marcusf 15y 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.
brudgers 15y 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.
- raganwald 15y 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.
  - brudgers 15y 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]
tomelders 15y 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 15y ago
  "Many hands make light work"
  - tomelders 15y ago
    "light", but not "good".
    - shadowfox 15y ago
      I am not sure you should take proverbs so literally (or take it as canon for that matter). By the original proverb fewer cooks only make the broth not-spoiled, not necessarily good either :P
      - tomelders 15y ago
        I up-voted for the lolz. But deep down I hate you and your reductive reasoning.
virmundi 15y 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.
Someone 15y 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 15y 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.
tashnosh 15y 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.
matwood 15y 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.
- brudgers 15y 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.
  - matwood 15y 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 15y 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 15y 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 15y 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 15y 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 15y 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 15y 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 15y 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 15y 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 15y 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 15y 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 15y ago
  100,000 lines of PHP or Java maybe. Probably not 100,000 lines of Haskell.
- roguecoder 15y 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.
dustingetz 15y ago
corollary: large teams have access to markets that small teams don't. things are the way they are for a reason.
mwd_ 15y 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.
jacques_chester 15y 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.
pnathan 15y 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.

226 points by gvb 15y ago

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

zizee 15y 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 15y 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 15y 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 15y 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/ 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?)
- nickik 15y 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 15y 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 15y 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 http://en.wikipedia.org/wiki/The_Mythical_Man-Month [2]http://en.wikipedia.org/wiki/Peopleware:_Productive_Projects_and_Teams http://en.wikipedia.org/wiki/Peopleware:_Productive_Projects...)

arethuza 15y 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 15y 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 http://www.lifewithalacrity.com/2004/03/the_dunbar_numb.html
  - gbog 15y ago
    split vote: do you really vote decisions? if it's 50/50, I'd say the real solution hasn't been found yet.
  - arethuza 15y ago
    I read that a long long time ago - but I'll have a think and see if I can recall where it was. I'd agree that a larger team effectively mitigates risks around individuals not fitting in or decision-making being stymied, but in my own personal experience I've definitely preferred, due to a perception of maximising by own personal productivity, that 3 or 4 was best. That is, of course, completely subjective!

leoedin 15y 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 15y ago
Less than 10% of your time being spent in meetings doesn't sound like it should slow you down that much.
- leoedin 15y ago
  When you're doing 4 other courses, you don't generally have more than 30 hours a week to spend on a project.

fab13n 15y 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 15y 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.
- rdtsc 15y 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.
  - fleitz 15y ago
    Silo-fication is good in a large company, you find a good silo and you make sure the rest of the dreck doesn't infect your group. If you've got a decent financial whiz who can end-run the bean counters in your silo even better. Take a look at a farm, what's outside the silo? Rats, rot, waste, what's inside the silo? Stuff you can sell for money that is well protected from the elements. In a large company you need to be a very adept bargainer / barterer to acquire all the resources you need despite the bean counter mentality.
  - fab13n 15y ago
    But in the rest of the large company, there are hordes of pointy-haired bosses who are busy full-time trying to take up as much credit, budget and headcount as they can. They'll be drawn to your success as rats to food. It takes a lot of political savvy and energy to keep these freeloaders out of an effective team.

marcusf 15y 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.

brudgers 15y 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.

raganwald 15y 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.
- brudgers 15y 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]

tomelders 15y 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 15y ago
"Many hands make light work"
- tomelders 15y ago
  "light", but not "good".
  - shadowfox 15y ago
    I am not sure you should take proverbs so literally (or take it as canon for that matter). By the original proverb fewer cooks only make the broth not-spoiled, not necessarily good either :P
    - tomelders 15y ago
      I up-voted for the lolz. But deep down I hate you and your reductive reasoning.

virmundi 15y 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.

Someone 15y 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 15y 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.

tashnosh 15y 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.

matwood 15y 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.

brudgers 15y 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.
- matwood 15y 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 15y 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 15y 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 15y 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 15y 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 15y 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 15y 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 15y 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 15y 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 15y 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 15y 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 15y ago
100,000 lines of PHP or Java maybe. Probably not 100,000 lines of Haskell.
roguecoder 15y 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.

dustingetz 15y ago

corollary: large teams have access to markets that small teams don't. things are the way they are for a reason.

mwd_ 15y 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.

jacques_chester 15y 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.

pnathan 15y 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.