अरे, नए साथी, हमने आपको सिर्फ सौंपा गया काम खत्म करने के लिए नहीं रखा है

• नए (N00b) engineer की value इस बात से तय नहीं होती कि उसने कितने tasks पूरे किए, बल्कि इस बात से तय होती है कि आगे चलकर वह आसपास के लोगों की productivity भी बढ़ाने वाला engineer बनने की संभावना रखता है या नहीं
• senior engineer नए लोगों को तीन वर्गों में देखते हैं: A, जो organization में बदलाव लाते हैं / B, जो stable performance देते हैं / C, जिनके एक साल के भीतर छोड़कर जाने की संभावना होती है; नए व्यक्ति को यह signal देना चाहिए कि वह किस वांछित वर्ग में आता है
• B बनने के लिए code का चलना जरूरी है / progress share करनी चाहिए / शुरुआती अनुमान के 3 गुना के भीतर जैसे reasonable समय में काम खत्म करना चाहिए / reviewers और operations के जिम्मेदार लोगों के लिए अनावश्यक काम नहीं बनाना चाहिए
• A वह व्यक्ति नहीं है जो बहुत सारे काम खत्म करता है, बल्कि वह है जो अनावश्यक काम हटाता है / ज्यादा impact वाले 10% को ढूंढता है / design सुधारता है / छोटे changes लगातार submit करता है—यानी हर काम से ज्यादा सीखने वाला व्यक्ति
• बेहतरीन performance दिखाने वाली activities में सिर्फ task बंद करने से ज्यादा समय लगता है, लेकिन endlessly side tracks में फंसने के बजाय बचाया गया समय अपने और colleagues के लिए मददगार तरीके से invest करना चाहिए

---

हम मौजूदा productivity नहीं, भविष्य के engineer को hire करते हैं

• senior engineers नए लोगों को देखने के लिए broadly तीन categories इस्तेमाल करते हैं
  • A आसपास के लोगों की productivity भी काफी बढ़ाने वाला बदलाव का driver बनता है
  • B stable performance देता है और धीरे-धीरे grow करता है
  • C के एक साल बाद organization में न रहने की संभावना होती है
• seniors को अपना काम करते हुए यह भी judge करना होता है कि हर नया व्यक्ति किस category में आता है
  • A को जितना संभव हो उतना support दिया जाता है
  • B को mature engineer बनने लायक support दिया जाता है
  • जो लोग organization में टिक नहीं पाएंगे, उन पर जितना हो सके उतना कम effort लगाना चाहते हैं
• नए व्यक्ति को सौंपा गया काम manager या technical leader खुद करें तो वह ज्यादा तेज और आसानी से खत्म हो सकता है
• अगर सिर्फ अभी की productivity महत्वपूर्ण होती, तो नए लोगों को hire करने की वजह ही नहीं होती; company अभी की salary उस engineer को secure करने के लिए option premium की तरह देती है जो नया व्यक्ति भविष्य में बनेगा
• अगर grooming सफल होती है, तो मजबूत next-generation engineers मिलते हैं; अगर असफल होती है, तो seniors को 10 साल बाद भी वही engineering work करते रहना पड़ेगा

सिर्फ tasks की संख्या से नए व्यक्ति का मूल्यांकन नहीं हो सकता

• एक quarter में 40 tasks पूरे करने वाले नए व्यक्ति और 20 tasks पूरे करने वाले नए व्यक्ति में कौन बेहतर है, यह सिर्फ task count से तय नहीं किया जा सकता
• भले ही सभी tasks की difficulty समान हो, A/B/C अलग करने के लिए जरूरी जानकारी फिर भी कम रहती है
• evaluation का उद्देश्य short-term output की तुलना करना नहीं, बल्कि यह देखना है कि नया व्यक्ति किस तरह के engineer के रूप में grow कर रहा है

B और C को अलग करने वाले basic signals

• task को सबसे कम समय में बंद करने से ज्यादा महत्वपूर्ण ये conditions हैं
  • लिखा गया code सच में काम करता हो
  • दूसरों को बताया जाए कि आप क्या कर रहे हैं
  • शुरुआती अनुमानित समय के 3 गुना के भीतर जैसे reasonable समय में task खत्म हो
  • दूसरों के लिए अनुचित रूप से बहुत ज्यादा extra work न बने
• मदद मांगने से सामने वाले का समय लगना स्वीकार्य है, लेकिन नीचे की स्थितियां खराब signal बनती हैं
  • reviewer को अनावश्यक रूप से बहुत ज्यादा समय खर्च करवाना
  • errors की वजह से on-call जिम्मेदार व्यक्ति को respond करना पड़ना
  • आपके कारण हुए incident की वजह से DevOps जिम्मेदार व्यक्ति को हस्तक्षेप करना पड़ना
