
Ask HN: Why are big companies so much less efficient? - aylmao
I&#x27;ve worked on companies big and small (relativley; smallest was around 400 people, though engineering was closer to 160-200). One thing that has struck me is that, in my opinion, smaller companies seem to get much more done per engineer than bigger ones. I&#x27;m curious-- has everyone else has seen this too? In your opinion and experience, why do you think this is?<p>Is this the overhead of decision-making (one person or the engineer deciding vs a chain of command)? Is it that people are just more motivated when they&#x27;re the underdog? Is it that the inherent size and complexity of a codebase grows exponentially as people grow linearly with time? Is it that some products seem to be &quot;done&quot;, and changes are iterative and pedantic, not risky and exciting? All of the above? Maybe even some more?<p>I&#x27;d love to hear your stories and thoughts!
======
whack
There are a hundred valid answers to this question. Here's one that I think is
a major factor: What is the degree of separation between the engineer, and the
people who benefit most from the engineer's work?

If you're a startup founder, you eat what you kill. There is no degree of
separation at all.

If you're working at a 10-person startup, you report directly to the founder.
1 degree of separation.

At a 50 person startup, you probably report to someone who reports to the
founder. 2 degrees of separation.

At a place like Microsoft, you're probably 7-8 degrees removed from the CEO,
who himself reports to the board-of-directors, who report to a decentralized
mob of shareholders.

At every degree of separation, there is an amplification of:

\- distortion of incentives

\- "Not my job"

\- "that decision is above my paygrade"

\- "What's in it for me?"

I don't think individual productivity can ever be as high in mega-corps, the
way they are in startups and smaller teams. Hence why mega-corps are generally
best at milking existing cash-cows, whereas startups are much better at
actually driving innovations.

~~~
lopmotr
If that were really true though, wouldn't a big company solve it by splitting
itself apart into smaller parallel units all doing the same job as each other
but with shorter hierarchies and not wasting time communicating with each
other? I think economies of scale still overwhelms the chain-of-command losses
you described and makes big companies more efficient overall.

~~~
vokep
might just be big (Big! like google) companies have only been around for so
long. I don't know of any company that has tried something like that, maybe it
would work great!

------
cimmanom
Communication overhead.

You've seen those graphs about how lines of communication explode
combinatorically. Once an organization hits ~20 people, if they're all
communicating directly and keeping up to date with everything they need to
know, everyone could be spending every minute of their day communicating and
not getting any other work done.

In order to cope with the communication overhead, larger corporations add
management hierarchies that maintain linear communication "vertically" and
smaller group sizes for "horizontal" communication. They also add processes
that decrease or streamline the amount of communication necessary. Management
and process are _necessary_ to keep the company from grinding to a halt under
the weight of its own communication overhead.

However, management and process even when done well will add a certain amount
of overhead and slow things down. Less than they would if every engineer had
to check with everyone in Sales and Marketing before deploying any change in
order to make sure that a deploy wouldn't disrupt a major campaign. More than
you and your two co-founders sitting next to one another and asking "hey, I'm
gonna deploy the Foo feature now - is that cool?" And when done poorly,
management and process slow things down even more.

~~~
petra
Why is "communication overhead" still relevant, when today, huge open-source
groups cooperate very effectively ?

~~~
jowiar
[Citation needed] -- Not saying this to be glib, but I'm just wondering what
is an actual "huge open-source group". From what I can tell, most open source
projects are heavily maintained by a single-digit number of people at any one
time.

------
dvfjsdhgfv
I wouldn't say less efficient but with larger margins. I could probably do the
work of 2 my colleagues if I was really pressed and was forced to work
overtime. Instead, I work something like 5-6 hours a day. This sounds like
inefficiency - however, when people get sick, when they go on holidays, when
new products are to be released and we need to do something extra fast - it's
business as usual and no extra sweat is involved. Pure comfort for everyone,
including the marketing and sales teams.

When I confront it with the times I worked for a small company... You had no
choice but to work hard. If you didn't do it, it wasn't done. Deadlines were
pushed forward, everybody was unhappy. There was no margin for anything, so I
had to work overtime very often. These two approaches are incomparable. (Of
course you can easily find opposite examples, especially in big consulting
firms, so take this with a grain of salt.)

~~~
maximp
> _You had no choice but to work hard. If you didn 't do it, it wasn't done.
> Deadlines were pushed forward, everybody was unhappy. There was no margin
> for anything, so I had to work overtime very often._

Can echo that this was my (small, well-funded, widely-used) startup experience
as well. Going into a bigger organization after this was shocking in terms of
how lax people worked.

~~~
justherefortart
I worked at a few clients in SF, CA a couple years ago. As a consultant 40
hours was the minimum. It was also my maximum.

I'd get to the jobsite at 6-7am (avoiding traffic/crowded trains/buses). I'd
go to lunch at 11am and leave around 3-4pm depending on how many hours I'd
been there.

I'd see the employees rolling in at 9:30-10am. They'd eat their breakfast, so
SCRUM at 10:30am. Then they'd take a 2 hour lunch and at 4 or so when I was
leaving would have to go "pick up the kids" or "doctor's appointment" or any
of 100 other excuses they had.

I had someone ask me once, "How many hours are you working?" (implying I was
there a lot). I said "Forty, how many are you working?" (implying the 26 or so
they were actually in the office).

I called it California Time. It wasn't at one company, it was at every medium
to large company I went out to as a consultant or contractor.

I guess if they were achieving their goals, it wouldn't be a big deal, but
when you've got $250+/hr consultants in there helping, you're not.

~~~
dte22
Wow, were you part of a consulting firm? did they find you the placements?

------
wenc
Big companies tend to optimize for business continuity rather than pure
efficiency.

It is a systems tradeoff.

You can hire 5 10X people, but if one of them leaves (10X invariably do), you
would have a harder time replacing, on-boarding, ramping up, culture-indoc,
etc. another 10X person, assuming you can find one. In the mean time, this
could potentially mean anything from a chaotic breakage of process or severe
team reorg.

Whereas if you hire 50 1X people, if 5 leave, the system will likely still run
at reduced capacity while you backfill if you have good process (not all big
companies do, but those that survive in competitive industries tend to).

Good process often wins over a concentration of pure talent over the long run.

~~~
icc97
I don't know about 10x people, but I think startups attract people who like
efficiency. People who hate wasting time in meetings. However for big
companies meetings seems to be like a drug.

The startup I work for that went from 3-30 people over the years was bought by
one of 100,000.

I keep wanting to have meetings of 2/3 people and the people I come across at
the new company love having 6+ people in a meeting.

~~~
Clubber
I like small companies because they let me get things done. "Solve this
problem." and I'd solve it. That could mean cleaning up some workflow, or
building 5 automation engines.

