विशेषज्ञों से भरे कमरे में नेतृत्व कैसे करें

• कई क्षेत्रों के विशेषज्ञों से भरे माहौल में नेता की भूमिका तकनीकी बारीकियों को सबसे गहराई से जानने की नहीं, बल्कि समस्याओं को जोड़ने और समाधान की दिशा तय करने की होती है
• नेतृत्व में केवल तकनीकी ज्ञान से अधिक अनुवाद करने की क्षमता और social skills महत्वपूर्ण होते हैं, और टकराव की स्थितियों को संतुलित करते हुए साझा लक्ष्य पर ज़ोर देना चाहिए
• महत्वपूर्ण यह है कि हर व्यक्ति की गहरी विशेषज्ञता से अधिक वास्तविक समस्या की परिभाषा और समाधान की दिशा स्पष्ट हो, और चर्चा उपयोगकर्ता की ज़रूरतों और परिणामों तक पहुँचे
• प्रभावी नेता सब कुछ जानने का दिखावा नहीं करते, बल्कि "मुझे नहीं पता" कहने का साहस रखते हैं और ऐसा माहौल बनाते हैं जहाँ विशेषज्ञ सक्रिय रूप से योगदान दे सकें
• नेता की असली अहमियत दृष्टिकोणों का अनुवाद, समस्या का संदर्भ देना, और सहयोग के लिए जगह बनाना में है, और यही बेहतरीन परिणाम निकालने का मुख्य तत्व है

---

हाल की एक समझ

• एक मीटिंग रूम में अलग-अलग क्षेत्रों के विशेषज्ञ डेवलपर्स और product team के साथ काम कर रहा हूँ
• मेरे पास किसी एक तकनीक में सबसे ऊँची विशेषज्ञता नहीं है, लेकिन मैं lead developer की भूमिका निभा रहा हूँ
• विशेषज्ञों के बीच एक नेता के रूप में मेरी भूमिका सभी जवाब जानना नहीं, बल्कि जवाबों को खोजकर जोड़ना है

Technical Leadership

• नेता की भूमिका तकनीकी ज्ञान की गहराई से अधिक, टीमों के बीच संवाद को सक्रिय करने वाले एक प्रभावी अनुवादक की होती है
• backend development team की टाइमलाइन की व्याख्या हो या product team की requirements, उन्हें हर पक्ष के दृष्टिकोण से समझाकर टीम सहयोग को आगे बढ़ाना ज़रूरी है

Leading is a Social Skill

• केवल तकनीकी विश्वसनीयता पर्याप्त नहीं है; social skills ही असली उत्पादकता पैदा करती हैं
• डेवलपर्स के बीच चल रही चर्चा को पढ़कर यह समझने की क्षमता चाहिए कि कब बहस को मध्यस्थता देनी है और कब उसे आगे बढ़ाना है
• प्रभावी communication केवल दस्तावेज़ों से नहीं, बल्कि सक्रिय बातचीत से बनता है

Leading is Remembering the Goal

• विशेषज्ञ जितने गहरे होते हैं, उतना ही वे तकनीकी विवरणों में डूबने की प्रवृत्ति रखते हैं, लेकिन नेता को समग्र लक्ष्य पर केंद्रित रहना चाहिए
• केवल तकनीकी चर्चा नहीं, बल्कि user experience की मूल समस्या और business उद्देश्य को स्पष्ट रूप से परिभाषित करना महत्वपूर्ण है
• यदि समस्या की असल प्रकृति स्पष्ट रूप से तय न की जाए, तो टीम के सदस्य अपने-अपने विश्लेषण के तरीकों के अनुसार वास्तविक मुद्दे को चूक सकते हैं
• नेता की ज़िम्मेदारी है कि वह टीम को समस्या सही तरह से समझने और एक ही लक्ष्य देखने लायक अनुवाद दे

Leading is Saying "I Don't Know"

