← Back to all projects

ORG DESIGN FOR ENGINEERING MASTERY

In 1967, Melvin Conway observed a fundamental truth: Organizations which design systems... are constrained to produce designs which are copies of the communication structures of these organizations. This became known as **Conway's Law**. It means that your software architecture is not just a technical choice; it is a reflection of your org chart.

Learn Org Design for Engineering: From Zero to Organizational Architect

Goal: Deeply understand the principles, patterns, and pitfalls of designing effective engineering organizations. By applying concepts like Conway’s Law and Team Topologies, you will learn to restructure teams, manage cognitive load, and align human communication pathways with desired system architectures. You will move from being a “consumer” of organizational structures to an “architect” capable of building resilient, high-flow environments that deliver real-world business value.

Why Org Design for Engineering Matters

In 1967, Melvin Conway observed a fundamental truth: “Organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations.” This became known as Conway’s Law. It means that your software architecture is not just a technical choice; it is a reflection of your org chart.

If your organization has silos between Frontend and Backend, your software will have friction at the API boundary. If your teams are overloaded with “extraneous” tasks (like managing their own Kubernetes clusters while also building features), your delivery speed will crawl.

Understanding Org Design unlocks:

Predictable Delivery: By aligning teams to value streams.
System Quality: By using the “Reverse Conway Maneuver” to drive better architecture through team design.
Talent Retention: By managing cognitive load and providing clear career paths.
Scalability: Knowing how to grow from 10 to 1,000 engineers without collapsing under the weight of communication overhead.

Core Concept Analysis

1. Conway’s Law: The Invisible Hand

Conway’s Law states that the software architecture will mirror the communication pathways of the organization.

Formal Org Structure:             Resulting Software Architecture:
[Team A] <---> [Team B]           [Service A] <---> [Service B]
    |               |                  |                 |
    | (Low Comm)    |                  | (Fragile API)   |
    ▼               ▼                  ▼                 ▼
[Team C] <---> [Team D]           [Service C] <---> [Service D]

If communication is difficult between Team A and Team C, the interface between Service A and Service C will likely be buggy or poorly defined.

2. Team Topologies: The Four Types

To optimize for flow, we move away from “functional silos” (QA, DB, Frontend) and toward four fundamental team types:

Stream-aligned: Owns a segment of the business domain end-to-end.
Platform: Provides internal services to reduce other teams’ cognitive load.
Enabling: Bridge knowledge gaps (e.g., a “Security Enabling Team”).
Complicated Subsystem: For math/science/complex parts that require deep specialization.

3. Cognitive Load: The Team’s Capacity

Cognitive load is the “mental RAM” of a team. It is divided into:

Intrinsic: The difficulty of the problem (e.g., “How do I write a binary search?”).
Extraneous: The friction of the environment (e.g., “How do I deploy to this broken CI/CD?”).
Germane: The value-adding complexity (e.g., “How do I solve this business problem?”). Goal: Minimize Extraneous load so teams have more room for Germane work.

4. Interaction Modes

Teams shouldn’t just “collaborate” by default. Collaboration is expensive. We define three modes:

Collaboration: Working closely for a limited time to discover an interface.
X-as-a-Service: Consuming a stable component with minimal interaction.
Facilitating: One team helps another learn a new skill.

5. The Reverse Conway Maneuver

Instead of letting the org chart break the architecture, we design the teams to look like the architecture we want.

Desired Architecture: 3 Microservices  --->  Design: 3 Independent Teams

Concept Summary Table

Concept Cluster	What You Need to Internalize
Conway’s Law	Your architecture will mirror your team communication. Fighting this is a losing battle.
Cognitive Load	A team’s effectiveness is limited by the mental friction they face. High friction = low flow.
Team Topologies	Not all teams are created equal. Use specialized types to enable the “Stream-aligned” team.
Interaction Modes	Collaboration is a cost, not a free benefit. Use “as-a-Service” for stability.
Loose Coupling	Org design is about reducing dependencies. If everyone must talk to everyone, no one gets work done.

Deep Dive Reading by Concept

This section maps each concept from above to specific book chapters. Read these before or alongside the projects.

The Human-System Mirror

Concept	Book & Chapter
Conway’s Law	Team Topologies by Skelton & Pais — Ch. 2: “Conway’s Law and the Inverse Conway Maneuver”
The Mirroring Hypothesis	An Elegant Puzzle by Will Larson — Ch. 2.1: “Sizing Teams”

Team Structure & Flow

Concept	Book & Chapter
Cognitive Load	Team Topologies by Skelton & Pais — Ch. 3: “Team Cognitive Load”
The Four Team Types	Team Topologies by Skelton & Pais — Ch. 5: “The Four Fundamental Team Topologies”
Team Sizing	An Elegant Puzzle by Will Larson — Ch. 2.1: “Sizing Teams”
Interaction Modes	Team Topologies by Skelton & Pais — Ch. 6: “Three Team Interaction Modes”

