Scaling Engineering Organizations with Patterns
0 likes263 views
The document discusses patterns for scaling engineering organizations as they grow in size and complexity. It describes patterns for teams, feature teams, requirement areas, distributed architectures, microservices, platform teams, and developer meshes. Each pattern has pros and cons, and prerequisites are discussed for some patterns. The document emphasizes the importance of mastering best practices like continuous integration before scaling, and having leadership, a clear mission, and infrastructure to support more autonomous patterns.
Scaling Engineering Organizations with Patterns
- 1. Scaling Engineering Organizations with Patterns @sshishkin Sergey Shishkin
- 3. x1 x1 x1 WELCOME TO MUSHROOM INC.
- 4. Humble Origins Uni鍖ed product direction Uncomplicated solution Fast technical decisions
- 5. LEVEL 1
- 7. LETS SCALE! x1 x1 x1
- 8. Pattern: Team Pros: Diverse ideas Increased throughput Decreased variability (bus factor) Cons: Cost of agreement Contention of shared resources
- 9. Universal Scalability Law See: https://blog.acolyer.org/2015/04/29/applying-the-universal-scalability-law-to-organisations/
- 10. Best Practices Collective Code Ownership Coding Standard Continuous Integration Pair Programming Test-Driven Development https://ronje鍖ries.com/xprog/what-is-extreme-programming/
- 11. Many organizations start to increase the number of teams before they master best practices with one team. This results in a bunch of underperforming teams and makes technical excellence harder to re-instill afterwards.
- 12. LEVEL 2
- 14. MORE TEAMS! x1 x1 x1
- 16. Pattern: Feature Teams Pros: Flexible prioritization of multiple stakeholders Increased throughput Cons: Increased cost of coordination Increased contention https://less.works/less/structure/feature-teams.html
- 17. LEVEL 3
- 20. Pattern: Requirement Area Pros: Manageable scope of prioritization Customer focus Potentially shippable backlog items Cons: Fragmented product vision Cost of agreement https://less.works/less/less-huge/requirement-areas.html
- 21. LEVEL 4
- 24. Pattern: Distributed Architecture Pros: Partitioned domain complexity Localized technology decisions Localized testing Cons: Cost of agreement on service interfaces Harder release coordination New failure modes
- 25. Conways Law
- 26. LEVEL 5
- 27. CHALLENGE: GROWING DEMAND x15 x5 x10
- 29. Pattern: Micro-Services Pros: Reduced team contention Scoped cognitive overhead Cons: Unpredictability of changes Operations complexity
- 30. Pattern: Micro-Services https://martinfowler.com/bliki/MicroservicePrerequisites.html Prerequisites: Infrastructure as a service Continuous deployment Observability
- 33. Pattern: Platform Teams Pros: Uni鍖ed solutions for common problems Economy of scale Competence development Cons: One size 鍖ts all solutions Innovation bottleneck
- 34. Look out for existing bright spots and promote them
- 36. LEVEL 6
- 40. Pattern: Developer Mesh Pros: Motivating autonomy Less organizational overhead Organic prioritization Cons: No centralized product authority
- 41. Pattern: Developer Mesh Prerequisites: Clear company mission and purpose Leadership at all levels
- 42. SUMMARY
- 45. GAME IS NOT OVER ITS YOUR TURN! @sshishkin Sergey Shishkin
- 46. Links Universal Scalability Law: https://blog.acolyer.org/2015/04/29/applying-the-universal-scalability-law-to- organisations/ eXtreme Programming Practices: https://ronje鍖ries.com/xprog/what-is-extreme-programming/ LeSS: Feature Teams: https://less.works/less/structure/feature-teams.html LeSS: Requirement Areas: https://less.works/less/less-huge/requirement-areas.html Conways Law: https://www.sketchplanations.com/post/175174474143/conways-law-im-paraphrasing- here-but-the-gist Pioneers, Settlers, Town Planners: https://blog.gardeviance.org/2015/03/on-pioneers-settlers-town- planners-and.html Dynamic Reteaming: http://www.heidihelfand.com/dynamic-reteaming/ You have to be this tall to use Micro-Services: https://martinfowler.com/bliki/MicroservicePrerequisites.html Cyne鍖n Framework: 鞄岳岳沿壊://敬敬敬.温乙庄鉛艶42.界看馨/艶稼/温乙庄鉛艶-庄稼韓看-界艶稼岳艶姻/界霞稼艶鍖n/ How GitHub (no longer) works: https://www.infoq.com/presentations/github-evolution/
- 47. Image Credits https://www.鍖aticon.com/authors/freepik https://www.鍖aticon.com/authors/eucalyp https://www.鍖aticon.com/authors/pixel-perfect https://www.鍖aticon.com/authors/mynamepong https://www.鍖aticon.com/authors/鍖at-icons https://www.鍖aticon.com/authors/monkik https://www.鍖aticon.com/authors/smashicons https://鍖ndicons.com/icon/423523/paper_mario