• सभी जवाब जानने का दिखावा करने के बजाय "मुझे नहीं पता, चलिए साथ मिलकर पता करते हैं" वाला रवैया भरोसा और खुली संस्कृति बनाता है
• यह रवैया विशेषज्ञों को सवाल उठाने और चर्चा करने की जगह देता है, और हर व्यक्ति को अपनी क्षमता दिखाने का अवसर देता है
• नेता विषय-विशेषज्ञों को निर्णय लेने का अधिकार और बोलने की जगह देता है, और चर्चा को उत्पादक दिशा में ले जाता है
• जब दो विशेषज्ञ implementation के तरीके पर असहमत हों, तो नेता की भूमिका "सही जवाब" चुनने की नहीं, बल्कि trade-off और user impact के नज़रिये से फ्रेम देना है

The Translation Challenge

• नेता को डेवलपर की भाषा, product की भाषा, और executive की भाषा को हर परिस्थिति के अनुसार अनुवाद करना आना चाहिए
  • डेवलपर: "अगर authentication service में सही circuit breaker नहीं होगा, तो लोड की स्थिति में cascading failure हो सकता है"
  • product team: "यदि login system में समस्या आती है, तो उसका असर पूरे app पर पड़ सकता है, इसलिए सुरक्षा तंत्र जोड़ना ज़रूरी है और टाइमलाइन एक हफ्ता बढ़ेगी"
  • executive: "इस sprint में हम system stability को प्राथमिकता देकर business risk कम कर रहे हैं"
• विशेषज्ञों से दूसरे विभागों की भाषा भी सीखने की अपेक्षा करना ज़रूरी नहीं है; उस खाई को पाटने वाला पुल नेता को बनना चाहिए

Beyond "Because, that's why!"

• "मैं lead हूँ, इसलिए ऐसे ही करेंगे" जैसी निर्णय शैली भरोसे और सहयोग की संस्कृति को नुकसान पहुँचाती है और टीम की उत्पादकता घटाती है
• टीम के साथ वयस्कों जैसा व्यवहार करना और निर्णय के कारण और संदर्भ को साफ़-साफ़ समझाना महत्वपूर्ण है
  • "हम conservative approach इसलिए चुन रहे हैं क्योंकि गलती होने पर उसकी लागत बहुत ज़्यादा है, और बाद में इसे बार-बार बेहतर किया जा सकता है"
  • "यह अतिरिक्त काम जैसा लग सकता है, लेकिन यह architecture के लक्ष्य के अनुरूप है और अगली features के विकास में मदद करेगा"
  • "यह सबसे elegant समाधान नहीं है, लेकिन तय समय सीमा के भीतर इसे भरोसे के साथ deploy किया जा सकता है"
• जितना अधिक आप विशेषज्ञ होने का अहं छोड़ते हैं, उतना ही सच्चा नेतृत्व संभव होता है

टीम को नेता कौन-सी वैल्यू दे

• समस्या की स्पष्ट परिभाषा
• निर्णय के संदर्भ की पर्याप्त व्याख्या
• टीमों के बीच दृष्टिकोण के अंतर का अनुवाद
• अनावश्यक जटिलता से सुरक्षा
• सर्वश्रेष्ठ परिणाम के लिए माहौल तैयार करना

निष्कर्ष

• विशेषज्ञ संगठन में technical leadership का केंद्र आदेश और नियंत्रण से आगे बढ़कर जोड़ने और संदर्भ देने पर होता है
• नेता सीधे वाद्ययंत्र बजाने वाला कलाकार नहीं, बल्कि ऑर्केस्ट्रा को एक रचना पूरा करने में मदद करने वाला conductor होता है
• यह सिर्फ कमरे का सबसे बुद्धिमान व्यक्ति बनने से कहीं अधिक रोमांचक चुनौती है

[shakespeares]

उल्टा सोचें तो, ऐसे माहौल में जहाँ experts नहीं हैं, खुद expert बनना ही पड़ता है।
बेशक, technical leadership के अलावा किसी और तरह की leadership करने का भी मन होता है, लेकिन जब ऐसे team members मिलते हैं जो knowledge share अच्छी तरह नहीं करते, तो वह भी करना मुश्किल हो जाता है—इसलिए लगता है कि यह स्थिति के अनुसार बदलता है।

[developerjhp]

बहुत बढ़िया नज़रिया है।

[jsdalsee]