Organizational Performance

Concept	Book & Chapter
Culture & Performance	Accelerate by Forsgren et al. — Ch. 3: “Measuring and Changing Culture”
Continuous Delivery Impact	Accelerate by Forsgren et al. — Ch. 4: “Technical Practices”
Measuring Success	An Elegant Puzzle by Will Larson — Ch. 3.4: “Metrics and Baselines”

Project 1: The Conway Audit (Visualizing Current State)

File: ORG_DESIGN_FOR_ENGINEERING_MASTERY.md
Main Programming Language: Python (for graph generation)
Alternative Programming Languages: JavaScript (D3.js), Mermaid.js
Coolness Level: Level 3: Genuinely Clever
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 2: Intermediate
Knowledge Area: Org Design / System Architecture
Software or Tool: GraphViz, LucidChart, or Mermaid
Main Book: “Team Topologies” by Skelton & Pais

What you’ll build: A “Mismatch Map” that overlays your current team communication chart (who actually talks to whom) with your software dependency graph (which service calls which).

Why it teaches Org Design: You’ll discover that “Service A” and “Service B” are tightly coupled because the teams that own them share the same manager and sit in the same Slack channel. You’ll see “Conway’s Law” in action as a physical force that shapes your code.

Core challenges you’ll face:

Implicit vs. Explicit Communication: Finding where people actually get answers (Slack/Coffee) vs. where they should (Documentation/APIs).
Defining Ownership: Realizing that some services are “orphans” or owned by 3 different teams.
Visualizing Conflict: Mapping two different domains (Human and Software) into a single view.

Key Concepts

Conway’s Law: Ch. 2 - Skelton & Pais
The Mirroring Hypothesis: Ch. 2.1 - Will Larson

Difficulty: Intermediate Time estimate: 1 week Prerequisites: Access to a real or realistic system architecture; basic understanding of graph data structures.

Real World Outcome

You will produce a “Mismatch Report” that highlights technical debt caused by organizational silos.

Example Output:

$ python conway_audit.py --org team_roster.json --system system_deps.json

[!] CONWAY MISMATCH DETECTED:
Service: "Auth-Service" (Team Alpha) <---> "Billing-Service" (Team Gamma)
- System Dependency: HIGH (Synchronous API calls)
- Team Communication: LOW (Zero shared meetings, different directors)
- RESULT: Frequent production outages at this boundary due to "surprising" API changes.

The Core Question You’re Answering

“Is our software architecture a choice we made, or an accident of who we sit next to?”

Project 2: The Cognitive Load Assessor

File: ORG_DESIGN_FOR_ENGINEERING_MASTERY.md
Main Programming Language: Python (for data processing)
Alternative Programming Languages: Spreadsheet / Excel
Coolness Level: Level 2: Practical but Forgettable
Business Potential: 2. The “Micro-SaaS / Pro Tool”
Difficulty: Level 2: Intermediate
Knowledge Area: Developer Experience (DX)
Software or Tool: SurveyMonkey or Google Forms (to collect data)
Main Book: “Team Topologies” by Skelton & Pais

What you’ll build: A spreadsheet or tool that calculates a “Cognitive Load Score” for every team in your org.

Why it teaches Org Design: It teaches you that “Teams” are a finite resource. If a team is maintaining 15 different microservices, they are likely doing none of them well.

Core challenges you’ll face:

Quantifying ‘Intrinsic’ vs ‘Extraneous’ Load: How do you measure “frustration with Jenkins” vs “complexity of the business logic”?
Thresholding: When is a team “Full”? (Is it 3 services? 10?)
The Platform Gap: Identifying which tasks should be moved to a Platform team.

Key Concepts

Cognitive Load Theory: Ch. 3 - Skelton & Pais
Thinnest Viable Platform: Ch. 5 - Skelton & Pais

Difficulty: Intermediate Time estimate: 1-2 weeks

Project 3: The Platform Interface (Platform as a Product)

File: ORG_DESIGN_FOR_ENGINEERING_MASTERY.md
Main Programming Language: Go or Python
Alternative Programming Languages: Terraform, Bash
Coolness Level: Level 3: Genuinely Clever
Business Potential: 4. The “Open Core” Infrastructure
Difficulty: Level 3: Advanced
Knowledge Area: Platform Engineering / Developer Experience
Software or Tool: Backstage, Terraform, or a custom CLI
Main Book: “Team Topologies” by Skelton & Pais

What you’ll build: A “Service Template” system (like a CLI or Portal) that allows a developer to provision a new microservice (repo, CI/CD, DB, K8s namespace) in 5 minutes with zero tickets.

