Org Chart: What It Is, How to Structure It, and How to Build One

An org chart is read for one reason: someone needs to know who to talk to. Every design decision follows from that. The chart that wins is not the complete one — it is the one a new joiner can use in ten seconds without asking a follow-up question.

Live interactive diagramUse the player controls to follow the steps

How a People team is organisedPlaying silently in this guideWatch with narrationOpen in editor

What an org chart actually is

A hierarchy: nodes are roles, edges are reporting lines. One root, one parent per node. That constraint is the whole notation, and breaking it is what turns a chart into a diagram nobody trusts.

The form dates to 1855, when Daniel McCallum drew the New York and Erie Railroad's organisation to work out who could authorise what on a line too long to manage by conversation. That is still the question it answers.

An org chart is a map of authority, not of importance. The moment it starts encoding status it stops being useful and starts being political.

The parts

• Node — a role. Put the role first and the person second: roles outlive people, and a chart keyed on names is stale the week someone moves.
• Solid line — the reporting relationship. Exactly one per node.
• Dotted line — a secondary or matrix relationship. This is notation, not styling: Diagramium protects a dotted connector from document-wide arrow settings for exactly that reason, so setting the whole chart to “dashed” cannot silently erase the distinction.
• Vacancy — an open role, drawn and labelled. Leaving it out hides the gap that explains the team's load.
• Grouping — a container or colour per function, when the chart is wide enough that scanning becomes work.

Why draw one at all

• It answers “who do I ask?” without a conversation. That is most of the value, and it accrues every week to every new person.
• It exposes span-of-control problems. A manager with eleven directs and a manager with one are both visible in a second, and neither is visible in a spreadsheet.
• It makes reorganisations discussable. Moving a box is a concrete proposal; describing a reorg in prose is an argument about what the words meant.

When to reach for one — and when not to

• You are describing a process, not a structure → a flowchart or swimlane.
• You need who decides rather than who reports → a RASCI swimlane. See the RASCI matrix.
• The structure is a system, not people → an architecture diagram.
• Every node can have several parents → you do not have a hierarchy; use a concept map and stop forcing it.
• You are showing a decomposition of a thing — assemblies, page trees → an org chart still works, and so does a sitemap.

Who actually draws these

• HR and People teams — onboarding packs, headcount planning, reorganisation proposals.
• Founders and executives — board packs and the “who owns this?” conversation.
• Programme managers — escalation paths, which is an org chart read upward.
• Anyone joining a company — the single most-requested artefact in a first week.
• Teachers and civics — governance, institutions and how a place is run.

Examples you can open and edit

Real structures from HR, healthcare, governance and manufacturing, plus a few simple ones for teaching. Open any of them and rename the roles.

Building one in Diagramium

1. Start from the root and work down one level at a time. Diagramium auto-arranges as you add, so you are naming roles rather than positioning boxes.
2. Put the role on the first line, the person on the second. The chart then survives people changing jobs.
3. Draw vacancies. An unfilled role is information; hiding it makes the team look better resourced than it is.
4. Use dotted lines sparingly — for genuine matrix reporting only. Three dotted lines per chart is usually the honest maximum.
5. Put context in step notes: scope, headcount, the date the structure took effect. A chart with no date gets treated as current forever.
6. Press Present. Revealing a structure a level at a time is a far better introduction than dropping a full chart on a slide.
7. Export as PNG for the handbook, or SVG so it stays sharp when someone prints it at A3.

Design decisions that separate a good one from a mess

• Roles first, names second. Always.
• Date it. Structures change quarterly; charts do not date themselves.
• Break at about five levels. Deeper than that, give a department its own chart and link to it.
• Colour by function, not by seniority. Seniority is already encoded by depth; colouring it too shouts.
• Keep box sizes equal. A bigger box reads as a more important person, whatever you meant by it.

Common mistakes

• Names without roles. Useless to the newcomer it was drawn for.
• Undated charts. The commonest defect, and the reason people stop trusting them.
• Dotted lines everywhere. If everyone matrix-reports to everyone, the chart says nothing.
• Hiding vacancies to look fully staffed. The gap is the point.
• Making the CEO's box bigger. Every reader notices, and it undermines the rest of the chart.

The checklist

Run this before you share it.

1. Every node names a role; people are secondary.
2. Exactly one solid reporting line per node.
3. Dotted lines are rare and mean matrix reporting specifically.
4. Open vacancies appear.
5. The chart carries an effective date.
6. Five levels or fewer, or split by department.
7. Box sizes are uniform.
8. A new joiner could use it unaided.