🏅 शाळेच्या पद्धतीने engineering leadership शिका

Engineering team चे नेतृत्व, मुख्याध्यापिकेचे कार्यालय म्हणून शिकवलेले: कतरिना, एक उत्तम गणित शिक्षिका, गणित विभागाची विभागप्रमुख होते — आणि तिला समजते की आता तिचे काम तिचे स्वतःचे तास नव्हे, तर संपूर्ण विभाग आहे. प्रत्येक धडा ही एक शाळेतील गोष्ट आहे, त्यासोबत काढलेली आकृती आणि एक lab — आणि हे कार्यालय repo मध्येच आहे: शुद्ध Python मधील deterministic models (lead/models.py, शून्य dependencies). प्रत्येक model विचार करण्याचे साधन आहे, माणसांसाठीचे सूत्र नाही.

🗓️ maker विरुद्ध manager वेळ💬 SBI feedback🤝 delegation चे स्तर🚌 bus factor🧑‍🏫 structured मुलाखती🎲 Monte Carlo अंदाज⚖️ cost of delay🧾 tech debt वरील व्याज📈 DORA four keys🧩 Team Topologies🚪 one-way doors🌱 sponsorship & on-call

🗓️ भाग 1 — नवे काम (1–4)

  • तास कुठे जातात 🗓️
  • 1:1s आणि SBI 💬
  • परिणाम सोपवा 🤝
  • rubric वापरून भरती करा 🧑‍🏫

🎲 भाग 2 — नियोजन आणि delivery (5–8)

  • पल्ल्यांमध्ये अंदाज करा 🎲
  • क्रमाची किंमत ठरवा ⚖️
  • debt म्हणजे portfolio 🧾
  • व्यवस्था मोजा 📈

🌱 भाग 3 — teams आणि वाढ (9–12)

  • teams ची रचना ठरवा 🧩
  • दाराकडे पाहून निर्णय घ्या 🚨
  • लिहून ठेवा ✍️
  • माणसांना वाढवा, त्यांना विश्रांती द्या 🌱
# 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
🎒 धडा 01 आधी: तुम्हाला फक्त Python 3 लागेल — बाकी काही नाही. हा lab म्हणजे deterministic शिकवणी models चा संच आहे, आणि प्रत्येक model विचार करण्याचे साधन आहे, माणसांसाठीचे सूत्र नाही: ते एखादे गृहीतक दृश्य करते म्हणजे तुम्ही त्यावर वाद घालू शकता; ते कधीही एखाद्या व्यक्तीचे मोजमाप करत नाही. जिथे संशोधन उपलब्ध आहे (DORA आणि Accelerate, Team Topologies, structured-interview अभ्यास) तिथे धडे त्याचा काळजीपूर्वक उल्लेख करतात. हा कोर्स कुठे बसतो: SRE शाळा incidents आणि on-call सखोल शिकवते, आणि CI/CD शाळा four keys मागचे pipelines बांधते.

🗺️ संपूर्ण चित्र — एक आकृती, पूर्ण कोर्स

संपूर्ण कोर्स एका कॅनव्हासवर. 4K आवृत्तीसाठी क्लिक करा.

The big picture: the new job (calendar, 1:1s and feedback, delegation, hiring), planning and delivery (forecasting, prioritisation, technical debt, delivery metrics) and teams and growth (team topologies, incidents and decisions, writing, growing people)

🗓️ भाग 1 — नवे काम (धडे 1–4)

एक git branch = एक कल्पना; branch 04 मध्ये धडे 01–04 आहेत. lead/ चा प्रत्येक run सारखाच असतो — randomness seeded आहे.

1

🗓️ Engineer पासून lead पर्यंत

आठवड्याचे तास कुठे जातात — maker विरुद्ध manager वेळ, आणि आता काम म्हणजे team चे output का आहे.lesson-01-from-engineer-to-leadधडा वाचा →आकृती पहा ↗
2

💬 1:1s आणि feedback

Report ची मालकी असलेल्या 1:1s, situation-behaviour-impact स्वरूपातील feedback, आणि कोण वगळले जाते ते दाखवणारा tracker.lesson-02-one-on-onesधडा वाचा →आकृती पहा ↗
3

🤝 Delegation आणि ownership

Delegation चे सात स्तर, नेमका एकच Accountable असलेले RACI, आणि team च्या कौशल्यांमधील bus factor.lesson-03-delegationधडा वाचा →आकृती पहा ↗
4

🧑‍🏫 भरती

एक structured rubric, debrief आधी लिहिलेले गुण, आणि मुलाखतकारांमधील calibration.lesson-04-hiringधडा वाचा →आकृती पहा ↗

🎲 भाग 2 — नियोजन आणि delivery (धडे 5–8)

काम कधी पूर्ण होईल, आधी काय करायचे, कोणते debt फेडायचे, आणि मोजमाप न बिघडवता delivery कशी मोजायची.

5

🎲 नियोजन आणि अंदाज

मागील throughput वरून seeded Monte Carlo अंदाज — एका अंदाजाऐवजी 50% आणि 85% तारखा.lesson-05-forecastingधडा वाचा →आकृती पहा ↗
6

⚖️ प्राधान्यक्रम

RICE, cost of delay आणि CD3/WSJF — गृहीतके अशा ठिकाणी लिहिलेली की लोक त्यावर वाद घालू शकतील.lesson-06-prioritisationधडा वाचा →आकृती पहा ↗
7

🧾 Technical debt

Debt म्हणजे portfolio: मुद्दल, साप्ताहिक व्याज, परतफेड, आणि कोणते debt जाणूनबुजून बाळगायचे.lesson-07-technical-debtधडा वाचा →आकृती पहा ↗
8

📈 Delivery metrics

DORA four keys आणि reliability, flow metrics — आणि Goodhart's law एखाद्या target चे काय करतो.lesson-08-delivery-metricsधडा वाचा →आकृती पहा ↗

🌱 भाग 3 — teams आणि वाढ (धडे 9–12)

Teams ची रचना, कठीण प्रसंग, lead ची पोहोच म्हणून लेखन, आणि पुढच्या वर्षीही निरोगी असलेली team.

9

🧩 Team topologies आणि Conway's law

Conway's law, संवादाचे मार्ग, चार team प्रकार आणि cognitive load.lesson-09-team-topologiesधडा वाचा →आकृती पहा ↗
10

🚨 Incidents आणि कठीण निर्णय

आधी परिणाम कमी करा, incident मधील भूमिका, one-way विरुद्ध two-way doors, आणि निर्णयांची नोंदवही.lesson-10-incidents-decisionsधडा वाचा →आकृती पहा ↗
11

