How Big Organizations Work

Everything so far in this book has been mostly about the near world: you, your team, the people you talk to every day. But your team doesn’t float in space. It sits inside something much larger — a department, a division, a company of hundreds or thousands of people, most of whom you will never meet. This part is about that larger thing: the organization. Why it’s shaped the way it is, how it makes decisions, why it moves slowly, and why so much of what happens around you seems to have no owner.

Here’s the promise of this part. Once you can read a large organization — see its structure, its wiring, its incentives — a huge amount of frustrating behaviour stops feeling arbitrary and starts making sense. The reorg that came out of nowhere, the decision that took three months, the two teams that quietly hate each other: none of it is random. It’s the predictable output of how the machine is built. This part teaches you to read the machine.

The core problem: coordinating people you’ll never meet

Start with the thing an organization actually solves. A team of five coordinates almost for free. You can see each other, overhear each other, ask a quick question across the desk, and everyone roughly knows what everyone else is doing. There’s no need for an org chart, a process document, or a chain of approvals — the coordination happens in the air.

Now scale that to a thousand people. You cannot overhear a thousand people. You will never meet most of them. You don’t know who owns what, who to ask, or whether the thing you need is already being built by a team three floors up. The easy, invisible coordination of five people has completely broken down. That breakdown is the problem every large organization exists to solve: how do a thousand strangers work toward one goal without tripping over each other?

This is why a big company behaves nothing like a big team. It isn’t a team that got larger. Somewhere on the way up, the informal coordination that worked for five stopped working, and had to be replaced by something deliberate — structure, rules, roles, reporting lines. Everything in this part is a response to that single problem.

The evidence — coordination doesn’t scale for free

There’s a well-known rule of thumb, sometimes traced to Fred Brooks’s writing on software projects in the 1970s, that the number of possible connections between people grows far faster than the number of people. Five people have ten possible pairings; fifty people have over a thousand. You can’t hold a thousand relationships in your head, so beyond a certain size, coordination must be structured rather than personal. The exact numbers vary, but the direction is not in dispute: communication cost rises sharply with headcount, and structure is how organizations pay it down.

Why structure exists at all

“Structure” sounds bureaucratic and cold, but at its root it’s the answer to three unavoidable questions that a group of strangers can’t answer informally:

• Who decides? When two paths are possible, who has the authority to choose?
• Who does? Whose job is this piece of work, so it doesn’t get dropped or done twice?
• Who talks to whom? How does information get from the people who have it to the people who need it?

A team of five answers these by looking at each other. An organization of a thousand answers them with structure: an org chart (who reports to whom), roles and titles (who does and who decides), and processes (how things reliably get done and communicated). Structure is not the enemy of getting things done — it’s the substitute for the informal coordination you can no longer rely on.

In practice — the same question, two sizes

A five-person cafe needs no policy on who orders the milk; whoever notices it’s low mentions it, and someone buys it. Now picture a hospital with forty wards. “Whoever notices we’re low on a drug buys it” is a recipe for disaster — stockouts, duplicate orders, expired supplies, no accountability. So the hospital builds structure: a procurement role, an ordering process, a reporting line. It feels heavier than the cafe, and it is — but the cafe’s method would kill the hospital. Structure is the price of scale, not a failure of it.

The throughline of this part

Every page ahead is a different response to that one coordination problem. It helps to see them as a single argument rather than a list of topics:

• Structure exists because informal coordination breaks at scale (the problem itself).
• The org chart — functional, divisional, or matrix — is the first big choice about how to group people.
• Hierarchy, span, and layers decide how steep or flat that chart is, and how far decisions travel.
• Centralization vs. decentralization decides where the deciding happens — the top, or the edges.
• Process and bureaucracy are how coordination gets encoded so it doesn’t depend on any one person.
• Goal systems (OKRs and KPIs) are how a thousand people are pointed at the same outcome.
• Politics is what happens in the gaps the structure leaves — and there are always gaps.
• Communication flows along all of the above, which is why structure quietly shapes what gets said.

Read that way, the part isn’t nine unrelated topics. It’s one problem — coordinating strangers toward a goal — examined from nine angles.

No structure is “right”

Before the roadmap, one idea to carry through the whole part: there is no correct organizational design. Every choice buys something and costs something else, always.

Group people by function (all the engineers together, all the marketers together) and you get deep expertise — but slow cross-team delivery. Group them by product or region instead and you get fast, focused delivery — but duplicated effort and inconsistent standards. Push decisions to the top and you get consistency but bottlenecks. Push them to the edges and you get speed but drift. There is no free lunch on this menu. Anyone who tells you their org design is simply “best” is hiding the bill.

So the goal of this part is not to crown a winner. It’s to help you see what each structure trades, so you can understand the one you’re in — and, if you ever design one, choose your trade-offs on purpose.

The common trap — believing the next reorg will fix everything

Because every structure has real costs, those costs are always visible and annoying, and it’s tempting to conclude the structure is broken and needs replacing. Sometimes it does. But often the reorg just swaps one set of costs for another: the functional org that was too slow becomes a divisional org that’s too duplicative, and eighteen months later everyone wants to reorganize back. The mature read isn’t “this structure is wrong,” it’s “this structure is optimized for X at the cost of Y — is X still what we need?” Reorganizing without naming the trade you’re making usually just resets the clock on the same frustration.

The roadmap for this part

Read these in order. Each page answers one question about how large organizations work, and each sets up the next.