मुझे ऐसे काम करना चाहिए

[GN⁺]

Hacker News राय

• टीम के लीड के रूप में, मैं आमतौर पर "मैं लीड हूं, और हमने यही तय किया है" जैसी शैली में फैसले लेने से बचता हूं, लेकिन ज़रूरत पड़ने पर बिना हिचक इसका इस्तेमाल करना चाहिए—इस पर ज़ोर देता हूं। मैं सबकी राय सुनने और सोच-समझकर निर्णय लेने में समय लगाता हूं, लेकिन जब टीम गैर-ज़रूरी बारीकियों पर अंतहीन बहस में फंस जाती है, तब लीड के रूप में व्यवस्था स्थापित करनी पड़ती है—यह मैंने समझा है। Steve Jobs की उस बात पर भी सोचता हूं कि “अगर तुम सबको खुश करना चाहते हो, तो लीडर मत बनो, आइसक्रीम बेचो।” ऐसे हालात गुजर जाने के बाद भरोसा फिर से बनाना और टीम को यह समझाना कि ऐसा करना क्यों ज़रूरी था, बहुत महत्वपूर्ण है

  • मैंने भी यह सबक काफ़ी मुश्किल से सीखा। जब मैं पहली बार मैनेजर बना, तो मुझे भोलेपन में लगता था कि मैं हमेशा सबकी सहमति बना लूंगा और टीम अपने-आप एकजुट हो जाएगी। बेहतरीन टीमों में शुरुआत में यह चला, लेकिन बाद में जब मुझे ऐसे इंजीनियरों के साथ काम करना पड़ा जो दूसरी टीमों के 25 साल पुराने तरीकों पर ही अड़े रहते थे, तब मैंने सहमति का इंतज़ार करते-करते बहुत समय गंवाया। आखिरकार समझ आया कि टीम के लोग अपनी बात पूरी तरह रख दें, उसके बाद एक समय ऐसा आता है जब लीड को दिशा तय करके निर्णायक कदम उठाना ही पड़ता है

  • मेरे अनुभव में, F50 में कई साल काम करते हुए मैंने ऐसी ही स्थिति देखी। एक ऐसे डोमेन में जहां 3 मुख्य लोग थे, विकल्प A ऊपर से अच्छा दिखता था लेकिन असल में उसमें बहुत समस्याएं थीं—यह सिर्फ हम जानते थे। समझाने के बावजूद हम टीम को मना नहीं पाए, इसलिए आखिरकार वोट को नज़रअंदाज़ करके अपने बॉस से बात की और सही फैसला ले पाए। इस प्रक्रिया में मैंने गहराई से समझा कि अगर उस दिशा (A) पर चला जाए जिसे बहुमत चाहता है, बजाय उस दिशा (C) के जिसे वे लोग चाहते हैं जिन्हें नतीजों से सीधे जूझना पड़ेगा, तो प्रोजेक्ट में लगातार समस्याएं और देरी होती रहती हैं। असली बात यह है कि जो लोग ज़िम्मेदारी और नतीजे सीधे उठाते हैं, उनके पास लोकप्रियता-आधारित वोट नहीं बल्कि 'veto' होना चाहिए—तभी प्रोजेक्ट में गति आती है। बड़े प्रोजेक्ट्स में अलग-अलग डोमेन के कई लीड निर्णय लें, और सिर्फ़ गतिरोध की स्थिति में बॉस स्पष्ट निर्णय दे—यही सही है। जब लीड निर्णय लेने से बचता है, तो सब लोग बस नाराज़गी जताते रहते हैं और टीम का मनोबल बुरी तरह गिर जाता है—यह मैंने बहुत झुंझलाहट के साथ देखा है

  • Steve Jobs वाला वह किस्सा भी याद आता है जिसमें उसने टीम को एक कमरे में बंद करके तब तक चर्चा करवाई जब तक सबको साझा विज़न नहीं मिल गया। सबको एक दिशा में ले जाना मुश्किल है, लेकिन अगर यह न हो तो execution काफ़ी कमज़ोर पड़ जाता है। साथ ही, अगर टीम के लोगों की राय को नज़रअंदाज़ किया जाए, तो उन्हें अनदेखा किए जाने का एहसास होता है; इसलिए भले ही नतीजा महत्वपूर्ण हो, यह लंबे समय तक टिकाऊ तरीका नहीं है

  • यह बात प्रभावशाली लगी कि “सबकी आवाज़ सुनना” और “सबको veto दे देना” बिल्कुल अलग बातें हैं। लीड के रूप में गतिरोध तोड़ना एक ज़रूरी भूमिका है—मैं ऐसा मानता हूं। बेशक, अगर हर मुद्दे पर लीड को ही फैसला करना पड़ रहा है, तो यह management, motivation, या टीम द्वारा strategy न समझ पाने की समस्या का संकेत है

  • मुझे जो तरीका पसंद है, वह है कहना: “अगर इसकी सीधी ज़िम्मेदारी तुम्हारी होती, तो तुम क्या निर्णय लेते—मुझे बताओ।” लीड का काम हमेशा खुद निर्णय लेना नहीं, बल्कि यह सुनिश्चित करना है कि निर्णय निकले

