Three Ways to Draw the Org Chart

The previous page argued that once a group gets too big to coordinate by memory and hallway conversation, it needs structure — a deliberate answer to who does what, who decides, and who talks to whom. But “you need structure” is not a plan. It leaves the real question open: how, exactly, do you group people together?

It turns out there are only a few basic answers. Almost every org chart you will ever see is a variation on three shapes: functional, divisional, and matrix. This page teaches all three from first principles — the logic that makes each one sensible, the payoff it delivers, and the specific way each one tends to break. Once you can see these three shapes, most confusing org charts stop being confusing. You are just looking at one of three answers, or a blend of them.

The one question underneath all org charts

Every org chart is answering a single question: when we split hundreds of people into teams, what do we group by?

You could group people by the skill they share. You could group them by the thing they produce. You could try to group them by both at once. That’s it — those are the three shapes. Each grouping optimizes for one thing and pays for it somewhere else. There is no free structure; every choice trades away something. The skill isn’t finding the “right” one — it’s knowing what each one buys and what it costs, so you can pick the trade that fits your situation.

The functional structure: group by expertise

The most natural first move is to put people who do the same kind of work together. All the engineers in one group, all the salespeople in another, all the finance people in a third. Each group is a function — a department organized around a shared skill.

                    CEO
        ┌────────────┼────────────┬────────────┐
   Engineering     Sales       Finance     Marketing
   ┌──┴──┐        ┌──┴──┐      ┌──┴──┐       ┌──┴──┐
  eng   eng     rep   rep    acct  acct    mkt   mkt

Think of a hospital organized this way: all the nurses report up through nursing, all the surgeons through surgery, all the pharmacists through pharmacy. Or a small company where everyone who writes code sits under one head of engineering and everyone who sells sits under one head of sales.

The strength is depth of skill. When all the specialists of one kind sit together, they learn from each other, hold consistent standards, and get very good at their craft. A junior engineer surrounded by senior engineers grows fast. Expertise concentrates, and there’s no duplication — you have exactly one finance team, one recruiting team, one set of standards. For a company doing essentially one thing, this is efficient and clean.

The weakness is silos and slow cross-team delivery. Here’s the catch: almost nothing valuable gets made by one function alone. Shipping a product needs engineering and design and marketing and sales and support. But in a functional structure, each of those lives in a different department, reporting to a different boss, with different priorities. To get one thing done, the work has to travel across several kingdoms — and each kingdom optimizes for itself, not for the shared outcome. Handoffs pile up. Nobody owns the end-to-end result; each function owns only its slice. That’s what people mean by a silo: a group so focused inward that it stops coordinating outward.

The common trap — every function is doing its job, and the customer still waits

The maddening thing about silos is that everyone can be working hard and performing well by their own department’s measures while the actual outcome crawls. Engineering hits its targets, marketing hits its targets, support hits its targets — and the customer’s problem still takes six weeks to cross all three. When delivery is slow in a functional org, resist the urge to blame a lazy team. Usually every team is fine; it’s the handoffs between them that are broken. The fix is rarely “work harder” — it’s giving someone clear ownership of the whole path.

The divisional structure: group by output

As a company grows and does more than one thing, the functional shape strains. So the second answer flips the logic: instead of grouping by skill, group by what you produce or serve — a product, a region, or a customer type. Each group becomes a division, and — this is the key move — each division contains its own functions.

                         CEO
        ┌─────────────────┼─────────────────┐
   Consumer Division  Business Division  Government Division
   ┌────┼────┐        ┌────┼────┐         ┌────┼────┐
  eng  sales fin    eng  sales fin      eng  sales fin

Picture a company with a consumer product, a business product, and a government contract. Rather than one shared engineering team serving all three, each division has its own engineers, its own salespeople, its own budget. A hospital group might do the same by site: each hospital runs its own staff and its own operations rather than pooling everyone centrally. You can also divide by region (North America, Europe, Asia) or by customer segment (enterprise, small business).

The strength is end-to-end ownership. A division has everything it needs to serve its market under one roof and one leader. It can move fast, make its own trade-offs, and — crucially — one person is accountable for the whole result. When the consumer product succeeds or fails, you know exactly whose result that is. Priorities are clear because the whole division points at one market.

