हमेशा छोड़ने के लिए तैयार रहें

• कार्यस्थल पर काम करने की एक अच्छी philosophy है: "Always be quitting"

• इसका मतलब यह नहीं है कि आप लगातार नौकरी छोड़ने के बारे में सोचें, बल्कि ऐसे काम करें कि आप कभी भी जा सकें

→ इससे आप एक बेहतर engineer बनते हैं और growth के मौके खुलते हैं

→ यह "खुद को replaceable बनाना" और "कार्यस्थल पर अपने काम को automate करना" जैसी बातों से मिलता-जुलता है

• मूल बात है "अनिवार्य न बनना": NOT being indispensable

→ अगर आप अनिवार्य बन जाते हैं, तो आप एक खास job में फँस जाते हैं और न छुट्टी मिलती है, न growth

→ और अगर वह job ही गैर-ज़रूरी हो जाए, तो आपकी जगह भी गैर-ज़रूरी हो जाती है

• विरोधाभासी लग सकता है, लेकिन disposable बनना ही आपको आज़ादी देता है

→ इससे ऊँची भूमिका में grow करना आसान हो जाता है, और जिस project पर आप काम कर रहे हैं उसे बदलना भी आसान हो जाता है

• इसे व्यवहार में लाने के कुछ ठोस तरीके

1. अपने ज्ञान को document करें.

→ जब कोई आपसे सवाल पूछता है, तो वह आपके बनाए हुए documents की कमी दिखाता है.

→ जवाब को documents, bugs, code comments या कहीं भी लिख दें ताकि आपके बाद आने वाले व्यक्ति को आपकी ज़रूरत न पड़े.

2. long-term plan को document करें.

→ ऐसा करें कि आपको real-time में समझाने की ज़रूरत न पड़े, और लोग उस plan को देखकर समझ सकें कि project में आगे क्या होने वाला है.

→ कई महीनों पहले से planning करके रखें, ताकि आपके जाने पर भी साथी पहले ही दिन से भटके नहीं.

3. meetings को document करें.

→ जिन meetings में आप शामिल होते हैं, उन सबका record बनाकर टीम के साथ साझा करें, और लिखें कि कौन शामिल था, क्या चर्चा हुई, और किस निष्कर्ष पर पहुँचे.

→ इन meeting notes का design documents में reference दें. आपके बाद आने वाले व्यक्ति को catch up करने के लिए इनकी ज़रूरत होगी.

4. दूसरे लोगों को meetings में invite करें.

→ अगर वह 1:1 meeting नहीं है और आपकी टीम से केवल आप ही किसी meeting में जा रहे हैं, तो और लोगों को भी invite करें.

→ अलग-अलग viewpoints उपयोगी होते हैं, लेकिन उससे भी ज़्यादा ज़रूरी है कि आप अकेले contact point न बनें.

5. अपने आसपास के लोगों को train करें.

→ लक्ष्य यह है कि वे independent बनें. (सामान्य engineering ladder में जिसे senior कहा जाता है)

→ उन्हें plans और skills से परिचित कराएँ, और documents का उपयोग करना सिखाएँ.

6. अपने successor को खोजें और train करें.

→ अगर आपको अपना role बदलना है, तो आपका replacement होना चाहिए. अपने स्थान पर आने वाले व्यक्ति को खोजें और उसे सक्रिय व लगातार coach करें.

7. लोगों को power दें.

→ उन पर भरोसा करें कि वे सही काम करेंगे.

→ अगर आप leadership position में हैं, तो दूसरों को हर बात के लिए आपसे permission माँगने की आदत न डालें.

→ उन्हें खुद चुनाव करने दें, और सही data के आधार पर निर्णय लेने में guide करें.

8. खुद PoC(Point of Contact) मत बनें.

→ mailing list या दूसरे communication channels बनाएँ जिनमें दूसरे लोगों को भी शामिल किया जा सके, और उन्हें scale करें.

9. delegate करें.

→ अगर आपने दूसरों को power दी है, उन्हें groups और meetings में शामिल किया है, और knowledge को document किया है, तो वे आपका काम करने के लिए तैयार हैं.

→ ऐसे काम delegate करें जिनसे वे grow कर सकें, और आप उन कामों पर ध्यान दें jo केवल आप कर सकते हैं.

10. हमेशा सीखते रहें.

→ जिन क्षेत्रों में रुचि है, उनमें अपना ज्ञान बढ़ाएँ और उसे मज़ेदार बनाए रखें.

→ अगर वह क्षेत्र आपके इच्छित भविष्य से मेल खाता है, तो यह bonus है!

• इसका मतलब यह नहीं है कि आप अपनी जिम्मेदारियों को छोड़ दें.

→ आपको अब भी अपने project और team की जिम्मेदारी लेनी चाहिए, और जब तक आप उस role में हैं, उसे निभाते रहना चाहिए.

→ यह महत्वपूर्ण है, क्योंकि यही जिम्मेदारी आपके लिए नए दरवाज़े खोलेगी.

• अगर आप ऊपर की ये सारी बातें करते हैं, तो आप सिर्फ खुद को नहीं बल्कि पूरी team को बेहतर बनाते हैं.

→ यह तब भी संभव है जब आप IC(Individual Contributor, यानी non-management role) हों, और वास्तव में यह Staff/Principal+ engineers की कुछ skills का अभ्यास करने जैसा है.

[bichi]

कम-से-कम यहाँ लिखी गई बातों को तो बिना किसी अपवाद के 100% लागू किया जाना चाहिए, तभी कोई कंपनी सामान्य रूप से काम कर सकती है।

[dua804]

मैंने अपने काम के लिए एक मानक भी तय किया है—"काम मेरे बिना भी चलता रहना चाहिए। अगर मैं हूँ, तो काम बेहतर होना चाहिए।" और मैं इसे निभाने की कोशिश कर रहा हूँ.

[xguru]

कुछ सलाह थोड़ी "हूँ?" जैसी लगती है। बड़े संगठनों के लिए यह ठीक बैठ सकती है, लेकिन startup संगठनों के साथ भी यह हमेशा अच्छी तरह मेल खाए, ऐसा नहीं है.

फिर भी, knowledge और meetings को document करना, training देना, authority देना, delegate करना, और हमेशा सीखने वाले रवैये के साथ काम करना अच्छा है, ऐसा मुझे लगता है.

HN पर भी इस लेख को लेकर पक्ष और विपक्ष, दोनों तरह की राय बहुत हैं https://news.ycombinator.com/item?id=27456222