✍️ लेखन

Design docs आणि RFCs, मागणी आधी मांडणारे status updates, आणि एका meeting ची किंमत.lesson-11-writingधडा वाचा →आकृती पहा ↗
12

🌱 माणसांची वाढ आणि संपूर्ण चित्र

Career ladders, sponsorship, psychological safety, on-call आणि कामाच्या वेळेनंतरचा भार — आणि संपूर्ण नकाशा.lesson-12-growthधडा वाचा →आकृती पहा ↗
🗣️ हे मोठ्याने समजावून सांगा — धडा 12 नंतर: (1) सारख्याच meeting तासांमुळे focus वेळ खूप वेगवेगळा का राहू शकतो? (2) SBI feedback चे तीन भाग कोणते? (3) bus factor 1 म्हणजे काय, आणि तो कसा वाढवायचा? (4) मुलाखतीचे गुण debrief आधी का लिहायचे? (5) "backlog ÷ average" हे जवळजवळ नाणेफेकीसारखे का आहे? (6) CD3 कशाच्या आधारे क्रम लावते? (7) technical debt फेडण्याऐवजी कधी बाळगावे? (8) वेगाच्या metric सोबत स्थिरतेचा metric का जोडावा? (9) Conway's law काय भाकीत करतो? (10) एखादा निर्णय one-way door कशामुळे ठरतो? (11) design doc चे कोणते दोन विभाग समस्या सर्वात स्वस्तात पकडतात?
🎓 याच शाळेतून: SRE · CI/CD · System Design · Observability — तेच उपमा-विश्व, तीच branch-दर-branch पद्धत.

📐 धड्यांच्या आकृत्या — क्रमांक अनुसरा

प्रत्येक धडा एका क्रमांकित बॉक्स-आणि-बाण आकृतीत — स्वतंत्र पानावरही.

1 🗓️ Engineer पासून lead पर्यंत

आठवड्याचे तास कुठे जातात — maker विरुद्ध manager वेळ, आणि आता काम म्हणजे team चे output का आहे.

🧒 सोप्या शब्दांत

कतरिना सर्वात चांगली गणित शिक्षिका होती. आता ती गणित विभागप्रमुख आहे. दिवसभर लोक तिचे दार ठोठावतात. तिच्या meetings विखुरलेल्या आहेत, म्हणून तिला विचार करायला मोठा शांत वेळ मिळत नाही. ती त्याच meetings दुपारी हलवते. आता प्रत्येक सकाळ एक मोठा शांत वेळ असते. आता संपूर्ण विभाग किती चांगले शिकवतो, हेच तिचे काम आहे.

📖 नवे शब्दmaker time — नियोजन किंवा लेखनासारखे अवघड काम स्वतः करण्यासाठी मोठे शांत तासfocus block — एका सलग तुकड्यात 2 तास किंवा जास्त मोकळा वेळ, विचार करण्याइतका मोठाfragment — दोन meetings मधली छोटी फट, अवघड काम सुरू करायला खूप लहानengineering lead — जिचे काम म्हणजे फक्त तिचे स्वतःचे नव्हे, तर संपूर्ण टीमचे काम
1🗓️ कतरिनाचा 40 तासांचा आठवडा, तीन प्रकारे (09:00–17:00, अर्ध्या तासाचे slots)शिक्षिका म्हणून (engineer)गोष्टी बनवण्यासाठी मोठे शांत blocksसोममंगळबुधगुरुशुक्र0910111213141516174 h2 h7 h5.5 h5 h7 hstandupstandupstandupstandupstandupनियोजन1:1reviewmeetings 5.0 तासतुकडे 4.5 तासfocus 30.5 तास, 6 blocks मध्येगणित विभागप्रमुख, विखुरलेलेजिथे slot रिकामा तिथे meetingsसोममंगळबुधगुरुशुक्र0910111213141516172.5 h2 h3 h2.5 h2 h2.5 hstandupstandupstandupstandupstandup1:11:11:11:11:1नियोजनभरतीभरतीsyncreviewreviewroadmapmeetings 12.5 hतुकडे 13.0 hfocus 14.5 h, 6 blocks मध्येगणित विभागप्रमुख, एकत्र गुंफलेलेत्याच meetings, दुपारी हलवलेल्यासोममंगळबुधगुरुशुक्र0910111213141516173 h2 h3 h2 h3 h2 h3 h2 h3 h2 hstandupstandupstandupstandupstandupनियोजन1:11:1भरती1:11:1syncreviewभरतीreview1:1roadmapmeetings 12.5 hतुकडे 2.5 hfocus 25.0 h, 10 blocks मध्येहिरवा = focus (2 h किंवा अधिकच्या blocks मधला मोकळा वेळ) · तुटक राखाडी = विचार करण्यास खूप लहान असलेले तुकडे2🧾 lead चे 12.5 meeting तास, प्रकारानुसारstandup2.5 h1:12.5 hनियोजन1 hभरती2 hsync1 hreview2 hroadmap1.5 hstandup, 1:1s,भरती, planning,reviews, roadmap:आता काम आहेसंपूर्णविभाग चालवणे3☀️ तेच meeting तास, हलवलेलेविखुरलेलेएकत्र गुंफलेलेfocus14.5 h25.0 hतुकडे13.0 h2.5 hदोन्ही आठवड्यांत meetings 12.5 h — फक्त त्यांची जागा बदललीतुकडे जोडून विचार करता येतील अशा सकाळी बनतातजाणीवपूर्वक काही maker time राखून ठेवा
⏪ आधी

शिक्षिका असताना कतरिनाला आठवड्यात 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.

🧪 इथे करून पाहा — कतरिनाचा आठवडा — एक मांडणी निवडा, meeting जोडण्यासाठी किंवा काढण्यासाठी अर्ध्या तासावर टॅप करा — हे विचार करण्याचे साधन आहे, माणसांसाठीचे सूत्र नाही
2

पूर्ण धडा 01 वाचा →

2 💬 1:1s आणि feedback

Report ची मालकी असलेल्या 1:1s, situation-behaviour-impact स्वरूपातील feedback, आणि कोण वगळले जाते ते दाखवणारा tracker.

🧒 सोप्या शब्दांत

