जिस मैनेजर से मैं नफ़रत करता था, उसने मुझे जो सबक सिखाया

• अब मैं एक engineering manager हूँ, लेकिन जब मैं software engineer के रूप में काम करता था, तब मैंने कई दिनों तक एक जटिल feature पर काम करके PR उठाया था
• feedback सख्त और ठंडा था: “यह over-engineering है। बहुत complex है। Refactor कीजिए” — बस यही एक छोटा-सा वाक्य था
• बिना एक भी तारीफ़ के सिर्फ आलोचना मिलने के अनुभव से मैं गुस्से में था, लेकिन उस manager के साथ यह किस्सा सिर्फ शुरुआत भर था

भावनाओं का ख़याल न रखने वाली leadership style

• यह manager उन leaders से अलग था जिन्हें मैं पहले से जानता था
• न वह हाथ पकड़कर चलाता था, न ही मुलायम शब्द बोलता था
• उसकी कुछ विशेषताएँ थीं
  • अधपके ideas को तुरंत reject कर देता था
  • complexity के लिए complexity से नफ़रत करता था
  • सिर्फ साफ़, maintainable और efficient code को महत्व देता था
• retrospectives में भी वह घुमा-फिराकर नहीं, सीधे समस्या की ओर इशारा करता था
• शुरुआत में मुझे लगा कि उसका स्वभाव बेहद कठोर है, लेकिन उसके पीछे एक अलग philosophy थी

self-respect को हिला देने वाले feedback का turning point

• sprint review में मैंने आत्मविश्वास के साथ feature demo किया, लेकिन manager ने बीच में रोककर पूछा
  > “यह fragile है। load की स्थिति में क्या होगा? rollback plan क्या है?”
• जब मैं ठीक से जवाब नहीं दे पाया, तो manager ने कहा:
  > “अभी तुम coder की तरह सोच रहे हो। तुम्हें engineer की तरह सोचना चाहिए”
• पहले मुझे गुस्सा आया, लेकिन अंततः मुझे एहसास हुआ कि मेरी coding style resilience से ज़्यादा cleverness पर केंद्रित थी

असली सबक: वह manager मुझ पर व्यक्तिगत हमला नहीं कर रहा था

• मेरी सोच में बड़ा बदलाव आया
  • “smart” code की जगह आसान से पढ़ा जाने वाला code लिखने लगा
  • failure scenarios को ध्यान में रखकर design करने पर ध्यान देने लगा
  • अपने लिए नहीं, बल्कि अगले developer के लिए code लिखने लगा
• उसके बाद उस manager के code reviews आसानी से pass होने लगे
• manager नहीं बदला था, मैं खुद विकसित हुआ था

मेरी leadership style पर इसका प्रभाव

• engineering manager बनने के बाद मैंने उस अनुभव को बहुत बार याद किया
• मैं ऐसा leader नहीं बनना चाहता था जिससे लोग नफ़रत करें, लेकिन सिर्फ नरम होने वाला leader भी नहीं बनना चाहता था
• मैंने अपनी style इस तरह बनाई
  • सीधा feedback, लेकिन context के साथ देता हूँ
  • system thinking पर ज़ोर देता हूँ
  • standards ऊँचे रखता हूँ, लेकिन मानवीय feedback देता हूँ
• engineers चुनौती पसंद करते हैं, लेकिन उन्हें नज़रअंदाज़ किया जाना पसंद नहीं होता

कब एक सख्त manager की ज़रूरत होती है

• leadership में ego, deadlines और pressure उलझे रहते हैं, इसलिए बहुत भ्रम पैदा होता है
• एक सख्त manager इस भ्रम को निम्न तरीकों से दूर करता है
  • features नहीं, scalability के बारे में सोचने पर मजबूर करता है
  • clever code की जगह maintainable code लिखवाता है
  • failure और edge cases के लिए पहले से तैयार कराता है
• वह भावनाओं से ज़्यादा code के टिकाऊपन को महत्व देता है

सख्त manager के तहत survive और grow कैसे करें

• अगर आप किसी दमघोंटू leader के अधीन हैं, तो इस तरह निपट सकते हैं
  • इसे व्यक्तिगत हमला न मानें: feedback code के बारे में है
  • feedback के बाद “क्यों?” पूछें: ज़्यादातर सख्त leaders जिज्ञासा का सम्मान करते हैं
  • खुद पहले failure points के बारे में सोचें: आपको manager की तरह सोचना शुरू करना होगा
• अगर आप leader हैं, तो आपको यह करना चाहिए
  • ऊँचे standards रखें, लेकिन यह भी समझाएँ कि वे क्यों महत्वपूर्ण हैं
  • अस्पष्ट feedback की जगह ठोस और specific बात करें
  • success से ज़्यादा growth का जश्न मनाएँ: अगर developer ने manager से पहले समस्या पकड़ ली, तो उसकी सराहना करें

Reject हुए Pull Request का सबसे बड़ा उपहार

