Map Teams to Architecture

Diagram how org structure shapes software architecture using Conway's Law.

Introduction

30 Second Summary

Ever noticed how a company with three separate departments always seems to build software with three disconnected pieces? That pattern is not a coincidence. It is a fundamental law of software design.

In this project, you will diagram a fictional company's team structure, predict the architecture it produces, and then redesign both the teams and the system together using a technique called the Inverse Conway Maneuver.

What You'll Build

You will create a visual case study of Conway's Law in action using Excalidraw, a free browser-based diagramming tool.

By the end of this project, you'll have:

An org chart diagram for a fictional e-commerce company showing team boundaries and communication paths.
A system architecture diagram that mirrors the org chart, with annotated pain points showing where misalignment creates friction.
A redesigned org + architecture diagram applying Team Topologies patterns to fix the problems.
Secret Mission: Diagnose a real open-source project's architecture through its contributor graph.

Are there any prerequisites?

None. You only need a web browser. No sign-up, installation, or accounts are required.

Before We Start

Before We Start...

Set Up Excalidraw

To visualize Conway's Law, you need a diagramming tool that lets you quickly sketch org charts and architecture diagrams.

Excalidraw is a free, browser-based whiteboard with an infinite canvas. No sign-up is needed. Let's get it open and confirm you can draw shapes with text.

In this step, get ready to:

Open Excalidraw in your browser.
Draw a rectangle with text inside it to confirm everything works.

Open Excalidraw in your browser

Excalidraw runs entirely in your browser. There is nothing to install and no account to create.

Open your web browser.
Navigate to https://excalidraw.com.

You should see a large white canvas with a toolbar across the top of the screen.

What is on the toolbar?

The toolbar contains shape tools (rectangle, diamond, ellipse), line and arrow tools for connecting shapes, and a text tool for adding labels. You will use all of these to build your diagrams throughout this project.

Seeing a blank page or error?

Make sure you typed the URL correctly. Try refreshing the page. If you are on a restricted network (such as a work or school network), Excalidraw may be blocked. Try a different network or device.

Help me troubleshoot why Excalidraw is not loading in my browser.

Draw your first shape with text

Before building full diagrams, confirm you can create shapes and add text inside them. This is the core interaction you will use for every diagram in this project.

Click the Rectangle tool in the toolbar at the top (it looks like a square icon).
Click and drag anywhere on the canvas to draw a rectangle.
Double-click the rectangle to enter text editing mode.
Type ShopFlow inside the rectangle. This is the name of the fictional company you will diagram in the next steps.
Click anywhere outside the rectangle to deselect it.

You should see a rectangle on the canvas with the text "ShopFlow" displayed inside it.

Other tools you will use later

The Arrow tool in the toolbar lets you draw connecting lines between shapes. You will use this to show communication paths between teams.

Press Cmd+D (macOS) or Ctrl+D (Windows) to duplicate any selected element. This saves time when creating multiple team boxes with similar shapes.

Can't add text inside the rectangle?

Make sure you are double-clicking directly on the rectangle shape, not on the empty canvas around it. If you accidentally created a separate text element, press Cmd+Z (macOS) or Ctrl+Z (Windows) to undo and try again.

Help me add text inside a shape in Excalidraw.

Your canvas is ready. Next up, you will diagram ShopFlow's team structure and let Conway's Law predict the architecture it produces.

Diagram ShopFlow's Organization

Every software system has a shape. Conway's Law tells us that shape is not accidental. It mirrors the communication structure of the organization that built it.

In this step, you will diagram ShopFlow, a fictional 60-person e-commerce company organized by technology layer. By the end, you will have a clear visual of who talks to whom and how often.

In this step, get ready to:

Draw ShopFlow's team hierarchy with a CTO and 6 teams.
Add labeled communication arrows showing coordination frequency.
Annotate the diagram with a Conway's Law prediction.

Draw the team hierarchy

ShopFlow is structured by technology layer. Each team owns one horizontal slice of the tech stack. This is a common pattern in growing companies, and it has consequences for architecture.

On your Excalidraw canvas, select the Rectangle tool from the toolbar at the top (or press R on your keyboard).
Draw a rectangle near the top center of your canvas. Double-click it and type CTO inside.
Below the CTO rectangle, draw 6 team rectangles arranged in a row. Leave enough space between them for arrows later.
Double-click each rectangle and label them with the team name and size:

Frontend Team (12 people)
Backend Team (15 people)
Database Team (8 people)
DevOps Team (5 people)
QA Team (10 people)
Mobile Team (10 people)

