- यह लेख "खतरनाक सलाह(dangerous advice)" की अवधारणा पर है, जो सक्षम senior engineers के लिए उपयोगी हो सकती है लेकिन अनुभवहीन engineers के लिए नुकसानदेह हो सकती है
- production SQL access permission जैसी चीज़ें "sharp tools" हैं
- अपने काम की प्राथमिकताएँ खुद तय करना, कभी-कभी कंपनी के नियमों को जानबूझकर तोड़ना, और अनिश्चितता में भी मज़बूत रुख अपनाना — ये खतरनाक सलाह के ठोस उदाहरण हैं
- ज़्यादातर career advice ज़िम्मेदारी से बचने या impression management के लिए लिखी गई नकली सलाह होती है; वास्तव में काम पूरा करने के लिए अक्सर आधिकारिक नियमों के बाहर जाकर काम करना पड़ता है
- managers के पास एक संरचनात्मक सीमा होती है कि वे ऐसा सीधे नहीं कह सकते, क्योंकि risk आखिरकार उन्हीं पर लौटता है
- खतरनाक सलाह की प्रकृति high-risk, high-reward होती है, और संगठन के आधिकारिक नियमों से परे मौजूद अदृश्य(illegible) क्षेत्र को समझना इसका मुख्य बिंदु है
"Sharp tools" और "खतरनाक सलाह" का रूपक
- "Sharp tools" जैसे ssh, kubectl, और read-write production SQL console ऐसे tools हैं जो क्षमता के आधार पर बहुत मदद भी कर सकते हैं और बहुत नुकसान भी पहुँचा सकते हैं
- "खतरनाक सलाह" में भी यही गुण होते हैं; इसे सही तरह से इस्तेमाल करने के लिए क्षमता और निर्णय-शक्ति चाहिए
- गलत व्यक्ति को खतरनाक सलाह देना, गलत व्यक्ति को production SQL access permission देने जैसा है
खतरनाक सलाह के ठोस उदाहरण
- खुद तय करें कि किस पर काम करना है
- कभी-कभी कंपनी के लिखित नियमों को जानबूझकर तोड़ें
- अनिश्चितता में भी मज़बूत रुख अपनाएँ
- खुद को थोड़ा-सा 'grifter' मानें
- shipping से जुड़ी नहीं होने वाली हर activity से जानबूझकर बचें
ज़्यादातर career advice नकली क्यों होती है
- सक्षम engineers खतरनाक सलाह को उसी वजह से तरसते हैं जिस वजह से वे sharp tools चाहते हैं
- ज़्यादातर career advice liability avoidance या लोगों को प्रभावित करने के उद्देश्य से लिखी जाती है
- जो लोग सच में काम पूरा करना चाहते हैं, वे आखिरकार ऐसी खतरनाक हरकतें करते ही हैं क्योंकि वे साफ़ तौर पर मददगार होती हैं
- जब सबको पता हो कि चीज़ें आधिकारिक तरीके से वैसे काम नहीं करतीं, लेकिन कोई यह बात कहे नहीं, तो इससे गहरी अलगाव की भावना पैदा होती है
- junior दिनों में, अनौपचारिक रूप से खुलकर बात करने वाले कुछ साथियों ने बहुत मदद की
managers खतरनाक सलाह क्यों नहीं दे सकते: संरचनात्मक कारण
- अगर कोई manager किसी engineer को कंपनी policy नज़रअंदाज़ करने की सलाह दे और engineer उसे गलत तरीके से लागू कर दे (जैसे Slack पर सार्वजनिक रूप से लिख दे कि manager ने अनुमति दी थी), तो manager को और बड़ा नुकसान हो सकता है
- tech companies का leadership अक्सर engineers को "useful idiots" की तरह देखता है, जबकि managers से professional behavior की अपेक्षा की जाती है
- कई managers ऐसी सलाह देना चाहते हैं, और अगर engineer खुद से इस तरह काम करे तो वे उसे उच्च मूल्यांकन देते हैं
- ऐसे सक्षम engineer को manage करना, जो काम को अधिक strategic तरीके से और job description में कम बँधकर करे तो बहुत अधिक प्रभावी हो सकता है, manager के लिए बहुत निराशाजनक होता है
खतरनाक सलाह की असली प्रकृति: high-risk, high-reward
- खतरनाक सलाह का पालन करने के लिए साहस चाहिए
- इसकी high-risk, high-reward प्रकृति के कारण यह सक्षम engineers के लिए अनुपातहीन रूप से उपयोगी और कमजोर engineers के लिए हानिकारक होती है
- अगर आप इसके साथ सहज नहीं हैं तो इसे कभी नहीं अपनाना चाहिए; लेकिन अगर आप पहले से इस तरह काम कर रहे हैं और दीर्घकालिक गलतियों को लेकर चिंतित हैं, तो संभव है कि यह बात आप पर लागू न होती हो
Hacker News की प्रतिक्रिया और संगठनों के अदृश्य तत्व
- Hacker News पर बहुत सकारात्मक और बहुत नकारात्मक, दोनों तरह की प्रतिक्रियाएँ मिलीं
- नकारात्मक टिप्पणियों की मुख्य गलती यह मानना है that organization यानी लिखित नियमों का एक सेट, और संगठन के भीतर काम करने का मुख्य तरीका औपचारिक और संरचित collaboration है
- यह James C. Scott की Seeing Like a State में बताई गई legibility को ज़रूरत से ज़्यादा प्राथमिकता देने वाली गलती जैसा है
- हर community में ऐसे अदृश्य लेकिन संरचनात्मक रूप से अनिवार्य(load-bearing illegible) घटक होते हैं
- अपने काम में इन अदृश्य हिस्सों के बारे में सावधानी से सोचना ही इस लेख और पूरे ब्लॉग का मुख्य तर्क है
अभी कोई टिप्पणी नहीं है.