🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🧩 धडा 09 — Team topologies आणि Conway's law: team प्रकार आणि cognitive load

📍 तुम्ही इथे आहात: 12 पैकी धडा 09 · मागचा: lesson-08-delivery-metrics · पुढचा: lesson-10-incidents-decisions

📦 या ब्रँचमध्ये काय आहे

धडा 08, आणि टीम्सची रचना. Conway's law (systems त्यांना बनवणाऱ्या संस्थेच्या संवाद-रचनेची नक्कल करतात), माणसांच्या संख्येपेक्षा खूप वेगाने वाढणारे संवादाचे मार्ग, Team Topologies चे चार team प्रकार, आणि cognitive load — एक टीम एका वेळी डोक्यात किती ठेवू शकते. topologies() lead/demo.py मध्ये; paths(), handoffs() आणि cognitive_load() lead/models.py मध्ये.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

शाळा मोठी होते. कतरिनाच्या विभागात आता 12 शिक्षिका आहेत, आणि त्या सगळ्या एकाच मोठ्या staff meeting मध्ये बसतात. 🗣️ प्रत्येकीला प्रत्येकीशी बोलावे लागते. 12 जणींमध्ये बोलण्याची गरज पडू शकणाऱ्या 66 वेगवेगळ्या जोड्या होतात!

म्हणून शाळा शिक्षिकांची विभागणी करते. पहिली कल्पना: कामाच्या प्रकारानुसार — एक गट प्रश्न लिहितो, एक गट पेपर छापतो, एक गट ते तपासतो. पण आता प्रत्येक नव्या परीक्षेला तिन्ही गट लागतात. प्रत्येक गट इतरांची वाट पाहतो. 🐌

दुसरी कल्पना: इयत्तेनुसार. इयत्ता 7 ची टीम इयत्ता 7 साठी सगळे काही करते — प्रश्न, छपाई, तपासणी. इयत्ता 7 च्या नव्या परीक्षेला फक्त इयत्ता 7 ची टीम लागते. 🎯

आणि photocopier, कागद आणि छपाईचे नियम? एक छोटी support team ते सांभाळते, आणि ते इतके सोपे करते की इयत्तांच्या टीम्स ते फक्त वापरतात — वाट पाहणे नाही.

कतरिनाला आणखी एक गोष्ट दिसते: शाळा शिक्षिकांची विभागणी जशी करते, तशीच शेवटी तिच्या परीक्षांची रचना होते. माणसांचा आकारच कामाचा आकार बनतो.

🗺️ आकृती

flowchart LR
    o["👥 one team of 12<br/>66 communication paths"] --> t["two teams of 6<br/>30 paths + one interface"]
    c["🧱 component teams<br/>frontend · backend · data · platform"] --> c1["team-waits 14<br/>5/6 features need >1 team"]
    s["🎯 stream-aligned + platform"] --> s1["team-waits 9 · 3/6"]
    ss["🛠️ stream-aligned + SELF-SERVICE platform"] --> s2["team-waits 5 · 0/6"]
    l["🧠 cognitive load<br/>grades team 4 · 'everything' team 10"]

🗺️ काढलेली आवृत्ती + एक lab: https://school-edh.pages.dev/engineering-leadership/lesson-diagrams.html#l09

❓ काय