Select the Arrow tool from the toolbar (or press A on your keyboard). Draw a straight arrow from the CTO rectangle down to each of the 6 team rectangles.
Select all elements by pressing Cmd+A (macOS) or Ctrl+A (Windows) to check that your hierarchy looks balanced.

You should now see a clear tree structure with the CTO at the top and six labeled teams below.

Duplicate to save time

Draw one team rectangle, style it the way you like, then select it and press Cmd+D (macOS) or Ctrl+D (Windows) to duplicate it. You can then reposition and relabel each copy.

Why organize by technology layer?

Layer-based teams are intuitive. You hire frontend specialists into a frontend team, database experts into a database team. Each group deepens its craft.

The trade-off is that every user-facing feature now crosses multiple team boundaries. A single checkout improvement needs Frontend, Backend, Database, and QA to coordinate. That coordination cost is where Conway's Law bites.

Add communication arrows between teams

Not all teams talk to each other with the same frequency. The arrows you draw next represent the real communication paths that shape the system's architecture.

Select the Arrow tool again.
Draw a thick arrow from the Frontend Team rectangle to the Backend Team rectangle. To make it thick, select the arrow, then increase the Stroke width in the properties panel on the left.
Double-click the arrow (or add a text element next to it) and label it API contracts.
Draw another thick arrow from Backend Team to Database Team. Label it schema changes.
Draw a thin dashed arrow from Frontend Team to Database Team. To make it dashed, select the arrow and change the Stroke style to dashed in the properties panel.
Draw another thin dashed arrow from Mobile Team to DevOps Team. Label it deploy schedules.

What do the arrow styles mean?

Thick solid arrows represent frequent, high-bandwidth communication. These teams talk daily and block each other regularly.

Thin dashed arrows represent infrequent communication. These teams interact only occasionally, which means the system interfaces between them tend to be brittle or duplicated.

Your diagram now shows both the hierarchy (who reports to whom) and the communication patterns (who coordinates with whom on what).

Arrows not connecting to shapes?

Make sure you start and end each arrow on the edge of a rectangle. When you hover over a shape's border, you should see a blue highlight indicating a connection point. If the arrow floats freely, delete it and redraw starting directly from the shape's edge.

Help me connect arrows to my rectangles in Excalidraw.

Annotate with a Conway's Law prediction

The final piece ties the org chart to architecture. You will add a text annotation that frames the diagram as a prediction.

Select the Text tool from the toolbar (or press T on your keyboard).
Click below your org chart and type: Conway's Law predicts: this org will produce a system that mirrors these communication paths.

Step back and look at your canvas. You should see a complete org chart with a CTO at the top, 6 team rectangles below, labeled communication arrows of varying thickness, and the prediction annotation at the bottom.

What does this org chart predict?

Look at the thick arrows. Frontend and Backend talk constantly about API contracts. Backend and Database coordinate on schema changes. These high-frequency communication paths will become the dominant interfaces in the software system.

The thin dashed arrows tell a different story. Mobile and DevOps rarely coordinate. Conway's Law predicts that the deployment process for mobile will be an afterthought in the system design.

Your org chart is complete. In the next step, you will draw the system architecture that this organization is constrained to produce, and you will see Conway's Law prediction come to life.

Predict and Draw the Resulting Architecture

Your org chart captures how ShopFlow's teams communicate. Now comes the core insight of Conway's Law: the software architecture will mirror those communication paths.

Teams organized by technology layers produce layered architectures. In this step, you will draw the system that ShopFlow's org structure inevitably produces, then annotate the pain points it creates.

In this step, get ready to:

Draw a layered architecture diagram that mirrors your org chart.
Connect architecture layers with arrows that match your team communication paths.
Annotate pain points in red to show where Conway's Law creates friction.

Draw the layered architecture stack

Layer-based teams produce layer-based architecture. Each team owns a horizontal slice of the system, so the system itself becomes a stack of horizontal slices.

Pan your canvas to the right of the org chart. Leave enough space so both diagrams sit side by side.
Select the Rectangle tool from the top toolbar.
Draw a rectangle at the top of your new section. Double-click it and type React Web App. This is owned by the Frontend Team.
Below it, draw two rectangles side by side. Label them iOS App and Android App. These are owned by the Mobile Team.
Below the mobile apps, draw a wide rectangle labeled REST API monolith. This is owned by the Backend Team.
Below the API, draw two rectangles side by side labeled PostgreSQL and Redis. These are owned by the Database Team.
Below the databases, draw a rectangle labeled CI/CD Pipeline + AWS Infrastructure. This is owned by the DevOps Team.
To the side of the main stack (not inside it), draw a rectangle labeled QA. Position it outside the main system because QA tests at integration boundaries rather than owning a layer.