This gets more difficult when you have modules that have more than one person
coding on it, because now you can step on each other's toes.

Big companies usually have 7-8 people working on a particular module, which
requires a lot more coordination. That module is probably spec'd out by
another team of a few people who talks to the business teams that will be
using it, or talk to a client. These teams all have managers who need to know
what's going on, so they have more meetings. When there's a question on the
spec, it now involves two teams that must have a meetings to talk. Teams ask
questions of other through their managers which leads to more meetings. The
original, "Solve this problem," was defined by an upper level executive 5
levels up, based on some grand strategy that I don't know about and won't be
explained to me.

It turns into a big mess.

------
mlazos
So I think another factor that hasn't been mentioned is that at a large
company there is often an aversion to two things: breaking existing services
and duplicating work that another team already "owns" (the second part is
normally done in vain, but still wastes time, as you can see by Google's
message app mess). This results in slower agility already, because if someone
would like to add a new feature, there needs to be some degree of
communication with owners of the needed projects and coordination across
teams. All of this takes time away from producing tangible work. The reason
that this continues is because at most large companies (at least tech
megacorps) _this inefficiency is a rounding error_ compared to the boatloads
of money that the company rakes in. The system in place keeps the ship moving
and delivers innovation at a manageable pace, and as a result nothing in the
organization structure really changes because the company continues to profit,
and everyone internally reaches their objectives:

\- Upper management: company is making money

\- Middle management: engineers are doing work, projects are coordinated

\- Engineers: projects move slowly, but getting paid and promoted and gaining
experience

None of these objectives are "streamlining organizational structure"

~~~
dmourati
Surprised this is the only comment mentioning the duplication of work problem.

------
shamino
It's like going to lunch with a group of people. If it's just you, you can go
wherever you like. Once it's with your partner, you have to take their
interested into account. Have you tried planning a lunch for 5 or more people,
taking into account dietary restrictions, location, time, etc.. ? And imagine
when it's 400 people - now you need to make sure the restaurant can hold that
amount of people, and if it's available during times that you like. The more
people that are involved, the more variables are introduced that influence
decision making.

~~~
nerpderp83
Or a music festival where multiple conflicting acts are playing. Getting more
than 2-3 to agree on a thing to attend is a nightmare and it just descends
into sitting in the beer garden listening to whatever.

~~~
eggpy
Or, you know, all going to see whatever you want and meeting up when you can.
Festival protip: there's no law saying a group must stick together the entire
time

~~~
nerpderp83
That is what I am saying. Trying to coordinate a group is a losing proposition
where it descends to LCD. Flocking vs herding, flock for discovery, herd for
safety.

------
Bahamut
Depends I think - big companies are vastly more efficient than small companies
at certain things.

To give a personal example from a FAANG, where I work at, web developers don't
have to worry much about a lot of the ops infrastructure - a lot of that work
is offloaded to another org whose sole responsibility is to have a robust
setup for the whole company. We don't have to reinvent the wheel for things
like CI/CD, and such nice features like deploy on a pull request basis. The
main inefficiency I see is that large organizations take time to make the
decision of whether something is the right thing to build. Once the decision
has been made, the implementation happens much faster than what small
companies can match that I've seen - my own employer moves frightfully fast
compared to any startup I've worked for.

From personal experience, I see small companies constantly struggle with
trying to standardize these things, and often solve these problems in a way
that causes long term iteration pain. Oftentimes the engineers aren't good
enough to solve many of these problems, and the short-termism of feature
development strangles a lot of proper solution building, which actually leads
to a lot of inefficiency.

A lot of times, small companies also often take shortcuts that bigger
companies cannot take. For example, internationalization and accessibility may
be minimum requirements at some bigger companies, whereas small companies may
not be hamstrung with supporting those fully for their customers, if at all.

~~~
doomjunky
I'm d’accord with that. I think many comments here have a misconception of
efficiency versus flexibility. For me it breaks down to:

\- Big companies are: More efficient but less flexible

\- Small startups are: Less efficient but more flexible

Big companies are more efficient because every employee has a narrow field of
responsibilities. They are dedicated to just a few tasks and can leveradge
from focusing their minds on just one thing (e.g. a web developer who is just
responsible for programming his mobule). Compared to a small inefficient
startup, were every employee has a broad spectrum of responsibilities and
needs to refocus his mind often (e.g. a web developer who has not only
programming tasks, but also system administration, setup/deployement, UI
design, customer support and cleaning the coffee machine and fixing the
printer).

Small startups are more flexible because everybody can directly give new ideas
to the boss, everybody has knowledge about the whole company and how
everything is tied together and changes to processes or infrastructure can
easily be adopted.

I think this situation is not a bad thing. Big companies and small startups
live in symbiosis. Startups are flexible enough to produce new innovations.
Then they either grow big (implement processes, standards, hierarchies, etc.)
or get acquired by a big company. However, big companies are not flexible
enough to produce new innovations but they have the resources to found spin-
offs / create new startups.

------
willart4food
The Pareto Effect.

The Pareto Effect, applied to companies' productivity, states that 50% of the
output is generated by the square root of the number of employees.

So, if you have a company with ~10 employees it's not a big deal, 50% of the
output is generated by ~3 employees. However if you have a company with 10,000
employees, only 100 of them are generating 50% of the output; and that becomes
pretty visible since each of these 100 employees knows most of the remainder
99, and most of the people they come across are "dead weight" to the company.

Give the company enough time, and the productive employees will leave to seek
greener pastures, so - little by little - the company collapses.

~~~
johnvanommen
I'm surprised this comment is buried. Your answer is correct, and it's a
fundamental economic principle.

------
shade23
This going to be more obtuse from what you would expect but i can give it a go

this is because efficiency isnt a goal , impact is. you might be efficient
enough to iterate 10 times a month. but that is not what a customer wants.
planning goes a long way compared to just doing something. as software
Engineers we often mistaken efficiency as "getting shit done". which is great
but there are too many instances when it is shit. the bigger the org and the
user base / affected population, the things you do has an impact . i've known
users to shift loyalty due to small mistakes that companies do. as a dev
deeply connected to the impact of your product, you realize that decisions
make a big difference. you plan ahead and mitigate probable failures. these
require time.A good product can go a longer way than an efficient team with no
direction. this does not imply that everything takes time. but repercussions
of a bad decision can be lasting in a big organisation. you have a large
number of stakeholders involved who would want to and can help you achieve
your goal. this is however not always good. the greater amount of red tape
involved can lead to competitors gaining an edge and also several cases of "i
fucked up". the bottom line being. efficiency isnt merely moving fast. its
about building things which matter and having an impact. if you look at
efficiency in that manner, then big orgs aren't any less efficient than the
smaller ones since their reach is much greater. perspective matters

