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

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

✍️ धडा 11 — लेखन: RFCs, status updates आणि एका meeting ची किंमत

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

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

धडा 10, आणि नेतृत्वाचे साधन म्हणून लेखन. दर आठवड्याच्या meeting ची person-hours मध्ये किंमत, reviewers ना प्रश्न स्वस्तात सापडावेत म्हणून design doc / RFC मध्ये लागणारे sections, आणि मागणी आधी मांडणारा status update. writing() lead/demo.py मध्ये; meeting_hours() आणि rfc_check() lead/models.py मध्ये.

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

दर सोमवारी सर्व 8 गणित शिक्षिका मागच्या आठवड्यात काय केले ते सांगण्यासाठी एक तास भेटतात. 🕐 त्यांपैकी बहुतेक जणी फक्त ऐकतात आणि आपल्या पाळीची वाट पाहतात.

कतरिना बेरीज करते. 8 शिक्षिका × 1 तास × 46 शालेय आठवडे = वर्षाला 368 तास. म्हणजे एका शिक्षिकेच्या नऊ पूर्ण कामाच्या आठवड्यांपेक्षा जास्त वेळ — बहुतेक 5 मिनिटांत वाचता येतील अशा गोष्टी ऐकण्यात गेलेला.

म्हणून ती काहीतरी नवे करून पाहते. दर शुक्रवारी ती एक छोटी नोंद लिहिते: काय बदलले, काय बिघडू शकते, आणि तिला लोकांकडून काय हवे आहे. ✍️ तिला 30 मिनिटे लागतात. प्रत्येक शिक्षिका ती 5 मिनिटांत वाचते. एकूण: वर्षाला सुमारे 54 तास — आणि मागच्या महिन्याची नोंद नंतर कोणालाही सापडू शकते.

सोमवारची meeting नाहीशी होत नाही. ती अशा गोष्टींसाठीची छोटी meeting बनते ज्यांवर लोकांनी खरोखर एकत्र बसून वाद घालण्याची गरज असते.

दीपिकाला gradebook बदलायचे असते तेव्हा कतरिना तिला आधी ते लिहून काढायला सांगते: समस्या काय आहे, ती काय करणार नाही, तिने आणखी कोणत्या कल्पनांचा विचार केला, आणि काय चुकू शकते. Reviewers ना "इतर कल्पना" भागात एक समस्या सापडते — कोणीही काहीही बनवण्याच्या आधी. 📝

🗺️ आकृती

flowchart LR
    m["🕐 weekly status meeting<br/>8 people × 60 min<br/>368 person-hours a year"] -->|"write it instead"| w["✍️ written update<br/>30 min + 8 × 5 min<br/>54 person-hours a year"]
    r["📝 Dipika's first design doc<br/>context · decision · rollout"] --> x["missing: goals, non-goals,<br/>options considered, risks,<br/>open questions"]
    s["📣 status update<br/>ask first · what changed · what is at risk"]

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

❓ काय

Meeting ची किंमत — लोक × कालावधी, पुन्हा पुन्हा. 8 लोकांसाठी आठवड्याचा एक तास म्हणजे दर आठवड्याला 8 person-hours. हा lab वर्षाला 46 कामाचे आठवडे मोजतो (एक गृहीतक) आणि सगळ्यांचा focus तुटण्याची अतिरिक्त किंमत दुर्लक्षित करतो (धडा 01).
Synchronous विरुद्ध asynchronous — meeting साठी सगळे एकाच वेळी लागतात; document वाचणाऱ्याला सोयीच्या वेळी वाचता येतो, आणि नंतर शोधता येतो. मतभेद, विश्वास, brainstorming आणि जलद देवाणघेवाणीसाठी meetings चांगल्या; माहिती, प्रस्ताव आणि नोंद लागणाऱ्या निर्णयांसाठी documents चांगले.
RFC / design doc — मोठ्या बदलासाठीचा लिखित प्रस्ताव, काम सुरू होण्याआधी तपासला जाणारा. अनेक engineering संस्था ते वापरतात ("RFC" हे नाव internet च्या Request for Comments मालिकेवरून घेतले आहे). Amazon meetings ची सुरुवात शांतपणे वाचल्या जाणाऱ्या लिखित narrative ने करण्यासाठी ओळखले जाते.
या lab मध्ये वापरलेले sections: context (सध्या काय खरे आहे) · goals · non-goals (हे जाणीवपूर्वक काय करणार नाही) · options considered ("काहीच न करणे" सह) · decision · risks · rollout (आणि roll back कसे करायचे) · open questions.
Status update — नियमित लिखित नोंद. एक उपयोगी रचना: आधी मागणी (मला तुमच्याकडून काय हवे आहे), मग काय बदलले, मग काय धोक्यात आहे. सैन्यातली BLUF — bottom line up front — ही लेखनाची सवय हीच कल्पना आहे.

