टूल थकान वास्तविक है: Engineering Managers क्या करें
Engineering Managers बहुत सारे टूल्स के साथ काम करते हैं। टूल थकान कैसे काम करती है, इसकी लागत क्या है और कौन से सिस्टम-स्तरीय समाधान मदद करते हैं।
By Ellis Keane · 2026-03-31
मंगलवार की सुबह के 9:47 बजे हैं और Engineering Manager ने न कोड की एक भी लाइन लिखी है, न कोई pull request समीक्षा किया है, न टीम में किसी से असली इंजीनियरिंग काम के बारे में बात की है। वह Linear से स्टेटस के साथ एक Notion डॉक्युमेंट अपडेट कर रही थी, Slack थ्रेड को क्रॉस-रेफ़रेंस करके यह पता लगाने की कोशिश कर रही थी कि कोई निर्णय लिया गया था या सिर्फ चर्चा हुई थी, और यह याद करने की कोशिश कर रही थी कि कल देखा गया Figma कमेंट v2 मॉकअप पर था या v3 पर – क्योंकि नोटिफ़िकेशन में बताने के लिए पर्याप्त संदर्भ नहीं था।
अगर आप Engineering Manager हैं, तो आप शायद इस सुबह को पहचानते हैं, भले ही आपने इसे कभी टूल थकान नहीं कहा हो।
समस्या का स्वरूप
Engineering Managers के लिए टूल थकान वास्तव में बहुत सारे टूल्स होने के बारे में नहीं है (हालाँकि इसे आमतौर पर ऐसे ही प्रस्तुत किया जाता है)। यह इस बात के संज्ञानात्मक बोझ के बारे में है कि जानकारी कहाँ रहती है, उसे वहाँ किसने रखा और क्या वह अभी भी वर्तमान है – इसका मानसिक मॉडल बनाए रखना। स्टैक में हर टूल सच्चाई का एक अलग स्रोत है, और Engineering Manager का काम चुपचाप उन स्रोतों को एक ऐसी सुसंगत चीज़ में बुनना बन गया है जिससे निर्णय लिए जा सकें।
व्यवहार में यह इस तरह दिखता है। मान लीजिए आप छह इंजीनियरों की टीम प्रबंधित कर रहे हैं, और आपकी कंपनी Linear को प्रोजेक्ट ट्रैकिंग के लिए, GitHub को कोड के लिए, Slack को संचार के लिए, Figma को डिज़ाइन के लिए और Notion को दस्तावेज़ीकरण के लिए उपयोग करती है। ये पाँच टूल हैं – हम जिन अधिकांश स्टार्टअप से बात करते हैं उनके लिए यह ईमानदारी से कम है।
title: "एक Engineering Manager का मंगलवार की सुबह" 8:30 AM|ok|Linear खोलता है, सक्रिय स्प्रिंट स्कैन करता है। तीन issues «in progress» के रूप में चिह्नित हैं, कोई हालिया अपडेट नहीं। 8:42 AM|amber|GitHub पर जाता है यह जाँचने के लिए कि उन issues के लिए PRs मौजूद हैं या नहीं। दो हैं। एक नहीं है। 8:51 AM|ok|गायब PR के संदर्भ के लिए Slack जाँचता है। शुक्रवार का एक थ्रेड मिलता है जहाँ इंजीनियर ने एक ब्लॉकर का उल्लेख किया था। 9:03 AM|amber|ब्लॉकर एक Figma कमेंट का संदर्भ देता है। Figma खोलता है। डिज़ाइन फ़ाइल पर कमेंट थ्रेड स्क्रॉल करता है। 9:14 AM|missed|कमेंट मिल जाता है, लेकिन Linear issue को अपडेट किए बिना इसे resolve किया गया था। इंजीनियर को शायद पता नहीं कि ब्लॉकर हटा दिया गया था। 9:22 AM|amber|Slack पर इंजीनियर को DM करता है जाँचने के लिए। जवाब का इंतजार करता है। 9:31 AM|ok|अब तक जो सीखा है उसके साथ Notion स्टेटस डॉक्युमेंट अपडेट करता है। तीन पैराग्राफ, ज्यादातर इस बारे में कि वह अभी तक क्या नहीं जानती। 9:47 AM|missed|महसूस करती है कि उसने कोई असल प्रबंधन काम नहीं किया। बस सूचना पुरातत्व।
कहीं न कहीं, «Engineering Manager» की नौकरी का नाम «Human API Router» का विनम्र पर्याय बन गया है – कोई ऐसा व्यक्ति जिसका मुख्य कार्य उन सिस्टम के बीच संदर्भ लाने-ले जाने का है जो एक-दूसरे से बात करने से इनकार करते हैं।
यह कोई असाधारण सुबह नहीं है। यही बेसलाइन है। Engineering Managers के लिए टूल थकान का मतलब है कि टीम में क्या हो रहा है यह समझने का काम चुपचाप एक पूर्णकालिक डेटा इंटीग्रेशन अभ्यास बन गया है – और किसी ने इसे ऐसे नहीं सोचा था।
stat: "77 मिनट" headline: "प्रतिदिन औसत कॉन्टेक्स्ट-स्विचिंग में बिताया समय" source: "4 सप्ताहों में हमारी टीम के आंतरिक समय ट्रैकिंग के आधार पर"
यह बेहतर नहीं, बदतर क्यों होता है
टूल थकान बढ़ती है – और मैं यह उस व्यक्ति के रूप में कह रहा हूँ जिसने इसे अपनी टीम में होते देखा है। आप जो हर नया टूल जोड़ते हैं वह सिर्फ अपना ओवरहेड नहीं जोड़ता: यह मौजूदा टूल्स के बीच बनाए रखने वाले कनेक्शन को गुणा कर देता है।
5 टूल्स के साथ, आपके पास 10 संभावित पेयरवाइज़ कनेक्शन हैं। 8 के साथ, 28 हैं। 12 के साथ, 66 हैं। Engineering Manager को उन सभी कनेक्शन का सक्रिय उपयोग नहीं करना है, लेकिन उन्हें यह जानना होगा कि कौन से मौजूद हैं और कौन से टूटे हुए हैं, क्योंकि टूटा हुआ कनेक्शन ही वह जगह है जहाँ जानकारी खो जाती है।
और Engineering Management में जानकारी का नुकसान अमूर्त नहीं है। यह एक डिज़ाइनर है जिसे पता नहीं था कि उनका ब्लॉकर हल हो गया था, इसलिए उन्होंने अगली iteration शुरू करने से पहले दो दिन इंतजार किया। यह एक स्प्रिंट प्रतिबद्धता है जो मानती थी कि एक डिपेंडेंसी पूरी हो गई थी क्योंकि Linear का स्टेटस «complete» दिखा रहा था, लेकिन असली PR अभी भी review में था। यह साप्ताहिक sync मीटिंग है जहाँ पहले पंद्रह मिनट यह स्थापित करने में बिताए जाते हैं जो हर कोई व्यक्तिगत रूप से पहले से जानता था लेकिन साझा नहीं किया था, क्योंकि टूल्स ने उन सिग्नल को नहीं जोड़ा था।
टूल थकान टूल्स की संख्या के बारे में नहीं है। यह उनके बीच के अंतराल की संख्या के बारे में है और इस तथ्य के बारे में कि उन अंतरालों को बंद करना Engineering Manager का अनौपचारिक दूसरा काम बन गया है।
क्या काम नहीं करता
टूल थकान के प्रति तीन सामान्य प्रतिक्रियाएँ जो वास्तव में काम नहीं करतीं:
अपने आप के लिए समेकन। प्रवृत्ति समझ में आती है: यदि समस्या बहुत सारे टूल्स है, तो कम टूल्स का उपयोग करें। लेकिन Engineering टीमों के पास अपने टूल्स के बारे में मजबूत राय रखने के अच्छे कारण हैं। Linear को «[all-in-one platform X] के अंदर के प्रोजेक्ट मैनेजमेंट मॉड्यूल» से बदलने की कोशिश करें और विद्रोह देखें। टूल्स समस्या नहीं हैं, उनके बीच के अंतराल हैं। टूल्स के एक सेट को दूसरे सेट से बदलना सिर्फ अंतरालों को हिला देता है।
डैशबोर्ड। मैं जानता हूँ, मैं जानता हूँ। «सभी को नियंत्रित करने वाले एक डैशबोर्ड» की अपील लगभग अप्रतिरोध्य है, और हर enterprise SaaS कंपनी के पास इस पर एक स्लाइड डेक है। लेकिन हमने जो अधिकांश डैशबोर्ड परीक्षण किए हैं वे स्थिति के read-only स्नैपशॉट हैं – वे आपको दिखाते हैं कि चीजें कहाँ हैं, लेकिन कल से क्या बदला, क्यों बदला, या आपको क्या करना चाहिए नहीं दिखाते। डैशबोर्ड देखने वाले Engineering Manager को अभी भी संख्याओं के पीछे का वास्तविक संदर्भ पाने के लिए हर टूल पर जाना होगा।
अधिक मीटिंग। यह वह है जो सबसे ज्यादा दर्द देता है क्योंकि यह बहुत सामान्य है। जब टूल्स एक-दूसरे से बात नहीं करते, तो टीमें सिंक्रोनस संचार से मुआवजा करती हैं (दैनिक standups, साप्ताहिक syncs, ad-hoc check-ins)। मीटिंग समस्या का समाधान नहीं कर रही है – यह मानवीय बैंडविड्थ के साथ टूटे हुए वर्कफ़्लो को ढक रही है। और मानवीय बैंडविड्थ टीम का सबसे महंगा संसाधन है।
लोग क्या करते हैं
- टूल समेकन – 5 टूल्स को 1 से बदलें। Engineers विद्रोह करते हैं; all-in-one 5 चीजें बुरी तरह करता है।
- डैशबोर्ड – read-only स्नैपशॉट जिन्हें वैसे भी मूल टूल्स से संदर्भ चाहिए।
- अधिक मीटिंग – टूटे हुए async वर्कफ़्लो की भरपाई के लिए सिंक्रोनस सूचना हस्तांतरण।
क्या वास्तव में मदद करता है
- कनेक्शन, समेकन नहीं – टूल्स को रखें, उनके बीच के अंतराल बंद करें।
- सिग्नल रूटिंग – वह दिखाएँ जो बदला और जिस पर ध्यान चाहिए, सब कुछ नहीं।
- Async संदर्भ वितरण – जानकारी वहाँ और जब आपको चाहिए तब पहुँचती है, माँगे बिना।
क्या वास्तव में मदद करता है
जो fixes एक असली Engineering टीम के संपर्क में आने पर टिके रहते हैं वे एक साझा विशेषता रखते हैं: वे इंसानों से इंटीग्रेशन काम नहीं माँगते। वे सिस्टम स्तर पर कनेक्शन बनाते हैं और Engineering Manager को सूचना संग्रह के बजाय निर्णय कॉल पर समय बिताने देते हैं।
इरादतन नोटिफ़िकेशन रूटिंग। अधिकांश टूल थकान गलत जगह पर गलत जानकारी आने से होती है। Slack चैनल जो स्टेटस अपडेट को डिज़ाइन फ़ीडबैक के साथ मिलाते हैं। GitHub नोटिफ़िकेशन उन repos के लिए जिनमें आप सक्रिय रूप से काम नहीं करते। fix कम नोटिफ़िकेशन नहीं है, बल्कि बेहतर-रूट की गई नोटिफ़िकेशन हैं। चैनल परंपराएँ स्थापित करें (हम Engineering सिग्नल के लिए #proj-[name]-eng, डिज़ाइन के लिए #proj-[name]-design उपयोग करते हैं) और आक्रामक रूप से छाँटें। एक concrete automation जो तुरंत अपना खर्च निकाल लेती है: एक GitHub webhook सेट अप करें जो PR स्टेटस बदलाव को message में Linear issue ID के साथ प्रोजेक्ट के Slack चैनल में पोस्ट करे। यह अकेला सुबह के अनुष्ठान से «क्या इस issue के लिए PR मौजूद है?» जाँच को हटा देता है। यह glamorous काम नहीं है, लेकिन यह शोर को सार्थक रूप से कम करता है।
«सूचना पुरातत्व» के लिए साप्ताहिक बजट। स्वीकार करें कि अभी के लिए कुछ cross-tool जोड़ना अपरिहार्य है, और इसे timeboxed करें। हम सोमवार की सुबह विशेष रूप से «शुक्रवार से टूल्स में क्या हुआ» स्कैन के लिए तीस मिनट आवंटित करते हैं। इसे scheduled होने का मतलब है कि यह सप्ताह के हर दूसरे घंटे में नहीं बहता, और timebox होने का मतलब है कि आप समय समाप्त होने पर रुकते हैं बजाय rabbit-hole में जाने के।
Cross-tool सिग्नल रूटिंग। यही वह दिशा है जहाँ यह category जा रही है – और हाँ, यही वह है जो हम Sugarbug पर बना रहे हैं। Engineering Manager के Linear, फिर GitHub, फिर Slack, फिर Figma को मैन्युअल रूप से जाँचने के बजाय विश्व की स्थिति बनाने के लिए: एक layer जो उन सभी टूल्स से उनके APIs के माध्यम से जुड़ती है और प्रासंगिक बदलावों, निर्णयों और ब्लॉकर को आपके पास रूट करती है। कोई डैशबोर्ड नहीं – जो passive है –, बल्कि कुछ ऐसा जो आपको सक्रिय रूप से बताता है कि आपके ध्यान की क्या जरूरत है और क्यों। यह उस तरह के करीब है जैसे एक अनुभवी team lead आपको brief करेगा, अगर उस team lead ने कल से हर Slack थ्रेड और हर PR कमेंट पढ़ा होता।
स्थिति का ईमानदार संस्करण: पहले दो fixes आज काम करते हैं, और तीसरा वह है जिसकी ओर Sugarbug काम कर रहा है। हम अभी तक खत्म नहीं हुए हैं – हमने अभी तक यह तय नहीं किया है कि सिग्नल फ़िल्टरिंग कितनी आक्रामक होनी चाहिए, और रैंकिंग मॉडल अभी भी कुछ शोर दिखाता है जिसे हम दबाना चाहते हैं। लेकिन मुख्य architecture काम कर रही है: हर टूल के लिए API connector, LLM-आधारित सिग्नल वर्गीकरण, और एक नॉलेज ग्राफ़ जो लोगों, कार्यों और चर्चाओं को स्रोतों में जोड़ता है। यह «शुक्रवार से क्या हुआ» स्कैन को सतहत्तर मिनट के बजाय सेकंड में संभालता है – यही वह हिस्सा है जो हमें आगे बढ़ाता है।
एक Engineering Manager का काम पाँच टूल्स को एक सुसंगत तस्वीर में जोड़ना नहीं होना चाहिए। यह मशीन का काम है। इंसान का काम तस्वीर के साथ क्या करना है यह तय करना है। attribution: Ellis Keane
अक्सर पूछे जाने वाले प्रश्न
सिग्नल इंटेलिजेंस सीधे अपने इनबॉक्स में प्राप्त करें।
Q: Engineering Managers के लिए टूल थकान क्या है? A: टूल थकान वह संज्ञानात्मक और परिचालन लागत है जो बहुत सारे असंबद्ध SaaS टूल्स में काम प्रबंधित करने से होती है। Engineering Managers के लिए इसका मतलब है कि Linear, Slack, GitHub, Figma और Notion के बीच जानकारी स्थानांतरित करने में वास्तव में उस जानकारी से निर्णय लेने से अधिक समय बिताना।
Q: क्या Sugarbug टूल थकान में मदद करता है? A: हाँ – यह नेटिव API इंटीग्रेशन के माध्यम से आपके मौजूदा टूल्स से जुड़ता है, प्रत्येक से सिग्नल वर्गीकृत करता है, और एक ही जगह पर वही दिखाता है जो मायने रखता है। अपनी पहली कॉफी से पहले पाँच डैशबोर्ड जाँचने के बजाय, आपको आवश्यक संदर्भ सीधे मिल जाता है। हम अभी भी इस पर iterate कर रहे हैं कि सिग्नल फ़िल्टरिंग ठीक-ठीक कैसे काम करती है (ईमानदारी से, यह हमारे द्वारा निपटाई गई कठिन डिज़ाइन समस्याओं में से एक है), लेकिन मुख्य pipeline live है।
Q: एक सामान्य Engineering टीम कितने टूल्स का उपयोग करती है? A: हम जिन अधिकांश टीमों से बात करते हैं वे टीम के आकार और कार्य के आधार पर 8 से 14 SaaS टूल्स के बीच चलती हैं। समस्या संख्या नहीं है, बल्कि वह संदर्भ है जो उनके बीच के अंतराल में खो जाता है। हमने तीन लोगों की टीमें देखी हैं जिनके पास आठ टूल थे और पचास लोगों की टीमें जिनके पास नौ थे। संख्या इससे कम मायने रखती है कि क्या टूल्स वास्तव में जानकारी साझा करते हैं।
Q: क्या Engineering Managers को अपना टूल स्टैक समेकित करना चाहिए? A: कभी-कभी, लेकिन आमतौर पर यह गलत दृष्टिकोण है। पाँच उद्देश्य-निर्मित टूल्स को एक all-in-one से बदलना जो पाँचों काम बुरी तरह करता है, अंतर्निहित समस्या को हल नहीं करता। असली समाधान उन टूल्स को जोड़ना है जो आपके पास पहले से हैं ताकि जानकारी बिना किसी के मैन्युअल रूप से संदर्भ copy-paste किए उनके बीच प्रवाहित हो। यदि आप वास्तविक अतिरेक कम कर सकते हैं – उदाहरण के लिए दो प्रोजेक्ट ट्रैकर –, तो करें। लेकिन छोटी संख्या के लिए समेकन न करें।