------
drunner
In my personal experience, complexity of the product.

Anyone can start a new product with 1/10th of the features of a competitor and
feel that large corporations are slow and inefficient.

Hammering out all of the edge cases and flushing out a product is often what
takes a lot of time and manpower. Not to mention dealing with a larger number
of customers who probably use said product.

There are success stories of small shops who automate everything, or who offer
a product that is so simple (not a knock, actually a complement) that it can
be run by a small team. Complexity is the enemy to shops like this, and I
think few know how to avoid it in the long run.

------
jcadam
I've worked for big companies early in my career (good place for a junior
engineer to get some experience), then mostly smaller companies (where I could
just walk into the CEO's office and strike up a conversation if I felt so
inclined), where I got used to being multi-hatted and pitching in wherever.

Right now, I'm sitting in a cube at a huge corporation. This job was a step up
in pay, but in every other way feels like a big step down. I'm pigeon-holed as
a senior engineer on one very specific part of an unnecessarily complex
software system (Java, of course).

I'm bored out of my mind and literally going stir-crazy - I get up and pace
around the cube farm often. I leave the building and go for walks during the
day as well. I also spend more time on HN than I should :)

I will never take a job with a megacorp again, ever. I want to work for a
small company where I have some autonomy and the ability to have an impact on
the business.

~~~
mirceal
yes. you're bored. yes. it sucks. But why is this megacorp less efficient than
a small company?

~~~
jcadam
The boredom is a symptom of the inefficiency of the large corporation.

Actually, I'm not sure I could say it's _less_ efficient. It's just optimized
differently. The company is deliberately set up to treat engineers as
interchangeable cogs to minimize risk. Following the _process_ is more
important than getting stuff done (and boy, do big companies love process).
Also, you are "protected" in a sense from gaining too much domain knowledge or
having direct communication with users/customers, and you are shuffled around
every so often (Matrix management, yay).

Small companies can't afford to do that. They can't hire a legion of average
performers and hope to make up for it with byzantine processes and tightly
defined roles and responsibilities.

------
neilalexander
As companies grow, it becomes harder to manage people and things, and
therefore processes get created. To bring chaos to order.

Each process brings an overhead - someone needs to create the process, then
some number of people need to manage the process, another number of people to
document and explain the process to others and finally a group of really
unfortunate people who will be forced to live with it.

All that happens is that the more people there are that need to use a process,
the more people are needed to manage it. If the use-cases outgrow the process
then someone else needs to come along and make a new process, and then even
more people will need to come along and advertise the merits of this wonderful
new process and to explain to everyone else how it works and why they should
be using it. Suddenly you have more processes and more people to drive them.

You hire some more people because you realise that all these processes are all
well and good but actually they aren't making you any money. All that happens
is that these people are also inundated with processes and therefore are less
efficient, because suddenly you're having to actually justify your work
internally or to go through some kind of process and time wasted doing that is
not making the company any money.

What happens eventually is that most of the people working at a big company
aren't actually working towards the goal of the company whatsoever. They're
just there to hand-crank a process. None of these people are actually revenue-
generating, and the people who are actually there to be revenue-generating are
slowed down or otherwise hindered by process.

The problem is self-perpetuating. Oh, no, we aren't making any money. How can
we improve our processes to make more money? The cycle continues.

------
dboreham
You're considering the wrong part of the company (R&D) when evaluating
efficiency. Big companies are efficient in terms of serving their customers
and extracting money from them.

Big companies often end up buying small ones precisely to extract the
efficiency benefits you cite.

Perhaps a good question is : could big companies' R&D be made more efficient?

In answering this you'll probably run into the question "who gives a crap
about the things you want to be more efficient?" Most people working in big
companies are focused on other stuff such as how to avoid being fired by their
psychotic boss, how to get a promotion, how to get a good performance rating,
how to get a better job elsewhere, and so on. Only sometimes are their motives
aligned with efficiency and things like delivering good products.

~~~
kazinator
> _Big companies are efficient in terms of serving their customers and
> extracting money from them._

Efficient in what parameter(s), compared to the service and money extraction
performance of small companies?

Big companies extract an _absolute_ bigger volume of money and provide a
bigger volume of service; that is undeniable.

But a measure of some sort efficiency need some sort of denominator under
that.

E.g. from the point of view of a top brass executive getting rich, a bigger
company is certainly much more efficient than a small one.

~~~
PeterisP
Economies of scale basically. If company A serves 100 000 customers and needs
$1m to do R&D of a particular feature, and company B is much larger, serves 1
000 000 customers and due to organizational inefficiencies needs to spend $2m
of R&D man-months to do the same feature, from the customer's viewpoint
they're still much more efficient than company A, since they have less
expenses per customer, so they can either charge lower prices or afford to add
more features to their product.

It's like the efficiency of Amazon and Walmart - a small store can outcompete
them on some aspects like, say, customer service, but not on efficiency as
measured as cost of overhead per item or sales dollar. Lots and lots of good
things are prohibitively expensive unless you can spread that fixed cost among
many customers.

~~~
kazinator
But economies of scale are not efficient _for making money_. It's about moving
more units at thinner margins. More volume has to be moved to make a buck.

Economies of scale are efficient for unit cost, for sure; the production of
stuff is efficient.

Two guys laying residential bathroom tiles are more efficient at making money
than Amazon, in some sense, though.

------
peacetreefrog
Ran across this Charlie Munger quote a few months ago that stuck with me about
the problem with larger companies and bureaucracy:

"...if you worked for AT&T in my day, it was a great bureaucracy. And in a
bureaucracy, you think the work is done when it goes out of your in-basket
into somebody else's in-basket. But, of course, it isn't. It's not done until
AT&T delivers what it's supposed to deliver. So you get big, fat, dumb,
unmotivated bureaucracies.

I think that's part of it. There's a natural human tendency to want to feel
like you're accomplishing things, and in large bureaucracies it's easier to
feel accomplished without actually getting the things done that need to get
done.

Also from Munger:

"They also tend to become somewhat corrupt. In other words, if I've got a
department and you've got a department and we kind of share power running this
thing, there's sort of an unwritten rule: “If you won't bother me, I won't
bother you and we're both happy.” So you get layers of management and
associated costs that nobody needs. Then, while people are justifying all
these layers, it takes forever to get anything done. They're too slow to make
decisions and nimbler people run circles around them."

------
dragonwriter
> One thing that has struck me is that, in my opinion, smaller companies seem
> to get much more done per engineer than bigger ones. I'm curious-- has
> everyone else has seen this too? In your opinion and experience, why do you
> think this is?