• मुझे लगता है कि इस क्षेत्र में मेरी थोड़ी विशेषज्ञता है। पहले मुझे ऐसे प्रोजेक्ट का लीड बनाया गया था जो इससे पहले तीन बार फेल हो चुका था, और मैं हर टीम के 6 सर्वश्रेष्ठ इंजीनियरों के साथ काम कर रहा था। सबकी राय मज़बूत थी और उसके पीछे पक्के कारण भी थे, लेकिन “गलती कर रहे दुश्मन को मत रोको” वाली कहावत की तरह, मैं “जब तुम्हारा साथी कुछ शानदार कर रहा हो, तो उसे मत रोको” वाला रवैया रखना चाहता था। सोच यह थी: “अगर वह हिस्सा तुम्हारी ज़िम्मेदारी नहीं है, तो जाओ और कुछ ऐसा बनाओ जिसमें तुम सबसे अच्छे हो।” हमने स्वाभाविक रूप से भूमिकाएं बांटी, एक-दूसरे पर नरमी से प्रभाव डाला, और कम महत्वपूर्ण हिस्सों में पूर्णता पर ज़ोर देने के बजाय लचीलापन रखा। नतीजा सफल रहा, और मुझे इस बात पर बहुत गर्व है कि कई प्रतिभाशाली लोगों वाली टीम में ऐसा ढांचा बना जहां लोग एक-दूसरे से सीखते थे और सिर्फ़ उन्हीं जगहों पर असली बहस होती थी जहां उसकी सच में ज़रूरत थी

  • मुझे लगता है आपका अनुभव उस leadership शैली जैसा है जिसे Servant Leadership(संबंधित wiki लिंक) कहा जाता है। यह वही leadership शैली है जो मुझे भी पसंद है

  • बेहतरीन इंजीनियरों के साथ बिना ज़रूरत से ज़्यादा दखल दिए उन्हें अपने विचार आगे बढ़ाने देना—इसके लिए लीड के रूप में असली भरोसा, संयम और आत्मविश्वास चाहिए, ऐसा मैं मानता हूं

• जब भी product team किसी “simple” feature की मांग करती है, मेरे दिमाग में तुरंत आता है कि इसके लिए कम-से-कम 3 teams चाहिए होंगी और हर एक microservice को update करना पड़ेगा। इस मायने में कभी-कभी मुझे modern web systems से सचमुच नफ़रत हो जाती है

  • मुझे लगता है यहां समस्या modern web खुद नहीं है, बल्कि वह architecture है जिसमें एक “simple” feature भी 3 microservices में बंटा होता है और dependencies हर जगह फैली होती हैं। आखिरकार बड़ी वजह system design की विफलता है

  • फिर यह जानने की जिज्ञासा होती है कि दूसरा विकल्प क्या होगा

• मेरे अनुभव में, “मैं लीड हूं” जैसा बयान आत्मविश्वास की कमी जैसा लग सकता है, इसलिए इससे बचना बेहतर है। इसके बजाय, सारी जानकारी इकट्ठा करने और निर्णय लेने के बाद आत्मविश्वास से यह कह पाना चाहिए: “ठीक है, अब हम यह करेंगे” या “मैं चाहूंगा कि हम यह करें”