🤔 का

कारण lead ची पोहोच तिच्या तासांनी मर्यादित असते, आणि लेखनाला ती मर्यादा नसते: एक design doc दहा जण meeting शिवाय review करू शकतात, आणि status नोंद खोलीत नसलेल्या लोकांपर्यंतही पोहोचते. लेखन स्पष्ट विचार करायलाही भाग पाडते — आत्मविश्वासाने बोलणारी व्यक्ती ज्या उणिवा बोलण्यात झाकू शकते त्या कागदावर दिसतात. आणि "options considered" व "non-goals" इथेच reviewers महागड्या चुका पकडतात, जेव्हा दिशा बदलायला अजून पूर्ण rewrite नव्हे तर फक्त एक comment लागतो.

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

lead/models.py मधील meeting_hours(people, minutes, per_year=46) नियमित meeting चे वर्षाचे person-hours परत देते. rfc_check(sections) draft मध्ये RFC_SECTIONS पैकी कोणते sections नाहीत ते परत देते. lead/demo.py मधील writing() status meeting ची लिखित update शी तुलना करते आणि दीपिकाचा पहिला draft तपासते. Sections ची यादी अनेकांपैकी एक योग्य template आहे: विचार करण्याचे साधन, लोकांसाठीचे सूत्र नव्हे — चांगला doc छोटा आणि स्पष्ट असतो, केवळ पूर्णतेसाठी पूर्ण नसतो.

🧪 करून पाहा

python3 lead/demo.py writing
python3 - <<'EOF'
import sys; sys.path.insert(0, "lead"); from models import meeting_hours, rfc_check
for people, minutes in ((4, 30), (8, 30), (8, 60), (12, 60)):
    print(f"{people:>2} people × {minutes} min weekly → {meeting_hours(people, minutes):>4.0f} person-hours a year")
full = ["context", "goals", "non-goals", "options considered", "decision", "risks", "rollout", "open questions"]
print("full RFC missing:", rfc_check(full) or "nothing")
print("goals-only draft missing:", rfc_check(["context", "goals"]))
EOF

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

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

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

 4 people × 30 min weekly →   92 person-hours a year
 8 people × 30 min weekly →  184 person-hours a year
 8 people × 60 min weekly →  368 person-hours a year
12 people × 60 min weekly →  552 person-hours a year
full RFC missing: nothing
goals-only draft missing: ['non-goals', 'options considered', 'decision', 'risks', 'rollout', 'open questions']

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

आठवड्याचा status तास वर्षाला 368 person-hours घेतो; लिखित आवृत्ती सुमारे 54. Meeting अर्धी करून 30 मिनिटांची केल्याने उपस्थितांची संख्या अर्धी करण्याइतकीच बचत होते (दोन्ही प्रकारे 184), आणि 12 लोकांसाठी तोच तास 552 घेतो. 6 जणांची 30 मिनिटांची निर्णय meeting 3 person-hours घेते — स्वस्त, जेव्हा खऱ्या निर्णयासाठी प्रत्यक्ष वादाची गरज असते. दीपिकाचा draft context वरून थेट decision वर गेला: पाच sections नव्हते, त्यांत असे दोनही होते जिथे reviewers प्रश्न स्वस्तात पकडतात — options considered आणि non-goals.

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

लिहिता आले असते तेच प्रत्येकजण वाचून दाखवते अशा status meetings
code नंतर लिहिलेले design docs, ज्या निर्णयावर कोणीच प्रभाव टाकू शकले नाही त्याचे documentation म्हणून
फक्त एकच option असलेला doc — reviewers ना काय नाकारले, किंवा का, हे कळत नाही
शेवटच्या परिच्छेदात मागणी दडलेले लांबलचक updates
प्रत्येक meeting च्या जागी documents आणणे — कठीण संवाद आणि विश्वासासाठी अजूनही लोकांनी एकत्र येणे लागते
लिखित निष्कर्ष नसलेल्या meetings: निर्णय फक्त आठवणींत असतो

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