There's a couple reasons, but the biggest is that less established companies
and their investors tend to have a higher risk tolerance, while well
established companies tend to be more risk averse; consequently, the small
companies _that survive_ get more done per engineer, on average, because
they've taken a higher risk / higher reward approach. (Google often gets
mocked as inefficient for taking multiple parallel stabs at the same problem,
and, sure, a company which just did whichever one turns out to get validated
by the market would be more efficient—but one which did only one of the losing
ones would fail and be forgotten.)

Another issue that is that bigger firms are often devoting considerable
resources to solving non-technical problems (like “securing enterprise and
government contracts”), which often are very rewarding in terms of profit, can
often be rewarding in terms of impact, but often compromise efficiency in a
narrow technical development sense.

------
jbob2000
Speaking more pragmatically, larger companies are much more family friendly -
people guard their personal lives fiercely at large companies. At least, this
is my experience at an 80,000+ employee company.

You're basically a huge asshole if you book a meeting at 3pm because you'll
make all the moms and dads late for picking up their kids. And you can't book
any meetings before 10am because more often than not, it's tough to get
everyone in earlier because they have to drop their kids off.

Aside from that, new parents are often glued to their phones waiting for
updates from whoever is taking care of their children. They are not fully
engaged in meetings and I often watch their attention drift to the daycare
nanny cam. I have a coworker who receives hourly updates from her mother who
is taking care of her young child. Sure enough, every hour there is something
that needs to be corrected and thus, a 15 min phone call ensues.

So here I am, a single software developer, who has to wait a week for our
sprint planning meeting because everyone else on the team has put up
roadblocks that prevent it from happening. I literally will sit here this week
doing nothing because of this. This is a regular occurrence.

This isn't a complaint really, I will want these same luxuries when I am a
parent, but I can't help but notice that 90% of my team would really rather be
elsewhere.

~~~
Ocerge
I definitely sympathize with this. I mean this in the best way: many large
companies are little more than adult daycares. And in many cases, it's a
feature, not a bug; it's probably about as close as we can get to some sort of
UBI. As long as the company is in the black and nothing too nefarious is going
on, it's 100% acceptable for people to come in, put in a Michael-from-Office-
Space level of work, and go home. Earlier in my career I found myself in the
position where I could hide away for multiple weeks and nobody would notice,
for this exact reason. I moved on to a smaller company so I could actually do
things, but if I were a parent, I'd make some calls and go right back to that
gig.

------
heyyyouu
One thing that I've found is that the more people there are at a company the
more people there are that feel a need to justify their job or themselves
(never underestimate ego), so they feel the need to put their finger in every
pie, even when they're not needed.