कतरिना दर आठवड्याला प्रत्येक शिक्षिकेला अर्धा तास एकटीने भेटते. एके दिवशी तिला दीपिकाला सांगायचे असते की तिचा attitude वाईट आहे. पण डोक्यातल्या अंदाजावर दीपिका काहीच करू शकत नाही. म्हणून कतरिना सांगते कोणती meeting, दीपिकाने काय केले, आणि त्यामुळे काय झाले. आता काय बदलायचे हे दीपिकाला नेमके कळते. कतरिनाच्या यादीतून हेही दिसते की लीला चार आठवडे वगळली गेली आहे.

📖 नवे शब्द1:1 — lead आणि तिच्या टीममधील एका व्यक्तीची नियमित खासगी meeting; तो वेळ त्या व्यक्तीचा असतोSBI — तीन भागांतला feedback: situation, दिसलेले behaviour, आणि त्याचा impactjudgement — एखाद्याच्या स्वभावाबद्दलचा अंदाज, जसे 'attitude' किंवा 'never', ज्यावर ती काहीच करू शकत नाही
1💬 तीच काळजी, दोन प्रकारे सांगितलेलीKatrina✗ एक न्यायनिवाडा“दीपिका, meetings मध्ये तुझी वृत्ती वाईट असतेआणि तू कधीच ऐकत नाहीस.”गहाळ: प्रसंग · परिणामन्यायनिवाड्याचे शब्द: वृत्ती · कधीचकोणती meeting? तिने काय केले? “कधीच” वाद सुरू करतोKatrina✓ SBI — प्रसंग, वर्तन, परिणामSमंगळवारच्या planning meeting मध्ये…B…ऐश्वर्या marking चा अंदाज समजावतअसताना तू तिला दोनदा मध्येच थांबवलेस…I…ती बोलायची थांबली, आणि तिने ओळखलेला धोकाविचारात न घेता आम्ही planning केले.काहीही गहाळ नाही · न्यायनिवाड्याचे शब्द नाहीतएक क्षण, दिसणारे वर्तन आणि त्याचा परिणाम: दीपिका तपासू शकेल आणि बदलू शकेल असे काहीतरी2📅 साप्ताहिक 1:1 tracker — 12 आठवडे123456789101112आठवडाDipika✓✓✓✓✓✓✓✓✓✓✓झाल्या 11/12 · सलग सर्वाधिक चुकल्या 1 · शेवटच्या नंतरचे आठवडे 0Aishwarya✓✓✓✓✓✓✓✓✓✓✓✓झाल्या 12/12 · सलग सर्वाधिक चुकल्या 0 · शेवटच्या नंतरचे आठवडे 0Meera✓✓✓✓✓✓✓✓✓✓झाल्या 10/12 · सलग सर्वाधिक चुकल्या 1 · शेवटच्या नंतरचे आठवडे 0लीला✓✓✓✓✓झाल्या 5/12 · सलग सर्वाधिक चुकल्या 4 · शेवटच्या नंतरचे आठवडे 4सलग 4 चुकल्यालीला ← उशीर झाला: या आठवड्यात बोलासर्वात शांत, team मध्ये सर्वात नवी व्यक्ती — तिच्याच1:1s पुढे ढकलल्या जातात — tracker ते दाखवून देतो
⏪ आधी

कतरिनाला दीपिकाला सांगायचे होते की तिचा attitude वाईट आहे आणि ती कधीच ऐकत नाही: क्षण किंवा परिणाम नसलेला निष्कर्ष.

💡 काय

SBI feedback म्हणजे situation, दिसणारे behaviour आणि त्याचा impact सांगणे; 1:1 हा त्या शिक्षिकेचा स्वतःचा साप्ताहिक वेळ आहे.

⚙️ कसे

त्या निष्कर्षात situation आणि impact नाहीत, आणि 'attitude', 'never' हे शब्द आहेत; SBI note मध्ये काहीच कमी नाही.

🎯 का

दीपिका एखादे behaviour तपासू आणि बदलू शकते. Tracker दाखवतो की लीलाच्या 12 पैकी फक्त 5 1:1 झाल्या, शेवटची 4 आठवड्यांपूर्वी.

🚀 पुढे

पुढचा धडा: प्रत्येक काम एकटीने कोण करू शकते, bus factor 1, आणि निर्णयाच्या अधिकारासह काम सोपवणे.

🧪 इथे करून पाहा — एखादी टीप प्रसंग · वर्तन · परिणाम यासाठी तपासा, मग 1:1 tracker वर टॅप करा — हे विचार करण्याचे साधन आहे, माणसांसाठीचे सूत्र नाही
2

पूर्ण धडा 02 वाचा →

3 🤝 Delegation आणि ownership

Delegation चे सात स्तर, नेमका एकच Accountable असलेले RACI, आणि team च्या कौशल्यांमधील bus factor.

🧒 सोप्या शब्दांत

कतरिना प्रत्येक काम आणि ते मदतीशिवाय कोण करू शकते याची यादी करते. दोन कामांसमोर एकच नाव आहे: तिचे. ती आजारी पडली तर ती कामे थांबतात. म्हणून ती कामे सोपवते. दीपिका releases शिकते, ऐश्वर्या runbooks घेते, मीरा database शिकते. एका सत्रानंतर प्रत्येक कामाला किमान दोन जणी आहेत. किती अधिकार देत आहे हेही ती स्पष्ट सांगते.

📖 नवे शब्दbus factor — किती लोक गैरहजर असले तर एखाद्या कामाला कोणीच उरत नाही; इथे तो 1 वरून 2 झालाdelegation — एखाद्याला काम आणि ते कसे करायचे हे ठरवण्याचा अधिकार देणेRACI — कोण काम करते, कोण मालक (फक्त एक), कोणाला विचारायचे आणि कोणाला कळवायचे हे सांगणारा तक्ता
1🧰 प्रत्येक काम मदतीशिवाय कोण करू शकते (3 पैकी level 2+)gradebookreleasedatabasefrontendrunbooksKatrina33323Dipika21131Aishwarya20211Meera10020लीला00010धारक31231bus factor 1कतरिना नसेल तर: release, runbooks ला कोणीच नाहीlevel: 0 काहीच नाही · 1 मदतीने · 2 एकटी · 3 शिकवू शकते2🤝 एका तिमाहीचे pairingकतरिना + दीपिकादीपिका releases चालवतेrelease12कतरिना + ऐश्वर्याrunbooks ऐश्वर्याच्या ताब्यातrunbooks12कतरिना + मीरामीरा database शिकतेdatabase02आताचे धारक: release 2 · database 3 · runbooks 2bus factor 23📋 RACI तपासणी — नेमका एक A, किमान एक RKatrinaDipikaAishwaryaसाप्ताहिक releaseAAC2 accountable(कतरिना, दीपिका)कोणीही responsible नाहीgradebook migration—RC0 accountable(कोणीही नाही)भरती loopARRA = accountable (जबाबदार) · R = responsible (काम करणारी) · C = consulted (सल्ला घेतलेली)4🪜 तुम्हाला कोणती level म्हणायची आहे ते सांगा (Appelo च्या सात)1सांगणे2पटवणे3सल्ला घेणेभरतीनिकष4सहमतीपरीक्षा-आठवडाfreeze5सल्ला देणे6चौकशी7सोपवणेtestframework← कतरिना ठरवतेteam ठरवते →
⏪ आधी

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 एका उमेदवाराला गुण देतात आणि आधी बोलणारी व्यक्ती निर्णय उलटवू शकते.