• समस्या की जड़ गलतफ़हमी नहीं, बल्कि एक-दूसरे पर भरोसे की कमी है। अगर एक टीम कहती है कि किसी काम में 2 हफ्ते लगेंगे, तो दूसरी टीम सोचती है कि वह तो एक दिन का काम है—और भरोसा नहीं करती। अगर आपसी भरोसा काफ़ी हो, तो लोग मान सकते हैं कि दूसरी टीम उस क्षेत्र में ज़्यादा विशेषज्ञ है, लेकिन असल दुनिया में अक्सर शक होता है कि estimate असली काम के लिए नहीं बल्कि extra cushion लेने के लिए बढ़ाया गया है। ऐसे में पर्याप्त explanation और reasoning साझा करना भरोसा बढ़ाने में मदद करता है

• मुझे lead developer बने लगभग एक साल हुआ है। अपनी role और responsibilities को लेकर मैं उलझन में था, लेकिन राहत हुई कि मैं शायद उसी तरह सोचते हुए काम कर रहा था जैसा इस पोस्ट में लिखा है। कुछ दिन पहले मैंने “गैर-डेवलपर के नज़रिये से tutorial पढ़ने का तरीका” जैसा एक लेख भी पढ़ा था और उससे भी जुड़ाव महसूस हुआ—इससे लगता है कि मैं शायद सही दिशा में जा रहा हूं

• मैंने भी software-adjacent product development teams में 3 बार ऐसे मामले देखे हैं जहां लीड ने दबाव बनाकर नेतृत्व किया, और हर बार नतीजे अच्छे नहीं रहे। कुछ बार खुद टीम लीड करने के बाद मुझे समझ आया कि मेरी भूमिका ‘कमांडर’ की नहीं बल्कि ‘hub और mediator’ की होनी चाहिए। जब टीम के लोगों में टकराव हो, तो मैं उसे सुलझाऊं; जब सवाल हों, तो उनकी बेचैनी कम करूं; जब ideas आएं, तो उनकी feasibility और value परखूं; और जब resources चाहिए हों, तो जिस किसी से भी मदद लेनी हो, वहां तक पहुंचने में सहायता करूं। समस्या आए तो ज़िम्मेदारी लूं, और उसे सुलझाने के लिए टीम को प्रोत्साहित करूं। यह सब सीखने में मुझे 10 साल से ज़्यादा लगे। मैं सबसे महान नहीं हूं, और ज़्यादातर लोग मेरा नाम भी नहीं जानते, लेकिन जब मैंने टीम के ‘सदस्य’ की तरह काम किया, तो नतीजे बेहतर रहे और प्रतिभाशाली लोगों का टीम छोड़ना भी कम हुआ। और लीड के रूप में “मुझे भी पूरा नहीं पता, लेकिन चलो हम साथ मिलकर जवाब ढूंढते हैं” कहना सचमुच बहुत ज़रूरी लगता है। इससे experts को अनिश्चित होने की जगह मिलती है, वे defensive नहीं होते, और उन्हें लगता है कि वे अकेले नहीं हैं। जिन लोगों ने पहले के लीडर्स के कारण खुद को अलग-थलग या बदलने योग्य पुर्ज़े जैसा महसूस किया है, उनके लिए दिल से संवेदना है। अगर कोई लीड अपनी टीम को लंबे समय तक अच्छे से आगे ले जाना चाहता है, तो उसे लोगों को मशीन की तरह नहीं बल्कि देखभाल के योग्य इंसान की तरह देखना होगा—यह मैंने महसूस किया है

  • मुझे लगता है आपने बिल्कुल मुद्दे पर बात की है। software तक सीमित नहीं, हर professional environment में technical leadership का मतलब “command-and-control” नहीं बल्कि “connection और context देना” है। यह वैसा है जैसे conductor हर instrument खुद नहीं बजाता, बल्कि पूरी orchestra को यह समझने में मदद करता है कि वे सब मिलकर कौन-सा piece बजा रहे हैं। कई business लोग company की तुलना music organization से करते हैं, और मेरा अनुभव भी ऐसा ही है। organization कभी परिपूर्ण नहीं हो सकती, इसलिए लीड का उसकी कमियों को भरने की कोशिश करना ज़रूरी है। जब लीड की क्षमता पर सवाल उठते हैं, तब उपलब्धियों की पहचान मिलना और लीड का अपने वास्तविक क्षेत्र में कुछ हद तक उत्कृष्टता दिखाना—इन्हीं से सम्मान बनता है, और फिर टीम लीड की गलतियों को भी कुछ हद तक स्वीकार करने लगती है। मैंने music organizations में यह चक्र काम करते देखा है। जब सक्षम लीड ने अपने क्षेत्र में थोड़ा-सा भी वास्तविक hands-on काम दिखाया, तब सिर्फ़ उसी से भरोसा बहुत बढ़ गया। इसलिए अयोग्य लीड जल्दी पकड़ में आ जाता है, और सम्मानित लीड पर अपने साथियों की अपेक्षाओं पर खरा उतरने की ज़िम्मेदारी भी होती है। आखिर में, चाहे hard rock band हो या classical orchestra, बिल्लियों को लीड करने के लिए लीडर को उसी झुंड की ‘बिल्ली’ होना पड़ता है—यह उपमा भी जोड़ना चाहूंगा