What I've seen happen is that a small group will try to get something done
quickly (with the CEO or COO's or whomevers blessing) but then other people
will get wind of it and say hey, I'm the XXX of Marketing, you can't do that
without me, or I'm the XXX of Project Management, you have to follow these
procedures, or I'm the XXXX of IT, why do you think you can just buy that $99
component yourself and get reimbursed instead of doing this and this and this?
None of those people are NEEDED to do the project, but they'll all be offended
if they're not included or, worse, the processes they've created aren't
followed when doing the project aren't followed.

This also tends to manifests at meetings -- meetings with more than, say, 7
people can de-escalate from let's talk about only what needs to be said for
this project to let me say what I need to say so that I can show that I know
what I'm talking about or that I look good for my boss or my department isn't
irrelevant or one of 100 other things that genuinely have nothing at all to do
with actually improving or helping the project itself.

There are ways to get around this -- meet with the individual stakeholder
groups individually, don't allow large meetings to happen if at all possible,
get the highest buy in you can from the beginning, forge key relationships in
each department so that you have go-to people for getting stuff done, but
honestly I'd rather just work in a small company because I can just do stuff
and get it done extremely quickly (and small companies have these same
problems too, they're just much easier to get around if you have the right
backing -- you're trying to get around a department of 2 that's trying to
roadblock you instead of a department of 50).

------
tabtab
Big orgs tend to rely on economies-of-scale and not nimbleness: they study the
process and "regiment-ize" it to make it efficient by partitioning and
standardizing labor, tasks, and parts so each part can focus on and perfect
their particular corner of the world. Lack of nimble-ness is not necessarily
the same as being less efficient.

However, regimentation can become less efficient if it gets in the way of
change, and big orgs are known to be slow to change.

------
eldenbishop
I have worked at many companies ranging in size from small two person startups
to massive megacorps (Hewlett Packard, Salesforce). One big difference I saw
was that, in a small company, everyone succeeds or fails together. Everyone
wins or everyone loses. This creates focus on shipping good product, not
getting promoted over other people or competing for a bonus pool for the top
10% of the team. Larger companies have numerous structures and methodologies
that decouple this and create many paths to "winning" that have nothing to do
with shipping anything of value. You can completely fail to do anything and
still get promoted. There is tremendous internal competition and politics,
fighting over budgets, hiring, resources and power plays of all sorts. I
personally got huge bonuses for literally doing nothing as managers and teams
optimized around the internal political structure rather than any kind of
product strategy.

~~~
panic
I think this is really the heart of it -- if you're working on a product
together, all you have to worry about is whether your work is improving the
product. You can get other people to help you as long as it also helps the
product. It's a lot easier to be productive when you don't have to worry about
whether team X will be on board or whether executive Y will like what you're
doing.

------
Spooky23
Efficiency is relative. The bigger an enterprise becomes, it becomes more
important for you to consistently deliver in a defined timeframe and cost and
have controls to prevent inconsistency, fraud and abuse. A smaller company
will be more agile, but usually does so with more risk. For the markets they
serve, that risk is often a competitive advantage, and things like pivoting
and adapting rapidly are part of the process -- you cannot pivot and adapt
without human agency.

For a huge company, consistency is key. The brake pad for a car must meet the
specification. Falling below spec leads to waste, and producing over spec
leads to cost and lost sales. In that context, manufacturing seeks to remove
as much human agency as possible and follow the defined process.

This is similar in software. Some stereotypical cobol/java programmer in a
bank/government building to spec is translating business jargon/requirements
to code. The process of delivering the correct calculation in a predictable
timeframe is the goal. Creativity, etc is usually a distraction best avoided,
because the organization literally doesn't care about anything but delivery in
the time/cost box.

Most big orgs separate operational teams from solution development and build.
In some cases all operational stuff is outsourced. In these places, those non-
operational teams get to be more creative, but are usually constrained by
enterprise standards/solutions.

------
matt_s
Risk Aversion.

The smaller companies (aka startups) will do most anything to get customers.
At some point in size when they become larger entities they will do almost
anything to not risk losing business. Make changes fast turns into assessing
the risk with every change and not wanting to cause problems. This slows down
delivery.

There are also organizational factors at play the larger a company gets. You
start getting teams having sometimes opposing goals set by the company. That
is basically because of bad management.

Micro management also becomes a factor, there are too many personalities at
play in a larger organization to quell this. Somebody will be the checker of
all things and sole decider as a manager. This will morph people reporting
into that person as risk-averse and decision-averse. They won't think for
themselves and will wait to be told what to do.

None of this has anything to do with how complex or large a code base might
become. It has nothing to do with technology. It is just an outcome of how
large organizations are run. Upper management wants fiscal efficiency which
usually means slower delivery and miscommunication.

I've been on smaller teams inside of a large mega-corp that were able to
operate like a startup. They were managed very well in the sense that upper
management "left them alone to do their thing". Then over time, the smaller
teams were absorbed into a larger micro-managed entity who wanted everyone to
do everything the same way.

------
gaius
_One thing that has struck me is that, in my opinion, smaller companies seem
to get much more done per engineer than bigger ones_

This may be true but you are not comparing like with like. No small company is
going to use agile methods to build a dam or an airliner or a nuclear power
plant or a chip foundry. Small companies are adept at doing trivial things
like websites. Big companies can take on projects longer than the career of
any individual.

------
debt
From my experience, larger, established businesses care very much about risk
mitigation. Legal is a huge component of large businesses.

Fixing and maintaining software can not only cause bugs but may open a
business open to serious legal problems.

So maybe a small change goes into production, and there's no problems
reported; everything is fine.

Well you find out later down the road that Cambridge Analytic was siphoning
off data from a properly working API deployed months before. No engineers were
at fault. No problems reported in production. But also there was no legal
analysis of the feature nor of the deployment in production.

Again, it's about risk. The more users or money flowing through the system the
higher likelihood you're opening up the business to potential legal risks.

Big or small changes to a system used by big businesses must be carefully
analyzed for potential serious negative financial impact on the business; from
a legal, business, marketing perspective.

It's much simpler for a startup with a fraction of the users; because, again,
they are exposed to less risk.

Either way, it's a great question.

------
lopmotr
You have to count all the failed small companies too to make a fair
comparison. All the man-hours that went into them is massive inefficient
waste. Big companies manage risk more carefully and I think that's why they
take more work to do that same thing. For instance, I sometimes the change the
pricing of my small business based on just a feeling. It takes hardly any time
at all. But if Microsoft changes the price of Windows, I'll bet there are
lawyers and accountants and everything working on it for years, not to mention
all the technical work and high level decision making. Seems inefficient but
there's some chance my price change will destroy by business because I forgot
something important, broke a law, didn't understand my market, programmed the
buying page wrong, or whatever. Whereas, for Microsoft, they probably won't
get sued out of existence for putting the decimal point in the wrong place
because everything's mistake-free.

~~~
aylmao
This is actually a very good point I didn't think about. By virtue of their
size bigger companies tend to have higher stakes, which means less margin for
error.

I do wonder though how there's still large failures at big companies: security
breaches, legal problems, DOA product launches, etc. I guess egos and
oversights are just hard to completely sideline.

------
angus-prune
While it is true that large teams are often less efficient than small ones,
for many good reasons given above, there is another aspect to consider:
Consistency and survivorship bias.

This only becomes clear when you compare a big company to _many_ small
companies rather than just the succesful small companies.

80% of small companies fail in the first few years[1]. This is for a bunch of
different reasons, but a significant proportion of the time it is because they
have launched a wrong product, or a bad product, or failed to launch a
product.

Lets assume that 50% of small companies fail for product related reasons [2]
(the other 30% being competition, regulatory etc etc).

We can all think of high profile products from large companies that were still
born or cancelled before being launched. If a large company had 50% of its
projects fail like this, then it wouldn't survive for long.

To prevent these failure numbers, the large company introduces inefficiencies.
Engineers or teams can't run off on their own and develop the 50% of projects
which fail. Instead they have to jump through approval hoops so that the
failure rate is much much smaller.

So even if an engineer is 50% as productive at a large company, they are
actually as productive, on average, when you consider that 50% of engineering
time at small companies is ultimately not productive.

As an ecosystem, large companies may not be that much more inefficient than
small companies as a whole, they are just optimised for consistency, rather
than risk and quick failure. Whereas the inefficiencies of small companies are
externalised as failed companies.

The other side of this is that the potential rewards are often smaller -
they're making a lot of small bets rather than a few big ones.

[1] my ass, but the close enough for this comment [2] ibid

------
terryjsmith
Two reasons in my experience: first, reproducability gets orders of magnitude
more complicated as you grow. One person can do something over and over with
no documentation, a few people can learn from them, but once you get to 10 -
20 staff in a role and you have some churn, you need good documentation,
training, and QA since your risk for errors goes up no matter how good the
documentation and training is.

Second, as others have mentioned is coordination. Now introducing a new
process, feature, or whatever to clients or internally means creating the
requirements, the documentation, working with sales or client services on
timing and release, working with QA on test scenarios, working with training
to get it into training programs, etc.

------
alexashka
It's important to ask the right question, to get the right answer.

One thing to wonder is if it's at all important to measure how much gets done,
'per engineer'. How can you possibly measure that and why bother?

One can be very productive, at doing something nobody will ever use. Another
can be 50% as productive, doing something that'll be used by billions of
people. One can be miserable and productive, another can be happy and 50% as
productive.

These things matter - individual productivity in isolation, not so much.

By narrowing your question down to single individual performance, you've
eliminated the possibility of getting a meaningful answer, other than 'revise
your question'.

------
jacques_chester
Any size company has economies and diseconomies of scale. Very large companies
tend to be very robust -- they can withstand a very wide range of conditions
and pressures. But the cost of robustness is sustained complexity, to carry
around many systems in case you might need them, whether you wind up actually
needing them or not.

This is not unique to businesses. It's true of any self-sustaining system.
Bacteria are _vastly_ more efficient forms of life than humans on many
criteria, but an individual bacterium is much, much less robust to varied
conditions than an individual human is.

------
SnowingXIV
Throwing in my 2c as I've worked at massive fortune 100 companies and took a
shift to work for small businesses.

The top comment about you eat what you kill in small business is the mantra.
It's frightening to think if you don't perform, the risk isn't about not
getting a raise, it's the company going under/firings will happen, now you
need a job, other very bad stuff. This pressure forces you to be efficient,
slacking off isn't an option and would be quite visible. Shit wouldn't get
done.

Working at the large companies this was never a fear, if you performed above
average (even probably average) your job was likely safe. The cost to hire,
train, get someone plugged into the ridiculous amount of systems, assigned
hardware, you name it is very high. Benefits are generally better as well
because economies of scale, neat discounted stock options, etc. This probably
opens the door to less efficient day-to-day stuff taking place (sometimes).

It's not cut and dry though, but I'm glad to have experienced both and am
always open to either. Startup culture right now is super appealing personally
because the whole Jobs' "Be Hungry" thing, age, mobility, etc but I'd imagine
once you have a family to take care priorities and risk analysis is
recalibrated which is cool too. Please note that I'm not saying having a
family or working at large corporation the worker is less efficient it just
might have less ramifications because of the structure.

------
ggg9990
Big companies are inefficient because too much is at stake! A zero-revenue
startup can publish an ad, and if it is offensive to the point of trashing the
brand, literally nothing was lost. A big company could lose billions of
dollars from the wrong kind of publicity. So there are 200 checks and balances
in publishing an ad, making it take 200 times as many people and slowing down
the efficiency of everything.

~~~
flatfilefan
Is also to some extent a survivor fallacy: big firms are small companies that
have survived and grown, failed small companies don’t get to be big. By not
accounting for this factor we deprive our model of a driver.

------
WDCDev
There is no one answer to this questions, and efficiency isn't always in the
best interests of a "big company". Efficiency always must be tempered with
risk. In startups, risk is embraced and therefore they can be very
"efficient", but in many large corporations (and the federal govt. especially)
risk must be quantified, controlled and eventually managed.

When you combine risk management with certain corporate cultures and market
verticals, you get a combination of the following:

Risk aversion

Lack of technical knowledge in the management layer

Technology viewed as overhead vs. a value provider

These three things are deadly to an ambitious corporate IT project. Unskilled
management can't appreciate requirements, manage scope nor understand trade-
offs very well. The business wants guarantees on budget and timelines. Budgets
are fixed, and management rarely wants to ask for more since ROI may be hard,
if not impossible to quantify.

So what do you end up with? The standard "over-promised and under-delivered
technology" solution that are endemic across so many enterprises.

[edit - formatting and spelling]

------
rammy1234
1\. When you do lot more yourself, there is a risk of burn out, risk of
breaking something and also small teams have the luxury to fail fast and
deploy more frequently which enterprises dont dare to do and now with more
CI/CD guidelines enterprises are getting there to iterate faster.

2\. Small teams have the luxury to communicate faster and less noise when
communication happens. Less heads involved in decision making , also problem
of hierarchy of chains to pass through before something is started.

3\. Enterprises sometimes under-estimate the power of development environment
setups. I know you might wonder why this point is here but if developer has
luxury to setup environment quickly and efficiently without spending time on
setting up dependencies lot gets done faster.

------
citilife
Many large companies don't realize there are other groups working on the same
project. This means you may see two teams of 6 people working on the exact
same problem. Resources are then split, potentially this actually makes both
projects fail.

------
Atreus
Scar tissue. It was something essential to stop loss of life at one time, but
now it only consumes. This is a federal and academia problem: if you use less
money this year, your budget is cut next year, so whether or not you need it
every department finds a way to spend every single penny.

Needs of the organism change. It isn't like "slight" it is day and night. It
is the nymph-been in the honeycomb-cell versus the working worker-bee. But
fear wins. What if we still need the old.

And the paradigm of successful business is "don't break the goose that lays
the golden egg, so change is very very bad".

------
lkrubner
Sometimes I assume everyone in the industry has read Fred Brooks, but that
can't be true, so allow me to quote some of him. This from a review of The
Design Of Design:

Quality should be the responsibility of one person

One of Brooks’s many excellent points is that quality happens only if somebody
has the responsibility for it, and that “somebody” can be no more than one
single person—with an exception for a dynamic duo. I am surprised that Brooks
does not cite Unix as an example of this claim, since we can pinpoint with
almost surgical precision the moment that Unix started to fragment: in the
early 1990s when AT&T spun off Unix to commercialize it, thereby robbing it of
its architects.

More than once in recent years, others have reached the same conclusion as
Brooks. Some have tried to impose a kind of sanity, or even to lay down the
law formally in the form of technical standards, hoping to bring order and
structure to the bazaar. So far they have all failed spectacularly, because
the generation of lost dot-com wunderkinder in the bazaar has never seen a
cathedral and therefore cannot even imagine why you would want one in the
first place, much less what it should look like. It is a sad irony, indeed,
that those who most need to read it may find The Design of Design entirely
incomprehensible. But to anyone who has ever wondered whether using m4 macros
to configure autoconf to write a shell script to look for 26 Fortran compilers
in order to build a Web browser was a bit of a detour, Brooks offers well-
reasoned hope that there can be a better way.

[http://www.smashcompany.com/technology/quality-should-be-
the...](http://www.smashcompany.com/technology/quality-should-be-the-
responsibility-of-one-person)

------
TallGuyShort
Think of a product as a graph where each component of the product is a node,
and each other component or aspect of the company that it affects is a
connection to another node. In most cases this means a graph where each node
has many connections, so as the graph grows the growth of connections
dramatically outpaces the growth of nodes.

As engineers on a product, we like to look at the nodes, but the business
reality is often all about the connections. Want to make a change to a node in
a simple 4-node graph? No problem. Want to make a change to a node in a
400-node graph with thousands of interconnections? Problem.

And that's why things slow down. Scaling a company is all about maintaining
that graph so the connections are understandable and manageable, the
connections are very well-defined (but not so defined that you can never
change anything) and that you have the infrastructure in place to make changes
and easily validate that there are no horrible side-effects.

------
ptero
This may be a wrong mental model, but I view it as overall cost to maintain a
structure. For example, the number of nodes (volume / support) to build a
pyramid of height H scales non-linearly with H.

Height is not the same as output (and H / V is not the same as efficiency),
but this model has some similarity to the real world engineering output. Just
my 2c.

------
allenleein
I think the opportunity exists in the business world because when companies
become successful is when collective leadership becomes most focused on
maintaining success.

Usually, leadership tends to see more risk in the downside of the current plan
and than upside in taking on new things.

Few things companies doing regularly:

1\. View a temporary trend as a competitive advantage. 2\. Focus on building
reputational momentum. 3\. Believe it’s easy to span across generations. 4\.
Love being right. 5\. Love the new idea, not new way of thinking. 6\. Love
being “Data-Driven”

Being right and staying right is totally different. Doing well reduces the
incentive to explore other ideas, especially when those ideas conflict with
your proven business model.

LINK: [https://allenleein.github.io/brains/2018/04/strategy-to-
mast...](https://allenleein.github.io/brains/2018/04/strategy-to-master-
theodds)

------
jameshart
I know what you mean. But appearances can be deceptive. How are you measuring
efficiency? While at a big company it may seem to take more people more time
and effort to move the wheels, the wheels are much bigger and they have much
bigger effects. Look at the revenue-per-employee numbers for some large tech
companies: [http://www.businessinsider.com/tech-companies-revenue-
employ...](http://www.businessinsider.com/tech-companies-revenue-
employee-2017-8). (Not shown: Netflix, whose numbers should probably be up at
the top of the range). Ignoring the top end outliers, those guys are averaging
around $0.5-1m. If the company grows by 10%, that’s like having every ten
person team bring in $5-10m in business through established channels, _and
find a new $0.5-1m revenue stream_ every year. That’s pretty efficient.

------
emrekzd
You can't generalize but most often that is the case. Having said that I'm
surprised nobody brought up maybe the most important factor: sunk investments.

If you have a brand name and credibility at stake, if you have customer
liability, if you have built significant the features and infrastructure, if
you hired the people that run and maintain those, if your revenue depends on
current status of your product... We can keep going on but, you have to take
extra actions and caution as you introduce change. That means additional
complexity.

However keep in mind big companies can benefit from certain types of barriers
to entry such as regulation that provide them efficiency over small companies.
For example US immigration policy favors big companies, and IMO GPDR will do
so as well.

------
marcus_holmes
Big companies are efficient. At producing the product/service that they
produce.

They've been relentlessly optimised to be really good at that one thing (or
that one small range of things). There have been people touring the facility
and cutting out slack for years to get it there.

