Engineering team चे नेतृत्व, मुख्याध्यापिकेचे कार्यालय म्हणून शिकवलेले: कतरिना, एक उत्तम गणित शिक्षिका, गणित विभागाची विभागप्रमुख होते — आणि तिला समजते की आता तिचे काम तिचे स्वतःचे तास नव्हे, तर संपूर्ण विभाग आहे. प्रत्येक धडा ही एक शाळेतील गोष्ट आहे, त्यासोबत काढलेली आकृती आणि एक lab — आणि हे कार्यालय repo मध्येच आहे: शुद्ध Python मधील deterministic models (lead/models.py, शून्य dependencies). प्रत्येक model विचार करण्याचे साधन आहे, माणसांसाठीचे सूत्र नाही.
# the 60-second wow — one department, twelve lessons:
git clone https://github.com/BaluRaut/learn-engineering-leadership-school.git && cd learn-engineering-leadership-school
python3 lead/demo.py # 12 lessons: calendars, feedback, forecasts, debt, metrics, on-call
python3 lead/test_lead.py # 12 checks across the lessons
तुम्हाला काय दिसायला हवे (छाटलेले — यश असे दिसते):
═══ calendar ═══
── Katrina's 40-hour week (09:00–17:00, half-hour slots) · 'focus' = free time in blocks of 2 h or more
as a teacher (engineer) meetings 5.0 h · free 35.0 h · focus 30.5 h in 6 blocks · fragments 4.5 h
as head of maths, scattered meetings 12.5 h · free 27.5 h · focus 14.5 h in 6 blocks · fragments 13.0 h
as head of maths, clustered meetings 12.5 h · free 27.5 h · focus 25.0 h in 10 blocks · fragments 2.5 h
the lead's meetings by kind: standup 2.5 h · 1:1 2.5 h · planning 1 h · hiring 2 h · sync 1 h · review 2 h · roadmap 1.5 h
same 12.5 meeting hours, moved to the afternoons → the fragments become mornings you can think in
the job moved: fewer hours making things yourself, more hours making the department work — protect some maker time on purpose
═══ oneonones ═══
── feedback as a judgement → missing ['situation', 'impact'] · judgement words ['attitude', 'never']
── feedback as SBI → missing nothing · judgement words none
SBI names a moment, an observable behaviour and its effect — something Dipika can check, and change
── weekly 1:1 tracker, 12 weeks:
Dipika held 11/12 · longest run missed 1 · weeks since last 0
Aishwarya held 12/12 · longest run missed 0 · weeks since last 0
Meera held 10/12 · longest run missed 1 · weeks since last 0
Leela held 5/12 · longest run missed 4 · weeks since last 4 ← overdue: talk this week
the quietest person, newest to the team, is the one whose 1:1s get moved — the tracker makes that visible
═══ delegation ═══
── who can do each job without help (level 2+ of 3):
gradebook 3 · Katrina, Dipika, Aishwarya
release 1 · Katrina
database 2 · Katrina, Aishwarya
frontend 3 · Katrina, Dipika, Meera
runbooks 1 · Katrina
bus factor 1 · if Katrina is out: ['release', 'runbooks'] have nobody
── after a quarter of pairing (Dipika runs releases, Aishwarya owns runbooks, Meera learns the database) → bus factor 2
── RACI check: weekly release: 2 accountable (Katrina, Dipika) · weekly release: nobody responsible · gradebook migration: 0 accountable (nobody)
delegation level for 'which test framework the gradebook uses': 7 delegate
delegation level for 'the exam-week release freeze': 4 agree
delegation level for 'the hiring bar': 3 consult
delegate the outcome and the authority, not just the task — and say which level you mean
═══ hiring ═══
── one candidate, rubric of 4 competencies (anchored 1–4), bar 3.0 · scores written BEFORE the debrief:
independent: Katrina 3.75 · Dipika 2.25 · Aishwarya 2.50 → panel 2.83 → no hire
after Katrina speaks first (others move halfway to her): Katrina 3.75 · Dipika 3.00 · Aishwarya 3.12 → panel 3.29 → hire
same evidence, a different decision — written independent scores keep each interviewer's evidence in the room
── calibration on 5 past panels: Katrina +0.37 · Dipika -0.33 · Aishwarya -0.03
candidate X (Katrina + Aishwarya): raw 3.25 → calibrated 3.08
candidate Y (Dipika + Aishwarya): raw 3.00 → calibrated 3.18
different panels, different habits: a lenient panel can outrank a stronger candidate — 5 panels is a small sample, so treat offsets as a prompt, not a correction
═══ forecast ═══
── the last 10 weeks' throughput (items finished): [2, 6, 1, 4, 7, 0, 5, 3, 6, 3] · average 3.7/week · backlog 40 items
the single-date guess: 40 ÷ 3.7 ≈ 11 weeks
Monte Carlo, 10,000 seeded trials replaying random past weeks → 50%: 11 weeks · 85%: 13 weeks · 95%: 15 weeks
chance of finishing within the guess (11 weeks): 58%
── the backlog grows 20% (40 → 48 items) → 50%: 13 weeks · 85%: 16 weeks
give a range with a probability, and re-forecast every week as the history and the backlog change
═══ priorities ═══
── RICE = reach × impact × confidence ÷ effort (reach: people a quarter · effort: person-months)
exam results page 1500 × 1 × 80% ÷ 2 = 600
parent portal login 2000 × 2 × 50% ÷ 4 = 500
gradebook export fix 400 × 1 × 80% ÷ 1 = 320
timetable rewrite 300 × 3 × 50% ÷ 6 = 75
raise the portal's confidence from 50% to 80% → 800, and it jumps to first — the ranking is only as good as that guess
── cost of delay (value lost per week) and duration (weeks): gradebook export fix 5/1 · exam results page 6/2 · parent portal login 8/4 · timetable rewrite 3/6
biggest value first: parent portal login → exam results page → gradebook export fix → timetable rewrite → total delay cost 142
CD3 (cost of delay ÷ duration): gradebook export fix → exam results page → parent portal login → timetable rewrite → total delay cost 118
write the numbers down so people argue with the assumptions, not with each other
═══ debt ═══
── technical debt as a portfolio: principal = hours to fix · interest = hours lost every week (a flat-interest model)
horizon 26 weeks:
flaky test suite principal 24 h · interest 6 h/wk · pays back in 4.0 wk · net +132 h → pay
manual release steps principal 40 h · interest 5 h/wk · pays back in 8.0 wk · net +90 h → pay
tangled gradebook core principal 200 h · interest 4 h/wk · pays back in 50.0 wk · net -96 h → carry
old report module principal 120 h · interest 1 h/wk · pays back in 120.0 wk · net -94 h → carry
horizon 104 weeks:
flaky test suite principal 24 h · interest 6 h/wk · pays back in 4.0 wk · net +600 h → pay
manual release steps principal 40 h · interest 5 h/wk · pays back in 8.0 wk · net +480 h → pay
tangled gradebook core principal 200 h · interest 4 h/wk · pays back in 50.0 wk · net +216 h → pay
old report module principal 120 h · interest 1 h/wk · pays back in 120.0 wk · net -16 h → carry
total interest 16 h/week out of a team's 160 h/week (10%) — paid every week, whether or not anyone decides to
pay the high-interest, low-principal debt first; carry debt in code nobody touches; re-price when plans change
═══ metrics ═══
── 4 weeks of deploys (the four keys, plus reliability):
deployment frequency 4.5/week · lead time for changes (median) 18 h · change failure rate 16.7% · failed-deploy recovery (median) 45 min · availability 99.52%
── target 'change failure rate under 10%' → two failures relabelled 'planned hotfix' → CFR 5.6% · availability still 99.52%
── target 'deploy more' → 18 config-only no-op deploys added → frequency 9.0/week · median lead time 1.8 h · users see nothing new
Goodhart's law, in Marilyn Strathern's words: when a measure becomes a target, it ceases to be a good measure
── flow: cycle times [5, 8, 2, 12, 3, 10] days · flow efficiency 40% (the rest is waiting) — use metrics to ask questions of the system, never to rank people
═══ 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
Conway's law: the system's shape copies the org's communication shape — so design the teams for the system you want
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
team types: stream-aligned · platform · enabling · complicated-subsystem
═══ incidents ═══
── roll back last night's gradebook release two-way door → decide now, the owner decides, log it, set a revisit date
── try a new standup format for 2 weeks two-way door → decide now, the owner decides, log it, set a revisit date
── move the gradebook from MySQL to PostgreSQL one-way door → slow down: write it up, consult, name a decider and a deadline
── sign a 3-year contract for a marking tool one-way door → slow down: write it up, consult, name a decider and a deadline
decision log: 3 entries · due for review by week 8: ['new standup format', 'freeze releases in exam week']
── incident, mitigate first (roll back) detected after 6 min · users hurt for 15 min
── incident, debug forward (find and fix) detected after 6 min · users hurt for 52 min
roles: Katrina is incident commander (coordinates, does not debug) · Dipika operates · Aishwarya writes the updates
afterwards: a blameless review — what made the mistake easy, not who made it
═══ writing ═══
── weekly status meeting, 8 people × 60 min → 368 person-hours a year (46 working weeks)
written status update: 30 min to write + 8 × 5 min to read → 54 person-hours a year — and it can be searched later
a 30-minute decision meeting of 6 → 3.0 person-hours; worth it when the decision needs a live argument
── Dipika's first design doc has 3 sections · missing: goals, non-goals, options considered, risks, open questions
options considered and non-goals are where a reviewer finds the problem cheaply — before the code exists
a status update: what changed · what is at risk · what I need from you (the ask comes first)
═══ growth ═══
── on-call, 13 weeks, rotation of 3: Katrina 5 wk / 7 after-hours pages · Dipika 4 wk / 3 after-hours pages · Aishwarya 4 wk / 9 after-hours pages
── on-call, 13 weeks, rotation of 5: Katrina 3 wk / 5 after-hours pages · Dipika 3 wk / 3 after-hours pages · Aishwarya 3 wk / 6 after-hours pages · Meera 2 wk / 1 after-hours pages · Leela 2 wk / 4 after-hours pages
weeks with more than 2 after-hours pages land on: ['Katrina', 'Aishwarya'] — a burnout signal to act on, not a badge
── visible opportunities in 6 months: Dipika 5 · Aishwarya 1 · Meera 0 · Leela 0 — sponsorship follows familiarity unless you track it
career ladder: expectations per level, in writing · psychological safety: people can say 'I broke it' and 'I disagree'
── the whole picture: protect the week → 1:1s and SBI → delegate the outcome → hire with a rubric → forecast in ranges → price the order → carry debt on purpose → measure the system → shape the teams → decide by the door → write it down → keep people growing and rested
✅ done — the department runs
संपूर्ण कोर्स एका कॅनव्हासवर. 4K आवृत्तीसाठी क्लिक करा.
एक git branch = एक कल्पना; branch 04 मध्ये धडे 01–04 आहेत. lead/ चा प्रत्येक run सारखाच असतो — randomness seeded आहे.
lesson-01-from-engineer-to-leadधडा वाचा →आकृती पहा ↗lesson-02-one-on-onesधडा वाचा →आकृती पहा ↗lesson-03-delegationधडा वाचा →आकृती पहा ↗lesson-04-hiringधडा वाचा →आकृती पहा ↗काम कधी पूर्ण होईल, आधी काय करायचे, कोणते debt फेडायचे, आणि मोजमाप न बिघडवता delivery कशी मोजायची.
lesson-05-forecastingधडा वाचा →आकृती पहा ↗lesson-06-prioritisationधडा वाचा →आकृती पहा ↗lesson-07-technical-debtधडा वाचा →आकृती पहा ↗lesson-08-delivery-metricsधडा वाचा →आकृती पहा ↗Teams ची रचना, कठीण प्रसंग, lead ची पोहोच म्हणून लेखन, आणि पुढच्या वर्षीही निरोगी असलेली team.
lesson-09-team-topologiesधडा वाचा →आकृती पहा ↗lesson-10-incidents-decisionsधडा वाचा →आकृती पहा ↗lesson-11-writingधडा वाचा →आकृती पहा ↗lesson-12-growthधडा वाचा →आकृती पहा ↗प्रत्येक धडा एका क्रमांकित बॉक्स-आणि-बाण आकृतीत — स्वतंत्र पानावरही.
आठवड्याचे तास कुठे जातात — maker विरुद्ध manager वेळ, आणि आता काम म्हणजे team चे output का आहे.
कतरिना सर्वात चांगली गणित शिक्षिका होती. आता ती गणित विभागप्रमुख आहे. दिवसभर लोक तिचे दार ठोठावतात. तिच्या meetings विखुरलेल्या आहेत, म्हणून तिला विचार करायला मोठा शांत वेळ मिळत नाही. ती त्याच meetings दुपारी हलवते. आता प्रत्येक सकाळ एक मोठा शांत वेळ असते. आता संपूर्ण विभाग किती चांगले शिकवतो, हेच तिचे काम आहे.
शिक्षिका असताना कतरिनाला आठवड्यात 5.0 h meetings होत्या आणि नियोजन व तपासणीसाठी 30.5 h चा मोठा focus time मिळायचा.
आता ती गणित विभागप्रमुख आहे, आणि तिच्या 12.5 h meetings आहेत: standups, 1:1s, hiring, planning, reviews आणि roadmap.
विखुरलेल्या meetings मुळे 14.5 h focus आणि 13.0 h तुकडे उरतात; दुपारी एकत्र केल्यावर focus 25.0 h होतो.
आता विभागाचे काम हेच तिचे काम आहे, म्हणून ती संध्याकाळी काम करण्याऐवजी maker time जाणीवपूर्वक जपते.
पुढचा धडा: साप्ताहिक 1:1, दीपिकाला वापरता येईल असा feedback, आणि लीलाला वगळले जात आहे हे दाखवणारा tracker.
Report ची मालकी असलेल्या 1:1s, situation-behaviour-impact स्वरूपातील feedback, आणि कोण वगळले जाते ते दाखवणारा tracker.
कतरिना दर आठवड्याला प्रत्येक शिक्षिकेला अर्धा तास एकटीने भेटते. एके दिवशी तिला दीपिकाला सांगायचे असते की तिचा attitude वाईट आहे. पण डोक्यातल्या अंदाजावर दीपिका काहीच करू शकत नाही. म्हणून कतरिना सांगते कोणती meeting, दीपिकाने काय केले, आणि त्यामुळे काय झाले. आता काय बदलायचे हे दीपिकाला नेमके कळते. कतरिनाच्या यादीतून हेही दिसते की लीला चार आठवडे वगळली गेली आहे.
कतरिनाला दीपिकाला सांगायचे होते की तिचा attitude वाईट आहे आणि ती कधीच ऐकत नाही: क्षण किंवा परिणाम नसलेला निष्कर्ष.
SBI feedback म्हणजे situation, दिसणारे behaviour आणि त्याचा impact सांगणे; 1:1 हा त्या शिक्षिकेचा स्वतःचा साप्ताहिक वेळ आहे.
त्या निष्कर्षात situation आणि impact नाहीत, आणि 'attitude', 'never' हे शब्द आहेत; SBI note मध्ये काहीच कमी नाही.
दीपिका एखादे behaviour तपासू आणि बदलू शकते. Tracker दाखवतो की लीलाच्या 12 पैकी फक्त 5 1:1 झाल्या, शेवटची 4 आठवड्यांपूर्वी.
पुढचा धडा: प्रत्येक काम एकटीने कोण करू शकते, bus factor 1, आणि निर्णयाच्या अधिकारासह काम सोपवणे.
Delegation चे सात स्तर, नेमका एकच Accountable असलेले RACI, आणि team च्या कौशल्यांमधील bus factor.
कतरिना प्रत्येक काम आणि ते मदतीशिवाय कोण करू शकते याची यादी करते. दोन कामांसमोर एकच नाव आहे: तिचे. ती आजारी पडली तर ती कामे थांबतात. म्हणून ती कामे सोपवते. दीपिका releases शिकते, ऐश्वर्या runbooks घेते, मीरा database शिकते. एका सत्रानंतर प्रत्येक कामाला किमान दोन जणी आहेत. किती अधिकार देत आहे हेही ती स्पष्ट सांगते.
Release चालवणे किंवा runbooks वापरणे फक्त कतरिनाला जमायचे, म्हणून ती एक आठवडा आजारी पडली तर दोन्ही कामे थांबली असती.
Bus factor म्हणजे कोणत्याही आवश्यक कौशल्याच्या सर्वात कमी धारक; RACI प्रत्येक कामाला एकच Accountable मालक देते.
Level 2+ चे धारक: gradebook 3, release 1, database 2, frontend 3, runbooks 1, म्हणून bus factor 1 आहे.
एका तिमाहीच्या pairing नंतर दीपिका releases चालवते, ऐश्वर्या runbooks सांभाळते आणि मीरा database शिकते: bus factor 2.
पुढचा धडा: hiring, जिथे तीन interviewers एका उमेदवाराला गुण देतात आणि आधी बोलणारी व्यक्ती निर्णय उलटवू शकते.
एक structured rubric, debrief आधी लिहिलेले गुण, आणि मुलाखतकारांमधील calibration.
तीन शिक्षिका एका उमेदवाराला शिकवताना पाहतात. Meeting मध्ये कतरिना आधी बोलते आणि खूप खात्रीने बोलते. दीपिकाला खरी शंका होती, पण ती कतरिनाच्या मागे जाते. उमेदवार निवडली जाते आणि ती शंका हरवते. पुढच्या वेळी सगळ्या एकच score sheet वापरतात आणि आधी आपले गुण लिहून ठेवतात. आता त्याच मतांमधून प्रामाणिक उत्तर येते: no hire.
Debrief मध्ये कतरिना आधी बोलली, बाकीच्या तिच्याकडे झुकल्या, आणि दीपिकाची खरी शंका कधी समोरच आली नाही.
Structured interview: 4 competencies ची तीच anchored rubric, 3.0 चा bar, आणि बोलण्याआधी लिहून ठेवलेले गुण.
आधी लिहिल्यावर panel ची सरासरी 2.83: no hire. कतरिना आधी बोलल्यावर बाकीच्या अर्ध्या सरकतात आणि ती 3.29 होते: hire.
पुरावा तोच, निर्णय वेगळा. Calibration दाखवते की panel च्या सरासरीपेक्षा कतरिना +0.37 आणि दीपिका -0.33 आहे.
पुढचा धडा: मुख्याध्यापिका विचारतात की 40 कामे कधी पूर्ण होतील, आणि सरासरीवरून काढलेली एक तारीख म्हणजे नाणेफेक.
मागील throughput वरून seeded Monte Carlo अंदाज — एका अंदाजाऐवजी 50% आणि 85% तारखा.
मुख्याध्यापिका विचारतात की 40 कामे कधी पूर्ण होतील. विभाग सरासरी आठवड्याला 3.7 कामे पूर्ण करतो, म्हणून सोपे उत्तर 11 आठवडे. पण काही आठवडे हळू जातात. कतरिना मागचे दहा आठवडे कार्डांवर लिहिते आणि ती यादृच्छिकपणे पुन्हा पुन्हा, 10,000 वेळा काढते. अर्धे खेळ 11 आठवड्यांत संपतात, आणि 100 पैकी 85 खेळ 13 आठवड्यांत.
कतरिनाने 40 कामांच्या backlog ला आठवड्याच्या 3.7 सरासरीने भागले आणि जवळपास 11 आठवडे असे वचन जाहीर केले.
Monte Carlo forecast मागचे आठवडे [2, 6, 1, 4, 7, 0, 5, 3, 6, 3] यादृच्छिकपणे पुन्हा खेळतो, backlog संपेपर्यंत.
10,000 seeded trials देतात 50%: 11 आठवडे, 85%: 13 आठवडे, 95%: 15 आठवडे; 11 आठवड्यांत फक्त 58% पूर्ण होतात.
संभाव्यतेसह दिलेली range प्रामाणिक असते. Backlog 48 कामांपर्यंत वाढला की forecast 13 आणि 16 आठवड्यांवर जातो.
पुढचा धडा: चार कामे एका टीमची वाट पाहतात, आणि निवडलेल्या क्रमानुसार थांबण्यात किती मूल्य जाते ते बदलते.
RICE, cost of delay आणि CD3/WSJF — गृहीतके अशा ठिकाणी लिहिलेली की लोक त्यावर वाद घालू शकतील.
चार कामे वाट पाहत आहेत, आणि विभाग एका वेळी एकच करू शकतो. एक शिक्षिका म्हणते सर्वात मोठे, मौल्यवान काम आधी करा. कतरिना विचारते की काम थांबले तर दर आठवड्याला किती नुकसान होते. छोटा export fix आठवड्याला 5 गमावतो आणि 1 आठवडा घेतो, म्हणून तो आधी. मोठे आधी केल्यास एकूण 142 जाते. तिच्या क्रमाने फक्त 118.
प्रत्येकजण आपल्या आवडत्या कामासाठी भांडत होती, आणि सर्वात मोठा आवाज म्हणाला सर्वात मोठे, मौल्यवान काम आधी करा.
RICE म्हणजे reach × impact × confidence ÷ effort; cost of delay विचारते की काम थांबले तर दर आठवड्याला किती मूल्य जाते.
RICE क्रम: results 600, portal 500, fix 320, timetable 75; portal चा confidence 80% केला तर तो 800 होतो.
सर्वात मोठे मूल्य आधी केल्यास 142 जाते; CD3, म्हणजे cost of delay ÷ duration, केल्यास 118. कामे तीच, फक्त चांगला क्रम.
पुढचा धडा: जुना गोंधळलेला code म्हणजे कर्ज, दुरुस्तीचे principal आणि दर आठवड्याला भरावे लागणारे interest.
Debt म्हणजे portfolio: मुद्दल, साप्ताहिक व्याज, परतफेड, आणि कोणते debt जाणूनबुजून बाळगायचे.
विभागात जुन्या, गोंधळलेल्या गोष्टी आहेत. Flaky tests दर आठवड्याला 6 तास वाया घालवतात आणि दुरुस्तीला 24 तास लागतात, म्हणून 4 आठवड्यांत ते वसूल होते. Old report module आठवड्याला 1 तास वाया घालवते पण दुरुस्तीला 120 तास लागतात. कतरिना ते सध्या तसेच ठेवते. दर आठवड्याला वेळ चोरणारा गोंधळ कोणी ठरवो वा न ठरवो, किंमत घेतोच.
जुना गोंधळ एकतर त्रास होईपर्यंत दुर्लक्षित राहायचा किंवा एकदम सगळा पुन्हा लिहिला जायचा, तुलना करायचा मार्ग नव्हता.
Technical debt एक portfolio म्हणून: principal म्हणजे दुरुस्तीचे तास, interest म्हणजे थांबल्यावर दर आठवड्याला जाणारे तास.
26 आठवड्यांत flaky tests (24 h, 6 h/wk) चा net +132 h: pay. Old report module (120 h, 1 h/wk) चा net -94 h: carry.
दर आठवड्याला 16 h interest भरले जाते, टीमच्या 160 h चे 10%, कोणी ठरवो वा न ठरवो.
पुढचा धडा: four keys ने delivery मोजणे, आणि एखादे माप target बनले की काय होते.
DORA four keys आणि reliability, flow metrics — आणि Goodhart's law एखाद्या target चे काय करतो.
मुख्याध्यापिका मोजतात की नवे काम किती वेळा जाते आणि किती वेळा चुकते. उपयोगी! मग त्या म्हणतात 10 पैकी 1 पेक्षा कमी चुका हव्यात. लोक चुकांना planned changes म्हणू लागतात, आणि आकडा 17% वरून 6% वर येतो. काहीच सुधारले नाही. कतरिना आकड्यांचा वापर कामाबद्दल प्रश्न विचारण्यासाठी करते, शिक्षिकांची क्रमवारी लावण्यासाठी कधीच नाही.
Process मधले बदल विभागाला मदत करतात का हे कोणालाच माहीत नव्हते, म्हणून प्रत्येक meeting मध्ये मतांनीच जागा भरली.
DORA four keys आणि reliability: deploy frequency, lead time, change failure rate, recovery आणि availability.
4 आठवड्यांत 18 deploys: 4.5/week, median lead time 18 h, change failure rate 16.7%, recovery 45 min, 99.52% up.
Target बनल्यावर failures चे नाव बदलून CFR 5.6% दिसतो आणि 18 no-op deploys ने 9.0/week दिसते, पण users ना नवे काहीच मिळत नाही.
पुढचा धडा: टीम्सची विभागणी त्या बनवत असलेल्या system ला कसा आकार देते, आणि 12 लोकांचे 66 मार्ग का होतात.
Conway's law, संवादाचे मार्ग, चार team प्रकार आणि cognitive load.
शाळेत 12 शिक्षिका होतात, आणि 12 जणींमध्ये बोलू शकणाऱ्या 66 जोड्या असतात. आधी त्या कामाच्या प्रकारानुसार विभागतात, आणि प्रत्येक परीक्षेला सगळे गट लागतात. मग त्या इयत्तेनुसार विभागतात, म्हणून इयत्ता 7 च्या परीक्षेला फक्त इयत्ता 7 ची टीम लागते. एक छोटी support team सामायिक साधने वापरायला सोपी करते. लोकांचा आकारच कामाचा आकार बनतो.
टीम technology layer नुसार विभागलेली होती, म्हणून प्रत्येक feature ला frontend, backend आणि data ची meeting लागायची.
Conway's law: system त्याच्या संस्थेच्या संवादाचा आकार घेते. 12 जणांच्या टीमचे 66 मार्ग; 6 च्या दोन टीम्सचे 30.
Component teams मध्ये 14 team-waits आणि 6 पैकी 5 features ना एकापेक्षा जास्त टीम; self-service platform मध्ये 5 आणि 0.
Stream-aligned teams बहुतेक features एकाच टीममध्ये ठेवतात, आणि cognitive load 4 राहतो, 5 domains मध्ये 10 नाही.
पुढचा धडा: परीक्षेच्या सकाळी gradebook बिघडते, आणि काही निर्णय असे दरवाजे असतात जिथून परत येता येत नाही.
आधी परिणाम कमी करा, incident मधील भूमिका, one-way विरुद्ध two-way doors, आणि निर्णयांची नोंदवही.
परीक्षेची सकाळ: नवे gradebook प्रत्येक गुण शून्य दाखवते. सगळ्या bug शोधायला गर्दी करतात. कतरिना प्रत्येकीला एक काम देते. दीपिका कालचे version परत आणते, आणि ऐश्वर्या पालकांना काय चालले आहे ते सांगते. Service 52 नाही तर 15 मिनिटांत परत येते. नंतर कतरिना सहज उलटता येणारे निर्णय पटकन घेते आणि कठीण निर्णय सावकाश.
काही बिघडले की सगळ्या मिळून bug शोधायच्या, आणि प्रत्येक निर्णय एकाच वेगाने व्हायचा.
आधी mitigate करा, incident roles स्पष्ट ठेवा, आणि निर्णयांची two-way doors आणि one-way doors अशी विभागणी करा.
6 min नंतर कळल्यावर rollback मुळे users ना 15 min त्रास होतो; पुढे debug करत राहिल्यास 52 min.
Standup चा प्रयोग two-way door आहे, लगेच ठरवा; 3 वर्षांचा contract one-way आहे. Log आठवडा 8 पर्यंत 2 reviews दाखवतो.
पुढचा धडा: लेखन हीच lead ची पोहोच, design docs पासून ask आधी मांडणाऱ्या status update पर्यंत.
Design docs आणि RFCs, मागणी आधी मांडणारे status updates, आणि एका meeting ची किंमत.
दर सोमवारी 8 शिक्षिका आपण काय केले हे सांगायला एक तास भेटतात. वर्षात ते 368 तास होतात. म्हणून कतरिना दर शुक्रवारी एक छोटी नोंद लिहिते: काय बदलले, काय चुकू शकते, आणि तिला काय हवे आहे. त्याला वर्षाला सुमारे 54 तास लागतात, आणि कोणालाही ती नंतर सापडते. दीपिका आधी आपला आराखडा लिहिते, आणि काहीही बनवण्याआधीच reviewer ला एक प्रश्न सापडतो.
दर सोमवारी सर्व 8 शिक्षिका मागच्या आठवड्याबद्दल सांगण्यासाठी एक तास भेटायच्या, बहुतेक वेळ आपल्या पाळीची वाट पाहत.
लिखित status updates आणि design docs, आणि meetings फक्त खऱ्या चर्चेची गरज असलेल्या निर्णयांसाठी.
ती meeting वर्षाला 368 person-hours घेते; लिखित update, 30 min लिहायला आणि 8 × 5 min वाचायला, 54 घेतो.
दीपिकाच्या पहिल्या design doc मध्ये 8 पैकी 3 sections आहेत; options considered आणि non-goals code आधीच प्रश्न पकडतात.
पुढचा धडा: दिसणाऱ्या संधी कोणाला मिळतात, रात्री page कोणाला होते, आणि lead च्या कामाचा संपूर्ण नकाशा.
Career ladders, sponsorship, psychological safety, on-call आणि कामाच्या वेळेनंतरचा भार — आणि संपूर्ण नकाशा.
वर्षाच्या शेवटी कतरिना दोन याद्या पाहते. दीपिकाला 5 मोठ्या संधी मिळाल्या, ऐश्वर्याला 1, मीरा आणि लीलाला एकही नाही. ऐश्वर्याला रात्री 9 वेळा फोन आला, आणि तिने कधीच तक्रार केली नाही. म्हणून कतरिना पुढच्या संधी ज्यांना मिळाल्या नाहीत त्यांना देते. ती रात्रीची यादी मोठी करते, म्हणजे कोणालाही ते ओझे एकटीने उचलावे लागू नये. चांगला विभाग पुढच्या वर्षीही निरोगी असतो.
कतरिनाला आधी आठवेल तिलाच संधी मिळायच्या, आणि रात्री page मुळे कोणाला उठावे लागले हे कोणी मोजत नव्हते.
Growth म्हणजे लिखित career ladder, नोंदवलेली sponsorship, psychological safety आणि योग्य on-call भार.
6 महिन्यांत दीपिकाला 5 संधी, ऐश्वर्याला 1, मीराला 0, लीलाला 0; 13 आठवड्यांत ऐश्वर्याला 9 after-hours pages.
5 जणांच्या rotation मुळे ऐश्वर्याचे pages 6 होतात; जड आठवडे burnout चा इशारा आहेत, आणि संधी जाणीवपूर्वक द्याव्यात.
यापुढे: SRE school incidents आणि on-call खोलवर शिकवते, आणि CI/CD school four keys मागच्या pipelines बनवते.