Engineering Org Chart: How to Map Teams to the Systems They Own

Most org charts answer one question: who reports to whom. Engineers rarely need that answer. During an incident they need to know which team owns the failing service and who is on call. In a design review they need to know which teams a change touches and how those teams work together. A chart of names and titles answers none of these.

This post builds an engineering org chart that does. It keeps the reporting lines for the people side and adds what engineering needs: team type, owned systems, on-call hours and how teams interact. It uses the Team Topologies vocabulary for teams and ends with what to label and how to keep the chart current.

What an engineering org chart should show

Past a handful of teams, leave individual engineers off the chart and show one card per team lead. A chart with sixty names is a phone book; a chart with eight teams is a map. Link each team to its own roster if people need the names.

Reporting lines are not the whole story

Mel Conway's paper "How Do Committees Invent?" was published in Datamation in April 1968. On his own page about the law, he states its thesis like this: an organization that designs a system produces a design whose structure copies the organization's communication structure. Fred Brooks later called it Conway's law, and the name stuck.

Note the word communication. An org chart shows reporting lines, and those are only part of how people communicate. Two teams under different directors that talk every day shape the system more than the line between their managers does. That is why the chart in this post writes down how teams work together, not only who they report to.

The law also works as a design tool. If two services should stay independent, do not give them to teams that must coordinate every change. Conway's paper adds a corollary: the first design is rarely the best one, so the organization needs to be flexible enough to change with it.

Team types and interaction modes

Team Topologies, by Matthew Skelton and Manuel Pais, gives teams a small, shared vocabulary: four team types and three ways for teams to interact.

The three interaction modes:

• Collaboration. Two teams work closely for a defined period to discover something new, such as an API or a practice. It is expensive, so give it an end date.
• X-as-a-Service. One team provides something and the other consumes it with little interaction, such as a deployment pipeline.
• Facilitating. One team helps and mentors another, for example while it adopts a new testing approach.

One caution from the Team Topologies site itself: it says the approach is not a method for designing a new org chart. It describes how work flows between teams. Use its vocabulary as labels on your chart, not as a reason to redraw every reporting line.

Keep ownership in one place

Ownership written only on a diagram goes stale. Keep the source of truth where engineers already look, and let the chart mirror it at team level.

In a service catalog such as Backstage, every component must name an owner: in the catalog descriptor format, spec.owner is a required field, and the owner is a single entity, commonly a team. In a repository, a CODEOWNERS file maps paths to the people or teams responsible for them, and GitHub automatically requests a review from code owners when a pull request that is not a draft changes their code.

If the chart and the catalog disagree, the catalog is usually right, and the chart is overdue for a review.

The example: engineering at an online shop

An online shop's engineering department has a VP and two directors. Product Engineering runs three teams: Checkout and Search, both stream-aligned, and Payments, a complicated subsystem team that owns payment processing and fraud scoring. Platform Engineering runs the Platform team, which owns CI/CD, the Kubernetes clusters and the observability stack, and a Developer Experience team whose lead role is still open.

Two interactions are active this quarter. Payments and Checkout are collaborating on 3-D Secure until the end of Q2. Developer Experience is facilitating Checkout's move to contract tests.

How to read it:

• Top to bottom, reporting lines. The VP, two directors and five team leads. The lines show who reports to whom, nothing else.
• Card color, team type. Amber for stream-aligned, rose for complicated subsystem, blue for platform and violet for enabling. Managers above team level stay gray.
• Under each team, the engineering view. The services the team owns, its on-call hours, and its current interaction with other teams.
• The dashed card is an open position. Developer Experience has no lead yet, and the chart says so instead of hiding the gap.

What to label

• Team names as people say them. If the incident channel says "Checkout", the chart says Checkout.
• Owned systems by the names used in the catalog, the dashboards and the alerts.
• On-call hours and where to escalate.
• Interaction mode and an end date for every collaboration.
• Dotted-line relationships, such as a security engineer who reports to the security team but works with Payments every day.
• Location or time zone when teams span several.
• The date of the last review, on the chart itself.

Common mistakes

• People without teams. A tree of names tells nobody where to go when something breaks.
• Systems nobody owns. If a service appears under no team, that is the finding. Assign it before the next incident does.
• Shared ownership. Two owners usually means none. Backstage asks for a single owner for a reason.
• Collaboration without an end. Collaboration is meant for a defined period. One that never ends often means the boundary between the two teams is in the wrong place.
• Overloaded teams. A team that owns a dozen services and two on-call rotations will be slow at all of them. Team Topologies treats a team's cognitive load as a limit to design for, and the chart makes the load visible.
• A chart nobody updates. Update it with every reorganization and every new service, and review it on a schedule.

The org chart shows who owns what; it does not show how the systems fit together. For that, draw a C4 model diagram or a microservices architecture diagram, and keep both current as described in architecture diagrams that don't rot.

Build it in Archboard

1. Sign in with Google or GitHub and create a diagram, or start from the org chart template.
2. From the Org chart pack, add an Employee card for the VP and fill in name, title, department and location.
3. Add people with the plus handles: below for a report, beside for a peer, above for a manager. The chart lays itself out from top to bottom.
4. Add an Open position card for each role you are hiring for.
5. Set each team lead's card color to its team type, and leave managers above team level gray.
6. Under each team lead, add Core Text with the team type, the systems it owns, its on-call hours and its current interaction mode.

The example uses 8 diagram nodes, within the Free plan; text does not count toward the limit. The org chart maker page covers sharing and export.

FAQ

Should an engineering org chart show every engineer? For a few teams, yes. Past that, show teams and their leads, and link each team to its own roster. The chart stays readable and changes less often.

How do I show a dotted-line manager? Draw a dashed line from the second manager and keep the solid line for the manager who runs performance reviews. In Archboard, a connection from a second manager becomes a dotted line, and the layout stays based on the first manager.

What is the difference between an org chart and a team topology? An org chart shows reporting lines. A team topology shows team types and how teams interact. Draw both, or annotate the org chart with the interactions, as in the example.

Where should service ownership live? In a service catalog or in CODEOWNERS files, where tools and people can find it. The org chart mirrors it at team level.

How often should an engineering org chart be updated? With every reorganization, new team or new service, plus a regular review, such as monthly. Put the date of the last review on the chart.

Start free — one seat, no credit card.