Online Tool Store
· 5 min read
How to Map Relationships Between People or Systems
Heshan Fernando
Co-founder & COO
Halfway through a project handover you realise nobody can explain who actually depends on whom. There’s an org chart, but it describes reporting lines, not the six informal relationships that keep the work moving — and one of those runs entirely through a contractor whose last day is Friday.
The same problem shows up in different clothes: a service map where two subsystems only touch through one queue, a novel where two plots are joined by a single character, a stakeholder list where one person is the only route to the client.
What a relation chart is for
A relation chart is a graph: entities as nodes, relationships as edges. That sounds abstract until you notice the three things it makes visible, all of which are hard to see in a list.
Clusters — groups that talk to each other far more than they talk to anyone else. These are usually real teams, real subsystems, or real subplots, whether or not the formal structure agrees.
Bridges — the single connections holding two clusters together. In an organisation that’s a bottleneck and a bus factor. In a system it’s a single point of failure. In a story it’s the character you can’t cut.
Orphans — entities with no connections at all. Sometimes that’s a genuine finding. More often it means someone was left off the map, which is its own finding.
Why people get stuck here
- Drawing before listing. Dragging boxes on a canvas encourages arranging what you already believe instead of recording what’s actually there.
- Too many nodes. Past about fifty entities every layout algorithm produces a hairball, and a hairball communicates nothing.
- Mixing relationship types. “Reports to”, “shares data with” and “sometimes helps out” on the same chart with the same arrows tells you nothing about any of them.
- Treating the chart as the deliverable. The output isn’t the picture; it’s the two or three things the picture reveals.
What a good relation chart looks like
It comes from text, not dragging
Writing Maya -> Devan (reports to) one line at a time is faster than positioning boxes, it diffs cleanly in version control, and it’s much easier to correct when someone says “that’s not right”.
The layout matches the question
Hierarchical layouts suit genuine trees — reporting lines, dependency chains. Force-directed layouts suit messy real-world networks, because they let clusters emerge from the data rather than imposing a shape. Circular layouts are good for showing that everything touches everything.
It’s labelled by relationship type
If you’re mapping more than one kind of connection, label the edges and consider separate charts. One chart per relationship type is nearly always clearer than one chart with a legend of five arrow styles.
| What You See | What It Usually Means | What To Do |
|---|---|---|
| A single bridge node | Bottleneck or bus factor | Add a second path before it leaves |
| Two dense clusters | Teams or subsystems that barely talk | Check whether that’s intentional |
| An isolated node | Missing data, or genuinely unused | Verify before deleting anything |
Common mistakes to avoid
- Building a fifty-node chart when the interesting part is a twelve-node subset.
- Using arrow direction inconsistently, so “A -> B” means “A manages B” in one line and “A depends on B” in another.
- Presenting the chart without saying what it shows — an unexplained network diagram reads as decoration.
- Forgetting to record when the map was made. Relationships change, and an undated chart gets trusted long after it’s wrong.
- Using a relation chart for a genuine hierarchy, where a plain tree diagram is clearer.
How to do it with Relation Chart Generator
The Relation Chart Generator takes plain text lines and draws the graph in your browser.
- Write one relationship per line: source, arrow, target, with an optional label in brackets.
- Pick a layout — hierarchical for reporting structures, force-directed for anything organic.
- Generate the chart and look first at the bridges and the orphans, not the middle.
- Trim the chart to the subset that answers your question, then present that.
For other planning views — org charts, timelines, comparison tables — see the tools directory; they all run locally with no account.
Frequently asked questions
How many entities can a chart handle before it’s unreadable?
Around fifty is the practical ceiling for a single view. Beyond that, split by cluster or by relationship type. A chart that requires zooming to read has already stopped being a communication tool.
Can I use this for a family tree?
You can, but a dedicated genealogy tool handles generations, marriages and dates far better. Relation charts are stronger for networks that aren’t trees — where connections loop back and cross between branches.
Is graph analysis worth learning for this?
For most working uses, no. The concepts worth knowing are clusters, bridges and degree — how many connections a node has. Graph theory goes considerably deeper, but those three cover the questions people actually ask of a chart.
Final thought
Draw the chart to find the bridge. If it doesn’t change what you do next — who you talk to, what you document, what you make redundant — you’ve made a picture rather than a decision.