The weakness is duplication and re-invented wheels. The cost is right there in the diagram: you now have three engineering teams, three finance teams, three of everything. That’s more expensive, and worse, the divisions drift apart. Each solves the same problem in its own way and none of them shares. The consumer division builds a billing system; six months later the business division builds a nearly identical one, not knowing the first existed. Expertise fragments — your engineers no longer all learn from each other, because they’re scattered across walled-off divisions. What functional structure was good at (deep, shared, non-duplicated skill), divisional structure gives up.

In practice — the two teams that built the same thing

A mid-sized retailer split into an in-store division and an online division, each with its own small tech team so each could move fast for its own channel. It worked — until someone noticed both teams had spent months separately building tools to manage the same product catalog, with different data that now disagreed with each other. Neither team did anything wrong; the structure simply gave them no reason, and no easy way, to know about each other’s work. This is the divisional tax in miniature: speed and ownership up front, quietly paid for in duplicated effort and drift.

The matrix structure: group by both at once

Look at the two shapes above and you’ll feel the tension. Functional gives you deep skill but slow delivery. Divisional gives you fast delivery but duplicated, fragmented skill. What if you want both — the shared expertise of functions and the end-to-end focus of divisions?

That wish is where the matrix comes from. In a matrix, people report along two axes at once. You still belong to your function (you’re an engineer, in the engineering department, with an engineering manager who owns your craft and career). And you’re assigned to a product, project, or region led by someone who owns that outcome. You have, in effect, two bosses.

                  Functional managers (own the craft)
                Eng lead   Design lead   Marketing lead
                   │            │              │
Product A  ────  eng ────── designer ────── marketer     ← Product A lead
                   │            │              │            (owns the outcome)
Product B  ────  eng ────── designer ────── marketer     ← Product B lead
                   │            │              │
     ↑ each person sits at an intersection: one functional boss, one product boss

Read the grid one way (down a column) and it’s functional: all engineers share a craft lead. Read it the other way (across a row) and it’s divisional: everyone serving Product A answers to Product A’s lead for what to build and when. Each person lives at an intersection.

Why it exists: the matrix is a deliberate attempt to get shared expertise and focused ownership, especially when the same specialists must be shared across several products or projects. It’s common in consulting firms (you belong to a practice area, but you’re staffed onto client projects), in engineering-heavy companies, and anywhere expensive specialists can’t be dedicated to just one product.

The weakness is the two-boss tension. Here is the failure mode, and it’s a real one: when you have two bosses, they can pull you in two directions. Your functional manager wants you to uphold the craft standard; your product lead wants it shipped by Friday. When those conflict — and they will — where does the tie break? Who decides your priorities this week? Who writes your review? A matrix that hasn’t answered those questions clearly leaves people stuck between two authorities, attending twice as many meetings, and quietly paralyzed. The matrix trades the clean single chain of command for divided loyalty, and that trade only pays off if the two axes are disciplined about who owns what.

The evidence — the matrix demands more, not less

Management researchers have studied matrix structures for decades, and the recurring finding is qualitative but consistent: matrices can genuinely deliver the “best of both” — but only when roles, decision rights, and conflict-resolution paths are spelled out unusually clearly. Left vague, they tend to multiply coordination cost rather than reduce it, because every ambiguous decision now has two people who might own it. The lesson most practitioners draw is that a matrix is a high-skill structure: it works when the organization is mature enough to name, explicitly, which boss wins on which kind of decision.

A plain heuristic: which shape fits which situation

You don’t need theory to choose. Match the structure to the shape of your work:

If your situation looks like...          ...lean toward
─────────────────────────────────────    ─────────────────
One core thing; deep, stable expertise    Functional
matters more than speed across teams

Several distinct products/regions/         Divisional
customers, each needing to move on its
own and own its result end-to-end

Expensive specialists that must be         Matrix
shared across several products/projects
at the same time

In one line: functional when expertise is the scarce thing and the work is essentially one kind; divisional when you have genuinely separate lines of business that each deserve their own end-to-end focus; matrix when you must share scarce specialists across several efforts and can afford the coordination discipline it demands.

