I sometimes read commentary about large software companies and notice a recurring pattern. People correctly identify real characteristics of large organizations, criticize them, but show little appreciation for why those characteristics exist in the first place.

This is not an abstract topic for me. I have worked at very large firms – Nortel and Google, which neatly bookend my career. I have also worked at companies in the 100-1000 person range, and at startups with fewer than ten people. I have seen the same problems from very different vantage points.

Some of the most common criticisms are familiar. They are not wrong, exactly. But they are often incomplete.

“There are too many meetings”

At very large software companies, programming ability, technical expertise, and raw resources are not the limiting factors. Coordination is.

Coordination is almost free in a ten-person startup. It is still relatively easy in a forty-person company. In a very large organization, coordination becomes one of the hardest problems to solve – second only to deciding what to build in the first place, because there is so much that could be built.

That there are too many meetings at a large company is just another way of saying the company is large. Work that matters spans teams. Interacting with more people is unavoidable. Meetings are not a dysfunction layered on top of scale; they are intrinsic to it.

You can have bad meetings. You can have too many of the wrong kind of meetings. But the existence of many meetings is not, by itself, evidence of organizational failure.

“Executives’ opinions are too dominant”

This criticism often misses a key structural fact: at very large companies, there are many layers between the people building the software and the customers using it.

One of the core jobs of an executive is to act as a proxy for the customer. They decide, imperfectly but necessarily, what the customer wants, what matters now, and what matters later. That is why their opinions carry weight.

If you work in such an organization, the practical choice is simple. You either build what the executives want, or you influence them to want something else. Complaining that their opinions are dominant misunderstands the role they are playing.

And if they get it wrong, that is where accountability should sit. Not with the system itself, but with the people operating it.

“There is too much process and bureaucracy”

This one usually reveals a deeper misunderstanding.

At a very large software company, the software matters. It may be relied on by millions of people. It may underpin businesses, infrastructure, or daily life. It may not be particularly glamorous software but it has to work. It has to keep working. Failure is not charming, and recovery is not always cheap.

At a ten-person startup, the software is often fun to write and sometimes cutting-edge. I’ve done it myself many times. But your software is not important – at least not yet. It may become important, but it is not important now. That difference in importance explains an enormous amount of the difference in process.

Process exists to manage risk, correctness, and scale. Calling it “too much process” without acknowledging the stakes involved is like criticizing a bridge for having too many safety checks because you once built a treehouse with a hammer and some nails.

Understanding before criticizing

Large software companies have real problems. Some are structural. Some are cultural. Many are self-inflicted. But many of the behaviors people complain about are not pathologies – they are consequences.

If you want to criticize how large organizations operate, it helps to first understand why they operate that way. Without that understanding, the criticism may feel sharp, but it will not be useful.