Conway's law — Melvin Conway (1968): संस्था अशा systems ची रचना करतात ज्या त्यांच्या स्वतःच्या संवाद-रचनेचे प्रतिबिंब असतात. (एक जुना विनोद असा सांगतो: compiler बनवणाऱ्या चार टीम्स four-pass compiler बनवतील.) Inverse Conway manoeuvre: तुम्हाला हवी असलेली system architecture डोळ्यासमोर ठेवून टीम्सची रचना जाणीवपूर्वक करा.
संवादाचे मार्ग — n लोकांच्या गटात n(n−1)/2 संभाव्य जोड्या असतात. Fred Brooks यांनी The Mythical Man-Month (1975) मध्ये हे वापरून समजावले की उशीर झालेल्या project मध्ये लोक वाढवल्याने तो आणखी उशिरा का होऊ शकतो ("Brooks's law" — अनुभवाचा नियम, मोजलेला नियम नव्हे).
Team Topologies — Matthew Skelton आणि Manuel Pais (2019) चार team प्रकार सांगतात: stream-aligned (एखाद्या user किंवा business क्षेत्रासाठी कामाचा प्रवाह सुरुवातीपासून शेवटपर्यंत सांभाळते) · platform (stream-aligned टीम्स स्वतःहून वापरू शकतील अशा अंतर्गत services देते) · enabling (इतर टीम्सना एखादी क्षमता शिकायला मदत करणारे तज्ज्ञ, जे नंतर बाजूला होतात) · complicated-subsystem (सखोल तज्ज्ञ ज्ञान लागणारा भाग सांभाळते). आणि तीन interaction modes: collaboration, X-as-a-Service, facilitating.
Component teams — technical layer नुसार विभागलेल्या टीम्स (frontend, backend, database). बहुतेक features प्रत्येक layer ओलांडतात, म्हणून बहुतेक features ना अनेक टीम्स लागतात.
Cognitive load — John Sweller यांच्या शिक्षणावरील कामातून: एखाद्या कामाला लागणारे मानसिक श्रम. Team Topologies हे टीम्सना लागू करते: टीमला फक्त तितकेच domains द्या जितके ती नीट समजू शकते — ढोबळमानाने, एक complex domain, किंवा काही सोपे domains. हा lab domains ना simple 1 · complicated 2 · complex 3 असे गुण देतो — शिकवण्यासाठीचे एक ढोबळ माप.

🤔 का

कारण engineering च्या वाटणाऱ्या अनेक delivery समस्या प्रत्यक्षात टीमच्या रचनेच्या समस्या असतात: चार टीम्स लागणारी features, त्यांच्यामधील tickets च्या रांगा, आणि अशी system जिचे सांधे org chart च्या सांध्यांच्या अगदी जागीच असतात. Lead चा टीमच्या सीमा आणि मालकीवर तिला वाटते त्यापेक्षा जास्त प्रभाव असतो — आणि त्या बदलल्याने अशी वाट पाहणे संपू शकते ज्याला कोणतीही process सुधारणा स्पर्शही करू शकली नसती.

🔧 कसे (या repo मध्ये)

lead/models.py मधील paths(n) म्हणजे n(n−1)/2. handoffs(features, owner, self_service=()) प्रत्येक feature कोणत्या components ना स्पर्श करते आणि प्रत्येक component ची मालक टीम कोणती हे घेते, आणि प्रत्येक feature ला कोणत्या टीम्सची वाट पाहावी लागते ते परत देते — self_service म्हणून दिलेल्या टीम्स वगळून, कारण त्यांचा platform त्यांची वाट न पाहता वापरता येतो. cognitive_load(domains) domain गुणांची बेरीज करते. lead/demo.py मधील topologies() सहा features तीन org रचनांवर चालवते. हे model प्रत्येक component चा एकच मालक आणि self-service खरोखर चालते असे गृहीत धरते: विचार करण्याचे साधन, लोकांसाठीचे सूत्र नव्हे.

🧪 करून पाहा

python3 lead/demo.py topologies
python3 - <<'EOF'
import sys; sys.path.insert(0, "lead"); from models import paths, handoffs
for n in (3, 5, 7, 9, 12, 20):
    print(f"team of {n:>2} → {paths(n):>3} paths")
feats = {"predicted grades": ["grades-ui", "grades-api", "grades-db"], "parent SSO login": ["auth", "parents-ui"]}
owner = {"grades-ui": "frontend", "grades-api": "backend", "grades-db": "data", "auth": "platform", "parents-ui": "frontend"}
for f, teams in handoffs(feats, owner).items():
    print(f"{f} waits for: {teams}")
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

topologies हे छापते:

── one team of 12: 66 communication paths · two teams of 6: 30 paths inside teams, plus one agreed interface between them
   component teams (frontend/backend/data/platform)   team-waits 14 · features needing >1 team 5/6
   stream-aligned teams + a platform team             team-waits  9 · features needing >1 team 3/6
   stream-aligned + a SELF-SERVICE platform           team-waits  5 · features needing >1 team 0/6
   cognitive load (simple 1 · complicated 2 · complex 3): grades team         4 across 2 domains
   cognitive load (simple 1 · complicated 2 · complex 3): 'everything' team  10 across 5 domains

तुमचा snippet हे छापतो:

team of  3 →   3 paths
team of  5 →  10 paths
team of  7 →  21 paths
team of  9 →  36 paths
team of 12 →  66 paths
team of 20 → 190 paths
predicted grades waits for: ['frontend', 'backend', 'data']
parent SSO login waits for: ['platform', 'frontend']

🏁 तुम्ही आत्ताच काय सिद्ध केले

मार्ग माणसांपेक्षा खूप वेगाने वाढतात: 5 लोकांच्या 10 जोड्या, 12 च्या 66, 20 च्या 190. 12 जणांना 6 च्या दोन टीम्समध्ये विभागल्यावर 30 मार्ग आणि ठरवायचा एक interface उरतो. Component teams मध्ये 6 पैकी 5 features ना एकापेक्षा जास्त टीम लागली (एकूण 14 team-waits); stream-aligned टीम्सनी ते 6 पैकी 3 वर आणले; आणि self-service platform ने — जो ticket न टाकता वापरता येतो — ते 6 पैकी 0 वर आणले. दरम्यान पाच domains वाहणाऱ्या "everything" टीमचा load score 10 होता, तर लक्ष केंद्रित grades टीमचा 4.

⚠️ नेहमीच्या चुका

code आणि systems ची मालकी न बदलता फक्त org chart वर पुनर्रचना करणे
प्रत्यक्षात ticket रांग असलेली "platform team" — मग ती वाट पाहणे कमी करण्याऐवजी वाढवते
इतर कोणालाही नको असलेले प्रत्येक domain एकाच टीमला देणे
technical layer नुसार टीम्स विभागणे आणि मग प्रत्येक feature ला meeting का लागते याचे आश्चर्य वाटणे
Team Topologies चे चार प्रकार शब्दसंग्रह म्हणून न वापरता भरायचे खोके म्हणून वापरणे
प्रत्येकजण प्रत्येकाशी बोलू शकते या बिंदूच्या पलीकडे एकाच टीमला वाढू देणे

🏭 प्रत्यक्ष वापरात

मालकी लिहून ठेवा, म्हणजे Conway's law तुमच्या बाजूने काम करेल. Service catalogue मधील एक नोंद:

# catalog-info.yaml — one per service (this layout follows Backstage's format)
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: gradebook-api
spec:
  type: service
  owner: team-grades          # a stream-aligned team
  lifecycle: production
  system: grades

Team API — इतर टीम्स तुमच्यासोबत कसे काम करतात — ही interaction modes स्पष्ट करण्यासाठी Team Topologies ची सूचना आहे:

## Team Grades — team API
- We own: gradebook-api, gradebook-ui, grades-db
- Ask us: #team-grades, or an issue on the gradebook repo (we answer within 1 working day)
- We use as-a-service: platform CI, auth, notifications
- Collaborating now (until week 20): the platform team, on the new storage service

दर तिमाहीला ही रचना वास्तवाशी ताडून पाहा: कोणत्या features ना एकापेक्षा जास्त टीम लागली, आणि त्यांनी किती वेळ वाट पाहिली? System Design school याच सीमांची architecture बाजू शिकवते.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: हळू delivery सुधारण्यासाठी process जोडण्याआधी, एका सामान्य feature ला किती टीम्स लागतात ते मोजा. उत्तर तीन किंवा चार असेल, तर मालकी बदला किंवा self-service platform बनवा — org chart हा architecture चाच भाग आहे.

⏭️ पुढे

नीट रचलेल्या टीम्सचेही वाईट दिवस येतात. पुढे: incidents आणि कठीण निर्णयांमध्ये नेतृत्व — आणि उलटता येणारे निर्णय न उलटता येणाऱ्यांपासून वेगळे ओळखणे.