Engineering is change. Changing a super-optimised process without degrading
its performance is difficult. Way more difficult than building a brand new
process.

Everyone involved in the project outside engineering is targeted and focused
on optimising efficiency for the thing. There needs to be a lot of arse-
covering and politics for them to accept that the thing needs to change, and
accept the changes. Hence the accepted changes tend to be iterative and
pedantic, not risky and exciting.

That's how I see it anyway...

------
scotty79
Big companies are amazingly efficient, just not in terms you consider. They
earn way more dollars for each dollar spent than smaller companies. They can
do that by having income sources beyond wildest dreams of smaller companies.
That's the reason they got big in the first place.

And why from the point of view of footsoldier things don't look as efficient
as they could be? Because they don't have to. Because inefficiency you see is
negligible and trying to eliminate it could cost more money than it's worth.
Heck, some income streams are larger if you work slower than you could. You
could be harming your bottom line by making things more efficient.

------
ALurchyBeast
I see the increase in policies and procedures as a big issue at larger
companies. Take your standard CRUD app created at some large corporation. It
will go through QA, security auditing, legal, and whatever other team has
established a policy or procedure around some process. Each one of these
elements takes some number of weeks or months, and each different silo is
typically unapproachable (or has some procedure on how to approach them, too).

Smaller companies can achieve higher velocity because the employees dont
necessarily need the policies and procedures, or they simply havent been
created yet.