Real companies are hybrids — and structures shift

Now the honest part: almost no real company is purely one of these. They’re blends. A company might be divisional at the top (a consumer division and a business division) but functional inside each division (an engineering department, a sales department). It might keep a few functions shared and central — one legal team, one finance team serving all divisions, to avoid the worst duplication — while everything else is divided. The three shapes are not a menu you pick from once; they’re building blocks you combine.

And the right blend changes as the company grows or its strategy shifts. A ten-person startup is functional by default — it does one thing, and everyone’s a specialist in the one shared effort. As it grows to serve several markets, it often splits into divisions so each can move independently. When it later needs to share scarce experts across those divisions, a matrix appears. None of these is a mistake to be corrected; each fit the company at its size and strategy, and each stopped fitting when the company changed. Structure follows strategy, and strategy follows growth. A reorganization usually isn’t failure — it’s the company noticing its old shape no longer matches what it’s trying to do.

Case study — the endless reorganizations of large firms

Large, long-lived companies famously reorganize every few years — swinging from divisional autonomy toward functional consolidation and back again. From the outside this looks like indecision. From the inside it’s usually a pendulum between the same two costs this page named: give divisions autonomy and you get speed but duplication; pull functions back to the center and you get efficiency but silos and slowness. There is no permanent winner, because the trade-off never disappears — it only shifts as the company’s strategy and size change. The practical lesson: don’t expect a “correct” structure to end the reorganizations. Expect instead to keep choosing which cost you’d rather pay right now.

How it connects

These three shapes decide how work is grouped, but two other choices sit right on top of them. How many layers of management the chart has, and how many people each manager oversees, is covered in Hierarchy, Span of Control, and Layers. And once you’ve grouped people, you still have to decide who gets to make which decisions — the subject of Centralization vs. Decentralization. Notice too that structure quietly shapes who talks to whom: silos and two-boss tensions are communication problems as much as reporting ones, which is exactly the thread picked up in How Structure Shapes Communication.

Try this

Draw your own organization’s chart from memory this week — just boxes and lines, no titles needed beyond the grouping. Then ask one question of it: what did we group by? If you grouped mostly by skill, you’re functional; by product, region, or customer, you’re divisional; if you find people reporting along two lines at once, you’re (at least partly) a matrix. Now name the cost you’re paying: slow handoffs (functional), duplicated effort (divisional), or two-boss confusion (matrix). Seeing which cost you’ve bought is the first step to deciding whether it’s the right one.

Reflect

1. What does your organization group people by — shared skill, the thing produced, or both at once? Which of the three shapes is that?
2. Which of the three failure modes do you actually feel day to day: slow cross-team handoffs, the same work being done twice, or being pulled between two bosses?
3. Think of a time something took far too long to get done. Was the real cause a slow team, or the handoffs between teams? What does that tell you about your structure?
4. If your company has reorganized recently, which trade-off was it chasing — more autonomy and speed, or more efficiency and consistency? What did it give up to get it?
5. If you had to redraw one part of your org to fix its worst problem, what would you group differently, and what new cost would you be accepting in exchange?

Show reflections

1. Most people find their org is a blend, and that’s the honest answer. The useful move is naming the dominant grouping at the level you work in — that tells you which payoff you’re getting and which cost you’re likely paying.
2. Whichever failure mode you feel most strongly is a strong clue to your real structure. Slow handoffs point to functional silos; repeated work points to divisional duplication; being torn between two managers points to a matrix that hasn’t settled who decides what.
3. This is the key insight of the functional trap: delays are usually about the seams between teams, not the teams themselves. If the cause was a handoff, no amount of pushing one team harder would have helped — the structure, not the effort, was the constraint.
4. Every reorg is chasing one side of the trade-off and paying on the other. A good answer names both: what the new shape buys (say, faster independent product teams) and what it quietly costs (say, three teams now duplicating platform work).
5. The point is to feel that there is no free fix — redrawing to solve one problem always buys a new cost. A strong answer picks the change and names the trade honestly, which is exactly how real structural decisions get made.