🧪 इथे करून पाहा — प्रत्येक काम एकटी कोण करू शकते? level बदलण्यासाठी cell वर टॅप करा — हे विचार करण्याचे साधन आहे, माणसांसाठीचे सूत्र नाही
2

पूर्ण धडा 03 वाचा →

4 🧑‍🏫 भरती

एक structured rubric, debrief आधी लिहिलेले गुण, आणि मुलाखतकारांमधील calibration.

🧒 सोप्या शब्दांत

तीन शिक्षिका एका उमेदवाराला शिकवताना पाहतात. Meeting मध्ये कतरिना आधी बोलते आणि खूप खात्रीने बोलते. दीपिकाला खरी शंका होती, पण ती कतरिनाच्या मागे जाते. उमेदवार निवडली जाते आणि ती शंका हरवते. पुढच्या वेळी सगळ्या एकच score sheet वापरतात आणि आधी आपले गुण लिहून ठेवतात. आता त्याच मतांमधून प्रामाणिक उत्तर येते: no hire.

📖 नवे शब्दrubric — प्रत्येक गुणासाठी स्पष्ट वर्णन असलेली score sheet, प्रत्येक उमेदवारासाठी तीचanchoring — आधी ऐकलेले मत आपल्या मताला आपल्याकडे ओढते तेव्हाcalibration — एखादी interviewer नेहमी इतरांपेक्षा जास्त किंवा कमी गुण देते का हे तपासणे
1🧑‍🏫 एक उमेदवार, तोच पुरावा — दोन debriefs (4 चा rubric, 1–4 anchored)debrief च्या आधी लिहिलेले गुणप्रत्येक बिंदू = एक क्षमता · रेषा = तिची सरासरी1234निकष 3.0कतरिना 3.75दीपिका 2.25ऐश्वर्या 2.50panel 2.83निवड नाहीकतरिना आधी बोलल्यानंतरइतर जणी तिच्याकडे अर्ध्या अंतरापर्यंत सरकतात (तुटक = त्या आधी कुठे होत्या)1234निकष 3.0कतरिना 3.75दीपिका 3.00ऐश्वर्या 3.12panel 3.29निवड“ती अप्रतिम होती!”2⚖️ मागील 5 panels वर calibration0 = panel ची सरासरी← अधिक कडकअधिक उदार →Katrina+0.37Dipika-0.33Aishwarya-0.035 panels हा छोटा नमुना आहे: offset कडे सूचना म्हणून पाहा,दुरुस्ती म्हणून नाही3🔀 raw विरुद्ध calibrated — क्रम उलटतो2.93.03.13.23.3उमेदवार X (कतरिना + ऐश्वर्या)raw 3.25calibrated 3.08उमेदवार Y (दीपिका + ऐश्वर्या)raw 3.00calibrated 3.18उदार panel मुळे अधिक सक्षम उमेदवार मागे पडू शकतोवेगवेगळे panels, वेगवेगळ्या सवयी
⏪ आधी

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 कामे कधी पूर्ण होतील, आणि सरासरीवरून काढलेली एक तारीख म्हणजे नाणेफेक.

🧪 इथे करून पाहा — एक उमेदवार, तीन मुलाखतकार — आधी कोण बोलते, आणि इतर जणी किती सरकतात? — हे विचार करण्याचे साधन आहे, माणसांसाठीचे सूत्र नाही
503

पूर्ण धडा 04 वाचा →

5 🎲 Planning आणि forecasting

मागील throughput वरून seeded Monte Carlo अंदाज — एका अंदाजाऐवजी 50% आणि 85% तारखा.

🧒 सोप्या शब्दांत

मुख्याध्यापिका विचारतात की 40 कामे कधी पूर्ण होतील. विभाग सरासरी आठवड्याला 3.7 कामे पूर्ण करतो, म्हणून सोपे उत्तर 11 आठवडे. पण काही आठवडे हळू जातात. कतरिना मागचे दहा आठवडे कार्डांवर लिहिते आणि ती यादृच्छिकपणे पुन्हा पुन्हा, 10,000 वेळा काढते. अर्धे खेळ 11 आठवड्यांत संपतात, आणि 100 पैकी 85 खेळ 13 आठवड्यांत.

📖 नवे शब्दthroughput — टीम एका आठवड्यात किती कामे पूर्ण करतेMonte Carlo — निकालांची range पाहण्यासाठी एखादा नशिबाचा खेळ हजारो वेळा खेळणे85% date — ज्या तारखेपर्यंत 100 पैकी 85 खेळ पूर्ण होतात, जसे 13 आठवडे
1🃏 मागचे 10 आठवडे, cards स्वरूपात2w16w21w34w47w50w65w73w86w93w10- - सरासरी 3.7/आठवडा2614705363यादृच्छिकपणे एक कार्ड काढा = पुढचा आठवडाबेरीज करा, पुन्हा काढा, 40 items पूर्ण होईपर्यंतमग हा संपूर्ण खेळ 10,000 वेळा खेळा2🎲 10,000 seeded trials — 40 items पूर्ण करायला लागणारे आठवडे7846491,256101,946112,027121,671131,20014692153631617717181920212223लागणारे आठवडे (प्रत्येक आठवडा-संख्येसाठी एक bar)50%: 11 आठवडे85%: 13 आठवडे95%: 15 आठवडेअंदाज 40 ÷ 3.7 ≈ 11 आठवडे → तोपर्यंत फक्त 58% trials पूर्ण होतात3📏 संभाव्यतेसह एक range — आणि backlog वाढला की पुन्हा forecast करा02468101214161820आतापासून आठवडे40 items50%: 11 आठ.85%: 13 आठ.95%: 15 आठ.48 items (+20%)50%: 13 आठ.85%: 16 आठ.कतरिना मुख्याध्यापिकेला काय सांगते:“11 आठवडे म्हणजे नाणेफेक आहे.तुम्हाला बऱ्यापैकी खात्री हवी असेल,तर 13 चा आराखडा करा (85%).”दर आठवड्याला पुन्हा forecast करा
⏪ आधी

