इंजीनियरिंग के मानवीय पहलू में महारत: Apple, Palantir और Slack से सीखे गए लीडरशिप सबक

• Apple के इंजीनियरिंग लीडर Michael Lopp इस बात पर ज़ोर देते हैं कि जिस दौर में प्रोडक्ट तेज़ी से बनाए जा सकते हैं, उसमें लोगों-केंद्रित ऑपरेशन और निर्णय क्षमता और भी महत्वपूर्ण हो जाती है
  • “कौन निर्णय लेता है, और उस निर्णय को कैसे लागू किया जाता है?” यही असल में इंजीनियरिंग का सार है
  • कोड लिखने की क्षमता से भी अधिक, लोगों-केंद्रित संगठन और लीडरशिप संगठन के परिणाम तय करते हैं
• Borland, Netscape, Palantir, Slack जैसे विविध परिवेशों में मिले अनुभव के आधार पर, वे संगठन संरचना, सहयोग संस्कृति और लीडरशिप की मुख्य क्षमताओं को ठोस रूप में पेश करते हैं
• तकनीकी लीडरशिप से अधिक, फोकस संगठन संचालन, लोगों के बीच सहयोग और मानव समझ पर है
• यह इंटरव्यू सिर्फ तकनीकी चर्चा नहीं है, बल्कि टिकाऊ और प्रभावी इंजीनियरिंग संगठन डिज़ाइन पर केंद्रित है, और प्रोडक्ट टीम के साथ संबंध, people-centric क्षमताएँ, अच्छे लीडर की शर्तें आदि को संस्थापकों और तकनीकी लीडरों के लिए व्यावहारिक सलाह के रूप में प्रस्तुत करता है

इंजीनियरिंग संगठन की संरचना कैसे डिज़ाइन करें

• अलग-अलग उद्योगों में भी साझा सफलता कारक के रूप में वे इंजीनियरिंग पर भरोसा, तेज़ वृद्धि और स्मार्ट टैलेंट की भर्ती को गिनते हैं
• इसके आधार पर, सफल इंजीनियरिंग संगठन डिज़ाइन करने के लिए तीन व्यावहारिक टिप्स सुझाए गए हैं

Tip #1: “Wolf Time” को बढ़ावा दें

• इंजीनियरों के समय को 71% वास्तविक काम / 29% स्वतंत्र रचनात्मक समय में बाँटें
• यह 29% “मापा न जा सकने वाला और समझाने की ज़रूरत न होने वाला समय” है, जहाँ रचनात्मकता और स्वप्रेरणा पनपती है
• Palantir में इसे औपचारिक बनाने की कोशिश विफल रही → औपचारिक ढाँचे से अधिक अनौपचारिक प्रोत्साहन और संवाद प्रभावी हैं
• उदाहरण: हर शुक्रवार अनौपचारिक आइडिया-शेयरिंग समय का प्रस्ताव
  > “अगर टीम के लोग यह महसूस ही न करें कि यह समय उन्हें मिला हुआ है, तो वे मीटिंग्स के बीच इसे छिपकर करेंगे और कुछ भी विकसित नहीं होगा”

Tip #2: बहस जितनी नियमित हो, उतना बेहतर

• शानदार प्रोडक्ट engineering, design और product इन तीन क्षेत्रों के सहयोग से बनते हैं
• इस सहयोग में अक्सर टकराव होता है, लेकिन वही बहस प्रोडक्ट की गुणवत्ता बढ़ाने की कुंजी है
• “क्या यह design समस्या है, product समस्या है, या feature की समझ की समस्या है” जैसे सवालों पर टीम के भीतर सक्रिय बहस होनी चाहिए
• लीडर को सिर्फ bottom-up ही नहीं, बल्कि top-down दिशा में भी विचारों को चुनौती देने के लिए प्रोत्साहित करना चाहिए
• संस्थापकों और कर्मचारियों के बीच की बहस कई बार कंपनी की दिशा बदल देती है

