Async-First इंजीनियरिंग टीम कैसे चलाएं
Async-first इंजीनियरिंग टीमों के लिए व्यावहारिक प्लेबुक – संचार नियमों से निर्णय-निर्माण की आदतों तक जो वास्तव में काम करती हैं।
By Ellis Keane · 2026-04-06
जब टेलीग्राफ ने रोज़ाना की ब्रीफिंग को खत्म किया
1844 में, Samuel Morse ने वाशिंगटन और बाल्टीमोर के बीच पहला टेलीग्राफ संदेश भेजा, और एक दशक के भीतर, जो व्यवसाय रोज़ाना के कूरियर ब्रीफिंग पर निर्भर थे, वे अलग तरह से काम करने लगे। इसलिए नहीं कि वे "टेलीग्राफ-फर्स्ट" बनना चाहते थे (ऐसा कोई नहीं कहता था), बल्कि इसलिए कि बाधा बदल गई थी। सूचना एक घोड़े से तेज़ यात्रा कर सकती थी, इसलिए घोड़ों के इर्द-गिर्द बने अनुष्ठान चुपचाप अनावश्यक हो गए।
Async-first इंजीनियरिंग टीम चलाने के साथ यह समानांतर असुविधाजनक रूप से सीधा है। हमारे पास Slack, Linear, GitHub, Notion और लगभग सात अन्य टूल हैं जो वेबहुक की गति से सूचना ले जाते हैं – फिर भी अधिकांश टीमें अभी भी अपने दिन उन समकालिक अनुष्ठानों के इर्द-गिर्द व्यवस्थित करती हैं जो तब के लिए बनाए गए थे जब कॉन्टेक्स्ट साझा करने के लिए एक ही कमरे में होना पड़ता था: रोज़ाना का standup जहाँ हर कोई अपने Jira टिकट उस manager को सुनाता है जिसके पास पहले से दूसरे मॉनिटर पर वही बोर्ड खुला है; "quick sync" जो 45 मिनट तक चलती है क्योंकि तीन लोग बारी-बारी से स्क्रीन शेयर कर रहे हैं जबकि बाकी सब अपना फोन देखते हैं।
हमारी जैसी छोटी इंजीनियरिंग टीम के लिए – तीन टाइम ज़ोन में चार लोग – यह पहचानना कि बाधा बदल गई है, आसान हिस्सा था। अनुष्ठानों को फिर से बनाने में अधिक समय लगा।
Async-first इंजीनियरिंग टीम वास्तव में कैसी दिखती है
Async-first इंजीनियरिंग का मतलब है कि आपकी टीम का डिफ़ॉल्ट संचार मोड असिंक्रोनस है। निर्णय लिखे जाते हैं। स्टेटस पूछे बिना दिखता है। कॉन्टेक्स्ट वहाँ दस्तावेज़ीकृत है जहाँ लोग अपने शेड्यूल पर इसे खोज सकते हैं। मीटिंग अभी भी होती हैं, लेकिन वे वह अपवाद हैं जिनमें आप जानबूझकर शामिल होते हैं, न कि वह डिफ़ॉल्ट जिससे आपको बाहर निकलना पड़ता है।
इसका यह मतलब नहीं है कि कोई कभी रियल टाइम में बात नहीं करता – जो बेतुका और, ईमानदारी से, थोड़ा अकेलापन देने वाला होगा। डिज़ाइन रिव्यू, संघर्ष समाधान, ब्रेनस्टॉर्मिंग सेशन और उस तरह की सूक्ष्म आर्किटेक्चरल चर्चाएँ जहाँ आपको बॉडी लैंग्वेज पढ़नी होती है और व्हाइटबोर्ड पर चित्र बनाने होते हैं – ये सब समकालिक ही रहती हैं, और यह ठीक है। अंतर यह है कि जब आपको कुछ संचार करना हो तो आप पहले किस मोड को चुनते हैं – और इंजीनियरिंग टीम में अधिकांश चीज़ों के लिए, जवाब होना चाहिए: कॉल शेड्यूल करने की बजाय लिखना। क्योंकि न्यूयॉर्क में दोपहर 2 बजे एक अच्छी तरह लिखी गई Linear टिप्पणी अगले दिन सुबह 9 बजे दिल्ली में भी उतनी ही समझ में आती है।
Async-first का मतलब async-only नहीं है। इसका मतलब है कि आपका डिफ़ॉल्ट असिंक्रोनस है, और जब स्थिति वास्तव में इसकी माँग करे तो आप सोच-समझकर समकालिक संचार चुनते हैं।
चार स्तंभ (जो तब तक स्पष्ट लगते हैं जब तक आप इन्हें आज़माते नहीं)
पिछले एक साल में, हमने Sugarbug को US East Coast और यूरोप में फैली चार लोगों की टीम के रूप में बनाया है। जिस चीज़ ने हमारी async-first इंजीनियरिंग टीम को वास्तव में काम कराया, वह टूल या नीतियाँ नहीं थीं – वे आदतें थीं। यहाँ वे चार आदतें हैं जो टिकीं।
1. निर्णयों को वहीं लिखें जहाँ वे हुए
लगभग कोई भी इसे लगातार नहीं करता। एक Slack थ्रेड में निर्णय लिया जाता है। कोई कहता है "ठीक है, Option B लेते हैं।" और फिर... वह वहीं रहता है। एक थ्रेड में जो तीन हफ्ते में व्यावहारिक रूप से ढूँढ़ने योग्य नहीं रहेगा।
समाधान एक निर्णय लॉग नहीं है (खैर, मुख्य रूप से नहीं)। समाधान एक नियम है: जो भी अंतिम निर्णय लेता है, वह एक वाक्य में यह सारांश लिखता है कि क्या तय हुआ और क्यों – उस टूल में जहाँ काम होता है। यदि आपने API रिस्पॉन्स फॉर्मेट बदलने का फैसला किया, तो वह सारांश Linear issue या GitHub PR विवरण में जाता है, न कि किसी Slack थ्रेड या मीटिंग ट्रांसक्रिप्ट में जिसे कोई दोबारा नहीं देखेगा।
हमने इसे महँगे तरीके से सीखा: एक PR तीन दिन रिव्यू में पड़ा रहा क्योंकि रिव्यूअर को नहीं पता था कि हमने उस पेज के लिए सर्वर-साइड रेंडरिंग का फैसला कर लिया था – निर्णय पिछले हफ्ते के एक Slack थ्रेड में दबा था, और किसी ने इसे issue में नहीं लिखा था। रिव्यूअर ने client-side hydration के ट्रेड-ऑफ पर छह टिप्पणियाँ छोड़ीं जो पहले ही तय हो चुकी थीं, author निराश हो गया, और हमने लगभग एक हफ्ता उस बातचीत में गँवाया जो दस सेकंड में खत्म हो सकती थी अगर कॉन्टेक्स्ट शुरू से काम से जुड़ा होता।
उसके बाद, हमने एक अलग निर्णय दस्तावेज़ बनाए रखने की कोशिश बंद कर दी (जो लगभग दो हफ्ते काम करता रहा, फिर एक और चीज़ बन गई जिसे कोई अपडेट नहीं करता) और issue में सीधे निर्णय लिखने लगे। दस सेकंड का प्रयास, और यह बचता है क्योंकि यह काम से जुड़ा है, किसी मेटा-दस्तावेज़ में तैर नहीं रहा जिसे कोई देखता नहीं।
2. स्टेटस को दिखाएं, रिपोर्ट न करवाएं
हमारी टीम के लिए, स्टेटस अपडेट मीटिंग सबसे महँगा समकालिक अनुष्ठान था – हर व्यक्ति बताता है कि उसने कल क्या किया और आज क्या करेगा जबकि बाकी सब आधे मन से सुनते हैं और अपनी बारी का इंतज़ार करते हैं। Async-first टीम में, स्टेटस वह चीज़ होनी चाहिए जो आप देख सकें, न कि वह जो कोई आपको बताए।
इसका मतलब है कि आपका प्रोजेक्ट मैनेजमेंट टूल वास्तव में हकीकत को दर्शाना चाहिए। यदि कोई Linear issue "In Progress" में है, तो इसलिए क्योंकि कोई इस पर अभी सच में काम कर रहा है, न कि इसलिए कि उसने इसे सोमवार को वहाँ रखा और तब से छुआ नहीं। GitHub PRs के वर्णनात्मक शीर्षक और लिंक किए गए issues होने चाहिए। Figma फ़ाइलें स्पष्ट नामकरण के साथ होनी चाहिए जो बताती हो कि क्या प्रगति में है और क्या अनुमोदित है।
स्टेटस को क्या दृश्यमान बनाता है
- Issues से जुड़े PRs – कोई भी देख सकता है कि कौन-सा कोड किस टास्क से जुड़ा है
- स्पष्ट ब्रांच नामकरण –
feat/user-onboarding-flow, fix-stuff से अधिक बताता है
- अपडेट किए गए issue स्टेट – टिकट तब मूव करें जब काम वास्तव में आगे बढ़े, standup के दौरान नहीं
- साप्ताहिक लिखित सारांश – एक व्यक्ति digest लिखता है, सभी इसे असिंक्रोनस रूप से पढ़ते हैं
स्टेटस को क्या अदृश्य रखता है
- केवल मौखिक अपडेट – मीटिंग खत्म होते ही जानकारी गायब हो जाती है
- स्टेटस मीटिंग रिकॉर्ड के रूप में – अगर standup में नहीं कहा तो हुआ ही नहीं
- पुराने बोर्ड – एक Kanban बोर्ड जिसे सोमवार से छुआ नहीं गया
- DMs में बंद कॉन्टेक्स्ट – दो लोग जानते हैं, बाकी सब अनुमान लगाते हैं
3. रिस्पॉन्स टाइम नहीं, रिस्पॉन्स विंडो तय करें
असिंक्रोनस संचार की सबसे सूक्ष्म चिंताओं में से एक है खुला इंतज़ार। आप एक संदेश भेजते हैं, और आपको नहीं पता कि जवाब बीस मिनट में आएगा या कल दोपहर को। अनिश्चितता वास्तविक देरी से बुरी है।
समाधान तेज़ जवाब की माँग करना नहीं है (यह बस अतिरिक्त चरणों के साथ समकालिक संस्कृति को फिर से बनाता है)। यह विभिन्न प्रकार के संचार के लिए रिस्पॉन्स विंडो के बारे में स्पष्ट अपेक्षाएँ तय करना है। हमारी टीम में यह लगभग ऐसा दिखता है:
- सार्वजनिक चैनलों में Slack संदेश: 4 कार्य घंटों के भीतर
- PR रिव्यू: एक कार्य दिवस के भीतर
- Linear issue टिप्पणियाँ: एक कार्य दिवस के भीतर
- अर्जेंट चिह्नित DMs: कार्य घंटों के दौरान 1 घंटे के भीतर
- बाकी सब: 2 कार्य दिवसों के भीतर
विशिष्ट विंडो उतनी महत्वपूर्ण नहीं हैं जितना कि यह तथ्य कि वे मौजूद हैं और सभी ने उन पर सहमति दी है। जब लय स्पष्ट हो जाती है, "क्या उन्होंने यह देखा?" की चिंता चली जाती है, और लोग तीस मिनट की चुप्पी के बाद फॉलो-अप संदेश भेजना बंद कर देते हैं।
4. जो वास्तव में ज़रूरी है उसके लिए समकालिक समय बचाएं
कुछ जो हमें उम्मीद नहीं थी: जो मीटिंग हमने रखीं वे ध्यान देने योग्य रूप से बेहतर हो गईं। जब मीटिंग डिफ़ॉल्ट के बजाय अपवाद हो, तो लोग तैयार और सक्रिय आते हैं क्योंकि वे जानते हैं कि यह एकमात्र खिड़की है जिसमें वे कुछ मिलकर सुलझा सकते हैं।
हमने तीन प्रकार की समकालिक मीटिंग रखीं:
- साप्ताहिक टीम सिंक (अधिकतम 30 मिनट) – स्टेटस अपडेट नहीं, बल्कि ब्लॉकर, क्रॉस-कटिंग चिंताएँ और "क्या कोई और भी सोचता है कि यह आर्किटेक्चरल निर्णय हमें परेशान करेगा?" जैसी बातचीत
- डिज़ाइन रिव्यू – कुछ चीज़ों को सच में समकालिक दृश्य प्रतिक्रिया की ज़रूरत होती है
- Pair programming सेशन – जब दो लोग फँसे हों, तो मिलकर बात करना अभी भी async के आगे-पीछे से तेज़ है
बाकी सब जो पहले मीटिंग थी, वह एक लिखित प्रस्ताव, एक Loom वीडियो या संबंधित issue पर एक टिप्पणी थ्रेड बन गई। हमारा कैलेंडर Tetris के खेल जैसा नहीं रहा, बल्कि कुछ ऐसा जिसके इर्द-गिर्द एक इंसान वास्तव में काम कर सके – जो, जैसा पता चलता है, कैलेंडर रखने का पूरा मतलब ही है।
stat: "3 मीटिंग/सप्ताह" headline: "12 से नीचे" source: "Async-first अपनाने के बाद हमारी टीम का वास्तविक कैलेंडर"
वह हिस्सा जिसके बारे में कोई नहीं बताता
Async-first का कठिन हिस्सा संचार नियम या टूल सेटअप नहीं है। यह भावनात्मक समायोजन है। जब हमने अपना रोज़ाना का standup बंद किया, तो हमारे एक इंजीनियर ने कहा कि किसी से चेक-इन किए बिना सुबह 10 बजे गहरे काम में लगना "अजीब तरह से दोषी" लग रहा था। दूसरे ने कहा कि दोपहर से पहले Slack पर चुप्पी ऐसा लगाती थी जैसे कोई काम नहीं कर रहा, जबकि GitHub हर घंटे commits दिखा रहा था।
यह समस्या का मानवीय-स्वभाव वाला हिस्सा है, और इसका कोई सिस्टम-स्तरीय समाधान नहीं है। जो चीज़ हमारे काम आई वह थी इसके बारे में खुलकर बात करना। हमने बात की कि async कभी-कभी अकेला महसूस करा सकता है, और यह ठीक है अगर आप किसी को सिर्फ इसलिए कॉल करें क्योंकि आप उस समस्या के बारे में किसी इंसान से बात करना चाहते हैं जिसे आप सुलझा रहे हैं। नियम "कभी कॉल न करें" नहीं है – यह है "जिन चीज़ों को कॉल की ज़रूरत नहीं उनके लिए कॉल की माँग न करें।"
टीम के कुछ लोग वास्तव में अधिक समकालिक बातचीत पसंद करते हैं, और इसे समायोजित करना async-first दर्शन की विफलता नहीं है – यह यह स्वीकार करना है कि संचार प्राथमिकताएँ व्यक्तिगत होती हैं, और किसी एक मोड पर कठोर रूप से टिके रहना अपने आप में एक तरह की खराबी है।
कठिन हिस्सा async वर्कफ़्लो सेट करना नहीं है। यह संदेशों के बीच की चुप्पी के साथ सहज होना है, और यह भरोसा करना है कि आपके साथी काम कर रहे हैं भले ही आप उन्हें ऐसा करते न देख सकें। attribution: Ellis Keane
इसे टिकाऊ बनाना: पहले 30 दिन
यदि आप किसी मौजूदा टीम को async-first इंजीनियरिंग टीम मॉडल में बदल रहे हैं, तो पहला महीना वह है जहाँ यह या तो जड़ें जमाता है या चुपचाप "बस एक quick call करते हैं" में वापस चला जाता है। यहाँ एक मोटी समय-सीमा के रूप में वह है जो हमारे लिए काम किया:
सप्ताह 1: संचार नियमों को लिख लें। सचमुच – एक पेज का दस्तावेज़ जो कहता है "हम इस तरह संचार करते हैं, ये अपेक्षित रिस्पॉन्स विंडो हैं, यह चीज़ मीटिंग को उचित ठहराती है।" इसे साझा करें, इसपर समकालिक रूप से चर्चा करें (हाँ, विडंबना), और सहमति प्राप्त करें।
सप्ताह 2: तीन आवर्ती मीटिंग रद्द करें या बदलें। वे चुनें जो सबसे स्पष्ट रूप से छुपे हुए स्टेटस-अपडेट हों और उन्हें एक लिखित फॉर्मेट से बदलें। एक साथ सब कुछ रद्द न करें – लोगों को एक क्रमिक ढलान चाहिए, न कि सीधी खाई।
सप्ताह 3: अपने टूल की स्वच्छता की जाँच करें। क्या Linear issues वास्तव में अपडेट हैं? क्या PR विवरण उपयोगी हैं? क्या निर्णय उन जगहों पर लिखे जा रहे हैं जहाँ काम होता है? यदि नहीं, तो यह उन नियमों को स्थापित करने का सप्ताह है। किसी को "async champion" के रूप में नियुक्त करें जो धीरे से याद दिलाए जब कोई निर्णय मौखिक रूप से लिया जाए लेकिन लिखा न जाए।
सप्ताह 4: रेट्रोस्पेक्टिव (स्वाभाविक रूप से, असिंक्रोनस)। एक सरल फॉर्म भेजें: "क्या काम कर रहा है? क्या नहीं? आपको क्या याद आ रहा है?" जवाब आपको चौंकाएंगे – कुछ लोग शांति से प्यार करेंगे, अन्य संघर्ष कर रहे होंगे। वास्तविक फीडबैक के आधार पर नियमों को समायोजित करें, न कि सिद्धांत के आधार पर।
- [x] संचार नियम दस्तावेज़ लिखें
- [x] प्रत्येक चैनल के लिए रिस्पॉन्स विंडो परिभाषित करें
- [ ] 3 स्टेटस मीटिंग रद्द करें या बदलें
- [ ] टूल स्वच्छता की जाँच करें (issues, PRs, निर्णय दस्तावेज़)
- [ ] संक्रमण के लिए async champion नियुक्त करें
- [ ] 30 दिनों के बाद असिंक्रोनस रेट्रोस्पेक्टिव चलाएं
- [ ] टीम फीडबैक के आधार पर नियम समायोजित करें
जब async-first गलत विकल्प है
कई सामान्य स्थितियों में async-first उचित नहीं है। यदि आपकी टीम एक ही कार्यालय में बैठे तीन लोग हैं, तो समकालिक संचार शायद ठीक है और async नियमों को औपचारिक बनाने का भार एक ऐसी समस्या को हल करेगा जो आपके पास है ही नहीं। इसी तरह, यदि आपकी टीम वास्तविक संकट में है – प्रोडक्शन डाउन है, एक महत्वपूर्ण लॉन्च आसन्न है, या आप प्रोडक्ट की दिशा बदल रहे हैं – तो यह समकालिक क्षेत्र है, और अन्यथा दिखावा करना व्यावहारिक के बजाय हठधर्मी होगा।
Async-first उन टीमों के लिए सबसे अच्छा काम करता है जो टाइम ज़ोन में वितरित हैं, लगभग पाँच से अधिक लोगों की टीमों के लिए (जहाँ समकालिक समन्वय का संयोजनात्मक विस्फोट दर्द देना शुरू करता है), और उन टीमों के लिए जो जो शिप किया उसके बारे में मीटिंग में बताने के बजाय कोड शिप करना पसंद करती हैं। यदि यह आप हैं, तो async नियमों में निवेश पहले महीने में ही अपना मूल्य वसूल कर लेता है, मुख्यतः उन इंजीनियरिंग घंटों की वसूली में जो पहले मीटिंग-औद्योगिक परिसर में गायब हो जाते थे।
टेलीग्राफ ने आमने-सामने की बातचीत को खत्म नहीं किया – इसने बस रोज़ाना की कूरियर सवारी को अनावश्यक बना दिया। Async-first एक इंजीनियरिंग टीम के लिए बस यही करता है: यह उन अनुष्ठानों को सेवानिवृत्त करता है जो केवल इसलिए अस्तित्व में थे क्योंकि टूल अभी तक पकड़ नहीं पाए थे, और उन बातचीत को बचाता है जो वास्तव में मायने रखती हैं।
अक्सर पूछे जाने वाले प्रश्न
Q: Async-first इंजीनियरिंग टीम में कोड रिव्यू कैसे संभालें? A: एक स्पष्ट रिव्यू SLA तय करें (हमारे यहाँ एक कार्य दिवस है) और PR विवरण को मुख्य काम करने दें – सिर्फ यह नहीं बताएं कि क्या बदला बल्कि क्यों बदला, संबंधित issue को लिंक करें, और जो भी रिव्यूअर को ध्यान देना चाहिए उसे हाइलाइट करें। Async रिव्यू में सबसे बड़ी विफलता वह PR है जो तीन दिन पड़ा रहता है क्योंकि रिव्यूअर को ऐसा कॉन्टेक्स्ट चाहिए जो किसी के दिमाग में ही है। लिख दीजिए – या बाद में कीमत चुकाएं।
Q: क्या Sugarbug async-first वर्कफ़्लो में मदद करता है? A: यह उस विशिष्ट समस्या में मदद करता है जहाँ कॉन्टेक्स्ट टूल्स के बीच बिखर जाता है – Slack में एक निर्णय, Linear में एक टास्क, Figma में एक डिज़ाइन टिप्पणी। Sugarbug उन सिग्नल को जोड़ता है ताकि स्टेटस बिना किसी मीटिंग में बताए दिखे। यह उस समस्या को हल करने का एकमात्र तरीका नहीं है (आप हर चीज़ को मैन्युअल रूप से क्रॉस-लिंक करने में भी बहुत अनुशासित हो सकते हैं), लेकिन हमने इसे इसलिए बनाया क्योंकि हम मैन्युअल संस्करण से थक गए थे।
Q: Async-first अपनाते समय टीमें सबसे बड़ी गलती क्या करती हैं? A: इसे आदत बदलाव की बजाय नीति बदलाव समझना। आप एक सुंदर "संचार नियम" दस्तावेज़ लिख सकते हैं, लेकिन यदि लोग वास्तव में अपने Linear issues अपडेट नहीं करते या निर्णय PRs में नहीं लिखते, तो आपने बस मीटिंग हटा दी बिना सूचना प्रवाह बदले। नियमों को मांसपेशी स्मृति बनना होगा, जिसमें लगभग एक महीने का धीरे और लगातार टोकने की ज़रूरत होती है।
Q: Async-first टीम में तत्काल प्रोडक्शन समस्याओं को कैसे संभालें? A: उन्हें async तरीके से न संभालें – यही "async-first, async-only नहीं" का पूरा मतलब है। एक स्पष्ट एस्केलेशन पथ परिभाषित करें: वास्तविक आपात स्थितियों के लिए एक समर्पित Slack चैनल या PagerDuty, इस समझ के साथ कि बाकी सब सामान्य रिस्पॉन्स विंडो का पालन करता है। मुख्य अंतर "तत्काल" (प्रोडक्शन डाउन) और "मुझे अभी जवाब चाहिए" (जो आमतौर पर अधीरता है, तात्कालिकता नहीं) के बीच है।
Q: क्या Sugarbug standup मीटिंग को पूरी तरह बदल सकता है? A: यह सूचना-संग्रह वाले हिस्से को बदल सकता है – "कल सबने क्या किया?" वाला अनुष्ठान – क्योंकि वह कॉन्टेक्स्ट पहले से GitHub, Linear और Slack के ज़रिए बह रहा है। जो यह नहीं बदल सकता वह है मानवीय जुड़ाव का हिस्सा, इसीलिए हम उन बातचीत के लिए एक छोटी साप्ताहिक सिंक अभी भी रखते हैं जो एक ही (वर्चुअल) कमरे में होने से लाभ उठाती हैं।
सिग्नल इंटेलिजेंस सीधे अपने इनबॉक्स में पाएं।