How and Why to Design Your Teams for Modern Software Systems
summary
Conway’s Law predicts organization structure shapes software architecture, and reverse Conway recommends designing teams to produce the architecture you want; academic work (2012) and team studies (US Navy, 1999) back this. Match team responsibility to cognitive load so maximum subsystem size fits team capacity, keep teams stable and “bring work to the team,” and evolve interactions from tight collaboration during discovery to clean X-as-a-service separations for delivery. Essential team classes are product, platform, productivity; component teams are optional. Cloud Foundry is cited as an example of aligned boundaries.
AI-written summary · about
chapters (10)
- 0:00Start
- 1:21by mentoring your teams
- 1:35How and why to design your teams for modern software systems
- 3:12(assumption) the team is stable, slowly changing, and long-lived #NoProjects
- 5:27homomorphic force shape
- 7:10Design the organisation architecture to produce the right software architecture
- 10:42Match the team responsibility to the cognitive load that the team can handle
- 23:56Evolve different team topologies for different parts of the organisation at different times to match the team purpose and context
- 27:13Also needed: culture, good engineering, sane funding models, clarity of business vision
- 28:48Safer, more rapid changes to software systems (Business Agility)
related talks
50mHow and why to design your Teams for modern Software Systems
45mConway's Law: when best practices aren't enough
35mOrganization: A Tool for Software Architects
49mConway's Law: When Best Practices Are Not Enough
34mCode as Culture How Organization Shapes Your Code
50mConway's Law: When Best Practices Are Not Enough
46mArchitecture for Cross-Functional Teams
24mThe (too) Many Faces of Architecture