Tip #3: स्केलेबल ऑपरेटिंग सिस्टम बनाइए

• अच्छी निर्णय क्षमता + संचालन क्षमता ही स्केलेबल प्रोडक्ट की नींव है
• निर्णय क्षमता का मतलब सिर्फ परिणाम नहीं, बल्कि “ऐसा निर्णय क्यों लिया?” यह समझा सकने की क्षमता है
• accountability का अर्थ है “ऐसी कहानी होना जिसे रिपोर्ट किया जा सके”
• कुछ लोगों की निर्णय क्षमता को पूरे सिस्टम तक स्केल करने के लिए स्पष्ट process चाहिए
• सिर्फ hiring process को देखकर भी ऑपरेशन की गुणवत्ता दिख जाती है (response speed, schedule clarity आदि)
• startup होने का बहाना बनाकर process को नज़रअंदाज़ न करें → कंपनी बनाना दरअसल ऑपरेशन बनाना भी है

इंजीनियरिंग और प्रोडक्ट टीम के बीच संबंध कैसे मज़बूत करें

• प्रोडक्ट टीम और इंजीनियरिंग टीम के बीच का तनाव और गलतफहमी पुरानी बात है,
  लेकिन high-quality प्रोडक्ट को स्केलेबल तरीके से बनाने के लिए इस रिश्ते को बेहतर बनाना अनिवार्य है
  • खराब PM इंजीनियरों को प्रोडक्ट का ownership लिए बिना सिर्फ पालन करने की स्थिति में डाल देता है
  • अच्छा PM इंजीनियरों को “हम यह क्यों बना रहे हैं” यह पर्याप्त रूप से समझने में मदद करता है
• Lopp इंजीनियर को “how” का व्यक्ति और PM को “why” का व्यक्ति मानते हैं
  • प्रोडक्ट टीम को ग्राहक की कहानी बतानी चाहिए, और कैसे बनाना है यह इंजीनियरों और डिज़ाइनरों को सौंप देना चाहिए
• मुख्य बात “why” को साझा करना है
  > PM से नहीं, इंजीनियर से सीधे पूछिए: “हम यह feature क्यों बना रहे हैं?”
  • अगर जवाब हो “PM ने कहा है”, तो यह गुस्सा दिलाने वाली बात है
  • असली समस्या यह नहीं कि प्रोडक्ट टीम का निर्णय गलत था, बल्कि यह है कि इंजीनियर संदर्भ को समझ नहीं पाया
    > "इंजीनियर वे लोग हैं जो अपने हाथों से प्रोडक्ट बनाते हैं। अगर वे ‘हम यह क्यों बना रहे हैं’ समझे बिना काम कर रहे हैं, तो वह संगठन विफल होगा"
  • Slack में block feature क्यों नहीं है, इस सवाल पर Stewart ने साफ़ तौर पर समझाया कि “यह ज़रूरी है कि जानकारी सभी को दिखाई दे”
    • यानी यह feature नहीं, vision का सवाल है
• अच्छे product manager को हर feature या आइडिया को पूरे product vision के संदर्भ में रखकर समझाने में सक्षम होना चाहिए
  • यही वह ‘why’ का हिस्सा है जिस पर सबको फोकस करना चाहिए

बेहतरीन लीडर कैसा होता है?

• सच्चा इंजीनियरिंग लीडरशिप सिर्फ तकनीकी क्षमता से कहीं आगे की चीज़ है
• “आख़िरकार, लीडरशिप लोगों को संभालने की कला है”

• लीडरशिप गुण #1: उसमें लचीलापन (Malleability) होता है

  • लीडर अलग-अलग स्वभाव के लोगों के साथ काम करता है, इसलिए उसे उनके अनुसार अपनी शैली बदलने में सक्षम होना चाहिए
  • Pinterest और Slack में बिल्कुल अलग तरीक़े से टीम लीड करने के अपने अनुभव का उदाहरण देकर वे इसे रेखांकित करते हैं
  • नए मैनेजरों से वे हमेशा एक ही सवाल पूछते हैं: “फीडबैक मिलने के बाद आपने क्या बदला?”
  • टीम संरचना भी तयशुदा मानकों पर नहीं, बल्कि साथ काम करते हुए सामने आने वाली ताकत और कमज़ोरियों के आधार पर दोबारा व्यवस्थित की जानी चाहिए
  • इसके लिए वे हर 6 महीने में reorg करते हैं

