हम में से अधिकांश लोग रिज्यूमे को एक टैक्स फॉर्म की तरह मानते हैं। हर कुछ महीनों में, या जब भी कोई रिक्रूटर संपर्क करता है, हम फाइल खोलते हैं, नवीनतम नौकरी जोड़ते हैं, कुछ क्रियाओं (verbs) को बदलते हैं, और सेव कर देते हैं। यह निर्माण नहीं, बल्कि रखरखाव का एक काम है। हम अपने करियर के बारे में 'डिलीवरेबल्स' की भाषा में बात करते हैं: बंद किए गए टिकट्स, शिप किए गए फीचर्स, या प्रतिशत सुधार जिनका पूरा श्रेय हम नहीं ले सकते। दस्तावेज़ लंबा तो होता जाता है, लेकिन उसमें गहराई कम ही आती है।
फिर वे क्षण आते हैं जब यह दिनचर्या टूट जाती है।
वह रिज्यूमे जिसे हम अपडेट तो करते हैं पर कभी पढ़ते नहीं
विशेष रूप से तकनीक के क्षेत्र में, अपडेट रहने का दबाव स्व-दस्तावेजीकरण (self-documentation) को एक भागदौड़ भरी दौड़ में बदल देता है। आप एक फ्रेमवर्क सीखते हैं, सर्टिफिकेट प्राप्त करते हैं, एक स्प्रिंट रेट्रोस्पेक्टिव का नेतृत्व करते हैं, और तुरंत अगली आवश्यकता की ओर बढ़ जाते हैं। इस बात पर विचार करने के लिए कोई संस्थागत ठहराव नहीं होता कि इन सब का अर्थ क्या था। करियर प्लेटफॉर्म इसी सपाटपन को बढ़ावा देते हैं। वे संदर्भ (context) नहीं, बल्कि कीवर्ड्स मांगते हैं; बाधाएं नहीं, बल्कि परिणाम मांगते हैं; निर्णय नहीं, बल्कि टूल्स मांगते हैं। समय के साथ, आप अपने काम का वर्णन तीसरे व्यक्ति (third person) में करना सीख जाते हैं, जैसे कि आप अपने ही जीवन के एक तटस्थ पर्यवेक्षक हों।
इसलिए जब एक विशेष रिज्यूमे को अपडेट करने का समय आया, तो इरादा पूरी तरह से यांत्रिक था। सर्टिफिकेट, कार्य रिकॉर्ड और प्रोजेक्ट दस्तावेज़ इकट्ठा करना। उन्हें रिवर्स क्रोनोलॉजिकल ऑर्डर में व्यवस्थित करना। जहाँ संभव हो, संख्यात्मक रूप देना। दो पृष्ठों तक सीमित करना। लेकिन पहले सर्टिफिकेट और अंतिम प्रोजेक्ट सारांश के बीच कहीं, यह अभ्यास प्रशासनिक से बदलकर अभिलेखीय (archival) हो गया। उस कागज़ ने केवल यह नहीं बताया कि काम कहाँ हुआ। उसने यह दिखाया कि काम ने कार्यकर्ता को कब बदल दिया।
आप जो बने, उसका दस्तावेजी प्रमाण
उस डेस्क पर फैली चीज़ें केवल योग्यता प्रमाण पत्र नहीं थीं। वहां देर रात तक काम करने के रिकॉर्ड थे—वे वेन्यू सेट करने, केबल और कुर्सियों को व्यवस्थित करने की रातें, ताकि अजनबियों से भरा एक कमरा विचारों को साझा कर सके। वहां सूर्योदय से पहले डिज़ाइन किए गए ग्राफिक्स थे, इसलिए नहीं कि यह जॉब डिस्क्रिप्शन में था, बल्कि इसलिए क्योंकि किसी और के लॉग-ऑन करने से पहले कुछ चीज़ों का सही दिखना ज़रूरी था। वहां पर्दे के पीछे संभाले गए लॉजिस्टिक्स और तकनीकी सहायता के प्रमाण थे, उस तरह का श्रम जिसका कोई 'कमिट हिस्ट्री' नहीं होता और कोई 'स्प्रिंट पॉइंट्स' नहीं मिलते, फिर भी जिसके बिना कुछ भी काम नहीं करता।
फिर वहां स्वयंसेवा (volunteer work) का काम था। वे कार्य जिनका कोई भुगतान नहीं मिला लेकिन उन्होंने लगभग सब कुछ सिखा दिया। आधिकारिक हिसाब-किताब में, इन घंटों की गिनती शून्य होती है। वास्तविकता में, यहीं पर 'सॉफ्ट स्किल्स' मजबूत हुए थे: उन वेंडर्स के साथ बातचीत करना जिनका मदद करने का कोई अनुबंधात्मक दायित्व नहीं था, उस वक्ता को शांत करना जिसकी स्लाइड्स प्रोजेक्ट नहीं हो रही थीं, और अटेंडियों की कतार लगने के दौरान रजिस्ट्रेशन पोर्टल को डीबग करना। ये वे दृश्य हैं जो किसी 'स्किल्स मैट्रिक्स' में ठीक से फिट नहीं होते, फिर भी वे किसी भी ट्यूटोरियल की तुलना में क्षमता को अधिक आकार देते हैं।
और हर लाइन आइटम के बीच में लोग बुने हुए थे। ऐसे रिश्ते जो केवल इसलिए शुरू हुए क्योंकि जब 'ना' कहा जा सकता था, तब उत्तर 'हाँ' था। किसी इवेंट में अचानक हुई मुलाकात जिसने सहयोग का मार्ग प्रशस्त किया। किसी सहकर्मी के लिए किया गया एक छोटा सा काम जिसने एक अप्रत्याशित रास्ता खोल दिया। संदेह के बावजूद स्वीकार किया गया एक कठिन प्रोजेक्ट। रिज्यूमे ने उस गहराई को नहीं पकड़ा, लेकिन यादों ने उसे संजो लिया।
जब आपका जॉब टाइटल आपकी कहानी चुरा लेता है
वर्षों तक, संक्षिप्त रूप सरल था: "मैं आईटी में काम करता हूँ।" यह एक ईमानदार लेबल है, लेकिन अधूरा है। लेबल सुविधाजनक होते हैं। वे रिक्रूटर्स को जल्दी से स्कैन करने देते हैं और रिश्तेदारों को डिनर पार्टियों में आपके रोजगार के बारे में बताने में मदद करते हैं। फिर भी वे पिंजरे भी बन जाते हैं। आप जितने लंबे समय तक एक ही टैग पहनते हैं, उतना ही अधिक आप यह विश्वास करने लगते हैं कि वह टैग आपकी उपयोगिता को सीमित कर देता है।
पूरे मोज़ेक (mosaic) को पीछे मुड़कर देखने पर, तस्वीर अधिक व्यापक थी। वही व्यक्ति जिसने नेटवर्क समस्याओं का समाधान किया, उसने प्रतिस्पर्धी प्राथमिकताओं वाली टीमों के बीच प्रोजेक्ट्स का समन्वय भी किया। वही हाथ जिन्होंने कॉन्फ़िगरेशन स्क्रिप्ट्स लिखीं, उन्होंने विजुअल सामग्री भी डिज़ाइन की जो गैर-तकनीकी दर्शकों को जटिलता समझा सके। समस्या समाधान (problem-solving) केवल एक बुलेट पॉइंट नहीं था; यह हर उस क्षेत्र में एक निरंतर सूत्र था जिसे संभाला गया था। इवेंट आयोजन कोई भटकाव नहीं था; यह सहनशक्ति, कूटनीति और कई धागों को बिना छोड़े संभालने की क्षमता का प्रमाण था।
तकनीकी करियर में यह एक आम जाल है। उद्योग विशेषज्ञता (specialization) को पसंद करता है। यह संकीर्ण क्षेत्रों में गहरी विशेषज्ञता को पुरस्कृत करता है। लेकिन क्षमता केवल जड़ों में नहीं, बल्कि शाखाओं में भी जमा होती है। अधिकांश तकनीकी विशेषज्ञ व्यवहार में शिक्षक, लेखक, समन्वयक और डिज़ाइनर भी होते हैं, भले ही उनके पद (title) में ऐसा न लिखा हो। इसे पहचानना गहराई को छोड़ना नहीं है। इसका अर्थ है किसी टेम्पलेट में फिट होने के लिए सतही होने का ढोंग करने से इनकार करना।
छोटे 'हाँ' से निर्मित
विकास शायद ही कभी किसी समारोह के साथ आता है। यह उन विकल्पों के माध्यम से जमा होता है जो इतने छोटे होते हैं कि उस समय वे महत्वहीन लगते हैं।
- उपलब्ध रहना। कोई वीरतापूर्ण पूरी रात जागकर काम करना नहीं, बल्कि निरंतर उपस्थिति। उपलब्ध रहने का बार-बार लिया गया निर्णय, बिना किसी के कहे डॉक्यूमेंटेशन पूरा करना, या किसी गलतफहमी को दूर करने के लिए मीटिंग के बाद दस मिनट रुकना।
- नए कौशल सीखना। कोई बड़े सर्टिफिकेशन रोडमैप नहीं, बल्कि ज़रूरत के वे क्षण। किसी प्रोडक्शन फिक्स के लिए ट्यूटोरियल को आधी गति पर देखना क्योंकि वह इंतज़ार नहीं कर सकता था। सोर्स कोड को तब तक पढ़ना जब तक कि पैटर्न समझ न आ जाए। एक प्रैक्टिस एग्जाम में फेल होना और फिर भी अगली शाम को वापस आना।
- दूसरों की मदद करना। मैनुअल का लिंक देने के बजाय जूनियर के सवाल का जवाब देना। पेयर प्रोग्रामिंग करना जब आप अकेले काम करना पसंद करते। ऑनबोर्डिंग गाइड लिखना जिसे किसी ने नहीं सौंपा था क्योंकि आपको अपने पहले हफ्ते की उलझन याद है।
- तैयार न होने पर भी 'हाँ' कहना। किसी ऐसे प्रोजेक्ट का स्कोप तय करने के लिए सहमत होना जिसे आपने पहले कभी नहीं किया। उस टाइमज़ोन में मीटिंग चलाने के लिए खुद को आगे लाना जिसे आप पसंद नहीं करते। उस काम को पेश करने के लिए खड़े होना जो अभी भी अधूरा सा लगता है। तैयार न होना आमतौर पर अपनी सीमाओं को आगे बढ़ाने (stretch) का संकेत है, अक्षमता का नहीं।
ये रेज़्यूमे के बुलेट पॉइंट्स नहीं हैं। ये क्षमता का अदृश्य ढांचा हैं। और ये तभी दिखाई देते हैं जब आप अपने रेज़्यूमे को एक प्रोडक्ट कैटलॉग के रूप में देखना बंद कर देते हैं और इसे अपनी आत्मकथा के रूप में देखना शुरू करते हैं।
आवेदन अंतिम निर्णय नहीं है
इस अभ्यास का एक स्पष्ट व्यावहारिक कारण है। एक जॉब एप्लिकेशन लंबित था। एक भूमिका सामने थी, और उस दस्तावेज़ को हायरिंग कमेटी को मनाने की ज़रूरत थी। लेकिन वास्तविक मूल्य का इस बात से लगभग कोई लेना-देना नहीं था कि इनबॉक्स में कोई ऑफर आएगा या रिजेक्शन।
जॉब मार्केट शोर-शराबे से भरा है। समय, आंतरिक राजनीति, गलत कीवर्ड, या बस बहुत अधिक योग्य लोग और बहुत कम सीटें होने के कारण किसी आवेदन को नज़रअंदाज़ किया जा सकता है। यदि आपका आत्म-सम्मान पूरी तरह से उस परिणाम पर टिका है, तो आप कमज़ोर हो जाते हैं। रेज़्यूमे रिव्यू से जो चीज़ बची रही, वह कुछ अधिक मज़बूत थी: यह अहसास कि काम पहले ही सफल हो चुका था। कागज़ थामे हुए व्यक्ति अब वह व्यक्ति नहीं था जिसने यात्रा शुरू की थी। सबसे बड़ी जीत नौकरी मिलने की संभावना नहीं थी। बल्कि वह काम करने में सक्षम व्यक्ति बनने का विश्वास था।
वास्तविक निष्कर्ष
यदि आपने हाल ही में ऐसा नहीं किया है, तो दो घंटे निकालें। अपने पास मौजूद हर सर्टिफिकेट, परफॉरमेंस रिव्यू, प्रोजेक्ट ब्रीफ और स्क्रीनशॉट निकाल लें। उन्हें फैला दें। उन्हें पहले तारीख के अनुसार क्रमबद्ध न करें। उन्हें यादों के अनुसार क्रमबद्ध करें। खुद से पूछें: मैं कहाँ देर तक रुका? मैंने ऐसा क्या बनाया जिसकी किसी को ज़रूरत नहीं थी? मैंने किसकी मदद की? मैंने डरते हुए कब 'हाँ' कहा?
संभवतः आप पाएंगे कि आपका आधिकारिक जॉब डिस्क्रिप्शन आपके वास्तविक मूल्य के शायद आधे हिस्से को ही कवर करता है। बाकी हिस्सा हाशिए (margins) में रहता है। उसे रोशनी में लाएं। अपनी कहानी को अनुमति की भीख के रूप में नहीं, बल्कि परिवर्तन के एक रिकॉर्ड के रूप में फिर से लिखें। अगली बार जब आप अपना रेज़्यूमे अपडेट करेंगे, तो आपको पता चल सकता है कि आप किसी भूमिका के लिए आवेदन नहीं कर रहे हैं। आप अंततः उस भूमिका को समझ रहे हैं जिसे आपने पहले ही बना लिया है।
स्रोत और प्रेरणा: dexxtorrrr on Dev.to
चर्चा और ऐसे ही और विचारों के लिए GyaanSetu learning community से जुड़ें।