कतरिनाने 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 आठवड्यांवर जातो.

🚀 पुढे

पुढचा धडा: चार कामे एका टीमची वाट पाहतात, आणि निवडलेल्या क्रमानुसार थांबण्यात किती मूल्य जाते ते बदलते.

🧪 इथे करून पाहा — मागचे यादृच्छिक आठवडे 10,000 वेळा पुन्हा खेळा — backlog ला किती वेळ लागेल? — विचार करण्याचे साधन, माणसांसाठीचे सूत्र नव्हे
4042

पूर्ण धडा 05 वाचा →

6 ⚖️ प्राधान्यक्रम

RICE, cost of delay आणि CD3/WSJF — गृहीतके अशा ठिकाणी लिहिलेली की लोक त्यावर वाद घालू शकतील.

🧒 सोप्या शब्दांत

चार कामे वाट पाहत आहेत, आणि विभाग एका वेळी एकच करू शकतो. एक शिक्षिका म्हणते सर्वात मोठे, मौल्यवान काम आधी करा. कतरिना विचारते की काम थांबले तर दर आठवड्याला किती नुकसान होते. छोटा export fix आठवड्याला 5 गमावतो आणि 1 आठवडा घेतो, म्हणून तो आधी. मोठे आधी केल्यास एकूण 142 जाते. तिच्या क्रमाने फक्त 118.

📖 नवे शब्दRICE — एक score: किती लोकांपर्यंत पोहोचते, गुणिले impact आणि confidence, भागिले effortcost of delay — काम थांबावे लागल्यावर दर आठवड्याला जाणारे मूल्यCD3 — cost of delay भागिले कामाला लागणारा वेळ; सर्वात जास्त असलेले आधी करा
1🧮 RICE = reach × impact × confidence ÷ effortपरीक्षा निकाल पान1500 × 1 × 80% ÷ 2600पालक portal login2000 × 2 × 50% ÷ 4500gradebook export fix 400 × 1 × 80% ÷ 1320वेळापत्रक पुन्हा लिहिणे 300 × 3 × 50% ÷ 675800confidence 50% → 80%: 800, पहिला क्रमांकreach: तिमाहीतील लोक · effort: व्यक्ती-महिने — क्रमवारी confidence च्या अंदाजाइतकीच चांगली असते2⏳ cost of delay: item जितके आठवडे थांबते, दर आठवड्याला गमावलेले मूल्य (क्षेत्रफळ = एकूण)सर्वात मोठे मूल्य आधी356802468101322portalनिकालfixवेळापत्रकआठवडेएकूण delay cost 142CD3: cost of delay ÷ कालावधी, सर्वाधिक आधी386502468101322fixनिकालportalवेळापत्रकआठवडेएकूण delay cost 118fix 5/1 · निकाल 6/2 · portal 8/4 · वेळापत्रक 3/6 (दर आठवड्याचा cost / आठवडे) — आकडे लिहून ठेवा, म्हणजे लोक एकमेकांशी नव्हे तर गृहीतकांशी वाद घालतील
⏪ आधी

प्रत्येकजण आपल्या आवडत्या कामासाठी भांडत होती, आणि सर्वात मोठा आवाज म्हणाला सर्वात मोठे, मौल्यवान काम आधी करा.

💡 काय

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.

🧪 इथे करून पाहा — एक अंदाज बदला आणि क्रमवारी हलताना पाहा — मग एक क्रम निवडा — विचार करण्याचे साधन, माणसांसाठीचे सूत्र नव्हे
5048

पूर्ण धडा 06 वाचा →

7 🧾 तांत्रिक कर्ज (Technical debt)

Debt म्हणजे portfolio: मुद्दल, साप्ताहिक व्याज, परतफेड, आणि कोणते debt जाणूनबुजून बाळगायचे.

🧒 सोप्या शब्दांत

विभागात जुन्या, गोंधळलेल्या गोष्टी आहेत. Flaky tests दर आठवड्याला 6 तास वाया घालवतात आणि दुरुस्तीला 24 तास लागतात, म्हणून 4 आठवड्यांत ते वसूल होते. Old report module आठवड्याला 1 तास वाया घालवते पण दुरुस्तीला 120 तास लागतात. कतरिना ते सध्या तसेच ठेवते. दर आठवड्याला वेळ चोरणारा गोंधळ कोणी ठरवो वा न ठरवो, किंमत घेतोच.

📖 नवे शब्दtechnical debt — code मधले शॉर्टकट आणि जुना गोंधळ, ज्यामुळे पुढचा प्रत्येक बदल हळू होतोprincipal — गोंधळ नीट दुरुस्त करायला लागणारे तासinterest — गोंधळ तसाच राहिल्यावर दर आठवड्याला जाणारे तास, जसे आठवड्याला 6 hpayback — दुरुस्तीने तिच्या खर्चापेक्षा जास्त वाचवायला किती आठवडे लागतात, जसे 4 आठवडे
1📉 निव्वळ तास = वाचलेले व्याज × आठवडे − मुद्दल-2000+200+400+6000265278104130आतापासून आठवडेक्षितिज 26 आठ.क्षितिज 104 आठ.0 च्या खाली: दुरुस्तीचा खर्च आतापर्यंत वाचलेल्यापेक्षा जास्त+600 h+480 h+216 h-16 h+132+90-96-942🧾 कर्जाची नोंदवहीकर्जfixदर आठ.परतफेडflaky test suite24 h6 h4.0 आठ.26 आठ.: फेडा104 आठ.: फेडाहाताने करायच्या release पायऱ्या40 h5 h8.0 आठ.26 आठ.: फेडा104 आठ.: फेडागुंतागुंतीचा gradebook core200 h4 h50.0 आठ.26 आठ.: वाहून न्या104 आठ.: फेडाजुने report module120 h1 h120.0 आठ.26 आठ.: वाहून न्या104 आठ.: वाहून न्यासपाट-व्याजाचे model — आराखडा बदलला की पुन्हा किंमत ठरवा3💸 व्याज दर आठवड्याला भरले जाते, कोणी ठरवो वा न ठरवोव्याज 16 h/आठवडा — टीमच्या 160 h/आठवड्याच्या 10%flaky tests 6 · हाताने releases 5 · गुंतागुंतीचा core 4 · जुने reports 1 (दर आठवड्याला गमावलेले तास)जास्त व्याज, कमी मुद्दल असलेले कर्ज आधी फेडा · ज्या code ला कोणी हात लावत नाही तिथले कर्ज वाहून न्या
⏪ आधी