------
annywhey
It's built into the design of an organization. It has a strong parallel to the
natural world and how larger creatures have a slower metabolism.

The main feature that defines a really big company is that it is making
something useful out of the labor of huge numbers of people - that the
business model has become in some way premised just on recruiting more bodies
and giving them a job to do, and that the company can keep generating jobs and
see an overall benefit to its bottom line. If we posit that all successful
companies are leveraging some mix of business structure against the labor and
goods markets, a big business is clearly trying to leverage labor quantity, vs
labor quality.

This becomes reflected throughout the organization with "industrial" best
practice: lots of red tape and guard rails, practices that lead to overlapping
roles and redundancies, an excess of meetings, brute force effort used to
solve many problems. Like an overengineered, overpowered, overcomplicated
machine, it works and it makes big products that nobody else can, just not
with the kinds of visible efficiencies one might hope for. At the biggest end
of the scale you get projects like the Apollo missions(great success!) or the
F-35(they tried).

On the other scale, the individual, the labor quantity is vanishingly small.
If you're sick that day, your output is probably zero or negative. But the
ability to switch direction and try new routes and deliberately leverage
skills and interests only you have is unparalleled. No "best practice" is
needed, flying by the seat of your pants and doing things in a "wrong" way may
well be the best way for you to go. And that's the kind of thing that defines
little startups - doing things that aren't standard and don't scale.

As a coder it has some strong implications for which projects are worth taking
on and when, too. Sheer feature quantity and complexity and mass consumer
scaling vastly favors the "industrial" approach of putting large teams to work
solving every problem by sheer force of will. Innovative designs optimized to
human scaled limits, on the other hand, tend to favor the talents of a single
human. And it can be hard to get a grasp on where you actually have leverage
because so much of the visible landscape is defined by bigger projects with
more bodies to throw at problems. They may move slower per programmer but they
have more going on as a business - more sales and marketing, more in-depth
research, more support calls, more deep technical issues caused by scaling,
compatibility, legacy code. You can go really fast by simply solving a smaller
problem on every axis - one customer, one feature, one deployment.

------
jfasi
I can contribute a few factors I've observed working at my Large Company of
Choice (starts with a G). Personally, I believe that, in the ways that matter,
engineers at larger companies are _more_ efficient than their friends at
smaller ones, while simultaneously getting _less_ done. It's basically a
"throughput vs. latency" problem: your work has a larger impact, but you don't
see that impact for a very long time, so it feels less productive:

* Existing codebases need to be maintained. Small companies tend to be younger, which naturally comes with fewer existing systems that require maintenance, and those systems that do exist are generally smaller. The time spent keeping a large production system up and running feels wasted, but it's absolutely not, especially when you consider the alternative is letting the thing fall over and losing the revenue, users, etc. Contrast this against a smaller company where more projects are fresh and satisfying to write.

* Lots of work centers around adding features instead of greenfield projects with no history. Most of the code is already written, much of the infrastructure is already in place, and oftentimes the problem is similar to one that was solved previously. You end up writing less code to get more results, as opposed to a greenfield project where you write tons of code to even arrive at a baseline.

* Larger companies almost certainly have more irons in the fire than smaller ones. While on an individual level it's annoying to have to wait for input from someone who has half a dozen projects on their plate at once, on a company level this makes sense: when you have to put fifty features into production, you don't organize each one individually, you create a pipeline composed of people and run your work through it.

* As a result, projects at larger companies have more stakeholders, which means you need to get agreement from more parties before you can move forward. Also, you're likely not the only thing on those peoples' radars, meaning you'll have to fight for their attention.

* Larger and older companies tend to encapsulate their lessons learned into this pipeline. I'll hazard a guess that this is what people mean when they talk about "institutional failures" led to damages like Well Fargo or Facebook/CA, etc: no individuals failed, instead the system put into place to pipeline their work was faulty. The "human pipeline" of a larger organization was almost certainly built up in response to a long series of nonpublic failures. More quality in the form of fewer such failures, at the expense of higher latency.

* Politics is a thing. Larger companies almost uniformly have career ladders, with the aim of giving people a way to advance their career besides "take a CTO position somewhere else and come back at a L+1 18 months later." This means at least some of engineers' time will be spent marketing themselves for promotion rather than writing code. This often means choosing and prioritizing their projects by biggest expected impact. This has consequences if that engineer is a stakeholder in some other engineer's project and they disagree on the importance of that project to their respective careers.

