जब कोई burn out होता है, तो standard advice बहुत personal सुनाई देती है: meditate करो, vacation लो, boundaries set करो, कोई wellness app install करो। जैसे problem बस ये है कि तुम पानी पीना भूल गए।
मैं सालों तक regularly burn out होता रहा। इसलिए नहीं कि मेरे अंदर discipline की कमी थी या self-care भूल गया था। बल्कि इसलिए कि जिन systems में मैं काम करता था, वो लोगों को consume करने के लिए design किए गए थे। जब मैंने burnout को character flaw की जगह systems problem मानना शुरू किया, तो burn out होना बंद हो गया। इसलिए नहीं कि मैं tough हो गया। बल्कि इसलिए कि मैंने plumbing ठीक कर दी। 🫶
Pipeline वाला problem
खुद को एक pipeline की तरह सोचो — एक system जो inputs लेता है (tasks, emails, meetings, decisions, crises) और outputs produce करता है (काम, solutions, support)।
हर pipeline की एक throughput होती है — maximum rate जो वो handle कर सकता है बिना टूटे। तीन नलों के लिए बनी पाइप में बारह नल लगा दो तो फट जाएगी। कोई पाइप को blame नहीं करता। Blame उसे करते हैं जिसने overload किया।
लेकिन जब कोई इंसान "फटता" है — resign करता है, breakdown होता है, medical leave पर जाता है — तो हम इंसान को blame करते हैं। "उसे better boundaries set करनी चाहिए थीं।" ये पाइप को blame करना है जबकि बारह नलों को ignore कर रहे हो।
Aflac WorkForces Report October 2025 के मुताबिक 72% U.S. employees moderate से very high workplace stress face कर रहे हैं — छह साल का high। India की IT industry में तो हालात और भी बुरे हैं — यहाँ burnout लगभग normalize हो चुका है। Advice industry ने और meditation apps launch कर दिए। Plumbing वैसी की वैसी टूटी रही।
Burnout एक throughput problem है। System इंसान की processing capacity से ज़्यादा inputs push करता है। Fix stronger इंसान नहीं है। Fix है — कम inputs, better routing, या ज़्यादा लोग।
पाँच system failures जो लोगों को जला देती हैं
मैंने ये same patterns अलग-अलग companies में अलग-अलग लोगों को destroy करते देखे हैं। ये personality failures नहीं हैं। Design failures हैं।
1. कोई input filtering नहीं। Client request, Slack का joke, critical bug, और meeting invite — सब एक ही inbox में, एक ही urgency level पर। Filtering के बिना तुम arrival order में process करते हो — critical काम trivia के पीछे फँसा रहता है। Backlog बढ़ता है। Anxiety follow करती है।
Fix: Tiered input channels। Critical issues एक channel में जाएँ notifications के साथ। बाकी सब batch queue में, दिन में दो बार check करो। वही principle जो hospitals को first-come-first-served की जगह triage करवाता है।
2. कोई WIP limits नहीं। WIP limits — Kanban का concept, manufacturing से आया workflow management method — cap करते हैं कि एक वक़्त पर कितने tasks handle करोगे। बिना इनके, open tasks pile up होते जाते हैं: छह projects, बारह tasks, तीस email threads। हर एक mental RAM खाता है। वो crushing feeling किसी एक hard task से नहीं आती — तीस contexts को simultaneously दिमाग में hold करने से आती है, जो कोई human brain नहीं कर सकता।
Fix: Strict WIP limits। Maximum तीन active projects। चौथा आए? तीन में से एक pause या delegate हो। "Pile में add" नहीं। Actively trade करो। ⚙️
3. कोई queue visibility नहीं। तुम्हारा workload बाकी सबके लिए invisible है। तुम्हारे manager को नहीं पता कि तुम्हारे पास 47 open tasks हैं। Colleagues और add करते रहते हैं क्योंकि pile दिखता नहीं। तुम चुपचाप डूबते रहते हो क्योंकि इतने busy हो डूबने में कि surface होकर बोल नहीं पाते "मैं डूब रहा हूँ।"
Fix: Shared task boards। Surveillance के लिए नहीं — load balancing के लिए। जब सबको सबकी queue दिखती है, तो कोई notice करता है कि एक teammate triple load carry कर रहा है। अच्छी teams बिना माँगे redistribute करती हैं।
4. Sprints के बीच कोई recovery नहीं। Sprint — Scrum methodology में usually 1-2 हफ़्ते का fixed work cycle — Friday को खत्म होता है। नया sprint Monday को शुरू। कोई buffer नहीं। साँस लेने की जगह नहीं। Accumulated debt के लिए time नहीं: documentation, cleanup, learning, rest। छह महीने back-to-back sprints, और लोग fumes पर चलने लगते हैं।
Fix: हर चौथा sprint cool-down sprint हो। आधी work capacity। Focus debt, learning, experiments पर। जो companies ये करती हैं, उनका sustained output साल भर में ज़्यादा होता है, क्योंकि 80% पर indefinitely cruise करने वाले लोग 100% पर sprint करके collapse होने वालों से बेहतर perform करते हैं। ⚙️
5. कोई escalation path नहीं। तुम्हारे पास कोई formal तरीका नहीं "ये बहुत ज़्यादा है" बोलने का, बिना failure feel किए। Overload का कोई process नहीं। बस वो unspoken expectation कि अच्छे workers जो भी आए absorb कर लेते हैं।
Fix: Explicit overload protocol। जब queue capacity से ज़्यादा हो, lead को notify करो: "मेरे पास X tasks हैं, capacity Y की है। ये हैं मेरे recommended cuts।" ये complain करना नहीं है। ये operational reporting है। Aircraft pilots fuel levels के साथ ये करते हैं। Knowledge workers को cognitive load के साथ करना चाहिए।
"बस ना बोल दो" bad engineering क्यों है
सबसे popular burnout advice — "boundaries set करो," "ना बोलना सीखो" — पूरा burden individual पर डाल देती है कि वो एक ऐसे system को resist करे जो maximum output extract करने के लिए design किया गया है।
सोचो एक assembly line worker से कहा जाए: "Overwhelm feel हो तो conveyor belt slow कर दो।" वो नहीं कर सकता। Belt speed management, clients, और market pressure set करते हैं। Worker को "boundaries set करो" बोलना जबकि line speed वही रहे — ये advice के भेस में cruelty है।
Individual boundaries matter करती हैं। लेकिन ये last line of defense हैं, first नहीं। First line है ऐसे systems design करना जिनमें survive करने के लिए heroic effort की ज़रूरत न पड़े। 🫶
Average-person test
मैं ये test हर team पर apply करता हूँ: क्या एक perfectly average इंसान यहाँ thrive कर सकता है? Superhero नहीं। Flawless discipline और zero personal problems वाला नहीं। एक अच्छा, competent, normal इंसान।
अगर जवाब ना है — अगर system तभी चलता है जब exceptional लोगों को peak capacity पर बिना किसी bad day के लगाओ — तो system टूटा हुआ है। World Health Organization ने burnout को May 2019 में "occupational phenomenon" classify किया था, medical condition नहीं — ये acknowledge करते हुए कि primary factor workplace है, worker नहीं।
Plumbing ठीक करने के बाद क्या बदला
जब मैंने अपने workflows को इन principles के साथ rebuild किया, तीन चीज़ें हुईं।
Sustained output 20% बढ़ गया जबकि working hours 15% कम हुए। Contradiction नहीं है — unnecessary काम कम हुआ, efforts के बीच proper recovery मिली।
Monday से डर लगना बंद हो गया। इसलिए नहीं कि अचानक काम से प्यार हो गया, बल्कि इसलिए कि Monday का load visible, bounded, और achievable था। कोई surprise avalanche नहीं।
तीन साल में पहली असली छुट्टी ली। दो हफ़्ते, कोई laptop नहीं। Systems मेरे बिना चलते रहे क्योंकि वो एक इंसान पर depend नहीं थे। कुछ नहीं गिरा। ये असली test है: अगर तुम्हारे बिना operation बिखर जाए, तो वो system नहीं है — वो एक इंसान है जो system होने का नाटक कर रहा है।
March 2026 तक, tech और knowledge work में burnout rates stubbornly high बने हुए हैं। Advice industry personal resilience बेचती रहती है। लेकिन तुम फटी हुई पाइप को ये बोलकर ठीक नहीं करते कि "और मज़बूत हो जाओ।" तुम उस system को ठीक करते हो जो उसमें से ज़रूरत से ज़्यादा push कर रहा है। 🫶
