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.

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.

That's at a well-managed company - with mediocre or poor management it can be more like log(log(# of people)), or "O(1)" (total output remains constant no matter how many people join), or total output can even decrease as the organization grows.

But if there's no continous stream of newcomers, or rather sufficient gaps between hiring, then more man-hours does (eventually) produce more output.

As the depth of communication increases, the message itself often gets lost, as in the venerable 'grapevine joke' where a simple message becomes garbled after passing through multiple re-transmissions.

This problem is central to businesses as they grow and must partition the growing workload into bite-sized pieces managed by ever more players. As the whole grows in size and complexity, each bite's purpose and design becomes ever more inexplicable to its owner making it more likely to fail somehow or require costly adjustments to fit into the final product/service.

1) self-motivation

2) people working towards proposals & being able to fork when unhappy.

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

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.

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.

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.

Continuity matters much more than output-per-input-hour at large companies.

Here's one way to look at it: big companies are large because they have big revenue streams to protect. Startups don't. So the risk/reward calculations look completely different. There's lots of "overhead" in a big company that can fairly be characterized as "systems that have evolved to protect the existing lines of business." For example, the political infighting at a Fortune 500 company over allocating $1M to new a new product R&D project (as opposed to marketing, or maintenance of existing products, or internal IT spend) is shocking to a startup founder in Silicon Valley who is able to raise a $1M seed round to try out a "good idea" relatively quickly, these days. Why are VCs with $25M funds so much more willing to underwrite product development than Fortune 500 executives with billion-dollar P&Ls? Because the VC's downside is limited to $25M.

Here's another way to look at it: you could define "efficiency" as "how often does a company of a given size" go out of business. By that measure, big companies are massively more efficient than small companies. Even factoring in the depredations of private equity investors. :-)

(This written by one of the above-mentioned startup founders who has struggled to get funding for new products from big company executives.)

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.

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.

- 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"

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

If it's efficient, it's not Research. The cost of the unknown has an unknown cost.

If anything, for a sufficiently large company, buying small companies is a fairly efficient way to do R&D. Unsuccessful products die at someone else's expense and you can buy the winners at a tolerable markup.

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

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.

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.

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

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

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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]

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.

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

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

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.

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.

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

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.

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

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.

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

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.

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

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.

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.

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

Distribution of responsibility/culpability

Culture of deniability

Systemic defense of the status quo

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/

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.

https://corbt.com/posts/2017/10/28/small-companies-and-the-p...

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.

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.