* Finally, there's a human component to this. In my experience, the sorts of people who join smaller organizations and get tons of work done tend to be younger and less tied down. You're not going to be working at a 6-days-a-week 8am-8pm startup with a wife and children. You're going to be looking to put in your time and head off to live your life. Meanwhile your management is still going to demand big things from you, so you end up becoming efficient out of necessity.

I'll leave you with the upside to this so you don't come away thinking large
organizations are hellish slave pits: The impact of your work is larger simply
by virtue of your being at a large company. I won't go into details, but I
work in a group that puts in months of work to move revenue by shavings of a
percentage point here and there. When you finally launch, you end up thinking
"man, all that work for a 0.5% improvement?" when in reality the baseline of
that improvement is _staggeringly_ large.

------
bluGill
Big companies take care of details that take time.

Every few weeks I have some form of training. Diversity, reminders to obey
copyright law... There is a fair number of things that I could screw up, a
small company hopes I won't - or at least I won't get caught. A large company
will change any bad behavior before there is a problem.

------
pkaye
I'd go by the Mythical Man Month. The communication overhead increases with
more people vs the work getting done. That was my experience in my last
company when we got acquired as our team sizes went from 5 to 15. In hindsight
would have been better to split the teams to do different projects instead of
one big project.

------
awat
Antecdotally in my experience there is also the fact that in large companies
some functions no longer need to exist. That being said you have leaders who
arent going to volunteer this and lose thier power or job so they clamp down
and create middle management holds such as bureacracy or fierce protection of
a function etc.

------
markwusinich
I think survival bias is a huge part of the problem of comparing these two
groups.

You are excluding from your set the small organizations with less efficient
engineers, because they can not survive with even one less efficient engineer.

Large corporations can survive with many more inefficient engineers.

Plus most of what everyone else said.

------
kylecordes
I've thought about this a lot, and reached a conclusion that feels a bit
novel... in that I haven't seen it written about much.

The larger the company, the greater the share of all the mental energy of the
total mental energy is spent internally competing for position.

------
pbreit
Coordination tax.

~~~
cousin_it
Yeah, best way to think about it IMO.

------
pasbesoin
Far from a complete answer, but here are a few factors I've observed, in
several large companies:

Distribution of responsibility/culpability

Culture of deniability

Systemic defense of the status quo

------
lutorm
Because big companies usually attempt bigger projects, and coordinating bigger
projects that require larger workforce is inherently less efficient?

------
DanielBMarkham
I've had a lot experience here and it's something that's bugged me quite a bit
too. I've spent several years on this.

The top comment right now mentions the separation between the engineer and the
people using the software. That's an excellent point, but in a way it's
circular. The larger you are, by definition the more people there are in-
between (or among) you and the folks you're trying to make happy. You can
mitigate that somewhat, but more people means more interference. So in way,
saying you're not close to the customer in big companies is restating the
obvious. Big companies do badly because they're big. True, but maybe not so
helpful.

There's another good one: focus. Startups that scale quickly have laser-sharp
focus on what value they're delivering. They can be so focused that they
almost feel like a cult. Big, old companies might have been that way once, but
they couldn't maintain it.

Communication overhead is another one of the top comments. I think that's
getting closer to it.

Disclaimer: I have book about this. It's called "Info-Ops"
[https://leanpub.com/info-ops/](https://leanpub.com/info-ops/)

Let me take all of these great comments and boil them down to the thesis of my
book: just like we normalize databases to minimize storage and maximize
efficiency, there's a minimum set of information complexity that any
organization needs to function. (There may be tons of ancillary information
not needed day-to-day, but relied on infrequently). In my experience, even in
small teams, the communication noise and overhead is such that you quickly
suffer from all three things: psychological distance from those you're
helping, lack of focus on things that are important, and tons of communication
overhead involving meetings, tools, and various things that doesn't seem to
directly accomplish anything useful.

In fact, this is a systemic problem. That means that good, intelligent people
acting in good faith doing their jobs? Only makes things worse. So not only
does the functioning of the organization get inefficient, the more people
teach, meet, adopt practices, and other things to fix it? The worse it gets.

There's a lot more, of course. But the thing to remember is that _big
organizations have everything they need to succeed_. The information is all
there. The people are all there. They have the time, tools, and money to
immediately do a better job. (I think is one of the saddest parts about it.)
It's the organization and flow of the information that gets quickly out of
whack. They know what to do, they just can't get coordinated enough to do it.

Sorry for the book plug. Happy to answer any questions you'd like that I'm
able to. There's a lot, lot more.

------
amriksohata
I find it's coordination between the sheer number of teams and layers of
management that create miscommunication

------
hawski
I think they are optimized for high throughput instead of low latency.

------
kcorbitt
Here's a post I wrote about my experience as an individual contributor moving
from Google to a smaller organization.

[https://corbt.com/posts/2017/10/28/small-companies-and-
the-p...](https://corbt.com/posts/2017/10/28/small-companies-and-the-
presumption-of-competence.html)

TL;DR is that I feel much more productive in the smaller company, in large
part because there were SO MANY stakeholders at Google that it took a very
long time to decide on a course and move forward with it. I think that
experience probably generalizes to most large organizations.

------
sunstone
Because they can afford it.

------
2_in_a_bath
_um_ Isn't someone saying: 'Don't be that preceptive', preceptive too ?

------
codeonfire
Go do a stint at Amazon and you will understand. Executive management is
insane there. For instance, executives will just lie and say they are in
charge of the X team where X is something popular and upcoming. There will be
for instance, 3 teams each claiming to own a part of the business. Then you
have middle managers lying to executives about what they have accomplished and
will accomplish. Executives are clueless. At the low end you have teammates
all who want to know what you are working on so they can go tell management
they are working on it and you are just helping. If anyone finds out what you
are working on you have literally 1 day to deliver the project before someone
either takes credit for it or gets it shitcanned.

~~~
borplk
Wow that sounds really nasty.

------
tytytytytytytyt
> Is it that the inherent size and complexity of a codebase grows
> exponentially as people grow linearly with time?

That's certainly a large part of it, and probably a large part of why no one
likes maintenance.

You also have more managers, who get where they are in no small part by
avoiding risk, who can derail re-writes in favor of more patching of things,
possibly leading to more long term code problems.

------
simon_000666
This is a systems redundancy problem. We are not the only species to face
this. Ant colonies also build in redundancy into their organizations.
[https://uanews.arizona.edu/story/lazy-ants-make-
themselves-u...](https://uanews.arizona.edu/story/lazy-ants-make-themselves-
useful-unexpected-ways)

