Systems Thinking by combining Team Topologies with Context Maps
summary
Combines Team Topologies and Context Maps to show concrete, actionable judgments: when a stream‑aligned team is actually entangled by a shared kernel and should evolve into an open host service with a conformist or an anti-corruption layer; maps how domain models propagate, where governance or cognitive‑load problems live, and which team interaction mode to switch to. Offers patterns, an evolutionary recipe (collaborate → OHS → conformist → ACL) and examples like API-driven coupling vs loose coupling.
AI-written summary · about
chapters (19)
- 0:00Combining Team Topologies and Context Maps
- 1:23Team Topologies and system design
- 4:43Soot architecture and Conway's law
- 7:32Purpose mastery and autonomy
- 9:20Systems thinking and blockers
- 11:09Team Topologies types and evolution
- 16:07Enabling teams and legacy
- 17:51Team interaction modes
- 20:21Team Topologies limitations
- 21:02Fracture planes and bounded contexts
- 22:50Context Maps vs Team Topologies
- 24:14Context Map patterns
- 27:08Conformist pattern trade-offs
- 28:09Customer-supplier governance
- 29:14Visualizing team relationships
- 31:24Examples of combining models
- 36:00Evolutionary team and system design
- 37:49Systems thinking and dynamics
- 38:34Resources and closing
related talks
43mAdaptive Socio-Technical Systems with Architecture for Flow
46mAdaptive Socio-Technical Systems with Architecture for Flow
40mAdaptive Socio-Technical Systems with Architecture for Flow
54mThe value of Org Topologies in the era of DIY-frameworks
56mOptimizing for a fast flow of value with adaptive, socio-technical systems
54mDomain-Driven Design and Team Topologies for Product-led Organizations
47mArchitecture for Flow with Wardley Mapping, DDD, and Team Topologies
39mTeam Topologies, Software Architecture & Complexity