Why does this look like the org chart flipped sideways?

That is exactly the point. Conway's Law is not a suggestion. It is a constraint.

If you have a frontend team, a backend team, and a database team, you will produce a three-tier architecture regardless of what the whiteboard says. The system interfaces form where team communication paths exist.

Draw arrows mirroring your org chart communication

The connections between architecture layers should mirror the communication arrows from your org chart. Where teams talk frequently, the system has tight coupling.

Select the Arrow tool from the top toolbar.
Draw a thick arrow from the React Web App down to the REST API monolith. This mirrors the Frontend-to-Backend communication in your org chart.
Draw thick arrows from both mobile apps down to the REST API monolith.
Draw a thick arrow from the REST API monolith down to PostgreSQL and Redis. This mirrors the Backend-to-Database communication.
Draw thin dashed arrows from QA to the boundaries between layers (e.g., between the apps and the API, between the API and the databases). QA tests at these seams.
Draw a thin dashed arrow from the CI/CD layer up to the REST API monolith to represent deploy coordination.

Matching arrow styles

To change arrow thickness, select the arrow and use the Stroke width option in the left panel. For dashed lines, change the Stroke style to dashed in the same panel.

Add red pain point annotations

The architecture diagram shows what Conway's Law produces. Now you will annotate why it hurts. These pain points are the problems that drive organizations toward the Inverse Conway Maneuver.

Select the Text tool (the T icon) from the top toolbar.
Change the text color to red. Click the color swatch in the left panel and select a red shade.
Click near the top of the architecture diagram and type: Every feature requires 3+ teams to coordinate.
Click near the REST API monolith and type: Backend team is a bottleneck for all changes.
Click near the mobile apps and type: Mobile team duplicates backend logic because communication is expensive.
Click near the QA box and type: QA discovers integration bugs late because they test at boundaries between teams.

Why are these pain points inevitable?

Each pain point traces directly back to a communication boundary in the org chart. Cross-team coordination is expensive, so teams avoid it. They duplicate logic, batch changes, and test late because those are locally rational responses to high communication costs.

The architecture did not become this way because of bad technical decisions. It became this way because the org structure made it the path of least resistance.

Canvas feeling cramped?

If your architecture diagram overlaps with the org chart, select all architecture elements (click and drag a selection box around them) and move them further to the right. Excalidraw has an infinite canvas, so there is always room.

If you cannot find the color option for text, make sure you have the text element selected first, then look for the color swatch in the properties panel on the left side.

You now have a clear visual showing how ShopFlow's team structure directly produces its architecture. The red annotations make the cost of this structure impossible to ignore. Next up, you will apply the Inverse Conway Maneuver to redesign both the teams and the architecture together.

Apply the Inverse Conway Maneuver

Your canvas now tells a clear story of the problem. The red annotations show exactly where ShopFlow's technology-layered org creates friction in its architecture. Now it's time to fix it.

The Inverse Conway Maneuver flips the script. Instead of letting your org structure accidentally dictate your architecture, you deliberately design your team structure to produce the architecture you want. In this step, you will redesign both the teams and the architecture together.

In this step, get ready to:

Draw a target architecture organized around business capabilities instead of technology layers.
Design cross-functional stream-aligned teams that map to each service.
Add communication patterns showing how the new structure enables independent deployment.

Draw your target architecture

The original ShopFlow architecture was organized by technology layer (frontend, backend, database). Your new target architecture organizes around business capabilities. Each capability becomes its own service that a single team can own end-to-end.

Create a new section on your canvas below or to the right of your existing diagrams.
Add a text label at the top of this section that says "AFTER: Inverse Conway Maneuver" so the before-and-after contrast is clear.
Draw 5 rectangles arranged side by side (not stacked vertically like before). These represent your capability-based services.
Label the first rectangle Product Catalog Service and add inside it: "browse, search, recommendations".
Label the second rectangle Checkout Service and add inside it: "cart, payment, order confirmation".
Label the third rectangle Fulfillment Service and add inside it: "shipping, tracking, returns".
Label the fourth rectangle Customer Account Service and add inside it: "auth, profiles, preferences".
Draw a wide rectangle beneath all four services and label it Platform with "infrastructure, CI/CD, observability" inside it.

Why organize by business capability?

When architecture is organized by capability, a single team can implement an entire feature (from UI to database) without coordinating across three other teams. The "every feature requires 3+ teams" problem from your red annotations disappears.

This is the core insight of the Inverse Conway Maneuver. You choose the architecture you want first, then shape the teams to match it.

Design the cross-functional teams

