Team Topologies & Org Design
How to structure teams as your organization grows. The modern answer to classical hierarchy, combining Conway’s Law, cognitive load theory, and Agile principles. Directly relevant as DigiTPME hires its first collaborators.
Why Org Design Matters for Tech Companies
Classical management (Fayol, Weber) designed organizations for industrial production: functional departments (finance, operations, HR, production) with clear vertical authority.
The problem for software products: functional departments create silos. The front-end team doesn’t talk to the back-end team, which doesn’t talk to the data team, which doesn’t understand customer needs, which the sales team learned but never wrote down.
Conway’s Law (Melvin Conway, 1967):
“Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.”
In practice:
- 3 backend teams + 2 frontend teams + 1 DevOps team → 3-tier architecture with deployment bottleneck
- 1 full-stack team per product domain → a modular, independently deployable service per domain
Inverse Conway Maneuver: design your org structure to produce the system architecture you want, not the other way around.
For SijiLab: 26 modules built by 1 person = low cohesion, high coupling. If you add engineers, structure them by domain (Clinical: Orders+Specimens+Results, Finance: Billing+Invoice, Quality, Operations: RH+Inventory) to produce properly bounded services.
Team Topologies (Matthew Skelton & Manuel Pais, 2019)
The most practical modern framework for organizing software teams. Four fundamental team types + three interaction modes.
The Four Team Types
1. Stream-Aligned Team (most important)
- Aligned to a flow of work for one product/service/user journey
- Has all skills to deliver end-to-end (full-stack, product, design, QA)
- Long-lived, stable, owns product from inception to operation
- Most teams should be this type
- Example: “SijilPharma team” that owns all pharmacy ERP features
2. Enabling Team
- Helps stream-aligned teams acquire new capabilities (e.g., security, testing, cloud infra)
- Temporary engagement: upskill → hand off → move on
- Does NOT build features
- Example: A “Platform Education team” that teaches other teams how to use Kubernetes
3. Complicated Subsystem Team
- Owns a technically complex component that few understand (ML models, physics simulations, signal processing)
- Reduces cognitive load for stream-aligned teams
- Example: “NOTQIN Physics team” that owns SymPy equations and physics-informed ML
4. Platform Team
- Provides internal developer platform (infrastructure, CI/CD, observability, auth, databases)
- Reduces cognitive load for product teams
- Builds “paved roads” — easy, correct ways to do common things
- Example: “DigiTPME Platform team” owning NestJS framework, PostgreSQL standards, Keycloak auth, GitHub Actions CI/CD
The Three Interaction Modes
| Mode | Description | When to use |
|---|---|---|
| Collaboration | Two teams work closely together, overlap expected | Discovery phase, new domains, building something novel |
| X-as-a-Service | One team consumes another team’s API/tool/platform | Stable, well-defined interface, routine consumption |
| Facilitating | Enabling team helps stream-aligned team upskill | Short-term, capability transfer, then move away |
Team Cognitive Load
Teams have limited cognitive capacity. Overloaded teams make mistakes, produce technical debt, and burn out.
Three types of cognitive load:
- Intrinsic: essential complexity of the domain (e.g., CBAM regulations, lab reference ranges)
- Extraneous: unnecessary complexity added by poor tooling/processes (e.g., manual deployments)
- Germane: learning that builds capability (good — invest here)
Team Topologies goal: minimize extraneous cognitive load, protect intrinsic, maximize germane.
Warning signs of overload:
- “We don’t have time to fix technical debt”
- Team owns too many services to understand any of them well
- Every task requires touching 5 repos
- Constant context switching
The Spotify Model (2012)
Not a framework (Spotify never claimed it was). A description of how Spotify organized in 2012:
TRIBE (50–150 people, one product area)
└── SQUAD (6–12 people, one feature/user journey)
├── Chapter (functional guild across squads: front-end devs, QA)
└── Guild (community of interest across entire org)
Key principles:
- Squads are autonomous: own their domain, deploy independently
- Chapters keep technical standards consistent across squads
- Guilds spread knowledge organically
The honest retrospective: Spotify itself moved on from this model. In 2023, Henrik Kniberg (who described the model) said it should never have been called a model — it’s a description of one moment in one company.
What’s actually useful: the principle of autonomous, cross-functional teams with shared technical standards. Not the specific squad/tribe/chapter/guild terminology.
Scaling Org Design — Stage by Stage
Stage 1: Founder Solo (you now)
- Structure: 1 person = 1 team
- Risk: cognitive overload across too many projects
- Key discipline: strict project prioritization (your operating rule: one flagship offer per quarter)
- Tool: Kanban task board, weekly review
Stage 2: 2–5 people (first collaborators)
- Structure: 1 stream-aligned team per active product
- Each person owns a domain (e.g., you own backend + ML, collaborator owns frontend + QA)
- Key discipline: documented DoD, contribution guidelines, async-first communication
- Tool: GitHub PRs as the communication mechanism, shared Obsidian vault
- Risk: “shared responsibility = no responsibility” → one owner per deliverable (your contribution guideline already says this ✅)
Stage 3: 6–15 people (small startup)
- Structure: 2–3 stream-aligned teams + 1 platform function
- Key discipline: explicit team APIs (what each team produces and how to consume it)
- Tool: Notion/Linear for project management, weekly team sync
- Risk: Conway’s Law starts mattering — org structure drives architecture
Stage 4: 15–50 people (series A scale)
- Structure: 3–6 stream-aligned teams, enabling team, platform team
- Key discipline: architectural standards, internal developer platform, on-call rotation
- Risk: communication overhead grows quadratically (n teams → n²/2 communication paths)
Hiring for a Tech Team — What Classical Theory Missed
Harrizi’s OST (Taylor) = hire specialists, train for specific tasks. This works for repetitive industrial work.
For software teams:
- Hire for generalist capability + one deep specialty (T-shaped people)
- Cognitive flexibility matters more than specific framework knowledge
- Culture fit (values alignment) predicts retention more than skill alone
T-shaped profile:
Broad knowledge (can discuss, review, understand)
─────────────────────────────────────────────────────────
│ Deep expertise
│ (NestJS backend,
│ ML pipelines,
│ IoT protocols)
Your Personal Profile says: “data engineer with full-stack web development background.” That’s T-shaped with the vertical being data engineering.
First Hire Decision Framework
For your first collaborator on DigiTPME/SijilPharma:
| Role | Hire if | Risk |
|---|---|---|
| Frontend dev | You’re the bottleneck on UI/UX | They need clear specs to be effective |
| Customer success / QA | Product is built, users need support | They don’t accelerate product development |
| ML engineer | Model accuracy is your differentiator | Need data before ML helps |
| Sales / BizDev | You have a validated product | Premature if no PMF yet |
| Full-stack intern | You need general capacity | High training overhead |
Recommended first hire: someone who complements your weaknesses. Your weaknesses as identified in your vault: inconsistent content publishing, no fixed target customer yet, no committed team. → A part-time business development collaborator or content creator may have more impact than another engineer right now.
Culture — What Modern Management Added to Harrizi’s Behavioral School
Harrizi covered Mayo (social needs at work), Maslow (hierarchy of needs), and McGregor (Theory X vs Y). Modern additions:
Psychological Safety (Amy Edmondson, Harvard, 2018)
“The belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes.”
Google’s Project Aristotle (2012–2015): studied 180 teams to find what made them effective. Result: psychological safety was the #1 predictor of team effectiveness, above all other factors (skills, experience, IQ).
How to build it: leader models vulnerability (says “I don’t know”), mistakes are treated as learning, questions are welcomed, disagreement is normalized.
Netflix Culture (Reed Hastings)
- Hire and pay for top performers (small team of exceptional people > large team of average)
- Minimal process, maximum context (tell people why not just what)
- “Freedom and responsibility” — radical autonomy + accountability
- No performance reviews for stars (only feedback when underperforming)
No Rules Rules (Hastings & Meyer, 2020) — 3 elements:
- Build up talent density (hire exceptional, remove mediocre)
- Increase candor (radical honesty, feedback culture)
- Remove controls (travel policy, leave policy — remove them for high-trust teams)
High-Performance Culture Signals (Reed Hastings / Patrick Lencioni)
| Healthy | Unhealthy |
|---|---|
| Problems surfaced early | Problems hidden until crisis |
| Disagreements aired in meetings | Fake agreement + back-channel complaints |
| Mistakes → learning, documented | Mistakes → blame, hidden |
| Clear ownership of each deliverable | Everyone responsible = no one responsible |
| Weekly review rhythm maintained | Reviews skipped when busy |
Your Contribution Guidelines already embed many healthy culture signals: “communicate blockers immediately,” “one owner per deliverable,” “document decisions.” ✅
Remote and Async-First Work (relevant for your distributed team)
async-first principles
- Write to communicate, not to schedule meetings
- Over-document decisions (your Decision Log ✅)
- Define working hours agreement early
- Prefer async (vault, GitHub, Discord) over sync (calls) except for critical decisions
Remote Team Communication Stack (recommended)
| Layer | Tool | Purpose |
|---|---|---|
| Long-form async | Obsidian vault | Strategy, knowledge, decisions |
| Code + review | GitHub PRs | The primary work product |
| Quick async | Discord / WhatsApp | Fast questions, unblocking |
| Sync | Weekly Monday call (30 min) | Alignment, blocker removal |
| Video | Google Meet / Zoom | Onboarding, complex discussions |
Applying Team Topologies to DigiTPME Today
Current state (solo founder):
Ahmed
├── Stream-Aligned: SijilPharma (contributor)
├── Stream-Aligned: SijiLab (owner)
├── Stream-Aligned: NOTQIN ecosystem (owner)
├── Stream-Aligned: DigiTPME Diagnostic (owner)
├── Stream-Aligned: Idarati RAG (owner)
└── Platform: hosting, auth, CI/CD (owner)
This is unsustainable. 5+ stream-aligned responsibilities = severe cognitive overload.
Recommended restructure:
- Bound SijilPharma to PRs-only (no new feature ownership) ✅ (already planned)
- Park GymOS until signal ✅ (already done)
- Designate ONE stream as the active sprint each quarter
- Treat others as “X-as-a-service” (run on their own, occasional maintenance)
First collaborator design:
- You → Complicated Subsystem role (ML, IoT protocols, architecture decisions)
- Collaborator → Stream-Aligned (picks up one product’s day-to-day feature delivery)
See Also
- Modern Management Overview
- Agile & Scrum
- OKRs — Objectives & Key Results
- Coordinator OS/01 — Founder’s Operating Manual
- Coordinator OS/06 — Hiring & Onboarding
- Roles
- People Map
- Contribution Guidelines