git checkout lesson-10-incidents-decisions

🧩 Lesson 09 — Team topologies and Conway's law: team types and cognitive load

📍 You are here: Lesson 09 of 12 · Previous: lesson-08-delivery-metrics · Next: lesson-10-incidents-decisions

📦 What's in this branch

Lesson 08, plus the shape of teams. Conway's law (systems copy the communication structure of the organisation that builds them), communication paths that grow much faster than headcount, the four Team Topologies team types, and cognitive load — how much one team can hold in its head. topologies() in lead/demo.py; paths(), handoffs() and cognitive_load() in lead/models.py.

🧒 Explain like I'm 5

The school grows. Katrina's department now has 12 teachers, and they all sit in one big staff meeting. 🗣️ Everyone needs to talk to everyone. With 12 people, that is 66 different pairs who might need to talk!

So the school splits the teachers. First idea: by job type — one group writes the questions, one group prints the papers, one group marks them. But now every new exam needs all three groups. Each one waits for the others. 🐌

Second idea: by year group. The Year 7 team does everything for Year 7 — questions, printing, marking. A new Year 7 exam needs only the Year 7 team. 🎯

And the photocopier, the paper and the printing rules? A small support team looks after those, and makes them so easy to use that the year teams just use them — no waiting.

Katrina notices something else: the way the school splits its teachers ends up being the way its exams are organised. The shape of the people becomes the shape of the work.

🗺️ Diagram

flowchart LR
    o["👥 one team of 12<br/>66 communication paths"] --> t["two teams of 6<br/>30 paths + one interface"]
    c["🧱 component teams<br/>frontend · backend · data · platform"] --> c1["team-waits 14<br/>5/6 features need >1 team"]
    s["🎯 stream-aligned + platform"] --> s1["team-waits 9 · 3/6"]
    ss["🛠️ stream-aligned + SELF-SERVICE platform"] --> s2["team-waits 5 · 0/6"]
    l["🧠 cognitive load<br/>grades team 4 · 'everything' team 10"]

🗺️ Drawn version + a lab: https://school-edh.pages.dev/engineering-leadership/lesson-diagrams.html#l09

❓ What

Conway's law — Melvin Conway (1968): organisations design systems that mirror their own communication structure. (An old joke puts it this way: four teams building a compiler will produce a four-pass compiler.) The inverse Conway manoeuvre: shape the teams deliberately for the system architecture you want.
Communication paths — in a group of n people there are n(n−1)/2 possible pairs. Fred Brooks used this in The Mythical Man-Month (1975) to explain why adding people to a late project can make it later ("Brooks's law" — a rule of thumb, not a measured law).
Team Topologies — Matthew Skelton and Manuel Pais (2019) describe four team types: stream-aligned (owns a flow of work for a user or business area, end to end) · platform (provides internal services that stream-aligned teams use on their own) · enabling (specialists who help other teams learn a capability, then step back) · complicated-subsystem (owns a part that needs deep specialist knowledge). And three interaction modes: collaboration, X-as-a-Service, facilitating.
Component teams — teams split by technical layer (frontend, backend, database). Most features cross every layer, so most features need several teams.
Cognitive load — from John Sweller's work on learning: the mental effort a task needs. Team Topologies applies it to teams: give a team only as many domains as it can understand well — roughly, one complex domain, or a few simpler ones. This lab scores domains simple 1 · complicated 2 · complex 3 — a crude teaching scale.

🤔 Why

Because many delivery problems that look like engineering problems are team-shape problems: features that need four teams, queues of tickets between them, and a system whose seams sit exactly where the org chart's do. A lead often has more influence over team boundaries and ownership than she thinks — and changing them can remove waiting that no process improvement would touch.

🔧 How (in this repo)

