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 featur

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.