तुम तेज़ चल रहे हो। Tasks board से उड़ रहे हैं। Slack messages का तुरंत reply। Code compile हुआ नहीं कि deploy हो गया। लगता है velocity है। दिखता है progress।
ज़्यादातर fake है।
Military operations में एक कहावत है: "Slow is smooth, smooth is fast." मतलब ये कि जल्दबाज़ी से गलतियाँ होती हैं, गलतियों से rework होता है, और rework में उतना वक़्त लगता है जितने में पहली बार सही से कर लेते। Deliberately चलो — धीमे नहीं, deliberately — तो frantically भागने से ज़्यादा तेज़ results आते हैं।
मैं पहले disagree करता था। फिर मैंने numbers track किए। 🧘
Rush tax
October 2025 में मैंने पूरे महीने हर task log किया। हर task को दो timestamps मिले: कब मैंने "finish" किया और कब actually complete हुआ — कोई follow-up नहीं, कोई bug fix नहीं, कोई "अरे यार, ये edge case तो भूल ही गया।"
"Finish" और "actually complete" के बीच का gap — इसे मैं rush tax कहता हूँ।
| Task type | "Finish" का time | Rush tax (rework) | Total time | Deliberately करने पर |
|---|---|---|---|---|
| Feature dev | 4 घंटे | 2.5 घंटे (bugs) | 6.5 घंटे | 5.5 घंटे |
| Config changes | 15 मिनट | 45 मिनट (गलत env) | 60 मिनट | 25 मिनट |
| Email responses | 2 मिनट | 15 मिनट (clarifications) | 17 मिनट | 8 मिनट |
| Deploy | 10 मिनट | 90 मिनट (rollback + fix) | 100 मिनट | 20 मिनट |
| Documentation | 30 मिनट | 3 घंटे (corrections) | 3.5 घंटे | 1.5 घंटे |
Pattern ये: जल्दबाज़ी से initial pass में 20–40% time बचा और rework में 50–200% खर्च हुआ।
Deploy वाली row देखो। Deploy — code को live server पर push करना ताकि users को changes दिखें — rushed करो तो 10 मिनट लगते हैं, कुछ टूटता है, और rollback समेत total 100 मिनट लगते हैं। Deliberately 20 मिनट का deploy proper checks के साथ — बस 20 मिनट। Rushed version 5 गुना धीमा है।
पूरे महीने में rush tax कुल मिलाकर हफ़्ते के करीब 12 घंटे था। यानी 30% productive time अपने ही हाथों की तबाही ठीक करने में गया। DORA State of DevOps report बड़े scale पर यही pattern confirm करती है: जिन teams की deploy frequency ज़्यादा है लेकिन proper safeguards हैं, वो हमेशा उन teams से आगे रहती हैं जो बस fast push करके भगवान भरोसे बैठ जाती हैं। ⚙️
Three-breath rule
October के ये numbers देखने के बाद मैंने एक simple चीज़ शुरू की: कोई भी action लेने से पहले जो production को touch करता हो — वो live system जिस पर real users depend हैं — या 5 से ज़्यादा लोगों को message भेजता हो, या code commit करता हो, मैं तीन साँसें लेता हूँ। दस सेकंड। Meditation नहीं। बस एक pause।
उन दस सेकंड में एक सवाल: "मैं क्या करने वाला हूँ, और क्या गलत हो सकता है?"
October 2025 से March 2026 के बीच, इस rule ने चार incidents रोके:
- November 2025, deploy से पहले: "रुक — migrations locally run नहीं किए।" एक migration — database structure बदलने वाली script — में bug था जो live system से एक data column permanently delete कर देता।
- December 2025, client email से पहले: "ये तो aggressive लग रहा है। दूसरा paragraph थोड़ा soft करूँ।" उस pause ने relationship बचा ली।
- January 2026, config change से पहले: "ये production config है, staging नहीं।" Staging — तुम्हारे system की test copy। मैं test settings real system पर push करने वाला था। Service down हो जाती।
- March 2026, PR merge से पहले: PR (pull request) — code change जो team approval का इंतज़ार कर रहा है। चौदह files changed, मैंने आठ review किए थे। बाकी review किए — file 11 में SQL injection मिला। ये वो vulnerability है जहाँ attacker input fields के ज़रिए तुम्हारा database manipulate कर सकता है।
कुल चालीस सेकंड का pause। बीस से ज़्यादा घंटों का rework रुका। ये है math।
तेज़ productive क्यों लगता है
Speed visible activity generate करती है। Tasks check off होते हैं। Messages उड़ते हैं। Code land होता है। Completed items का dashboard ऊपर चढ़ता है। लगता है जीत रहे हो।
लेकिन एक task जो done हुआ और फिर undo हुआ — bug की वजह से, miscommunication से, missed requirement से — उसका net impact zero था। Time दो बार खर्च हुआ, value शून्य बार deliver हुई।
तुम 60 घंटे काम करो और 35 घंटे के deliberately किए गए हफ़्ते से कम real value ship करो। मैंने दोनों जिए हैं। 35 घंटे वाले हफ़्ते में मैंने हर task एक बार, सही तरीके से complete किया। 60 घंटे वाले में आधे tasks दो बार किए — पहले fast, फिर right।
जो सबसे effective operators मैं जानता हूँ, वो slow दिखते हैं। Code लिखने से पहले पूरी spec पढ़ते हैं। शुरू करने से पहले clarifying questions पूछते हैं। Friday रात नहीं, Monday सुबह deploy करते हैं। दिन में कम चीज़ें finish करते हैं और लगभग कुछ redo नहीं करते। महीने भर में ज़्यादा ship करते हैं। साल भर में तो comparison ही नहीं। 📋
Slowness as a system
"ज़्यादा careful रहो" काम नहीं करता। अगला crisis आएगा तो वापस जल्दबाज़ी पर आ जाओगे। Principle तुम्हारे tools में होना चाहिए, intentions में नहीं।
Surgeon Atul Gawande ने medicine और aviation के लिए यही case The Checklist Manifesto में बनाया। वही logic ops पर apply होता है।
Deploy checklists. एक script — तुम्हारी memory नहीं — verify करे: tests pass, migrations locally tested, health check updated, rollback ready। पाँच मिनट। किसी भी जल्दबाज़ी से ज़्यादा incidents रोकता है।
Message delay. Emails और Slack messages तुरंत लिखो, 30 मिनट बाद भेजने के लिए schedule करो। उस window में tone problems, missing attachments, और गलत numbers पकड़ में आ जाएँगे जिनके लिए शर्मनाक follow-ups भेजने पड़ते।
PR cooling period. कोई भी pull request open होने के 2 घंटे के अंदर merge नहीं होता। Review 10 मिनट में हो जाए, तब भी wait करो। Fresh eyes — चाहे तुम्हारी अपनी हों — distance के बाद बेहतर काम करती हैं।
Incident response delay. Alert आए तो act करने से पहले 2 मिनट रुको (full outage हो तो छोड़ो)। Google का SRE handbook भी यही कहता है: करीब 30% alerts कुछ ही मिनटों में अपने आप resolve हो जाते हैं। Self-resolving alert पर act करना time waste और चीज़ें और बिगाड़ने का risk। दो मिनट का patience 30% false starts खत्म कर देता है।
Capybara principle
Capybaras जल्दी नहीं करते। Panic नहीं करते। गर्म पानी के कुंड में बैठे रहते हैं जबकि दुनिया उनके चारों तरफ भागती रहती है। और किसी तरह वो South America की सबसे successful species में से हैं — वहाँ flourish करते हैं जहाँ ज़्यादा aggressive जानवर struggle करते हैं।
Capybara fast होकर survive नहीं करता। Consistent, calm और deliberate रहकर करता है। Manufactured urgency पर energy waste नहीं करता। Capacity बचाकर रखता है उन moments के लिए जब genuinely action की ज़रूरत हो।
लगभग कुछ भी उतना urgent नहीं है जितना लगता है। वो Slack message जिसका "अभी जवाब चाहिए" — एक घंटा रुक सकता है। वो "critical" bug usually important है लेकिन time-sensitive नहीं। वो deploy जो "आज ही जाना चाहिए" — usually इस हफ़्ते जाना ही काफ़ी है। Real urgency — service down, data breach, active security incident — महीने में शायद एक बार आती है। बाकी सब manufactured है — खराब planning से, unclear priorities से, या इस cultural assumption से कि faster हमेशा better होता है।
जब तुम हर चीज़ को urgent मानना बंद करते हो, दो चीज़ें होती हैं। तुम्हारे काम की quality बढ़ती है। और जब कुछ genuinely urgent होता है, तुम्हारे पास handle करने की capacity होती है — क्योंकि तुमने routine tasks को emergencies की तरह treat करके अपने reserves नहीं जलाए। 🍵
Deliberately चलो। ऐसी चीज़ें बनाओ जो टूटें नहीं। Monday को शांति से deploy करने वाली team हमेशा Friday को panic-deploy करने वाली team से आगे रहेगी — इसलिए नहीं कि वो ज़्यादा talented हैं, बल्कि इसलिए कि वो अपना आधा हफ़्ता अपनी ही गलतियाँ ठीक करने में नहीं बिताते।
Slow is smooth. Smooth is fast. और fast, ironically, slow है। 🫶
