How to build an org chart.

An org chart answers three questions that come up constantly: who does what, who reports to whom, and where the gaps are. New joiners use it to decode the company. Managers use it to plan hiring and cover. Leadership uses it to see whether the shape of the organisation still matches the work it is trying to do. When the chart is trusted, all three groups answer their own questions in seconds. When it is not, every one of those questions becomes a conversation, and the conversations add up.

It is worth being honest about what a chart is not. It is not a map of influence, friendship or how work really flows, and it never will be. It is the formal skeleton: roles, reporting lines and teams. That narrower job is still valuable, because the skeleton is what payroll, access, approvals and headcount planning all hang from. A chart that tries to capture everything ends up capturing nothing reliably.

Most org charts die the same way. Someone builds a careful diagram in a slide or a drawing tool, presents it, and moves on. From that moment the chart and the organisation begin to drift apart: a resignation here, a new hire there, a quiet restructure of one team. Nobody owns updating the file, because updating it is nobody’s job. Within a quarter the chart is wrong in small ways, within two it is wrong in ways that matter, and people quietly stop consulting it.

The root cause is not laziness, it is architecture. A drawn chart is a second copy of information that already exists somewhere else: the employee records. Any system that keeps two copies of the same facts guarantees they will disagree, and the copy that gets corrected is always the one used to pay people, not the one used to present. The fix is not more discipline. It is removing the second copy.

The reliable way to build an org chart is to not draw it at all. Hold one record per person with their role, team and manager, and generate the chart from those records. Then a hire, an exit or a reporting change updates the picture the moment it is recorded, because the picture is the records. This is the single biggest decision in the whole exercise, and it costs nothing extra: the data must exist anyway for payroll and administration to function.

If you are starting from scratch, the sequence is short. List every person with three facts: role title, team, and the name of the one manager they report to. Resolve the arguments this surfaces, and there will be arguments, because dotted lines and shared reports hide in every company. Then load the list into whatever will hold the records going forward. The chart you generate on day one will be imperfect and honest, which beats polished and fictional.

Two numbers describe most of what matters about a structure. Span of control is how many people report directly to one manager. Layers is how many reporting steps sit between the top and the front line. Neither has a universally correct value, but the extremes are informative in both directions. A manager with twelve direct reports cannot give meaningful attention to each one. A manager with a single report is a layer of delay wearing a title. And every layer added moves decisions further from the information they depend on.

Use the numbers as prompts, not verdicts. A wide span over experienced, self-directed people can be perfectly healthy; the same span over new hires in a complex role is neglect by structure. A deep hierarchy in a regulated operation may be deliberate; the same depth in a fifty-person company is usually an accident of promotions. The chart’s job is to make these shapes visible so that someone can ask whether they were chosen or inherited.

A living chart is one that reflects reality without anyone maintaining it, and it changes what the chart can do. Presence and leave can appear on the cards, so cover questions answer themselves. Open roles can sit in the structure they will join, so hiring is planned in context. Structural risks, the overloaded manager, the team one exit from empty, can be spotted while they are still cheap to fix. None of this is possible with a diagram, because a diagram only knows what was typed into it.

A static chart is not worthless. For a pitch deck or a one-off review, a snapshot is fine. The mistake is using a snapshot as an operating tool: making cover, hiring and restructure decisions on a picture with an unknown error rate. A useful rule of thumb: if a chart is going to be consulted more than once a month, it needs to be generated from records, not maintained by hand.

Organisations argue about the past constantly. When did that team move? Who was managing them during that quarter? How big were we when we opened the second office? A drawn chart has no memory: each edit destroys the version before it. Keeping history means keeping dated records of every structural change, so that any past date can be replayed. That sounds like a luxury until the first dispute, audit or post-mortem, at which point it is the difference between evidence and recollection.

History also makes growth legible. Comparing the structure at two dates shows where layers crept in, which teams swelled and which quietly hollowed out. Those patterns are invisible day to day and obvious in replay. If you are choosing tooling, treat time travel as a first-class requirement rather than a novelty, because it cannot be retrofitted: history only exists if it was being recorded all along.