Engineering leaders के लिए Anti-patterns

 (review.firstround.com)
53 पॉइंट द्वारा xguru 2024-07-08 | 9 टिप्पणियां | WhatsApp पर शेयर करें
  • CTO या engineering leaders से मिलते समय सबसे आम बातचीत का विषय यह होता है कि CEO की तरफ़ से "engineering की speed बढ़ाओ" का दबाव रहता है
  • sales या hiring के विपरीत, engineering में स्पष्ट performance metrics नहीं होते
  • engineering leader के नज़रिए से CEO से यह कहना कठिन होता है कि "engineering एक कला है, इसलिए इसके नतीजों का अनुमान लगाना मुश्किल है"
  • engineering leaders और management के बीच मतभेद के कारण
    • engineering leaders अक्सर पारंपरिक leadership advice को बहुत कठोरता से मानते हैं
    • अगर किसी practice को सार्वभौमिक रूप से उपयोगी या अनुपयोगी मान लिया जाए, तो उसे संगठन की स्थिति के अनुसार लागू करना कठिन हो जाता है
    • परिस्थिति के अनुसार यह तय करना कि किसी practice का पालन करना है या नया approach आज़माना है, प्रभावी engineering leadership का मूल है
  • Carta के CTO, Will Larson ने podcast में जो बातें कही थीं, यह लेख उनका सार है

engineering leadership के 3 anti-patterns

  1. micromanagement से बचने की अति
  2. imperfect metrics को मापने से हिचकिचाहट
  3. leader का टीम के लिए umbrella बन जाना