Repository मध्ये ठेवलेला design-doc template, म्हणजे तो code सारखाच review होतो:

# RFC-012: Move the gradebook to PostgreSQL
Author: Dipika · Reviewers: Aishwarya, Katrina · Status: in review · Decide by: week 12

## Context
## Goals
## Non-goals
## Options considered   (including "do nothing")
## Decision
## Risks
## Rollout (and rollback)
## Open questions

Phone च्या screen वर मावणारा आठवड्याचा status update:

Maths dept — week 14
ASK: Head teacher — approve the exam-week release freeze by Wed.
CHANGED: gradebook export fixed (was 12 tickets/wk); results page 60% done.
AT RISK: parent portal — auth vendor answer late; 85% forecast moved from week 25 to 27.

खऱ्या calendar वर, तिमाहीतून एकदा तुमच्या नियमित meetings पाहा: प्रत्येकीसाठी विचारा की तिथे कोणाची गरज आहे, ती document असू शकते का, आणि ती छोटी करता येईल का.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: code आधी प्रस्ताव लिहा, meeting आधी update लिहा, आणि meeting नंतर निर्णय लिहा. चांगले लिहिणाऱ्या टीमला कमी meetings लागतात, नवे लोक लवकर रुळतात, आणि आपण गोष्टी का केल्या हे तिला आठवते.

⏭️ पुढे

शेवटचा धडा हे सगळे करणाऱ्या लोकांबद्दल आहे: ते कसे वाढतात, आणि हे करत राहण्याइतकी टीम निरोगी कशी राहते — आणि मग संपूर्ण चित्र.

git checkout lesson-12-growth

✍️ Lesson 11 — Writing: RFCs, status updates and the cost of a meeting

📍 You are here: Lesson 11 of 12 · Previous: lesson-10-incidents-decisions · Next: lesson-12-growth

📦 What's in this branch

Lesson 10, plus writing as a leadership tool. What a recurring meeting costs in person-hours, the sections a design doc / RFC needs so reviewers can find problems cheaply, and a status update that leads with the ask. writing() in lead/demo.py; meeting_hours() and rfc_check() in lead/models.py.

🧒 Explain like I'm 5

Every Monday, all 8 maths teachers meet for an hour to say what they did last week. 🕐 Most of them just listen and wait for their turn.

Katrina adds it up. 8 teachers × 1 hour × 46 school weeks = 368 hours a year. That is more than nine full working weeks of one teacher's time — mostly spent listening to things that could be read in 5 minutes.

So she tries something new. Each Friday she writes a short note: what changed, what might go wrong, and what she needs from people. ✍️ It takes her 30 minutes. Each teacher reads it in 5. Total: about 54 hours a year — and anyone can find last month's note later.

The Monday meeting does not disappear. It becomes a short meeting for the things that really need people to argue together.

When Dipika wants to change the gradebook, Katrina asks her to write it down first: what the problem is, what she will not do, which other ideas she considered, and what could go wrong. The reviewers find a problem in the "other ideas" part — before anyone builds anything. 📝

🗺️ Diagram

flowchart LR
    m["🕐 weekly status meeting<br/>8 people × 60 min<br/>368 person-hours a year"] -->|"write it instead"| w["✍️ written update<br/>30 min + 8 × 5 min<br/>54 person-hours a year"]
    r["📝 Dipika's first design doc<br/>context · decision · rollout"] --> x["missing: goals, non-goals,<br/>options considered, risks,<br/>open questions"]
    s["📣 status update<br/>ask first · what changed · what is at risk"]

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

❓ What

