
Small teams are dramatically more efficient than large teams - gvb
http://spin.atomicobject.com/2012/01/11/small-teams-are-dramatically-more-efficient-than-large-teams/
======
fab13n
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.

~~~
bh42222
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
_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.

~~~
andywood
This probably depends on the local culture. When I was at Microsoft, in the
groups I worked in, we were explicitly evaluated on criteria such as "makes
others better". My reviews actually stated that actively mentoring and going
out of my way to be genuinely helpful to others contributed to my score, and I
ranked on top almost every year. When I think of other colleagues who I know
ranked highly, the people who come to mind are the ones who had both the
ability and willingness to help a lot of other people do their jobs better.

~~~
bh42222
_This probably depends on the local culture._

Yep, and what I've heard (and only heard, never worked there myself) is that
Microsoft has some of the most programmer friendly corporate culture around.

A lot (if not most) big companies are not like that. The reason Joel's writing
on company culture is so popular is because such simple things are still quite
rare in the world.

~~~
sliverstorm
_Microsoft has some of the most programmer friendly corporate culture around_

I figure this is part of what has kept them around, and is fueling what seems
to me to be a come-back in spite of everything going against them.

I don't have a great depth of knowledge on them, but I did interview with
their Xbox team, and everyone was just really enthused to be there.

------
matwood
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
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
_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.

~~~
brudgers
With five people, you might be able to be more selective in hiring talent.
With 30 people, unless you are Google, you will probably be less selective -
half of all teams are below average.

On occasion a come to jesus talk might be appropriate with some types of
employees, but once one starts threatening people with the loss of employment,
bad things often follow - particularly in the US where such threats often mean
loss of access to healthcare for the employee's family.

BTW, when the job is pushing the boulder forward, smart people recognize the
sisyphean nature of the task and respond accordingly.

~~~
matwood
_half of all teams are below average_

If you only look at your organization then yes 1/2 of the teams in your org
are below average for your _org_ , not necessarily below average for all
software developers. I'm not talking about trying to hire only the best of the
best like Google. I'm talking about avoiding the worst of the worst.

 _On occasion a come to jesus talk might be appropriate with some types of
employees, but once one starts threatening people with the loss of employment,
bad things often follow - particularly in the US where such threats often mean
loss of access to healthcare for the employee's family._

So are you arguing to just fire them outright? I thought that's what you were
against? And since when is a frank review of performance a threat? This must
be where 'everyone gets a trophy' day has led us. Unless people are told their
true performance and how it stacks up to what's expected they will not be able
to improve. It may be that they are simply unaware how bad they are
performing, or they simply need to be motivated.

 _BTW, when the job is pushing the boulder forward, smart people recognize the
sisyphean nature of the task and respond accordingly._

Huh? Are you saying all work is useless? That's certainly not what I meant by
the term. Pushing the boulder forward is what I consider advancing the
business in a given direction, one that I certainly hope doesn't have to be
backtracked.

In business there are people on the boulder deciding where it should go then
there are people on the ground making it happen (I'm including all the support
people here). Finally there are people standing on the boulder doing neither,
and instead provide dead weight to be carried.

In small companies the people who decide the direction and make it happen are
often the same. This is what makes small companies so nimble. Those deciding
where to go also know directly of the challenges of getting there. Small
companies also rarely have much dead weight just standing around.

In big companies there is often a huge divide between those who decide
direction and those who make it happen. Big companies also tend to have lots
of people just standing around on the boulder. Now, standing around isn't so
bad until these people start getting in the way of the job of advancing the
business. When they start actively trying to make things harder for those
pushing because they feel some odd sense of job security by doing it that way.

~~~
brudgers
> _"If you only look at your organization then yes 1/2 of the teams in your
> org are below average for your org, not necessarily below average for all
> software developers."_

If you look across the industry odds are most or all of your organization's
teams are below average given that Google, Microsoft, Apple, Oracle, IBM, etc.
are able to retain a significant fraction of the top talent and
entrepreneurship claims many as well.

In a large organization, smart people realize that those distant people who
decide what to do with the boulder are often motivated to move the boulder
because they must do something and moving the boulder is something.

Occasionally, moving the boulder improves things, often it doesn't. A good
manager musters resources to the former and gives lip service to the latter. A
good manager listens to the whining of those compelled to demonstrate needless
nimbleness by pointing to the degree to which others are not participating in
the fire drill of the quarter, while retaining adequate staff in a pleasant
workplace to move the boulder when it actually needs moving.

------
mbesto
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...](http://en.wikipedia.org/wiki/Peopleware:_Productive_Projects_and_Teams))

~~~
arethuza
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
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>

~~~
arethuza
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!

~~~
arethuza
I can't find where I originally read that (although I believe the original
research was by IBM).

However, here is a more recent article that suggests that "best" team size is
5 plus or minus 2 - which fits into my preferred range:

[http://www.informit.com/articles/article.aspx?p=1674234&...](http://www.informit.com/articles/article.aspx?p=1674234&seqNum=7)

------
machinagod
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).

------
brudgers
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
_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
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]

~~~
nickik
I would clame that per line of code (assuming the same language) a small team
producess much more value. Communication is fast and common problems are
identified fast. In a large team it can happen easly that two people need to
parse XML and they take a diffrent parser (simple example), stuff like this
will be a source of trouble in the project going forward.

------
leoedin
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
Less than 10% of your time being spent in meetings doesn't sound like it
should slow you down that much.

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

------
tomelders
"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
"Many hands make light work"

~~~
tomelders
"light", but not "good".

~~~
shadowfox
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
I up-voted for the lolz. But deep down I hate you _and_ your reductive
reasoning.

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

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

------
51Cards
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.

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

------
zizee
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!

------
shawn42
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.

------
jcromartie
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
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?)

~~~
nickik
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.

------
Chris_Newton
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.

~~~
roguecoder
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.

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

------
darasen
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.

------
SNK
” 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
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.

------
ohyes
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
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.

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

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

------
afy
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
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.

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

------
chalst
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.

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

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

things are the way they are for a reason.