#	Page	The question it answers
2	Why Organizations Need Structure	Why can’t a big company just work like a big team?
3	Three Ways to Draw the Org Chart	Functional, divisional, matrix — how do you group people, and what does each cost?
4	Hierarchy, Span of Control, and Layers	How steep or flat should the org be, and how far do decisions have to travel?
5	Who Gets to Decide: Centralization vs. Decentralization	Should decisions happen at the top or at the edges?
6	Why Process and Bureaucracy Exist	Why all the rules, forms, and approvals — and when do they turn toxic?
7	Goal Systems: OKRs and KPIs in Plain Terms	How do you point a thousand people at the same outcome?
8	Organizational Politics, Explained Honestly	What is “politics,” really, and how do you navigate it without becoming a snake?
9	How Structure Shapes Communication	Why does the org chart secretly decide what gets said, and to whom?
—	Part Recap: Reading the Machine	Did it hold together?

Notice the order. We open with the problem (Page 2), because structure only makes sense once you feel the coordination it’s replacing. Then we make the big design choices in sequence: how to group people (Page 3), how steep to stack them (Page 4), and where decisions live (Page 5). Pages 6 and 7 cover the two systems that make coordination reliable — process (how work gets done consistently) and goals (how effort gets aimed). Page 8 is honest about politics, the human behaviour that fills every gap structure leaves. And Page 9 closes the loop: because all of this shapes communication, which is where the rest of the book picks back up.

The thread

If you forget everything else in this part, keep this thread:

A thousand people + one goal  →  informal coordination breaks
        so you build STRUCTURE  (chart, hierarchy, where decisions live)
                and SYSTEMS      (process to do work, goals to aim it)
                        every choice buys speed OR consistency, never both
                                and POLITICS fills whatever the structure missed

That sequence — problem, structure, systems, trade-offs, politics — is the whole of this part in five lines. Once you can name which trade a company has made and where its structure leaves gaps, most of its behaviour stops being mysterious.

This is descriptive, not cynical

One last reassurance, because this part covers hierarchy, bureaucracy, and politics — words that carry a bad smell. The goal here is not to make you cynical about organizations, and it’s not to teach you to “play the game” against your colleagues.

The goal is literacy. An organization is a human machine built to solve a hard problem, and like any machine it has parts, forces, and failure modes. Understanding them honestly — including the ugly bits — is what lets you get real work done inside one, protect your team from the machine’s rough edges, and stay sane when things move slowly for reasons that aren’t anyone’s fault. Reading the machine clearly is the opposite of cynicism: it’s how you keep your idealism and get things done.

How it connects

This part sits between the near world of your team and the wider world of the company. It builds directly on Foundations: the coordination problem that creates the manager’s job is the same one, scaled up, that creates the organization’s structure. And it feeds forward into the rest of the book — especially Communication, since the final page shows how structure decides what gets communicated, and Managing Up, which is largely the skill of working with the machine this part describes.

Try this

This week, draw your own organization’s structure from memory — no peeking at the official chart. Sketch who reports to whom above you, and the teams your work touches sideways. Then, for each box, note in a word what it optimizes for (expertise? speed? consistency?). Where your sketch is fuzzy or wrong is exactly where the coordination is unclear — and that fuzziness is usually where your day-to-day frustration is coming from. Keep the sketch; you’ll refine it as you read the part.

Reflect

1. Think of a recent decision or delay at work that felt arbitrary or frustrating. Can you name a structural reason — how people are grouped, who had to approve it, how far it had to travel — behind it?
2. Is your organization closer to a “big team” that still coordinates informally, or a “true organization” that runs on structure? What size did the shift happen at?
3. Where does your company sit on the speed-vs-consistency trade? Does its structure seem tuned for fast, local delivery or for uniform, controlled output — and does that match what it actually needs?
4. When you hear the words “hierarchy,” “bureaucracy,” and “politics,” what’s your gut reaction? How much of that reaction is about the thing itself versus a bad experience of it?
5. Looking at the roadmap, which question do you least know the answer to right now? That’s probably the page you most need.

Show reflections

1. Almost every “arbitrary” frustration has a structural fingerprint. The useful move is to trace it: a slow decision often means it traveled too far up (hierarchy) or needed too many sign-offs (centralization); duplicated work often means the org is grouped by product with no shared function. Naming the cause is the first step to not taking it personally.
2. Most people can pinpoint a rough size where their org stopped feeling like a team — often somewhere in the tens to low hundreds. The point is to feel that the shift is real and predictable, not a sign that “the company lost its soul.” It lost its ability to coordinate informally, which is a different and fixable-by-structure thing.
3. There’s no right answer, only a fit question. A hospital or an airline should be tuned for consistency and control, even at the cost of speed — mistakes are catastrophic. A young startup should be tuned for speed. Mismatch is the interesting finding: a company that needs speed but is built for control, or vice versa, will feel constantly at war with itself.
4. This surfaces whether you’re reading the part as an analyst or as someone nursing a grievance. Both are fine starting points, but the aim is to separate the mechanism (hierarchy is just a decision-routing structure) from your history with a bad version of it. The mechanism isn’t the enemy; a badly-tuned instance of it might have been.
5. The question whose answer feels least obvious usually hides an assumption you haven’t examined. If “what is politics, really?” or “where should decisions live?” feels genuinely open, read those pages most slowly — they’re where your model of organizations is thinnest.