[Anti-pattern #1: micromanagement से बचने की अति]

बेहतरीन engineering executive बनने के लिए तीन विरोधाभासी भूमिकाएँ

  • engineering executive को तीन परस्पर विरोधी भूमिकाएँ निभानी पड़ती हैं, और सर्वश्रेष्ठ executive इन भूमिकाओं के बीच कुशलता से आ-जा सकते हैं
    • management team के सदस्य की भूमिका: business को आगे बढ़ाने के तरीक़े खोजता है
      • कभी-कभी engineering budget में कटौती जैसे, "पूरी engineering के लिए बुरे" निर्णय भी लेने पड़ सकते हैं
      • इसमें ऐसे business unit model की ओर जाना भी शामिल हो सकता है जहाँ किसी खास विषय पर engineering की आवाज़ कम हो जाए
    • engineering manager की भूमिका
      • engineering organization चलाने के लिए ज़रूरी policies की संरचना समझना और effective people leader बनना
    • engineer की भूमिका
      • बाहरी दबावों के बावजूद technical excellence और engineering execution की ज़िम्मेदारी लेना
      • technical excellence के standards ऊँचे बनाए रखने चाहिए
  • कई executive इन तीन भूमिकाओं में से किसी एक की ओर ज़्यादा झुक जाते हैं
  • चाहे कोई भी भूमिका निभा रहे हों, जब नेता ऐसी management practices पकड़े रहते हैं जो अब मददगार नहीं रहीं, तब वे गलती करते हैं
  • अचानक टीम के manager बनने पर आपके पास तकनीकी रूप से टीम के काम का सबसे अधिक context होता है, लेकिन साथ ही आप people manager भी बन जाते हैं
  • इसी समय लोगों को लगातार details से पीछे हटने की सलाह दी जाती है
  • नए engineering managers को अक्सर "code से दूर हो जाओ" जैसी सलाह मिलती है
  • यह माना गया है कि कुछ लोगों के लिए यह सलाह मददगार हो सकती है
  • लेकिन बहुत सक्षम executives के पास उस domain की कुछ detailed understanding होती है जिसे वे चला रहे होते हैं
  • अगर आप details से बहुत दूर चले जाएँ, तो आप बस bureaucrat बन जाते हैं, और यही वजह है कि इतने सारे engineering managers अंततः bureaucrat बन जाते हैं

leadership style का विकास

  • Larson engineering executives से कहते हैं कि micromanagement शब्द को पूरी तरह भूल जाएँ और इसकी जगह अलग-अलग leadership styles विकसित करने पर ध्यान दें, जिनमें से ज़रूरत के अनुसार चुन सकें
  • जब आगे का रास्ता स्पष्ट न हो, या रास्ते का context रखने वाले लोग आपस में तीखी असहमति रखते हों, तब details में जाकर ख़ुद निर्णय लेना उपयोगी हो सकता है
  • इससे यह समझा जा सकता है कि business को वास्तव में बदलने वाले leverage points क्या हैं, टीम को कौन-से outcomes हासिल करने हैं, उसके लिए समय-सीमा क्या है, और users को बेहतर सेवा कैसे देनी है
  • निर्णयों को लेकर मज़बूत conviction विकसित करना जीवनभर का अभ्यास है, और Larson ख़ुद भी इस पर काम कर रहे हैं
  • "हम क्या कर रहे हैं? ऐसा क्यों कर रहे हैं? data क्या कहता है? असली data source कहाँ है?" जैसे सवाल हर महीने या तिमाही में पूछना details में और गहराई तक जाने में मदद करता है

details के क़रीब जाने की दो tactics

  1. "conflict mining" के ज़रिए context समझना

    • नए माहौल में context के छोटे अंतर भी execution की सफलता को नुकसान पहुँचा सकते हैं
    • भले ही अलग नज़रिया रखने वाले लोगों से बात करने में समय लगे, "conflict के बीज" ढूँढने की प्रक्रिया महत्वपूर्ण है
    • सफल नेता यह पूछते हैं, "मैं कैसे बदलूँ ताकि संगठन के अनुकूल हो सकूँ?", न कि "संगठन को कैसे बदलूँ ताकि वह मेरे तरीक़े के अनुकूल हो जाए?"

  2. details को document करना

    • strategy हर जगह होती है, लेकिन शायद ही कभी document की जाती है
    • महत्वपूर्ण decisions के पीछे की reasoning अक्सर document नहीं होती
    • documentation culture बनाना तेज़ी से आगे बढ़ने वाले engineering organization की कुंजी है
    • नए leaders को strategy ख़ुद बनाने से पहले मौजूदा हर चीज़ का अध्ययन करना चाहिए और दूसरी कंपनियों की सफल practices को benchmark बनाना चाहिए
    • strategy document लिखते समय Richard Rumelt के "Good Strategy, Bad Strategy" framework के इस्तेमाल की सिफ़ारिश की गई है
    • strategy चाहे कितनी भी ख़राब लिखी गई हो, उसे document कर देने भर से वह overnight बेहतर हो सकती है

[Anti-pattern #2: imperfect metrics को मापने से हिचकिचाहट]

  • measurement में anti-patterns भरे पड़े हैं
  • आदर्श रूप से शुद्धतावादी ढंग से यह कहा जा सकता है कि "हमें इसे measure नहीं करना चाहिए", लेकिन ऐसा करने से आसपास के संगठन की learning बस धीमी होती है
  • engineering executive का सबसे मूल्यवान काम दूसरे executives को यह सिखाना है कि engineering वास्तव में कैसे काम करती है

mental model को बेहतर बनाने पर फ़ोकस

  • हम चाहते हैं कि metrics वास्तविकता दिखाएँ, लेकिन metrics का काम सिर्फ़ सच दिखाना नहीं, लोगों को शिक्षित करना भी है
  • अपने mental model को ठेस पहुँचने की चिंता से ज़्यादा, board या CEO के mental model को बेहतर बनाने की चिंता करनी चाहिए

CEO को details के अंदर लाना

  • "यह measure करने का बहुत ख़राब तरीका है" कहने के बजाय यह कहना चाहिए: "आइए यहीं से शुरू करें और इस तरीके की सीमाएँ समझ में आने तक इसे गहराई से देखें"
  • लोगों को जबरन details से दूर रखना कभी अच्छा तरीका नहीं होता। उन्हें details में लाना चाहिए और वहीं सिखाना चाहिए

[Anti-pattern #3: टीम के लिए umbrella बन जाना]

  • पहले यह मान्यता थी कि टीम की रक्षा के लिए manager को "umbrella" की तरह व्यवहार करना चाहिए
  • लेकिन टीम को वास्तविकता से बचाकर रखना लंबे समय में उसी टीम को नुकसान पहुँचाता है
  • manager और engineers, दोनों को महत्वपूर्ण बातचीत में शामिल होने देना चाहिए

strategic decision-making के लिए नया दृष्टिकोण ज़रूरी

  1. Bottom-Up strategy
    • फ़ायदा: टीम को तेज़ी से काम करने और tools पर नियंत्रण रखने में मदद मिलती है
    • नुकसान: केंद्रित technical investment करना कठिन होता है, और जानकारी थोड़ी देर से मिलती है
  2. Top-Down strategy
    • नुकसान: CTO या architecture group द्वारा हर निर्णय लेना अक्षम होता है
    • committees बहुत कम ही सबसे अच्छे निर्णय लेती हैं

"navigator" का उपयोग कर निर्णयों की रफ़्तार बढ़ाना

  • हर business unit में "mini CTO" जैसी भूमिका निभाने वाले "navigator" रखकर decision-making तेज़ की जा सकती है
  • इससे ज़मीनी स्तर पर सबसे अधिक context रखने वाले लोग सबसे उपयुक्त tech stack decisions ले सकते हैं
  • सफलता के लिए सीख:
    1. documentation कभी न छोड़ें
    2. postmortem ज़रूर करें
    3. जिन लोगों पर भरोसा करेंगे, उनके चयन में बहुत सावधान रहें
  • संगठन कुछ चुनिंदा व्यक्तियों के accumulated judgment पर खड़ा होता है, और इससे बचा नहीं जा सकता

समापन

  • नियमों का बहुत सख़्ती से पालन करने का जोखिम
    • जब engineering team कंपनी के साथ बढ़ने लगती है, तो leaders को यह नहीं भूलना चाहिए कि अतीत में किन बातों ने कई अच्छे इरादों वाले executives को मुश्किल में डाला था
    • अंतिम लक्ष्य ऐसा high-quality mechanism बनाना है जो लोगों को जिज्ञासु बनने और exceptions खोजने के लिए प्रेरित करे
  • learning circle
    • Larson पिछले साढ़े तीन साल से हर दो हफ़्ते में एक "learning circle" आयोजित करते आ रहे हैं
      • 6 से 10 CTO, VP of Engineering, या tech companies के अन्य senior engineering executives इकट्ठा होकर updates साझा करते हैं और tactics व process से जुड़ी समस्याओं पर चर्चा करते हैं
      • हर meeting की शुरुआत इस तरह होती है कि बारी-बारी से हर व्यक्ति 1 मिनट में बताता है कि इस हफ़्ते उसका फ़ोकस किस पर है और वह किस विषय पर बात करना चाहता है
      • किसी विषय पर लगभग 5 मिनट बात करने के बाद, समूह एक विषय चुनता है और अगले लगभग 20 मिनट उसी पर गहराई से चर्चा करता है
      • विषय "मैं इस project की वजह से मुश्किल में हूँ" से लेकर "हमने अभी एक शानदार व्यक्ति को hire किया है और मैं उत्साहित हूँ" तक कुछ भी हो सकते हैं
  • अभ्यास के माध्यम से सीखना
    • जो लोग अभ्यास से सीखते हैं, वे learning circle या व्यक्तिगत reflection जैसी नियमित चिंतन प्रक्रियाओं के सहारे अपने नियमों को सूक्ष्म रूप से समायोजित करने के लिए आवश्यक self-reflection को मजबूर कर सकते हैं
    • Larson कहते हैं, "मैं उन लोगों के सबक़ से सीखकर बेहतर leader बना हूँ जिन्होंने मेरी तरह की गलतियाँ की थीं"

संबंधित पढ़ाई

9 टिप्पणियां

 
geniuskey 2024-07-09

आख़िर में जो हिस्सा है, Larson은 "나는 ... 더 나은 리더가 되었다"고 말함. वह थोड़ा शर्मनाक लगा। उसकी जगह अगर कुछ ऐसा होता कि 리더는 ... 하기 위해 지속적으로 노력해야한다. 나도 아직도 부족하며, 더 나아지기 위해 노력하는 중이다 तो पढ़ने में थोड़ा ज़्यादा सहज लगता। क्या यह बहुत ज़्यादा कोरियाई नज़रिया है? ^^;;
 
savvykang 2024-07-10

आपने यह पूछा कि क्या यह कोरियाई नज़रिए से है, इससे लगता है कि आप इसे अच्छी तरह समझते हैं। मेरी नज़र में वक्ता narcissism दिखा भी नहीं रहा, इसलिए ऐसी प्रतिक्रिया थोड़ी अजीब लगती है।
 
tofumaker 2024-07-10

आप लेख के सार या उसकी सामग्री पर नहीं, बल्कि वक्ता के रवैये पर ध्यान दे रहे हैं, जो बहुत कोरियाई लगता है।
 
2024-07-08
[यह टिप्पणी छिपाई गई है.]
 
savvykang 2024-07-08

यह 'Anti-pattern #1: माइक्रोमैनेजमेंट से बचें' है, लेकिन फिर माइक्रोमैनेजमेंट को भूल जाने को कहना सामग्री के प्रवाह को अजीब बना देता है।
 
frog08 2024-07-08

माइक्रोमैनेजमेंट को बुरी चीज़, यानी जिसे नहीं करना चाहिए, मानकर हर हाल में उससे बचना ही एक anti-pattern है। बात यह है कि यह तय करने के बजाय कि कुछ माइक्रोमैनेजमेंट है या नहीं, ज़रूरत के मुताबिक़ बारीकियों पर ध्यान देना चाहिए।
 
savvykang 2024-07-08

कम से कम इसे 'Anti-pattern: micromanage को एक विकल्प मानना' या 'डिटेल्स पर ध्यान देने और micromanaging को एक ही चीज़ समझना' जैसा कहा होता, तो संदर्भ थोड़ा अधिक सहज लगता। लेख की मंशा समझ में आती है, लेकिन आखिरकार जो संदेश देना है, वह यही है कि 'micro'manage के बजाय डिटेल्स पर ध्यान देने वाला manage करना चाहिए, है न।
 
kandk 2024-07-08

CTO या engineering leaders से मिलते समय सबसे ज़्यादा जिस विषय पर बात होती है, वह है CEO का दबाव कि "engineering की speed बढ़ाइए"
sales या hiring के विपरीत, engineering में कोई स्पष्ट performance metrics नहीं होते
engineering leaders के लिए CEO से यह कहना मुश्किल होता है कि "engineering एक कला है, इसलिए इसके outcomes का अनुमान लगाना कठिन है"
 
xguru 2024-07-08

इस लेख पर Hacker News की राय भी देखें.

  • कई संगठनों में लागू करके देखने पर यह राय सामने आई कि Will Larson की methodology उतनी प्रभावी नहीं है. उनकी methodology इंजीनियरों और बिज़नेस के बीच टकराव पैदा करती है.
  • Ron Jeffries की किताब की सिफारिश: "The Nature of Software Development" की सिफारिश की गई है, जो incremental value, engineer-led development, continuous feedback, और flexibility पर ज़ोर देती है.
  • यह सकारात्मक बात है कि Larson में आत्मचिंतन और आलोचना करने की क्षमता है. उनकी लिखी बातें हमेशा सही या गलत नहीं होतीं, लेकिन वे समस्या-समाधान में गहराई से डूबे रहते हैं.
  • web-आधारित products की प्रकृति के कारण errors घातक नहीं होते, और बार-बार होने वाले बदलाव अक्सर marketing कारणों से किए जाते हैं. इसलिए तेज़ी से आगे बढ़ने और गलतियों को स्वीकार करने वाली संस्कृति बनती है.
  • micromanagement का सकारात्मक पक्ष: अच्छा engineering leader details को अच्छी तरह समझता है और टीम के साथ संवाद कर सकता है. यह micromanagement से अलग है.
  • बहुत अधिक technical staff होने से समस्याएँ पैदा होती हैं. अगर बेहतर tools विकसित हो जाएँ, तो छोटे teams भी पर्याप्त रूप से काम कर सकेंगे.
  • समस्या measurement में नहीं, बल्कि उसके नतीजों के आधार पर गलत निर्णय लेने में है. metrics का उपयोग सवाल उठाने के tool के रूप में होना चाहिए.
  • बड़े पैमाने पर software development में collaboration सबसे अहम है. community का टूटना project की रफ़्तार धीमी होने का मुख्य कारण है.
  • development pipeline में अगर हर व्यक्ति की भूमिका और अपेक्षाएँ स्पष्ट न हों, तो समस्याएँ पैदा होती हैं. managers को ऐसी स्थितियों का समाधान करना चाहिए.
  • राय है कि लेख अच्छा है, लेकिन अगर इसकी लंबाई 25% कम होती, तो यह और बेहतर होता.