Scaling engineering teams with an architecture North Star
summary
Claims that an architecture North Star lets dozens of autonomous agile teams align without adding heavy coordination, based on a real WeWork scaling story (from ~6 locations to hundreds) and a 30-person engineering org. Uses domain-driven design to produce a small set of principles, context map boundaries and n-type atoms, targets practical horizons (six months to a year), prioritizes architecture-significant requirements, and keeps the guiding model minimal so teams can make fast, local decisions.
AI-written summary · about
chapters (24)
- 0:00Intro
- 0:34About me
- 1:11About WeWork
- 1:33About WeWork today
- 2:31How many of you work on an agile team
- 2:44We follow the agile principles
- 3:53Team size
- 4:31Cracks
- 5:24Common concerns
- 6:16What happened
- 6:38Architecture diverges
- 7:32How do we address it
- 8:51Autonomy
- 9:27Architecture Northstar
- 9:54Architecture Northstar Definition
- 13:06Should you do an Architecture Northstar
- 14:35How do we come up in the Architecture Northstar
- 15:16Domaindriven design
- 16:29Contact map
- 16:44Involve stakeholders
- 18:25Prioritize requirements
- 19:06Be practical
- 19:24Core domains
- 21:53Conclusion
related talks
16mEveryone architect!
24mThe Secret to Scaling a Team? Strategic Architecture
26mScaling engineering organizations
45mTowards Architecture Organization Topologies for Sustainable Fast Flow of Change
16mEnlarge your team!
51mWhy We Need Architects (and Architecture) on Agile Projects
19mScaling Fast – Engineering Lessons From ~15 Years of Tech Startups
53mThe art of scaling an Engineering Organization