Why it teaches Org Design: It teaches you the “X-as-a-Service” interaction mode. You are designing a boundary where the “Platform Team” interacts with “Feature Teams” through an API, not through meetings. This is how you scale an organization without scaling the management overhead.

Key Concepts

Thinnest Viable Platform: Ch. 5 - Skelton & Pais
The Golden Path: “Internal Developer Portals” - PlatformEngineering.org

Difficulty: Advanced Time estimate: 2 weeks

Project 4: The Reverse Conway Simulation

File: ORG_DESIGN_FOR_ENGINEERING_MASTERY.md
Main Programming Language: Python
Alternative Programming Languages: NetLogo, Mesa
Coolness Level: Level 5: Pure Magic (Super Cool)
Business Potential: 5. The “Industry Disruptor”
Difficulty: Level 5: Master
Knowledge Area: Systems Theory / Organizational Dynamics
Software or Tool: Python (Mesa library)
Main Book: “Thinking in Systems” - Donella Meadows

What you’ll build: An agent-based simulation where “Engineers” work on “Code Modules.” You will model two different organizational structures and measure the “Technical Debt” and “Coupling” that emerges over time.

Why it teaches Org Design: It proves that Org Design is a System. You will observe emergent behavior: how a simple rule (like “Only talk to people in your team”) leads to a massive monolithic block in the center of your codebase.

Key Concepts

The Reverse Conway Maneuver: Ch. 2 - Skelton & Pais
Systems Thinking: Ch. 1 - Donella Meadows

Difficulty: Master Time estimate: 1 month

Project 5: The Domain Reorg (Monolith Splitter)

File: ORG_DESIGN_FOR_ENGINEERING_MASTERY.md
Main Programming Language: Markdown / Strategic Planning
Alternative Programming Languages: LucidChart, Miro
Coolness Level: Level 3: Genuinely Clever
Business Potential: 5. The “Industry Disruptor”
Difficulty: Level 3: Advanced
Knowledge Area: Domain-Driven Design (DDD) / Organizational Transformation
Software or Tool: Event Storming (methodology), Miro
Main Book: “Domain-Driven Design” by Eric Evans

What you’ll build: A “Domain-to-Team Map” for a legacy 100-person organization. You will take a monolithic business (e.g., an e-commerce site) and divide it into “Bounded Contexts,” then design a team structure that perfectly mirrors those contexts.

Why it teaches Org Design: It teaches you that Domain Boundaries = Team Boundaries. If you get the business domain wrong, your team structure will be a mess, and your code will have “Leaky Abstractions.”

Difficulty: Advanced Time estimate: 2 weeks

Project 6: The Team API Agreement

File: ORG_DESIGN_FOR_ENGINEERING_MASTERY.md
Main Programming Language: Markdown
Alternative Programming Languages: Notion / Wiki
Coolness Level: Level 2: Practical but Forgettable
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 1: Beginner
Knowledge Area: Communication / Operational Excellence
Software or Tool: GitHub Wiki or Notion
Main Book: “Team Topologies” by Skelton & Pais

What you’ll build: A standardized “Team API” document for 3 interacting teams that reduces meeting time by 50%.

Why it teaches Org Design: It teaches you that Teams are black boxes. If you have to know who is on a team to get work done, your organization isn’t scalable.

Difficulty: Beginner Time estimate: Weekend

Project 7: The Incident-to-Org Root Cause Analysis

File: ORG_DESIGN_FOR_ENGINEERING_MASTERY.md
Main Programming Language: Markdown
Alternative Programming Languages: None
Coolness Level: Level 3: Genuinely Clever
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 3: Advanced
Knowledge Area: SRE / Organizational Learning
Software or Tool: Blameless Post-mortem process
Main Book: “Accelerate” by Forsgren et al.

What you’ll build: A “Post-Mortem of the Org.” You will take a real or fictional technical outage and trace it back to an Organizational Anti-pattern.

Difficulty: Advanced Time estimate: 1 week

Project 8: The Engineering Career Ladder

File: ORG_DESIGN_FOR_ENGINEERING_MASTERY.md
Main Programming Language: Markdown
Alternative Programming Languages: YAML (for schema)
Coolness Level: Level 2: Practical but Forgettable
Business Potential: 1. The “Resume Gold”
Difficulty: Level 2: Intermediate
Knowledge Area: Leadership / HR Systems
Software or Tool: Google Docs / Notion
Main Book: “An Elegant Puzzle” by Will Larson

What you’ll build: A “Dual-Track” Career Ladder (IC and Management) that defines exactly what is expected at every level from Junior to VP.

Difficulty: Intermediate Time estimate: 1 week

Project 9: The Reorg Impact Simulator