• लीडरशिप गुण #2: storytelling में माहिर होता है

  • वे micromanagement के प्रति गहरी नापसंदगी जताते हैं: "इंजीनियरों को आदेश देना जितनी परेशान करने वाली चीज़ है, उतनी कम ही चीज़ें होती हैं"
  • इसके बजाय, लीडर को “Box और Soup” देना चाहिए
    • Box: ऐसा ढाँचा जिसमें आइडिया और संदर्भ भरे गए हों
    • Soup: ऐसी जानकारी की बुनियाद जिसे सदस्य अपनी इच्छा से ग्रहण या मिलाकर इस्तेमाल कर सकें
  • निर्देश देने के बजाय प्रेरित करने वाली कहानी दी जाए, तो लोग खुद निर्णय लेते हैं और आगे बढ़ते हैं
  • कुछ सदस्य कहते हैं, “बस बता दीजिए क्या करना है”, लेकिन तब भी वे अंततः उसे अपने तरीके से ही समझते हैं
    > लीडर की भूमिका soup देना है। उसे पीना है या उसमें क्या मिलाना है, यह उनका चुनाव है।

• लीडरशिप गुण #3: सदस्यों की प्रेरणा और लक्ष्य समझता है

  • लीडर को यह पता होना चाहिए कि हर टीम सदस्य किससे बढ़ता है और किससे प्रेरित होता है
  • एक उदाहरण: जिस इंजीनियर के लिए तकनीकी चुनौती ही जीवन की ऊर्जा है, उसे लगातार समस्या-समाधान के अवसर देने चाहिए
  • दूसरा उदाहरण: Palantir की एक assistant ने reward-केंद्रित motivation को स्पष्ट रूप से बताया → इसलिए उसे स्पष्ट रूप से मैनेज किया जा सका
  • मुख्य बात है हर व्यक्ति की “एक केंद्रीय प्रेरणा” को समझना और उसमें लगातार निवेश करना
  • इसके लिए जिज्ञासा (curiosity) और लगातार “क्यों?” पूछना अनिवार्य है
    > लीडर को लोगों के भीतर ऐसी प्रेरणाएँ खोजनी चाहिए जिन्हें वे खुद भी न पहचानते हों, और उनके लिए विकास के अवसर बनाने चाहिए।

निष्कर्ष: सफल इंजीनियरिंग का सार मानव समझ है

• सफल इंजीनियरिंग संगठन इस बात पर निर्भर करता है कि मानवीय गतिशीलता (Human Dynamics) कितनी सुचारु रूप से काम करती है
  • बेहतरीन प्रोडक्ट असाधारण व्यक्तियों से नहीं, बल्कि अच्छे से सहयोग करने वाले लोगों के समूह से जन्म लेते हैं
  • लीडर की भूमिका संगठन को बनाने वाले लोगों को सशक्त करने से शुरू होती है
• “इंजीनियरिंग टीम जटिल और शानदार इंसानों की एक विशाल tapestry है”
  • इस tapestry की संरचना और प्रवाह को समझने की कोशिश ही वह कुंजी है जो प्रोडक्ट के मूल्य को पूरे संगठन में प्रभावी ढंग से पहुँचने देती है
    > "जब आप यह समझने की प्रेरणा रखते हैं कि लोग कैसे interact करते हैं, तभी आपकी कंपनी प्रोडक्ट के मूल्य को बड़े पैमाने पर पहुँचाने के लिए तैयार होती है।"

[xguru]

