How and why to design your Teams for modern Software Systems
summary
Conway’s Law drives the claim that org structure shapes software architecture so to get microservices each team must hold its own data capability rather than a central DBA, and teams must be stable long‑lived units with clear responsibilities. Cognitive load limits how much a team can own, so split systems into team‑sized subsystems. Recommended topologies are product/feature team, platform or substrate team, component and supporting teams; evolve collaboration into platform as a service over time using tools like Kubernetes, Cloud Foundry or AWS.
AI-written summary · about
chapters (8)
- 0:00Designing teams for success
- 2:58Conway's law explained
- 9:02Cognitive load and performance
- 13:57DevOps team topologies
- 21:51Effective collaboration models
- 25:51Four fundamental team types
- 34:18Evolving team topologies
- 38:40Summary and Q&A
related talks
31mHow and Why to Design Your Teams for Modern Software Systems
34mCode as Culture How Organization Shapes Your Code
38mConway's law in practice: Agile teams & Microservises
36mThe human factor you might be missing when designing your system
49mConway's Law: When Best Practices Are Not Enough
05mcultures and microservices
35mOrganization: A Tool for Software Architects
45mConway's Law: when best practices aren't enough