File: ORG_DESIGN_FOR_ENGINEERING_MASTERY.md
Main Programming Language: Python
Alternative Programming Languages: Spreadsheet
Coolness Level: Level 3: Genuinely Clever
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 3: Advanced
Knowledge Area: Change Management
Software or Tool: Python
Main Book: “Dynamic Reteaming” - Heidi Helfand

What you’ll build: A tool that calculates the “Productivity Debt” incurred when you move engineers between teams (The “Re-jelling” cost).

Difficulty: Advanced Time estimate: 1 week

Project 10: The Onboarding Journey Map

File: ORG_DESIGN_FOR_ENGINEERING_MASTERY.md
Main Programming Language: Markdown
Alternative Programming Languages: None
Coolness Level: Level 2: Practical but Forgettable
Business Potential: 2. The “Micro-SaaS / Pro Tool”
Difficulty: Level 1: Beginner
Knowledge Area: Employee Experience
Software or Tool: Notion / Loom
Main Book: “An Elegant Puzzle” by Will Larson

What you’ll build: A “Day 1 to Day 90” onboarding process that specifically addresses “Organizational Context” rather than just technical setup.

Difficulty: Beginner Time estimate: Weekend

Project 11: The Policy & Exception Manager

File: ORG_DESIGN_FOR_ENGINEERING_MASTERY.md
Main Programming Language: Python / SQLite
Alternative Programming Languages: Go
Coolness Level: Level 1: Pure Corporate Snoozefest
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 2: Intermediate
Knowledge Area: Governance / Scaling Consistency
Main Book: “An Elegant Puzzle” by Will Larson

What you’ll build: A system to track “Organizational Exceptions” (e.g., when a team is allowed to deviate from a standard).

Why it teaches Org Design: It teaches you the principle: “Work the policy, not the exceptions.” If exceptions become the rule, your organizational design is failing.

Difficulty: Intermediate Time estimate: 1 week

Project 12: The Engineering Strategy Generator

File: ORG_DESIGN_FOR_ENGINEERING_MASTERY.md
Main Programming Language: Markdown
Alternative Programming Languages: None
Coolness Level: Level 3: Genuinely Clever
Business Potential: 1. The “Resume Gold”
Difficulty: Level 3: Advanced
Knowledge Area: Strategic Planning / Alignment
Main Book: “An Elegant Puzzle” by Will Larson

What you’ll build: A structured “Strategic Pillar” document that aligns 5 disparate teams under one single technical goal.

Difficulty: Advanced Time estimate: 1 week

Project Comparison Table

Project	Difficulty	Time	Depth of Understanding	Fun Factor
1. Conway Audit	Level 2	1 week	Deep (The “Why”)	★★★★☆
2. Cognitive Load	Level 2	1 week	Moderate (The “How”)	★★★☆☆
3. Platform IDP	Level 3	2 weeks	Deep (Scaling)	★★★★☆
4. Reverse Conway	Level 5	1 month	Expert (Systems)	★★★★★
5. Domain Reorg	Level 3	2 weeks	Deep (Architecture)	★★★☆☆
6. Team API	Level 1	Weekend	Basic (Comm)	★★☆☆☆
7. Incident RCA	Level 3	1 week	Deep (Learning)	★★★★☆
8. Career Ladder	Level 2	1 week	Moderate (Incentives)	★★★☆☆
12. Eng Strategy	Level 3	1 week	Deep (Alignment)	★★★★☆

Recommendation

Start with Project 1: The Conway Audit. Why? Because it makes the invisible visible. Before you try to change an organization, you must understand the “Invisible Hand” of Conway’s Law that is currently shaping your software. It is the most “eye-opening” project for a developer.

Final Overall Project: The “Hypergrowth” Blueprint

What you’ll build: A comprehensive “Engineering Operating System” for a company growing from 50 to 500 engineers.
Why it teaches Org Design: This project applies every concept: You will design the team topologies, the career ladders, the platform interfaces, the strategy documents, and the decision-making frameworks for a 10x scale event.
Outcome: A “Company Playbook” that defines how engineering work is done at scale.

Summary

This learning path covers Engineering Org Design through 12 hands-on projects.

Recommended Learning Path

For Individual Contributors: Projects #1, #2, #3, #6, #10 For Aspiring Managers: Projects #5, #7, #8, #11, #12 For Systems Architects: Projects #1, #4, #5, #9

Expected Outcomes

After completing these projects, you will:

Master the application of Conway’s Law.
Be able to design team structures that optimize for “Fast Flow.”
Understand how to reduce cognitive load across an entire organization.
Know how to lead high-impact reorganizations with minimal disruption.
Build internal developer products that empower rather than constrain.

You’ll have built a portfolio of organizational maps, simulations, and strategies that demonstrate elite leadership and systems thinking skills.