Michael Lopp तकनीकी लीडर्स के लिए एक Slack चलाते हैं.
RLS - Rands Leadership Slack
जिनकी रुचि हो, वे एक बार इसमें शामिल होकर देख सकते हैं. फिलहाल इसमें 36000 से अधिक लोग जुड़े हुए हैं, और यह एक बहुत बड़ा Slack है.
जॉइन करने के लिए ऊपर दिए गए लिंक की जानकारी ध्यान से पढ़ें और Lopp को ईमेल भेजें.
नाम/पेशा/क्यों जुड़ना चाहते हैं/RLS के बारे में कहाँ से सुना/अपना LinkedIn या Twitter आदि अकाउंट

[techiemann]

तो बात यह है कि अगर आपने महंगे engineer को रखा है, तो सिर्फ इसलिए कि वह कलम घुमाने वाला है, उसे LLM की तरह ट्रीट करते हुए Doraemon से झटपट चीजें बनवाने जैसा हर छोटी-बड़ी बात में यह करो, वह करो कहकर निर्देश मत दीजिए; बस अपना vision साझा कीजिए, और उसे उसे लागू करने का engineering approach खुद तय करने दीजिए, क्योंकि वही उसका विशेषज्ञता का क्षेत्र है।

ध्यान से सुनता हूँ तो पता नहीं क्यों मेरे दिमाग में हमारे यहाँ गांव-देहात में country house बनवाने या पुराने apartment की remodeling करवाने वाले लोगों और contractor, construction company, architect के बीच होने वाली खींचतान का वही पूरा सिलसिला घूमने लगता है।

[nemorize]

बाद वाला मामला शायद थोड़ा अलग संदर्भ का नहीं है क्या?

देहाती मकान या पुराने अपार्टमेंट की remodeling,
सबसे पहले business से ज़्यादा एक तरह से अपने सपने को पूरा करने के करीब का क्षेत्र है,
और construction/remodeling कंपनियों पर भरोसा करके काम सौंपने के बाद उनसे धोखा खाने वाली घटनाएँ अजीब तरह से बहुत बार होती रहती हैं...

[groge]

अगर मालिक खुद बनवाने के बजाय किसी और से यह काम करवाए, तो लगता है बिल्कुल यही स्थिति होगी.
चाहे आप कितनी भी अच्छी तरह समझा दें, गलतफहमियाँ रहती ही हैं, और चाहे आप कितनी भी बारीकी से ध्यान रखें, फिर भी कुछ ऐसे हिस्से रह जाते हैं जिनके बारे में सोचा नहीं गया होता.
अगर वे हर उस हिस्से के बारे में एक-एक करके पूछते हुए काम करें जो मालिक ने बताया नहीं, तो बहुत समय लगेगा और काफी झुंझलाहट भी होगी, इसलिए काफी कुछ विशेषज्ञ अपने हिसाब से संभाल लेते हैं, और लगता है वही हिस्से सबसे ज़्यादा विवाद की वजह बनते हैं.
वैसे, यह देख कर ईर्ष्या होती है कि लगता है आपने SI कंपनी से अभी तक ज़्यादा धोखा नहीं खाया है.

[nicewook]

हाल ही में पढ़ी गई Modern Software Engineering भी याद आती है। उसमें सिर्फ़ development नहीं, बल्कि teams और organization के बारे में भी बात की गई है।

[haejuk99]

Engineering leadership पर कई तरह की राय और तरीके हैं, लेकिन लगता है कि मूल बात यही है कि इसकी नींव टीम के सदस्यों की समझ पर टिकी होती है। टीम के सदस्यों को समझना कहना आसान है, लेकिन लगता है कि यह वह हिस्सा है जहाँ आपसी feedback के ज़रिए leader और सदस्यों के बीच सहानुभूति के आधार पर भरोसा बनना चाहिए। शायद यह एक बार में बन जाने वाली चीज़ नहीं है। सोचने लायक अच्छा कंटेंट साझा करने के लिए धन्यवाद।