• इस बात से प्रभावित हूं कि लेखक ने खुद मुख्य लेख का audio रिकॉर्ड किया

  • यह वाकई अच्छा है। अगर साइट इस बात को ज़्यादा स्पष्ट तरीके से उभारे कि यह audio किसी असली इंसान ने पढ़ा है, तो और बेहतर होगा। ज़्यादातर “Listen to this article” फीचर AI से पढ़वाए जाते हैं और स्वाभाविक नहीं लगते, इसलिए मैं आमतौर पर उन पर ध्यान ही नहीं देता

• उसने कहा कि उसे “It's because that's why” वाला वाक्यांश पसंद है, और अगर किसी की इस क्षेत्र में रुचि हो तो Vanessa Van Edwards की किताबों से यह सीखने में बहुत मदद मिल सकती है कि स्थिति के अनुसार warmth और competence के signals कैसे दिए जाएं। एक इंसान के पास हर जवाब नहीं हो सकता, लेकिन मुझे इससे काफ़ी positive अनुभव मिले हैं

  • मुझे लगता है “यह तो मामूली bikeshed बहस है” कहना ज़्यादा प्रभावी रहता है। हर बार कोई एक सही जवाब नहीं होता, लेकिन किसी निष्कर्ष पर पहुंचना ज़रूरी होता है—यह बात महत्वपूर्ण है

• निर्णय लेने के बारे में मुझे लगता है कि बात “यह सुनिश्चित करने” से थोड़ी आगे भी जाती है कि कोई निर्णय हो ही जाए। पहला, जहां संभव हो, किसी और को निर्णय लेने देना चाहिए—मैं यही सलाह दूंगा। Apple के समय Jean-Louis Gassee उन मैनेजर्स के झगड़ों में, जो फैसला करवाने आते थे, ऐसा निर्णय सुना देता था जो दोनों को नापसंद हो; तब वे दोनों खुद ही कोई ऐसा विकल्प लेकर लौटते थे जिस पर वे सहमत हो सकें। दूसरा, ज़रूरी यह भी है कि टीम के सभी लोग सचमुच उस निर्णय के साथ खड़े हों—और इसकी शुरुआत खुद से करनी चाहिए। उसने जोड़ा कि हवा के रुख़ के साथ बहने वाले मैनेजर के लिए यह बेहद मुश्किल होता है। उसने उदाहरण दिया कि law student हमेशा सावधानी और विश्लेषण के साथ सोचता है, लेकिन lawyer को ठोस तरीके से पक्ष रखना पड़ता है और सबको मनाने वाला रवैया अपनाना पड़ता है। हर बार आदर्श सहमति नहीं बनती, इसलिए customer या outcome goals जैसे ठोस anchors तय कर देने से निर्णय को आगे बढ़ाने और उसे लागू करवाने में मदद मिलती है