paths(n) in lead/models.py is n(n−1)/2. handoffs(features, owner, self_service=()) takes the components each feature touches and the team that owns each component, and returns the teams each feature must wait for — skipping teams listed as self_service, whose platform can be used without waiting for them. cognitive_load(domains) adds up the domain scores. topologies() in lead/demo.py runs six features against three org designs. The model assumes one owner per component and that self-service really works: a thinking tool, not a formula for people.

🧪 Try it

python3 lead/demo.py topologies
python3 - <<'EOF'
import sys; sys.path.insert(0, "lead"); from models import paths, handoffs
for n in (3, 5, 7, 9, 12, 20):
    print(f"team of {n:>2} → {paths(n):>3} paths")
feats = {"predicted grades": ["grades-ui", "grades-api", "grades-db"], "parent SSO login": ["auth", "parents-ui"]}
owner = {"grades-ui": "frontend", "grades-api": "backend", "grades-db": "data", "auth": "platform", "parents-ui": "frontend"}
for f, teams in handoffs(feats, owner).items():
    print(f"{f} waits for: {teams}")
EOF

✅ Verify — what you should see

topologies prints:

── one team of 12: 66 communication paths · two teams of 6: 30 paths inside teams, plus one agreed interface between them
   component teams (frontend/backend/data/platform)   team-waits 14 · features needing >1 team 5/6
   stream-aligned teams + a platform team             team-waits  9 · features needing >1 team 3/6
   stream-aligned + a SELF-SERVICE platform           team-waits  5 · features needing >1 team 0/6
   cognitive load (simple 1 · complicated 2 · complex 3): grades team         4 across 2 domains
   cognitive load (simple 1 · complicated 2 · complex 3): 'everything' team  10 across 5 domains

Your snippet prints:

team of  3 →   3 paths
team of  5 →  10 paths
team of  7 →  21 paths
team of  9 →  36 paths
team of 12 →  66 paths
team of 20 → 190 paths
predicted grades waits for: ['frontend', 'backend', 'data']
parent SSO login waits for: ['platform', 'frontend']

🏁 What you just proved

Paths grow much faster than people: 5 people have 10 pairs, 12 have 66, 20 have 190. Splitting 12 into two teams of 6 leaves 30 paths plus one interface to agree on. With component teams, 5 of 6 features needed more than one team (14 team-waits in total); stream-aligned teams cut that to 3 of 6; and a self-service platform — one you use without filing a ticket — brought it to 0 of 6. Meanwhile an "everything" team carrying five domains had a load score of 10, against 4 for a focused grades team.

⚠️ Common mistakes

reorganising on the org chart without changing ownership of the code and systems
a "platform team" that is really a ticket queue — then it adds waits instead of removing them
giving one team every domain nobody else wants
splitting teams by technical layer and then wondering why every feature needs a meeting
treating Team Topologies' four types as boxes to fill, rather than as a vocabulary
growing one team past the point where everyone can still talk to everyone

🏭 In production

Write the ownership down, so Conway's law works for you. A service catalogue entry:

# catalog-info.yaml — one per service (this layout follows Backstage's format)
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: gradebook-api
spec:
  type: service
  owner: team-grades          # a stream-aligned team
  lifecycle: production
  system: grades

A team API — how other teams work with you — is Team Topologies' suggestion for making interaction modes explicit:

## Team Grades — team API
- We own: gradebook-api, gradebook-ui, grades-db
- Ask us: #team-grades, or an issue on the gradebook repo (we answer within 1 working day)
- We use as-a-service: platform CI, auth, notifications
- Collaborating now (until week 20): the platform team, on the new storage service

Check the shape against reality every quarter: which features needed more than one team, and how long did they wait? The System Design school covers the architecture side of the same boundaries.

🏭 Why this matters in production: before you add a process to fix slow delivery, count how many teams a typical feature needs. If the answer is three or four, change ownership or build a self-service platform — the org chart is part of the architecture.

⏭️ Next

Well-shaped teams still have bad days. Next: leading through incidents and hard decisions — and telling the reversible ones from the irreversible.

git checkout lesson-10-incidents-decisions

← Previousdelivery metrics Next →incidents decisions

This page is the lesson's README from the lesson-09-team-topologies branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.