• जो काम नहीं किया उसे किया बताकर evaluation system को manipulate करने जैसा व्यवहार तुरंत C signal बन जाता है
• कोई भी गलती से C signal भेज सकता है, लेकिन वही C signal दो बार repeat नहीं करना चाहिए, और overall B वाले signals ज्यादा होने चाहिए

A और B को अलग करने वाली learning speed

• कम-से-कम B category में आने वाले नए लोगों में A को अलग करने का criteria पूरे किए गए tasks की संख्या नहीं, बल्कि हर task से कितना सीखा जाता है है
• नए व्यक्ति की current productivity senior से कम होना expected है; महत्वपूर्ण productivity खुद नहीं, बल्कि productivity improve होने की speed है

A category वाला behavior

• नीचे दिए गए behavior सिर्फ task xử理 करने के स्तर से आगे जाकर learning और organization की productivity बढ़ाने वाले A signals बनते हैं
  • इस बात का convincing आधार बनाना कि वह task करना ही जरूरी नहीं है
  • data analyze करके वह 10% काम ढूंढना जो कुल benefit का 90% बनाता है
  • वही काम कई तरीकों से implement करके देखना
  • बेहतर design ढूंढना, और task implementation के साथ-साथ आसपास के code को भी simplify करने वाली diff की series submit करना
    • implementation से पहले कठिन change को आसान बनाकर, फिर आसान बने change को करना बेहतर evaluation दिलाता है
  • एक बड़े diff के बजाय कई छोटे diffs लगातार submit करना
    • रोज diff upload करने में अतिरिक्त advantage है
  • मिलते-जुलते tasks को simplify करने वाला internal tool लिखना
    • अगर आगे फिर वैसा कोई similar task नहीं आने वाला है, तो यह उल्टा negative factor बन जाता है
  • official task खत्म करने में बाधा न डालते हुए दूसरे teams या code areas के लिए भी useful diff submit करना
  • सीखी गई बातों को interesting / useful / convincing तरीके से document करना
  • insightfully review करना और feedback पर तेजी से respond करना
  • solid unit tests शामिल करना
• बेहतरीन performance दिखाने के तरीके mistakes avoid करने के तरीकों से कहीं ज्यादा विविध होते हैं

minimum time से ज्यादा reasonable time महत्वपूर्ण है

• A signal वाली activities में task बंद करने के लिए जरूरी minimum implementation करने की तुलना में ज्यादा समय लगता है
• यह interesting side tracks पर unlimited समय खर्च करने की permission नहीं है
• official task हमेशा reasonable समय में खत्म होना चाहिए, लेकिन उसे absolute minimum time में खत्म करना जरूरी नहीं है

बचाए गए समय को अपने और colleagues में reinvest करें

• ऐसा लग सकता है कि additional learning और improvements के लिए समय नहीं है, लेकिन time management / work queue management / diff queue management जैसी skills से progress speed बढ़ाई जा सकती है
• इस तरह बचाया गया समय दूसरों को भी benefit देने वाले तरीके से अपने growth में invest करना चाहिए

[loblue]

ऐसा लगता है कि बात इस पर होनी चाहिए कि A बनने की क्षमता वाले नए लोगों को कैसे चुना जाए, और क्षमता वाले नए लोगों को A बनाने की ट्रेनिंग कैसे दी जाए...
लेकिन लेख की सामग्री काफ़ी उकसाने वाली है..

[kimjoin2]

संगठन को बदल देने वाला A / स्थिर प्रदर्शन देने वाला B / 1 साल के भीतर छोड़कर जाने की संभावना वाला C
A / B को अलग करना समझ में आता है, लेकिन C में A, B होते हुए भी C भी बहुत होंगे...
लगता है यह ऐसी कंपनी है जो प्रदर्शन और प्रभाव के मुताबिक वेतन में तुरंत-तुरंत अच्छी तरह से दिखाती है, इसलिए employee satisfaction बहुत ऊंचा होगा.

[cartwheel8815]

जो काम नहीं किया उसे किया हुआ दिखाना जैसी हरकतों से evaluation system में हेरफेर करने की कोशिश करना तुरंत C signal बन जाता है

इसे देखें तो सच में 1 साल के भीतर चले जाने की संभावना, firing को नरम ढंग से कहने वाला वाक्य भी हो सकती है...

[kimjoin2]

अच्छा, ऐसा है। haha मैंने तो नौकरी से निकाले जाने के बारे में सोचा ही नहीं था।