Organizational Structure
How teams are organized, grouped, and what they own
How is the organization structured? What do teams “own”? How are teams organized—around customer segments, technology components, customer journey, jobs-to-be-done, or all of the above?
This is an interesting area of discovery because most organizations have an official org chart. Workday, or some other HR tool, has lists of people, who they manage, who they report to, and a name for the department. In short, a lot of this discovery is simply about extracting existing information so that you can model it in Dotwork.
But that only gets you part of the way there. In many organizations, there are multiple competing “contexts” used to distinguish teams. Finance might treat all teams as if they were “project teams,” while the technology organization is intent on defining teams around services, capabilities, products, or something else.
Step 1 — Containment and Grouping
Randomly select a team at your company. A “team” in this context is a group of roughly 10–15 people who collaborate frequently, have a “name” of some sort, and have been intentionally organized around something.
Work up from that team in terms of the organizational chart. Are they part of a group, pod, area, or department? Now go up another level: “____ is a part of the _________ which is a part of the ___________.”
Repeat this with another team from a different part of the organization. Continue until you've explored your org structure from a “grouping” or “containment” perspective.
Step 2 — Domain Context
Next, we dig into “ownership” or “domain” contexts. For example, some teams are organized around stages of a customer journey, some around customer touchpoints, and some around technical components.
Instructions
- Make a list of 10–15 teams.
- For each team, pick one primary paradigm from the table below.
- Add one or two secondary paradigms if they clearly apply.
- Move on quickly. Do not debate definitions.
- After 5–8 teams, look at the patterns that emerge.
Approaches to Organizing Teams
| Approach | Description | Example |
|---|---|---|
| Customer Journey Stages | Teams aligned to steps in the customer journey (e.g., awareness, onboarding, retention). | An Onboarding team that owns the first-time user flow. |
| Customer Segment | Teams aligned to specific customer groups (e.g., SMBs vs. Enterprise). | An SMB team that tailors pricing, onboarding, and support for small businesses. |
| Surface / Channel | Teams aligned to customer-facing "surfaces" such as mobile apps, web, or APIs. | A Mobile App team that owns the iOS and Android experience. |
| Customer Job-to-Be-Done | Teams organized around enduring capabilities or core "jobs" customers need. | A Payments team that enables secure checkout across all surfaces. |
| Product Area / Module | Teams aligned to bounded parts of the product needing ongoing ownership. | A Notifications team that owns email, SMS, and in-app messaging. |
| Geography / Region | Teams aligned to specific geographies (e.g., US, EU, APAC). | A Europe team that customizes features to meet GDPR and EU regulatory needs. |
| Feature Teams | Cross-functional teams organized around delivering specific features. | A Wishlist team that builds and maintains the ability to save products for later. |
| Architecture Layers | Teams aligned to layers of the technical stack. | A Backend Services team that manages APIs and data models. |
| Internal Capability (Platform) | Teams organized around shared internal capabilities. | A Developer Tooling team that provides CI/CD pipelines and dev productivity tools. |
| Specialized Discipline | Teams organized around deep expertise in a horizontal discipline. | A Machine Learning team that builds recommendation models used across web and mobile. |
| Initiative-Based Teams | Temporary teams spun up to pursue a specific initiative or experiment. | A Growth Experiment team tasked with running pricing experiments for three months. |
Step 3 — Building Your Spreadsheet
After completing containment (Step 1) and domain classification (Step 2), pull everything together into a simple spreadsheet. This becomes the working model of how teams are structured, how they relate, and how the organization actually thinks about them.
The goal is not to create a perfect taxonomy. The goal is to make everything visible, legible, and discussable.
Spreadsheet Columns
- Team Name
- Team Lead / POC (optional)
- Containment Level 1, 2, 3, 4
- Primary Paradigm
- Primary Capability / Domain
- Secondary Paradigm(s)
- Secondary Capability / Domain(s)
- Notes / Ambiguities / Conflicts
| Team Name | Containment 1 | Containment 2 | Primary Paradigm | Primary Domain | Secondary Paradigm | Notes |
|---|---|---|---|---|---|---|
| Activation Team | Growth Pod | Product Dept | Customer Journey Stage | Onboarding + First-Time Activation | Capability (JTBD) | Behaves like a capability team but classified as a journey team during planning. |
| Mobile App Team | Consumer Surfaces | Product Dept | Surface / Channel | iOS + Android App Experience | Product Area / Module | Still responsible for legacy auth flows despite unclear ownership. |
| Payments Team | Core Services | Engineering | Capability (JTBD) | Payments + Checkout | Architecture Layer | Engineering sees this as an architecture team; Product sees it as a customer capability team. |
| EU Market Team | Regional Ops | International | Geography / Region | EU Localization + Compliance | Customer Segment | Frequently pulled into global journey work despite a regional mandate. |
| ML Recommendations | Data Science | Engineering | Specialized Discipline | Recommender Systems + ML Models | Internal Capability (Platform) | Provides platform capabilities but is sometimes treated like a feature team. |
You're Done When
- You've captured real containment (team → group → department → division).
- You've mapped teams to primary and secondary paradigms (journey, capability, etc.).
- You've captured domain boundaries and ownership.
- You've assembled a containment + domain spreadsheet.