Meeting cost — people × duration, repeated. A weekly hour for 8 people is 8 person-hours every week. This lab counts 46 working weeks a year (an assumption) and ignores the extra cost of breaking everyone's focus (lesson 01).
Synchronous vs asynchronous — a meeting needs everyone at the same time; a document can be read when it suits the reader, and can be searched later. Meetings are better for conflict, trust, brainstorming and fast back-and-forth; documents are better for information, proposals and decisions that need a record.
RFC / design doc — a written proposal for a significant change, reviewed before the work starts. Many engineering organisations use them (the name "RFC" borrows from the internet's Request for Comments series). Amazon is known for starting meetings with a written narrative read in silence.
The sections used in this lab: context (what is true now) · goals · non-goals (what this will deliberately not do) · options considered (including "do nothing") · decision · risks · rollout (and how to roll back) · open questions.
Status update — a regular written note. A useful shape: the ask first (what I need from you), then what changed, then what is at risk. The military writing habit of BLUF — bottom line up front — is the same idea.

🤔 Why

Because a lead's reach is limited by her hours, and writing does not have that limit: a design doc can be reviewed by ten people without a meeting, and a status note reaches people who were not in the room. Writing also forces clear thinking — gaps that a confident speaker can talk past are visible on the page. And "options considered" and "non-goals" are where reviewers catch the expensive mistakes, when changing course still costs a comment rather than a rewrite.

🔧 How (in this repo)

meeting_hours(people, minutes, per_year=46) in lead/models.py returns person-hours per year for a recurring meeting. rfc_check(sections) returns the sections from RFC_SECTIONS that a draft is missing. writing() in lead/demo.py compares a status meeting with a written update and checks Dipika's first draft. The section list is one reasonable template among many: a thinking tool, not a formula for people — a good doc is short and clear, not complete for its own sake.

🧪 Try it

python3 lead/demo.py writing
python3 - <<'EOF'
import sys; sys.path.insert(0, "lead"); from models import meeting_hours, rfc_check
for people, minutes in ((4, 30), (8, 30), (8, 60), (12, 60)):
    print(f"{people:>2} people × {minutes} min weekly → {meeting_hours(people, minutes):>4.0f} person-hours a year")
full = ["context", "goals", "non-goals", "options considered", "decision", "risks", "rollout", "open questions"]
print("full RFC missing:", rfc_check(full) or "nothing")
print("goals-only draft missing:", rfc_check(["context", "goals"]))
EOF

✅ Verify — what you should see

writing prints:

── 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

Your snippet prints:

 4 people × 30 min weekly →   92 person-hours a year
 8 people × 30 min weekly →  184 person-hours a year
 8 people × 60 min weekly →  368 person-hours a year
12 people × 60 min weekly →  552 person-hours a year
full RFC missing: nothing
goals-only draft missing: ['non-goals', 'options considered', 'decision', 'risks', 'rollout', 'open questions']

🏁 What you just proved

The weekly status hour costs 368 person-hours a year; the written version about 54. Halving the meeting to 30 minutes saves as much as halving the attendees (184 either way), and at 12 people the same hour costs 552. A 30-minute decision meeting of 6 costs 3 person-hours — cheap, when a real decision needs a live argument. Dipika's draft jumped from context to decision: five sections were missing, including the two where reviewers catch problems cheaply — options considered and non-goals.

⚠️ Common mistakes

status meetings where each person reads out what could have been written
design docs written after the code, as documentation of a decision nobody could influence
a doc with only one option — reviewers cannot tell what was rejected, or why
long updates with the ask buried in the last paragraph
replacing every meeting with documents — hard conversations and trust still need people together
meetings with no written outcome: the decision exists only in memories

🏭 In production

A design-doc template, kept in the repository so it is reviewed like code:

# RFC-012: Move the gradebook to PostgreSQL
Author: Dipika · Reviewers: Aishwarya, Katrina · Status: in review · Decide by: week 12

## Context
## Goals
## Non-goals
## Options considered   (including "do nothing")
## Decision
## Risks
## Rollout (and rollback)
## Open questions

A weekly status update that fits on a phone screen:

Maths dept — week 14
ASK: Head teacher — approve the exam-week release freeze by Wed.
CHANGED: gradebook export fixed (was 12 tickets/wk); results page 60% done.
AT RISK: parent portal — auth vendor answer late; 85% forecast moved from week 25 to 27.

On a real calendar, look at your recurring meetings once a quarter: for each, ask who needs to be there, whether it could be a document, and whether it could be shorter.

🏭 Why this matters in production: write the proposal before the code, the update before the meeting, and the decision after it. A team that writes well needs fewer meetings, onboards faster, and remembers why it did things.

⏭️ Next

The last lesson is about the people doing all of this: how they grow, and how the team stays healthy enough to keep doing it — and then the whole picture.

git checkout lesson-12-growth

← Previousincidents decisions Next →growth

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