जुना गोंधळ एकतर त्रास होईपर्यंत दुर्लक्षित राहायचा किंवा एकदम सगळा पुन्हा लिहिला जायचा, तुलना करायचा मार्ग नव्हता.

💡 काय

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 बनले की काय होते.

🧪 इथे करून पाहा — मुद्दल, साप्ताहिक व्याज आणि क्षितिज — फेडायचे की वाहून न्यायचे? — विचार करण्याचे साधन, माणसांसाठीचे सूत्र नव्हे
26246

पूर्ण धडा 07 वाचा →

8 📈 Delivery metrics

DORA four keys आणि reliability, flow metrics — आणि Goodhart's law एखाद्या target चे काय करतो.

🧒 सोप्या शब्दांत

मुख्याध्यापिका मोजतात की नवे काम किती वेळा जाते आणि किती वेळा चुकते. उपयोगी! मग त्या म्हणतात 10 पैकी 1 पेक्षा कमी चुका हव्यात. लोक चुकांना planned changes म्हणू लागतात, आणि आकडा 17% वरून 6% वर येतो. काहीच सुधारले नाही. कतरिना आकड्यांचा वापर कामाबद्दल प्रश्न विचारण्यासाठी करते, शिक्षिकांची क्रमवारी लावण्यासाठी कधीच नाही.

📖 नवे शब्दfour keys — deploy frequency, lead time, change failure rate आणि recovery timechange failure rate — production मध्ये चुकणाऱ्या deploys चा वाटा, जसे 16.7%Goodhart's law — एखादे माप target बनले की ते चांगले माप राहत नाही
1🚀 4 आठवड्यांचे deploys — प्रत्येक bar एक बदल: commit पासून production पर्यंतचे तास0 h24 h48 h72 h206305245 min842672120 min10145284830 min92231640- - median lead time 18 hलाल = तो बदल production मध्ये अयशस्वी झाला (label: recover होईपर्यंत users वर परिणामाची मिनिटे)deployment frequency4.5/आठवडावेगlead time for changes18 hवेगchange failure rate16.7%स्थिरताfailed-deploy recovery45 minस्थिरताavailability99.52%विश्वासार्हता2🎯 target 'change failure rate 10% पेक्षा कमी'45 min त्रासनियोजित hotfix120 min त्रासनियोजित hotfix30 min त्रासCFR 16.7%report वर 5.6%availability अजूनही 99.52% — users ना तितकाच वेळ त्रास झालादोन failures ना नवे label दिले; काहीच सुधारले नाही3🎯 target 'जास्त deploy करा'18 खरे deploys + 18 फक्त-config no-op deploysfrequency 4.5 → 9.0/आठवडाmedian lead time 18 h → 1.8 husers ना काहीच नवीन दिसत नाहीआकडे दुप्पट झाले; काम नाही4🌊 flow: cycle time आणि त्यातली वाट पाहणे0246810121416item 15 ditem 28 ditem 32 ditem 412 ditem 53 ditem 610 dflow efficiency 40%बाकी सगळी वाट पाहणेभरीव = सक्रिय दिवस (एकत्र काढलेले) · तुटक = वाट पाहणे · Goodhart चा नियम: एखादे माप target बनले की ते चांगले माप राहत नाही
⏪ आधी

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 मार्ग का होतात.

🧪 इथे करून पाहा — 18 deploys मधून चार keys — आता एका metric ला target बनवा — विचार करण्याचे साधन, माणसांसाठीचे सूत्र नव्हे
0

पूर्ण धडा 08 वाचा →

9 🧩 टीम रचना (Team topologies) आणि Conway चा नियम

Conway's law, संवादाचे मार्ग, चार team प्रकार आणि cognitive load.

🧒 सोप्या शब्दांत

शाळेत 12 शिक्षिका होतात, आणि 12 जणींमध्ये बोलू शकणाऱ्या 66 जोड्या असतात. आधी त्या कामाच्या प्रकारानुसार विभागतात, आणि प्रत्येक परीक्षेला सगळे गट लागतात. मग त्या इयत्तेनुसार विभागतात, म्हणून इयत्ता 7 च्या परीक्षेला फक्त इयत्ता 7 ची टीम लागते. एक छोटी support team सामायिक साधने वापरायला सोपी करते. लोकांचा आकारच कामाचा आकार बनतो.

📖 नवे शब्दConway's law — system शेवटी ती बनवणारे लोक एकमेकांशी कसे बोलतात त्याच आकाराची होतेstream-aligned team — एक क्षेत्र सुरुवातीपासून शेवटपर्यंत सांभाळणारी टीम, म्हणून बहुतेक काम तिच्याकडेच राहतेcognitive load — टीमला एका वेळी डोक्यात किती ठेवावे लागते
1🕸️ 12 जणांची एक टीम: 66 संवाद मार्गप्रत्येकाला प्रत्येकाशी बोलावे लागते: n(n−1)/22🧩 6 जणांच्या दोन टीम्स: 30 मार्ग + एक ठरवलेला interfaceinterface15 मार्ग15 मार्गsystem चा आकार संस्थेच्या संवादाच्या आकाराची नक्कल करतो (Conway)3⏳ तीन टीम रचनांमध्ये प्रत्येक feature ला कोणत्या टीम्सची वाट पाहावी लागतेcomponent teamsteam-waits 14 · >1 टीम 5/6frontendbackendडेटाfrontendbackendplatformplatformfrontendbackendfrontendfrontendbackendडेटाplatformstream-aligned + platformteam-waits 9 · >1 टीम 3/6gradesगृहपाठplatformplatformपालकgradesगृहपाठplatformplatformstream-aligned + self-service platformteam-waits 5 · >1 team 0/6gradesगृहपाठपालकgradesगृहपाठ✓ कोणाचीही वाट पाहावी लागत नाहीअंदाजित गुणगृहपाठ आठवणीपालक SSO loginगुण export CSVगृहपाठ फोटो uploadअधिक वेगवान CIतुम्हाला हवी असलेली system डोळ्यासमोर ठेवून teams ची रचना करा: बहुतेक features एकाच team मध्ये पूर्ण व्हायला हवीत4🧠 cognitive load (सोपे 1 · गुंतागुंतीचे 2 · जटिल 3)गुण teamgradesपरीक्षा export2 domains मध्ये 4'सगळं काही' teamgradesगृहपाठपालक loginCIसूचना5 domains मध्ये 10team चे प्रकार:stream-aligned · platformenabling · complicated-subsystem
⏪ आधी