Each service now gets its own cross-functional team. These are stream-aligned teams from the Team Topologies framework. A stream-aligned team owns a business domain end-to-end and contains every skill needed to build, test, and deploy its service.

Below your target architecture, draw 5 new rectangles. These represent the teams that will own each service.
Label the first rectangle Catalog Team and add its composition inside: "2 frontend + 3 backend + 1 mobile + 1 data engineer".
Label the second rectangle Checkout Team and add: "2 frontend + 3 backend + 1 mobile + 1 data engineer".
Label the third rectangle Fulfillment Team and add: "2 frontend + 2 backend + 1 mobile + 1 data engineer".
Label the fourth rectangle Accounts Team and add: "2 frontend + 2 backend + 1 mobile + 1 data engineer".
Label the fifth rectangle Platform Team and add: "5 people providing shared infrastructure as a self-service product".
Draw a dashed line or arrow connecting each team to the service it owns above.

What is a platform team?

The Platform Team does not own a business feature. It provides shared infrastructure (CI/CD pipelines, monitoring, deployment tools) as a self-service product that the other four teams consume. This reduces cognitive load on the stream-aligned teams so they can focus on their business domain.

Draw the communication pattern

The final piece is showing how communication flows differently in this new structure. The key difference: high-bandwidth communication happens within teams, not between them.

Draw thick solid arrows circling within each team rectangle. Label these "high-bandwidth, daily" to show that frequent coordination happens inside the team.
Draw thin dashed arrows between the service rectangles (not the teams). Label these "well-defined APIs" to show that inter-team communication is low-bandwidth and happens through stable interfaces.
Add a green text annotation below the new team structure that reads: "Each team can build, test, and deploy their service independently."

Why does this solve the pain points?

Look back at your red annotations from the "before" state. "Every feature requires 3+ teams to coordinate" is gone because each team has every skill it needs. "Backend team is a bottleneck" is gone because there is no single backend team. "Mobile duplicates logic" is gone because mobile engineers sit inside each team.

Conway's Law still applies. The difference is that now you shaped the org to produce the architecture you wanted, instead of accepting whatever the old org produced by accident.

Step back and look at your full canvas. You should now see a clear before-and-after comparison. On one side, technology-layered teams produce a layered monolith with friction. On the other side, capability-aligned teams produce modular services with independent deployment.

Canvas feeling cluttered?

If your before-and-after sections overlap or feel cramped, select all elements in the "after" section and drag them further to the right or below. You can also zoom out using Ctrl+- (or Cmd+- on Mac) to see the full picture.

help me lay out my before-and-after diagrams so they are easy to compare

Your visual case study is complete. You have a powerful before-and-after diagram that tells the full story of Conway's Law in action. Next up, you will write a short analysis to solidify your understanding of when and why to use these concepts.

Write Your Analysis

Your before-and-after diagrams now tell the full visual story of Conway's Law in action. They show what happens when team boundaries don't match system boundaries, and what changes when you deliberately align them.

In this step, you'll add written analysis to your canvas that explains the reasoning behind your diagrams. This transforms your work from a set of pictures into a case study you could present to a team.

In this step, get ready to:

Explain why ShopFlow's original org produced a layered monolith.
Define the Inverse Conway Maneuver in your own words.
Identify situations where the Inverse Conway Maneuver is NOT the right approach.

Create a new analysis section on your canvas

Your diagrams capture the "what" of Conway's Law. The written analysis captures the "why" and makes your understanding explicit.

Scroll to an empty area below your before-and-after diagrams on the Excalidraw canvas.
Select the Rectangle tool from the top toolbar and draw a large rectangle to act as a frame for your analysis section.
Double-click the rectangle and type Analysis: Conway's Law in ShopFlow as a title inside it.
Select the Text tool (the "A" icon in the toolbar) and click below your title to start adding written answers.

Use separate text blocks for each question

Click a new spot on the canvas for each answer rather than putting everything in one text block. This makes it easier to reposition and resize your analysis later.

Answer the three analysis questions

Write short answers (2-4 sentences each) to the following three questions. These questions test whether you understand Conway's Law as a diagnostic tool, a design lever, and a constraint with limits.

Using the Text tool, write your answer to Question 1: "Why did the original ShopFlow org produce a layered monolith?"

What should my answer reference?

Think about three things: communication paths follow org chart boundaries, teams optimize for their own local concerns rather than end-to-end features, and cross-team coordination is expensive so it becomes the system's bottleneck.

Look back at your org chart. Every feature (like adding a promo code to checkout) requires the Frontend, Backend, and Database teams to coordinate. That coordination cost is why the architecture calcifies into rigid layers.