• शुरुआत में मेरी self-respect को ठेस पहुँची थी, लेकिन अब पीछे मुड़कर देखता हूँ तो वह reject हुआ PR मेरी ज़िंदगी का सबसे बड़ा अवसर था
• उसी ने मुझे coding को personal project नहीं, बल्कि system building के रूप में देखना सिखाया
• सख्त manager आपको अच्छा महसूस नहीं कराते, लेकिन एक developer के रूप में बढ़ने में मदद करते हैं
• असली growth PR pass होने पर नहीं, बल्कि reject होने पर शुरू होती है

[ohyecloudy]

अगर एक ऐसा सीधा-सादा मैनेजर हो जो भावनाओं का ख़याल नहीं रखता, और दूसरा ऐसा सौम्य मैनेजर हो जो rapport बनाए रखता है, तो फीडबैक के ज़रिए टीम सदस्य की growth को आगे बढ़ाने में किस तरह का मैनेजर ज़्यादा मदद कर सकता है? पिछला लेख पढ़ते हुए मेरे मन में यही सवाल आया।

मेरे हिसाब से यह probability का खेल है। बेहद खराब odds को पार करके grow करने वाले लोग कहीं भी मिल जाते हैं। मुझे लगता है कि मैनेजर को ऐसे लोगों को अलग रखकर कुल probability बढ़ाने की कोशिश करनी चाहिए। जो मैनेजर अपने तरीके से probability बढ़ाने वाला रवैया मानकर काम करता है, वह सम्मान के योग्य है। बस इतना काफ़ी है कि वह यह सोचकर पुराने तरीके पर अड़ा न रहे कि वैसे भी चल ही जाएगा।

[roxie]

मुझे लगता है कि इस तरह का feedback, व्यक्ति के स्वभाव, cultural background और व्यक्तिगत अंतर के अनुसार, सुनते समय बुरा लग सकता है या गुस्सा भी आ सकता है। लेकिन मूल रूप से यह सोचकर आगे बढ़ना कि "वह व्यक्ति मुझे जानबूझकर परेशान नहीं कर रहा है" मानसिक रूप से भी और growth के नज़रिए से भी बेहतर लगता है। जब ऐसी स्थिति आए, तो इस लेख को याद करके "शायद यह manager भी?" ऐसा सोचकर देख सकते हैं। अच्छा लेख है।

[bbulbum]

लोग अक्सर kind and direct की बात करते हैं, लेकिन सच कहें तो kind होने से कहीं ज़्यादा मुश्किल direct होना है।

[pcj9024]

भले ही वह पूरा context न दे, लेकिन जो context followers को follow करने के लिए चाहिए वह भी न बता पाने वाला leader किसी काम का नहीं है
लगता है यह लेख किसी ऐसे बेहतरीन follower ने लिखा है जो अपनी उत्कृष्ट क्षमता का श्रेय दूसरों को देता है
अगर leader context ही न दे, तो उस leader की खास ज़रूरत नहीं है
उसे तुरंत बदल देना चाहिए

[colus001]

जो बात सुनने में अच्छी लगे, वह ज़रूरी नहीं कि सच में अच्छी ही हो। मुझे भी लगता है कि मेरी ज़िंदगी में सबसे मददगार code review वही था जिसमें सिर्फ़ दो शब्द थे: Nasty Code.

[halfenif]

हर डेवलपर एक जैसा डेवलपर नहीं होता।

[kipsong133]

मैंने सोचा कि "systemic thinking" आखिर क्या है, और इस लेख के संदर्भ में यह किसी application के काम करने के नज़रिए से सोचने जैसा लगता है। लेकिन मुझे लगता है कि यह वाकई बहुत महत्वपूर्ण नज़रिया है.

[play1204dev]

चीज़ों को बहुत नरमी से संभालते-सम्भालते codebase को बिखरते हुए देखा है, इसलिए इससे काफ़ी सहमति है। सच में manager की capability की अहमियत बहुत बड़ी होती है।

[girr311]

मैं सहमत हूँ

[spilist2]

लेख का निहितार्थ यह ज़्यादा लगता है कि वह मैनेजर असाधारण था, ऐसा नहीं, बल्कि खुद लेखक ने अच्छा किया। (क्या लेखक शायद ऐसे व्यक्ति हैं जो किसी भी तरह का feedback पाकर आगे बढ़ते हैं?)

मुझे याद है कि मैंने एक शोध देखा था जिसमें कहा गया था कि जब (संदर्भ की कमी वाला) नकारात्मक feedback मिलता है, तो व्यवहार के अपेक्षा के उलट बदलने की संभावना अधिक होती है.

[kandk]

यह समझना ज़रूरी है कि काम पर मिलने वाला फ़ीडबैक व्यक्तिगत आलोचना नहीं होता।
अगर मैनेजर बेहतर इंसान होता तो शायद और अच्छा होता, लेकिन कंपनी स्कूल नहीं है... और हम professionals हैं... इसलिए फ़ीडबैक से कैसे सीखना है, यह हमें खुद सीखना पड़ता है.
यह कहने की हिम्मत भी चाहिए कि अगर कुछ नहीं पता, तो साफ़-साफ़ कह सकें कि नहीं पता।