टीम 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 बिघडते, आणि काही निर्णय असे दरवाजे असतात जिथून परत येता येत नाही.

🧪 इथे करून पाहा — लोकांची विभागणी करा, मग teams कशा आखायच्या ते निवडा — हे विचार करण्याचे साधन आहे, माणसांसाठीचे सूत्र नाही
122

पूर्ण धडा 09 वाचा →

10 🚨 Incidents आणि कठीण निर्णय

आधी परिणाम कमी करा, incident मधील भूमिका, one-way विरुद्ध two-way doors, आणि निर्णयांची नोंदवही.

🧒 सोप्या शब्दांत

परीक्षेची सकाळ: नवे gradebook प्रत्येक गुण शून्य दाखवते. सगळ्या bug शोधायला गर्दी करतात. कतरिना प्रत्येकीला एक काम देते. दीपिका कालचे version परत आणते, आणि ऐश्वर्या पालकांना काय चालले आहे ते सांगते. Service 52 नाही तर 15 मिनिटांत परत येते. नंतर कतरिना सहज उलटता येणारे निर्णय पटकन घेते आणि कठीण निर्णय सावकाश.

📖 नवे शब्दmitigate — कारण शोधण्याआधी त्रास थांबवणे, उदाहरणार्थ rollback करूनincident commander — incident चे समन्वय करणारी व्यक्ती, जी स्वतः debug करत नाहीone-way door — उलटणे कठीण किंवा अशक्य असलेला निर्णय, जसे 3 वर्षांचा contractblameless review — मागे वळून पाहणे जे चूक सोपी का झाली हे विचारते, ती कोणी केली हे नाही
1🚪 दारावरून निर्णय घ्या: हे मागे घेणे किती कठीण आहे?दुतर्फी दारएकतर्फी दारकाल रात्रीचे gradebook release roll back करणेमागे घेणे: 0 दिवस2 आठवडे नवीन standup पद्धत वापरून पाहणेमागे घेणे: 1 दिवसgradebook MySQL वरून PostgreSQL वर हलवणेमागे घेणे: 60 दिवस · उलटवता येत नाहीगुणदान tool साठी 3 वर्षांचा करार करणेमागे घेणे: 365 दिवस · उलटवता येत नाहीआत्ताच ठरवा, owner निर्णय घेते,नोंद करा, पुन्हा पाहण्याची तारीख ठरवासावकाश: लिहून काढा, सल्ला घ्या,निर्णय घेणारी व्यक्ती आणि deadline ठरवाmodel: उलटवता येणारे आणि मागे घ्यायला जास्तीत जास्त 5 दिवस → दुतर्फी; नाहीतर एकतर्फीहे विचार करण्याचे साधन आहे, कायदा नाही: दार कोणते हे कोणीतरी प्रामाणिकपणे ठरवायला हवे2🚨 परीक्षेची सकाळ: प्रत्येक गुण शून्य दिसतो0102030405060users वर परिणाम सुरू झाल्यापासूनची मिनिटेआधी नुकसान थांबवा(roll back)users ना 15 min त्रास6 min नंतर लक्षात आले⏪ कालची version परतपुढे debug करणे(शोधा आणि दुरुस्त करा)users ना 52 min त्रासआधी service पूर्ववत करा; कारण नंतर शांतपणे शोधा3🧭 प्रत्येकीला एकच कामKatrinaincident commanderसमन्वय करते, debug करत नाहीDipikaoperate करतेroll back करतेAishwaryaसंवाद साधतेupdates लिहितेनंतर: दोषारोपविरहित review —चूक सोपी कशामुळे झाली, ती कोणी केली हे नाही4📒 निर्णयांची नोंदवही — आठवडा 8 पर्यंत review करायचीआठवडानिर्णयमालकदारपुन्हा पाहणेआठवडा 83नवीन standup पद्धतDipikaदुतर्फीआठवडा 5← वेळ झाली: review करा3PostgreSQL migration RFC स्वीकारलेKatrinaएकतर्फीआठवडा 12अजून नाही4परीक्षेच्या आठवड्यात releases थांबवणेAishwaryaदुतर्फीआठवडा 8← वेळ झाली: review करा
⏪ आधी

काही बिघडले की सगळ्या मिळून 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 पर्यंत.

🧪 इथे करून पाहा — हे मागे घेणे किती कठीण आहे? मग incident आणि निर्णयांची नोंदवही चालवून पाहा — हे विचार करण्याचे साधन आहे, माणसांसाठीचे सूत्र नाही
0158

पूर्ण धडा 10 वाचा →

11 ✍️ लेखन

Design docs आणि RFCs, मागणी आधी मांडणारे status updates, आणि एका meeting ची किंमत.

🧒 सोप्या शब्दांत

दर सोमवारी 8 शिक्षिका आपण काय केले हे सांगायला एक तास भेटतात. वर्षात ते 368 तास होतात. म्हणून कतरिना दर शुक्रवारी एक छोटी नोंद लिहिते: काय बदलले, काय चुकू शकते, आणि तिला काय हवे आहे. त्याला वर्षाला सुमारे 54 तास लागतात, आणि कोणालाही ती नंतर सापडते. दीपिका आधी आपला आराखडा लिहिते, आणि काहीही बनवण्याआधीच reviewer ला एक प्रश्न सापडतो.

📖 नवे शब्दperson-hours — लोक गुणिले तास: 8 जणी 1 तासासाठी म्हणजे 8 person-hoursdesign doc — goals, non-goals, options आणि risks असलेला लिखित आराखडा, coding आधी तपासला जाणाराnon-goals — आराखडा ज्या गोष्टी करणार नाही असे सांगतो, म्हणजे कोणी त्यांची अपेक्षा ठेवत नाही
1🕐 नियमित meeting ची किंमत (वर्षाला person-hours, 46 आठवडे)साप्ताहिक status meeting · 8 × 60 minसाप्ताहिक status meeting368 hलेखी status update: लिहायला 30 min + वाचायला 8 × 5 min54 h…आणि नंतर तो शोधताही येतो6 जणींची 30 मिनिटांची निर्णय meeting→ 3.0 person-hours: तेव्हाच योग्य जेव्हानिर्णयासाठी प्रत्यक्ष चर्चा आवश्यक असतेलोक × मिनिटे ÷ 60 × 46 आठवडे — ही गृहीतके तुम्ही बदलू शकता2📨 status update, आधी मागणी1. मला तुमच्याकडून काय हवे आहेमागणी सर्वात आधीमागणी2. काय बदललेया आठवड्यात, थोडक्या ओळींत3. कशाला धोका आहेआणि त्याबद्दल आपण काय करत आहोतकतरिनाकडून, दर शुक्रवारी3📝 दीपिकाचे पहिले design doc — reviewer काय पाहतेDesign: gradebook बदलणेसंदर्भउद्दिष्टेउद्दिष्टे नसलेलेविचारात घेतलेले पर्यायनिर्णयधोकेrolloutअनुत्तरित प्रश्नAishwaryareviewerविचारात घेतलेले पर्याय आणि उद्दिष्टे नसलेले इथेचreviewer ला समस्या स्वस्तात सापडते —code लिहिण्याआधीच3 विभाग आहेत · नाहीत: उद्दिष्टे, उद्दिष्टे नसलेले, विचारात घेतलेले पर्याय, धोके, अनुत्तरित प्रश्नसंदर्भ · उद्दिष्टे · उद्दिष्टे नसलेले · पर्याय · निर्णय · धोके · rollout · अनुत्तरित प्रश्न
⏪ आधी

