How to Make an Org Chart People Actually Understand

A founder I know sketched her startup's org chart on a whiteboard before a board meeting. Fifteen people, eight boxes, and a tangle of lines so dense that someone asked, "Wait, who does the new designer actually report to?" Nobody could answer from the chart. That's the failure mode of most org charts: they show that structure exists without making the structure legible.

An org chart isn't decoration for the company wiki. It answers three questions fast — who reports to whom, who owns what, and where the gaps are. When it can't answer those at a glance, it's just boxes. Here's how to make one people actually understand.

What an org chart is for (and what it isn't)

An org chart maps reporting relationships — the lines of accountability between people. That's a different job than a mind map, which radiates ideas outward with no hierarchy, or a flowchart, which traces a process through time. An org chart is strictly top-down: authority flows from the top box, and every line below it means "this person is accountable to the one above."

Keep that distinction tight, because the most common mistake is smuggling other meanings into the lines. A line in an org chart is not "works with," "talks to," or "sits near." It's "reports to." The moment you let it mean anything else, the chart stops being trustworthy and people stop reading it.

Start at the top and work down in layers

Build it in tiers, not all at once.

Tier 1 — the top. One box. Usually the CEO or founder. If you have co-founders sharing the top, put them side by side at the same level — but be honest about whether decisions actually split, because two top boxes with no clear division of authority is the first sign of a chart that's lying to you.

Tier 2 — direct reports. The handful of people who report straight to the top: your function heads. Engineering, Sales, Operations, Finance. This row is the backbone of the whole chart. Get it right and everything below slots in cleanly.

Tier 3 and down — the teams. Under each function head, place the people who report to them. Keep going until everyone's on the chart.

Working in tiers forces a useful question at every level: does this person have exactly one manager? In a clean hierarchy they should. If you find someone with two solid lines coming into them, you've either found a real problem (unclear accountability) or a relationship that isn't a reporting line at all.

A worked example: a 15-person startup

Let's build one. Say the company is a 15-person SaaS startup:

• Maya — CEO (top box)
• Reporting to Maya: Dev (Head of Engineering), Priya (Head of Sales), Tom (Head of Operations)
• Under Dev: three engineers and one QA
• Under Priya: two account executives and one SDR
• Under Tom: one finance lead, one support rep, and a product designer

That's the clean version — a tree three levels deep, every person with one manager. Drawn top-down with a single box at the top, three function heads on the second row, and their teams fanning out below, anyone can trace any person to Maya in two hops.

Now the real world intrudes. The product designer sits under Tom in Operations for HR purposes, but does most of her actual work with Dev's engineering team. This is where charts get messy — and where you make a deliberate choice instead of drawing a second solid line.

Handle dotted lines and matrix reports deliberately

The designer above is a dotted-line report: a formal manager (Tom) plus a working relationship to someone else (Dev). The convention is exactly what it sounds like — draw the reporting line to Tom as a solid line, and the working relationship to Dev as a dashed line. The solid line is who does her review and approves her vacation; the dashed line is who she collaborates with day to day.

Use dotted lines sparingly. One or two on a chart clarify; a dozen of them turn the diagram back into the whiteboard tangle. If half your chart needs dotted lines, the problem isn't the chart — it's that your reporting structure is genuinely ambiguous, and the chart is doing its job by exposing that.

A couple more real-world cases worth a deliberate decision:

• The founder wearing three hats. Early on, Maya might be CEO and acting Head of Marketing and the person the office manager reports to. Don't draw Maya as three boxes. Draw her once, and let the extra reports hang off her box directly — the visual crowding is accurate. It should look like she's overloaded, because she is.
• One manager, nine direct reports. If a single box has nine lines fanning out of it, that's a flat team — common in support or sales. It's fine, but the wide fan is a signal: that manager's span of control is large, and the chart is telling you a team lead might be coming.

The mistakes that make org charts unreadable

A few specific things kill legibility:

1. Mixing roles and people inconsistently. Pick one. Either every box is a person ("Priya — Head of Sales") or every box is a role ("Head of Sales," to be filled). Don't mix named people with empty role boxes unless you're deliberately showing open positions — and if you are, style the open ones differently (a lighter fill, a dashed border) so they read as "vacant," not "mystery person."
2. Crossing lines. When reporting lines cross each other, the eye can't follow them. Reorder the boxes within a tier so lines run straight down. You can almost always uncross them by swapping sibling positions.
3. Too many colors. Color should mean something — one color per department, say. Fifteen boxes in fifteen shades is noise. If color isn't encoding information, make everything one color.
4. Cramming the whole company on one page. Past about 30 people, a single chart gets unreadable. Show the top three tiers, then break each department into its own sub-chart. A reader who wants the whole picture follows the trail; a reader who wants the shape gets it immediately.

Let AI draw the boxes so you can fix the structure

Here's the part that actually saves time. The tedious work in an org chart isn't thinking about who reports to whom — you already know that. It's the box-dragging, line-routing, and re-aligning every time someone joins or moves teams.

So don't drag boxes. Describe the hierarchy in plain text and let Ridvay lay it out. Type something like "Org chart: Maya (CEO); reporting to Maya — Dev (Head of Engineering), Priya (Head of Sales), Tom (Head of Operations); under Dev: three engineers and a QA; under Priya: two AEs and an SDR; under Tom: finance lead, support rep, product designer (dotted line to Dev)" and you get a clean top-down tree with the tiers and lines already routed. Then you do the part that needs judgment: spot the founder wearing three hats, decide whether that wide fan needs a team lead, mark the open roles.

The diagram is the easy part. Reading the structure honestly is the point. Get a draft on the screen in seconds, then spend your time on what it reveals.

Describe your team and watch it lay itself out: make an org chart in Ridvay.