Introduction

An organizational structure can be modeled as a graph where people or teams are nodes and reporting relationships are edges. In the simplest case the graph is a tree, but real organizations often include dotted-line reporting, project leads, or matrix structures that make the shape more general than a basic org chart.

Start with the Data Model

Before drawing anything, decide what one node and one edge mean. A common model is:

• one node per employee or role
• one directed edge from manager to direct report

That gives you a hierarchy you can traverse, validate, and render.

In Python, a small in-memory representation can look like this:

1employees = [
2    {"id": 1, "name": "CEO", "manager_id": None},
3    {"id": 2, "name": "CTO", "manager_id": 1},
4    {"id": 3, "name": "CFO", "manager_id": 1},
5    {"id": 4, "name": "Engineering Manager", "manager_id": 2},
6    {"id": 5, "name": "Developer", "manager_id": 4},
7]

If your data comes from a database, the same fields usually exist already: an identifier, a display label, and some form of parent or manager reference.

Build the Graph with NetworkX

networkx is a convenient Python library for constructing and inspecting graphs. A directed organizational graph is usually modeled with DiGraph.

1import networkx as nx
2
3employees = [
4    {"id": 1, "name": "CEO", "manager_id": None},
5    {"id": 2, "name": "CTO", "manager_id": 1},
6    {"id": 3, "name": "CFO", "manager_id": 1},
7    {"id": 4, "name": "Engineering Manager", "manager_id": 2},
8    {"id": 5, "name": "Developer", "manager_id": 4},
9]
10
11graph = nx.DiGraph()
12
13for person in employees:
14    graph.add_node(person["id"], label=person["name"])
15    if person["manager_id"] is not None:
16        graph.add_edge(person["manager_id"], person["id"])
17
18print("Nodes:", graph.nodes(data=True))
19print("Edges:", list(graph.edges()))

This creates a graph that can be queried programmatically. Once it exists, you can answer questions such as:

• who reports to a given manager
• how deep the hierarchy is
• whether the data contains invalid cycles

Validate the Structure Before Rendering

A valid hierarchical org chart should not contain cycles. If employee A manages B and B manages A, the graph is inconsistent.

1import networkx as nx
2
3if nx.is_directed_acyclic_graph(graph):
4    print("Structure is acyclic")
5else:
6    print("Invalid org structure: cycle detected")

This validation step matters because visualization tools may still draw a bad graph, but the picture will hide the underlying data problem. Catching the issue early is much safer than generating a misleading chart.

You may also want to verify that there is exactly one root node in a classic hierarchy. A root is a node with no manager.

roots = [node for node, indegree in graph.in_degree() if indegree == 0]
print("Root nodes:", roots)

If there are zero roots or several unrelated roots, the organization data may be incomplete or represent multiple independent structures.

Render the Graph

For quick visualization, you can draw the graph with matplotlib. It will not look like a polished HR org chart, but it is useful for debugging.

1import matplotlib.pyplot as plt
2import networkx as nx
3
4labels = nx.get_node_attributes(graph, "label")
5pos = nx.spring_layout(graph, seed=42)
6
7nx.draw(graph, pos, with_labels=False, arrows=True, node_size=2500)
8nx.draw_networkx_labels(graph, pos, labels=labels)
9plt.show()

For a cleaner hierarchical layout, teams often export to Graphviz or render the structure in a web UI. The important part is that the graph model comes first. Once the relationships are correct, the rendering technology can change without changing the underlying logic.

Trees Versus Matrix Structures

A simple company hierarchy is often a tree, but many organizations are not pure trees. A matrix structure may give one person a line manager and a project lead. In graph terms, that means more than one incoming edge.

That is still a graph, but no longer a strict tree. If you are building a system that must support both kinds of reporting, design the data model for graphs from the start instead of assuming every node has exactly one parent forever.

Common Pitfalls

• Treating every organization as a pure tree when dotted-line or matrix reporting exists.
• Skipping cycle detection and ending up with impossible management chains.
• Building the visualization first and only later realizing the source data is inconsistent.
• Using display names as unique identifiers instead of stable employee or role IDs.
• Forgetting to handle multiple root nodes when the data actually represents several divisions.

Summary

• Model the org structure as nodes plus directed reporting edges.
• Use a directed graph when manager-to-report relationships matter.
• Validate cycles and root nodes before trusting the visualization.
• Use networkx or a similar library to build and inspect the structure programmatically.
• Treat trees as a special case of graphs, not the only possible organizational model.