Type an indented list on the left, get a downloadable org chart on the right
| Structure | Organized By | Works Best At | Watch Out For |
|---|---|---|---|
| Functional | Discipline (eng, marketing, finance) | Startups to ~200 people | Silos; cross-team projects drift |
| Divisional | Product line, region, or customer | Multi-market companies | Duplicated functions, higher cost |
| Matrix | Function + project simultaneously | Agencies, consultancies, large tech | Two bosses; needs clear arbitration |
| Flat | Barely any layers | Small teams under ~30 | Founds its ceiling fast; founder bottleneck |
| Manager's Reports Are⦠| Healthy Span | Why |
|---|---|---|
| Also managers | 4β7 | Coaching other managers is deep, frequent work |
| Individual contributors, varied work | 5β8 | Each report needs real 1:1 and review time |
| Individual contributors, similar work | 8β15 | Standardized work needs less per-person attention |
| Trainees or seasonal staff | 15β30 | Supervision replaces mentorship |
These are the ranges that recur across management research and practice, not laws. A span outside them isn't automatically wrong, but it deserves a reason.
The left pane is a plain indented list; the right is a rendered chart. Each line is a box, each indent level is a reporting layer, and the dash, pipe, or comma splits name from title. The layout engine gives every leaf its own horizontal slot, centers each manager over their direct reports, and draws elbow connectors between them. The output is SVG, so the download stays crisp at any size, from a slide to a poster.
Write the top of the organization first, then work down level by level, one indent (two spaces) per level. Keep names and titles short; boxes wrap at about twenty characters. Skip empty seats and note planned hires as "Open β Data Engineer" so the chart doubles as a headcount plan. If a team list gets long, split deep departments into their own charts; a readable chart of one division beats an unreadable chart of the whole company.
The sample list describes a 12-person company with a CEO, three VPs, and two levels below engineering. Parsed, it renders four tiers: the CEO box centered at the top, three VP boxes below, and their reports fanned out underneath. Count the spans as you read it: the VP of Engineering carries five total reports across two layers, which sits inside the healthy range for a manager of managers.
One person per line. Indent two spaces (or a tab) per level down the hierarchy, and separate the name from the title with a dash, pipe, or comma: "Priya Nair β VP Engineering". The first line becomes the top box, and each deeper indent becomes its direct report. Lines starting with # are ignored so you can leave yourself notes.
Functional (teams organized by discipline: engineering, marketing, finance), divisional (by product, region, or customer), matrix (people report to both a function and a project), and flat (few or no layers between leadership and staff). Most small companies start functional; divisional and matrix structures usually appear past a few hundred people.
Research and practice converge on roughly 5 to 8 direct reports for managers whose reports also manage others, and up to 10 to 15 for leads of individual contributors doing similar work. Below about 4, layers multiply and decisions slow; above about 10 for real management work, coaching quality drops.
Text-based org charts like this one draw solid reporting lines only, which covers the structure most companies want to publish. For matrix relationships, add the second role in the title ("Analyst (also: Growth squad)") or maintain a separate project chart. Dedicated diagramming tools can draw the dashed lines if you need them visually.
Three practical reasons: new hires orient faster when they can see who does what, approval paths become explicit instead of tribal knowledge, and planning headcount forces you to see where managers are over- or under-loaded. A chart you can regenerate in a minute stays accurate; a diagram in a design tool goes stale in a quarter.