जूनियर इंजीनियरों को क्यों हायर करना चाहिए
- हाल के वर्षों में Big Tech कंपनियाँ मुख्य रूप से ऐसे staff developers को पसंद कर रही हैं जो "तुरंत योगदान दे सकें"
- बहुत से लोग मानते हैं कि AI जूनियर डेवलपर्स को पूरी तरह replace कर देगा
- लेकिन जूनियर कर्मचारियों के होने का कारण सिर्फ श्रम उपलब्ध कराना नहीं है, बल्कि मनोवैज्ञानिक रूप से सुरक्षित संस्कृति और innovation को बढ़ावा देना भी है
टीम पर जूनियर प्रतिभा का प्रभाव
- जूनियर प्रतिभाएँ टीम को सिखाने, coaching करने और सहयोग करने के लिए मजबूर करती हैं
- Nonaka और Takeuchi की 'The Knowledge-Creating Company' में तर्क दिया गया है कि जापानी कंपनियों ने ज्ञान-सृजन पर ध्यान देकर innovation को आगे बढ़ाया
- innovative कंपनियाँ ज्ञान को सिखाने, फैलाने और साझा करने को प्राथमिकता देती हैं
- ज्ञान की खोज स्वयं innovation है
- जूनियर कंपनी के ज्ञान को absorb करके उसे दोबारा process करते हैं और explicit knowledge में बदलते हैं
- जूनियर टीम में redundancy भी लाते हैं, जिससे bug fixes और late-night work जैसी साधारण टीम ज़रूरतें पूरी होती हैं
Generalists विशेषज्ञों की तुलना में बेहतर innovation ला सकते हैं
Range नामक किताब में कहा गया है कि "generalists अक्सर innovative ideas पेश करते हैं"
- इसका एक典型 उदाहरण Wright brothers हैं, जो विशेषज्ञ नहीं थे बल्कि साइकिलों से छेड़छाड़ करते-करते आखिरकार हवाई जहाज़ का आविष्कार कर गए
- NoSQL databases relational database विशेषज्ञों से नहीं, बल्कि distributed systems से छेड़छाड़ करने वाले लोगों से आए
- जूनियर कर्मचारी अक्सर Socratic dialogue के ज़रिए समस्याएँ सुलझाने की कोशिश करते हैं
- विशेषज्ञ कई बार ego या blind spots की वजह से साफ़ दिखने वाले समाधान नहीं देख पाते
- जूनियर लगातार कोशिश करते रहते हैं, और कभी-कभी उन समस्याओं को भी हल कर देते हैं जिन्हें seniors बहुत कठिन मान चुके होते हैं
- जूनियर अक्सर "मूर्खतापूर्ण" लगने वाली चीज़ें आज़माते हैं जो ज़्यादातर बार fail होती हैं, लेकिन कभी-कभी वे यह दिखा देती हैं कि विशेषज्ञ कितने समय से अपनी मान्यताओं के अंधे बने हुए थे
- कुछ महान ideas जूनियर कर्मचारियों से ही आए हैं
- Jack Dorsey ने podcast कंपनी में जूनियर कर्मचारी रहते हुए Twitter का idea दिया था
- Post-it का आविष्कार 3M के जूनियर कर्मचारियों Spencer Silver और Art Fry ने किया था
- Firefox Netscape में काम कर रहे Blake Ross का side project था
- जूनियरों की backgrounds seniors की तुलना में अधिक विविध होती हैं, जिससे ऐसे विचार और perspectives आते हैं जिन्हें senior पूरी तरह miss कर देते हैं
जूनियर का मतलब है psychological safety, और इसका मतलब है अधिक innovation
- organizational literature में psychological safety शब्द 1999 में Amy Edmonson के paper से आया
- मुख्य उद्धरण: "टीम की psychological safety का learning behavior से संबंध है, लेकिन team efficacy का नहीं" (
efficacy == perceived competence)
- जब coaching को norm बनाया जाता है, तो psychological safety बढ़ती है. टीम के सदस्य अपनी गलतियाँ स्वीकार करने और errors report करने के लिए अधिक तैयार रहते हैं
- संक्षेप में, learning culture psychological safety पैदा करती है. psychological safety learning पैदा करती है. learning और innovation साथ-साथ चलते हैं
- यह group cohesion से कुछ हद तक विपरीत है
- group cohesion का मतलब उन सहकर्मियों के बीच घनिष्ठ संबंध है जो लंबे समय से साथ काम कर रहे हों
- ऐसी cohesion दूसरे लोगों के विचारों का विरोध करने और उन्हें चुनौती देने की इच्छा को कम कर सकती है (
groupthink घटना)
- इसका अर्थ है interpersonal risk लेने की कमी
- लंबे समय से साथ काम कर रहे सहकर्मियों से बनी स्थिर टीमें groupthink में फँस जाती हैं और innovation की क्षमता खो देती हैं
- वे कभी-कभी बाहरी ideas और अनुभवों के खिलाफ एक immune system जैसा बना लेती हैं
- किसी नए व्यक्ति को, खासकर जूनियर को, onboard करना झुंझलाने वाला लग सकता है, क्योंकि सहकर्मी सिखाने और सीखने का आनंद नहीं लेते
- हम सबने ऐसे जिद्दी कर्मचारियों को देखा है जो अपने knowledge silo में जीते हैं और अपना काम दूसरों के सामने खोलने से हिचकते हैं
- वे "learning behavior" वाली muscle खो देते हैं
- "learning behavior" में experiment करने की क्षमता भी शामिल है**
- यही वह चीज़ है जो हम चाहते हैं कि और ज़्यादा टीमों में हो
- इसका मतलब नए approaches आज़माना, अधिक A/B tests चलाना, और ऐसे product directions को भी आज़माने के लिए तैयार रहना है जो शायद काम न करें (लेकिन कभी-कभी करते हैं)
- founders अक्सर कहते हैं "fail fast", लेकिन founders/managers भी अपने सबसे बड़े दुश्मन बन सकते हैं: वे सिर्फ ऐसे विशेषज्ञ चाहते हैं जिनके पास पहले से सारे जवाब हों, न कि ऐसे जूनियर जो नए जवाब खोजने की कोशिश करें
अगर आप जूनियरों को हायर नहीं करेंगे, तो आपकी organization किन समस्याओं से गुज़रेगी
- ऊपर कही गई कई बातें यहाँ एक-दूसरे से जुड़ने लगती हैं:
- ऐसे जूनियर हायर करें जो सीखना चाहते हों
- ऐसे seniors हायर करें जो सिखाना चाहते हों
- जो सिखा नहीं सकता, उसे शायद "करने" की भी अनुमति नहीं मिलनी चाहिए
- एक टीम बहुत हद तक एक healthy university lab जैसी होती है
- आदर्श senior खुले मन वाला होता है और challenge किए जाने के लिए उत्सुक रहता है
- वह नए रास्ते खोजने के लिए अपनी expertise छोड़ने को तैयार रहता है
- और जब ऐसे जूनियर साथ हों जो स्पंज की तरह ज्ञान सोखने के उत्साह के साथ आते हैं, तो वे अपने भोले सवालों से नए ideas निकालते हैं और बुनियाद तक हिला देते हैं
- यही है high-performing team का हिस्सा होने जैसा एहसास
- लोग ideas के लिए खुले होते हैं, credit बाँटने को तैयार रहते हैं, और blame से बचते हैं
- वे लगातार shipping करते हैं, सफलता और सीख को साझा करते हैं, और टीम पर भरोसा करते हैं
- यह पूरी तस्वीर का सिर्फ 50% है (व्यक्तिगत राय)
- बाकी 50% के लिए "outside world" के साथ एक interface चाहिए, जो इस टीम की रक्षा करे, अंदर की अव्यवस्था को एक सुसंगत कहानी के रूप में पेश करे, और investors व stakeholders के साथ मिलकर बिखरे हुए experiments को प्रगति की शानदार कहानी में बदल दे
- दुर्भाग्य से, बहुत से executives leadership की इस सतही छवि को ही पूरा system समझ लेते हैं, और उस teaching-learning के internal combustion engine को नज़रअंदाज़ कर देते हैं जो इसे वास्तव में चलाता है
GN⁺ की राय
- जूनियर डेवलपर्स को हायर करना सिर्फ code लिखने वाले लोग जुटाने से कहीं अधिक मायने रखता है. यह सीधे organization culture और innovation capability से जुड़ा मुद्दा है
- AI तकनीक की प्रगति से यह लग सकता है कि जूनियर डेवलपर्स की भूमिका खतरे में है, लेकिन इसके बजाय इसे AI के साथ collaborate करके नई value बनाने के अवसर के रूप में देखना चाहिए
- जो कंपनियाँ जूनियर डेवलपर्स की सक्रिय रूप से भर्ती और परवरिश करती हैं, उनके पास लंबी अवधि में अधिक प्रतिस्पर्धात्मक बढ़त होगी. सामने दिख रहे तात्कालिक नतीजों से चिपके रहने के बजाय organization की sustainable growth के लिए निवेश करना चाहिए
- अगर जूनियर डेवलपर्स को हायर करना कठिन हो, तो in-house training programs को मज़बूत करना, internship models का उपयोग करना जैसे कई उपाय तलाशे जा सकते हैं
- सबसे बढ़कर, management और leaders को जूनियर प्रतिभा की value को सही तरह से समझना होगा और उन्हें विकसित व उपयोग करने के लिए long-term vision पेश करनी होगी
6 टिप्पणियां
मैं कुल मिलाकर सहमत हूँ, लेकिन मुझे लगता है कि junior developer को hire करना एक उदाहरण हो सकता है.
मुझे यह भी लगता है कि non-expert developer (जो उस domain को अच्छी तरह नहीं जानता) भी कुछ हद तक इसी तरह का मामला हो सकता है.
यह एक ऐसा नज़रिया है जिसके बारे में मैंने पहले नहीं सोचा था, इसलिए अच्छा लगा.
> जूनियर कंपनी के ज्ञान को आत्मसात करके उसे दोबारा प्रोसेस करते हैं और उसे स्पष्ट ज्ञान में बदलते हैं
इस हिस्से से मुझे खास तौर पर सहमति है, और लगता है कि इससे सहकर्मी भी ज्ञान को स्पष्ट रूप में बदलने की कोशिश करने लगते हैं.
सिर्फ code review को ही लें, तो अनुभवी लोग कई चीज़ों से सहज रूप से बचते हैं, लेकिन जूनियर उन्हें आज़माने की कोशिश करते हैं, और उन्हें समझाने के लिए लोग ज्ञान को व्यवस्थित करके साझा करने लगते हैं.
"खुद को जानो" by सोक्रेटीस
निष्कर्ष: स्मार्ट, रचनात्मक, सीखने के इच्छुक और कुल मिलाकर हर काम में अच्छे junior developers को hire करें
इस लेख का सिर्फ़ शीर्षक देखकर कुछ चालाक प्रबंधक शायद सिर्फ़ श्रम लागत के बारे में सोचेंगे।
Hacker News की राय
code review के ज़रिए डेवलपर्स code quality बनाए रख सकते हैं और सीख सकते हैं
John Ousterhout की "A Philosophy of Software Design" के सिद्धांतों का पालन
junior developers को guidance की ज़रूरत होती है
हम सिर्फ junior developers को hire करने वाली कंपनी हैं
हर generalist junior नहीं होता, और हर junior generalist नहीं होता
कई कंपनियाँ junior developers को hire नहीं करतीं
junior developers की गलत hiring codebase पर नकारात्मक असर डाल सकती है
junior developers को hire करना और train करना industry की सेहत के लिए महत्वपूर्ण है
senior developers के जाने की स्थिति के लिए junior developers को hire और train करना चाहिए
अक्सर यह डर होता है कि junior developers प्रभावी नहीं होंगे
junior developers की सफलता की रणनीति