[vvvvvv]

ऐसा लगता है कि आपका दृष्टिकोण मेरे दृष्टिकोण से काफ़ी अलग है। शायद मेरा करियर अभी उतना लंबा नहीं रहा, इसलिए मैंने ज़्यादातर यही देखा है कि अस्पष्ट feedback और ऐसे feedback जिनमें संदर्भित व्यक्ति या चीज़ साफ़ न हो, उल्टा नकारात्मक असर ही पैदा करते हैं...

[laeyoung]

वर्तनी गलत है।
"यह समझना चाहिए कि यह आलोचना नहीं है।" -> आपको इसे "यह समझना चाहिए कि यह आलोचना नहीं है।" लिखना चाहिए।

आप जानते होंगे कि यह व्यक्तिगत आलोचना नहीं है, लेकिन मुझे लगता है कि इसे देखते ही मेरी इस टिप्पणी पर आपको गुस्सा आया होगा। कोई इसे 조삼모사 कह सकता है, लेकिन लोगों का 조삼모사 और 조사모삼 को अलग तरह से लेना भी स्वाभाविक लगता है।

ps. मुझे भी आपकी वर्तनी की गलती का पता नहीं था, लेकिन एक उदाहरण ढूँढना चाहता था, इसलिए spell checker में डालने के बाद ही मुझे पता चला कि आपने इसे गलत लिखा था।

[roxie]

अगर कोई आपकी वर्तनी की गलती सुधार दे, तो "धन्यवाद, मुझे पता नहीं था" कह देने भर की बात है; मुझे नहीं लगता कि यह गुस्सा करने की वजह है। मुझे लगता है कि जैसा आपने महसूस किया, वैसा ही दूसरे लोग भी महसूस करेंगे, यह मान लेना एक खतरनाक सामान्यीकरण है। और "स्वीकार करना" नहीं, बल्कि "अपनाना" है।

[kandk]

मेरा मानना है कि तनाव देने वाली चीज़ों को भी सुलझा पाना ही प्रोफेशनल होने की पहचान है.
मैं तनाव पैदा करने वाली बातों को सही ठहराने की कोशिश नहीं कर रहा हूँ. प्रोफेशनल की तरह काम करते हुए गुस्सा दिलाने वाली स्थितियाँ भी आएँगी, लेकिन उन्हें समझदारी से सुलझाना ही असली प्रोफेशनलिज़्म है.

[kandk]

मैं कोई वर्तनी विशेषज्ञ नहीं हूँ। कम्युनिटी भी कोई कंपनी नहीं है।

[qodot]

मैं इस टिप्पणी से पूरी तरह सहमत हूँ। मेरा मानना है कि इसे स्वीकार करने वाले व्यक्ति की क्षमता और मानसिकता बेहतरीन रही होगी। मुझे लगता है कि उस मैनेजर का दर्शन तो स्पष्ट था, लेकिन अपनी सोच को टीम तक पहुँचाने के लिए वह अच्छा तरीका अपनाना नहीं जानता था।

[kwj9211]

शायद यही होता है, कोई बात कितनी भी उलझाकर फेंके, उसे तुरंत ठीक से समझ लेना... हा हा

[tsboard]

वाकई बहुत अच्छा लेख है। लगता है इसे PR उठाने से पहले भी और उसके बाद भी लगातार देखते रहना चाहिए।

[ethanhur]

मुझे लगता है कि इसे व्यक्तिगत हमला बनने से बचाने के लिए पहले से अच्छा rapport बनाकर रखना ज़रूरी है। (खासकर कोरियाई समाज के संदर्भ में)

मैं व्यक्तिगत रूप से subject के इस्तेमाल पर ध्यान देता हूँ। Overengineering "यह code" है, "सामने वाला व्यक्ति" गलत नहीं है।

[winterjung]

विशेषज्ञ के दिमाग में आखिर चल क्या रहा होता है वाला लेख याद आता है। जब “यह over-engineering है। बहुत जटिल है। Refactoring कीजिए”, “यह असुरक्षित है। लोड की स्थिति में क्या होगा? Rollback प्लान क्या है?” जैसी review मिलती है, तब उन्होंने ऐसा क्यों सोचा, वे किस तरह की समस्या की आशंका कर रहे हैं, और वे सुधार की किस दिशा के बारे में सोच रहे हैं—यह पूछना भी अच्छा रहेगा। (यह नहीं कि लेख लिखने वाले ने ऐसा नहीं किया, बल्कि ऐसे हालात में कैसे अधिक उपयोगी बात हासिल की जा सकती थी, बस यही सोचकर कह रहा/रही हूँ.)

[kandk]

वाकई बहुत अच्छा लेख..