Write your answer to Question 2: "What is the Inverse Conway Maneuver?"

What should my answer capture?

The Inverse Conway Maneuver means deliberately designing your team structure to produce the architecture you want. Instead of letting architecture emerge passively from your existing org structure, you choose the architecture first and then organize teams to match.

Your answer should describe this flip: from "org drives architecture" to "desired architecture drives org design."

Write your answer to Question 3: "When would you NOT apply the Inverse Conway Maneuver?"

What situations should I consider?

Think about three scenarios where the maneuver is not the right tool. Small teams (under ~30 people) where everyone can communicate informally don't need it. Conway's Law naturally produces a monolith in this case, and that's fine.

Organizational restructuring is sometimes politically infeasible. In that case, align your architecture to the org you have rather than fighting the structure.

Finally, if your bounded contexts are not yet stable enough, forming permanent team boundaries around them is premature. You need to understand your domain well before locking in team structure.

Review your written analysis

Read through all three answers and check that each one is 2-4 sentences long.
Confirm that your analysis section is positioned below or beside your before-and-after diagrams so the full case study reads as a single visual narrative.

✔️ I'll try it first

Write your answers in your own words based on what you learned from building the diagrams. Your experience of seeing how ShopFlow's layers mirror its teams is the best guide.

ⓧ Let me check my work

Here are reference answers you can compare against:

Question 1: ShopFlow's org chart is divided by technology layer (Frontend, Backend, Database). Communication paths follow these org boundaries, so the system architecture mirrors them as rigid horizontal layers. Each team optimizes for its own local concerns rather than end-to-end features. Cross-team coordination is expensive, so it becomes the system's bottleneck and the architecture calcifies around it.

Question 2: The Inverse Conway Maneuver means deliberately designing your team structure to produce the architecture you want. Instead of letting architecture emerge from existing org structure, you choose the target architecture first (capability-aligned services) and then restructure teams to match those boundaries.

Question 3: You would NOT apply it when: (1) your team is small (under ~30 people) and everyone can communicate informally, making a monolith the natural and correct choice. (2) Organizational restructuring is politically infeasible, so you should align architecture to the org you have. (3) Your bounded contexts are not yet stable enough to form permanent team boundaries around them.

Why does the small-team threshold matter?

Martin Fowler puts it clearly: "A dozen or two people can have deep and informal communications, so Conway's Law indicates they will create a monolith. That's fine." The Inverse Conway Maneuver only becomes necessary when the team grows large enough that informal communication breaks down and you need deliberate organizational design.

Secret mission

Diagnose a Real Project

You've mapped Conway's Law on a fictional company. Now apply it to the real world. Pick a well-known open-source project and infer its organizational structure from publicly visible signals like directory layout, OWNERS files, and PR review patterns.

Clean Up Your Resources

This project runs entirely in your browser using Excalidraw's free editor, so there are no ongoing costs or cloud resources to worry about.

Decide whether to keep your diagrams accessible, save them for later, or clear everything out.

Resources you used:

Excalidraw canvas (stored in your browser's local storage at excalidraw.com).

Keep everything running

No action needed. Choose this if you want to keep refining your diagrams or reference them in the future.

Your Excalidraw canvas is automatically saved in your browser's local storage.
You can return to excalidraw.com anytime and your diagrams will still be there (as long as you use the same browser and haven't cleared your browsing data).

Pause - I'll come back to this later

Export your diagrams so you have a backup in case browser storage gets cleared.

In Excalidraw, click the hamburger menu (three horizontal lines) in the top-left corner.
Select Export image to save your canvas as a PNG file to your computer.
Alternatively, select Save to disk to export the canvas as an .excalidraw file that you can re-open later.
You can close the browser tab after exporting.

Delete - I don't want to use this again

Remove all project diagrams from your browser.

In Excalidraw, click the hamburger menu (three horizontal lines) in the top-left corner.
Select Reset the canvas to clear all your diagrams from local storage.
Close the browser tab.
To fully remove stored data, open your browser settings, navigate to your browsing data or site data settings, find excalidraw.com, and delete its stored data.

Nice Work!

You just built a complete visual case study of Conway's Law in action. You now have diagrams that show how organizational structure shapes software architecture, and the practical skill to use this as a design lever.

You've learned how to:

Diagram an organization's communication structure and predict the system architecture it produces.
Identify pain points caused by misalignment between team boundaries and desired system boundaries.
Apply the Inverse Conway Maneuver to redesign teams and architecture together using Team Topologies patterns (stream-aligned teams and a platform team).
Secret Mission: Applied Conway's Law to diagnose a real open-source project's architecture from its contributor structure.

Ready to quiz yourself?