दर सोमवारी सर्व 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 च्या कामाचा संपूर्ण नकाशा.

🧪 इथे करून पाहा — नियमित meeting ची किंमत, आणि design doc मध्ये काय राहिले आहे — हे विचार करण्याचे साधन आहे, माणसांसाठीचे सूत्र नाही
86046305

पूर्ण धडा 11 वाचा →

12 🌱 लोकांची वाढ आणि संपूर्ण चित्र

Career ladders, sponsorship, psychological safety, on-call आणि कामाच्या वेळेनंतरचा भार — आणि संपूर्ण नकाशा.

🧒 सोप्या शब्दांत

वर्षाच्या शेवटी कतरिना दोन याद्या पाहते. दीपिकाला 5 मोठ्या संधी मिळाल्या, ऐश्वर्याला 1, मीरा आणि लीलाला एकही नाही. ऐश्वर्याला रात्री 9 वेळा फोन आला, आणि तिने कधीच तक्रार केली नाही. म्हणून कतरिना पुढच्या संधी ज्यांना मिळाल्या नाहीत त्यांना देते. ती रात्रीची यादी मोठी करते, म्हणजे कोणालाही ते ओझे एकटीने उचलावे लागू नये. चांगला विभाग पुढच्या वर्षीही निरोगी असतो.

📖 नवे शब्दsponsorship — एखाद्याला वाढीसाठी दिसणाऱ्या संधी देण्यासाठी आपला प्रभाव वापरणेon-call — काही बिघडल्यावर, रात्रीसुद्धा, उत्तर देणारी व्यक्ती बनण्याची आळीपाळीpsychological safety — लोक न घाबरता 'I broke it' किंवा 'I disagree' म्हणू शकतातcareer ladder — प्रत्येक level साठी लिखित अपेक्षा, म्हणजे वाढ स्पष्ट आणि न्याय्य होते
1🌙 on-call, 13 आठवडे — प्रत्येक चंद्र म्हणजे कामाच्या वेळेनंतरचे एक pageआ. 1आ. 2आ. 3आ. 4आ. 5आ. 6आ. 7आ. 8आ. 9आ. 10आ. 11आ. 12आ. 133 जणींचे rotationKatrinaDipika—AishwaryaKatrinaDipika—AishwaryaKatrinaDipikaAishwarya—KatrinaDipikaAishwaryaKatrina—13 आठवड्यांतील कामाच्या वेळेनंतरचे pages: कतरिना 7 · दीपिका 3 · ऐश्वर्या 95 जणींचे rotationKatrinaDipika—AishwaryaMeeraलीला—KatrinaDipikaAishwaryaMeera—लीलाKatrinaDipikaAishwarya—13 आठवड्यांतील कामाच्या वेळेनंतरचे pages: कतरिना 5 · दीपिका 3 · ऐश्वर्या 6 · मीरा 1 · लीला 43 जणींचे rotation: 2 पेक्षा जास्त after-hours pages असलेले आठवडे कतरिना, ऐश्वर्या यांच्यावर येतात — हा burnout चा इशारा आहे, त्यावर कृती करा; हा बिल्ला नाही2🌟 6 महिन्यांतील ठळक संधीDipika5 संधीleads m… मध्ये सादरीकरणपरीक्षा-आठवड्याचे rel… नेतृत्वinterview panelmigration RFC लिहिणेनव्या सहकारीला mentor करणेAishwarya1 संधीमुख्याध्यापिकेसमोर demoMeera0 संधीनाहीलीला0 संधीनाहीतुम्ही लक्ष ठेवले नाही तर sponsorship ओळखीच्या लोकांकडेच जाते3🪜 लेखी शिडी · अशी खोली जिथे लोक मोकळेपणाने बोलतातस्तर 1स्तर 2स्तर 3स्तर 4स्तर 5प्रत्येक स्तराच्या अपेक्षा, लेखीलीलाMeera“माझ्याकडून हे बिघडलं.”“मी असहमत आहे.”psychological safety: दोन्ही बोलणे सुरक्षित आहे4🗺️ संपूर्ण चित्र — विभाग सुरळीत चालतो🗓️1 · आठवड्याचे रक्षण करा💬2 · 1:1s आणि SBI🤝3 · परिणाम सोपवा🧑‍🏫4 · rubric वापरून भरती करा🎲5 · श्रेणींमध्ये अंदाज करा⚖️6 · क्रमाची किंमत मोजा🧾7 · debt जाणीवपूर्वक बाळगा📈8 · व्यवस्था मोजा🧩9 · टीम्सची रचना करा🚪10 · दाराच्या प्रकारानुसार निर्णय घ्या✍️11 · लिहून ठेवा🌱12 · लोकांची वाढ होत राहू द्या आणि त्यांना विश्रांती मिळू द्या
⏪ आधी

कतरिनाला आधी आठवेल तिलाच संधी मिळायच्या, आणि रात्री 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 बनवते.

🧪 इथे करून पाहा — on-call rotation वाढवा, आणि पुढच्या संधी विचारपूर्वक वाटा — हे विचार करण्याचे साधन आहे, माणसांसाठीचे सूत्र नाही
32

संपूर्ण धडा 12 वाचा →

धडा 01 सुरू करा → 🗓️ अभ्यास योजना (4 आठवडे) 📐 सर्व 12 धड्यांच्या आकृत्या 🧪 प्रश्नमंजुषा (16 प्रश्न) ⏮️ आधी काय होते & फायदे-तोटे