किसी कर्मचारी का प्रदर्शन कमज़ोर होने के दो कारण होते हैं। क्षमता की कमी और प्रेरणा की कमी।
यह पहचानने का तरीका सरल है कि कमी किस चीज़ की है। अगर जान दाँव पर लगी हो तब भी वह न कर सके, तो पहला कारण है।
एक मैनेजर का आउटपुट दरअसल उस टीम के आउटपुट के बराबर होता है जिसे वह मैनेज करता है या जिस पर उसका प्रभाव होता है। टीम को अच्छा आउटपुट, यानी अच्छा प्रदर्शन देना है तो टीम के रूप में synergy महत्वपूर्ण है, लेकिन व्यक्तिगत कर्मचारियों का प्रदर्शन भी उतना ही महत्वपूर्ण है। ऐसा इसलिए है क्योंकि टीम के प्रदर्शन पर इस बात का बड़ा असर पड़ता है कि उच्च क्षमता वाले और भरपूर प्रेरित होकर high performance देने वाले कर्मचारी कितने हैं।
इसलिए मैनेजर का सबसे महत्वपूर्ण काम यह है कि वह कर्मचारियों को अपना सर्वश्रेष्ठ प्रदर्शन देने में मदद करे, यानी उनकी क्षमता और प्रेरणा दोनों को ऊँचा करे। इसके लिए मैनेजर मोटे तौर पर तीन तरह के कदम उठा सकता है।
- शिक्षा और प्रशिक्षण के माध्यम से कर्मचारियों की क्षमता बढ़ाना।
- कर्मचारियों की ज़रूरतों को self-actualization के स्तर तक ले जाना ताकि वे स्वयं प्रेरित हों।
- ऐसा माहौल बनाना जिसमें प्रेरित कर्मचारी अच्छी तरह काम कर सकें।
Andy Grove का मानना था कि प्रेरणा भीतर से आती है, इसलिए किसी दूसरे व्यक्ति के लिए किसी को प्रेरित करना संभव नहीं है। इसलिए उनका विश्वास था कि मैनेजर के लिए सबसे अच्छा तरीका यह है कि वह कर्मचारियों की ज़रूरतों को इस तरह उभारे कि वे स्वयं प्रेरित हों, और फिर उस प्रेरणा को बनाए रखने में मदद करे।
मैनेजर कर्मचारियों की ज़रूरतों को प्रभावी ढंग से self-actualization के स्तर तक कैसे ले जाए और वहाँ बनाए रखे? किताब में यह बात बिल्कुल स्पष्ट रूप से नहीं दी गई, लेकिन किताब की सामग्री और अपने विचारों को मिलाकर मैंने पाँच बिंदु बनाए हैं।
1. शिक्षा और प्रशिक्षण
self-actualization की ज़रूरत को क्षमता बढ़ाने की इच्छा और उपलब्धि बढ़ाने की इच्छा में बाँटा जा सकता है। यानी शिक्षा और प्रशिक्षण क्षमता-वृद्धि का साधन तो हैं ही, साथ ही self-actualization की ज़रूरत को ऊँचा करने का साधन भी हो सकते हैं।
2. ऐसा माहौल जो ठोस परिणामों को महत्व दे और उन्हें मान्यता दे
शिक्षा के ज़रिये ज्ञान बढ़ जाए, तब भी केवल उससे प्रदर्शन पैदा नहीं होता। बढ़ी हुई क्षमता को प्रदर्शन में बदलने के लिए केवल ज्ञान-पिपासा शांत करना या कुछ आज़माकर देखना काफी नहीं है; ऐसा माहौल बनाना होगा जो वास्तविक परिणाम पैदा करने पर ज़ोर दे।
3. चुनौतीपूर्ण लक्ष्य प्रस्तुत करना
लक्ष्य का स्तर ऐसा रखें कि मौजूदा क्षमता के साथ पूरी कोशिश करने पर उसे हासिल करने की संभावना लगभग 70% हो, ताकि उपलब्धि की इच्छा भी उभरे और efficacy की भावना भी कमज़ोर न पड़े।
4. स्वयं को मापने के लिए मेट्रिक्स तय करना
जो लोग self-actualization की अवस्था तक पहुँचते हैं, उन्हें अपनी उपलब्धियों को मापने के तरीके की ज़रूरत होती है, और इसका सबसे अच्छा तरीका है उनके प्रदर्शन पर feedback। अगर मैनेजर टीम के महत्वपूर्ण काम से जुड़े performance metrics तय करे और उनके आधार पर उचित feedback दे, तो कर्मचारी इन्हें अपनी उपलब्धि मापने के guideline के रूप में इस्तेमाल कर सकते हैं।
5. प्रयोग और असफलता को प्रोत्साहित करने वाला माहौल
self-actualization की ज़रूरत के लिए सबसे बड़ा खतरा है असफलता का डर, या असफलता के कारण क्षमता में गिरावट और उपलब्धि में कमी का डर। यदि मैनेजर यह स्पष्ट कर दे कि लंबे समय में बेहतर परिणाम देने के लिए प्रयोग और असफलता अनिवार्य हैं, तो इस डर के कारण कर्मचारियों के अत्यधिक रूढ़िवादी ढंग से काम करने की संभावना कम हो जाएगी।
8 टिप्पणियां
पहले पैराग्राफ़ में जान की बात आने से
लगता है जैसे इंसान को एक औज़ार की तरह देखा जा रहा हो
उदास लग रहा है :(
आह, तो आपको ऐसा महसूस हुआ। दरअसल मुझे लगता है कि यह किताब काफ़ी गर्मजोशी भरी और मानवीय है। शायद पहले पैराग्राफ़ में मैंने ज़रूरत से ज़्यादा सारांश कर दिया था।
मुझे नहीं लगता कि यह लेख बिल्कुल भी “जान पर बन आए तो क्या ऐसा कुछ है जो नहीं कर सकते? बस कर डालो” जैसी बात कहता है। उदाहरण के लिए, लेखक ने कहा था, “अगर मुझसे अचानक violin बजाने को कहा जाए, तो जान दाँव पर लगी हो तब भी मैं नहीं बजा सकता।”
इसलिए मैंने इसे इस अर्थ में लिया कि मैनेजर को यह अच्छी तरह समझना चाहिए कि क्या वह व्यक्ति की क्षमता के अनुरूप काम दे रहा है या नहीं।
लगभग 70% सफलता-संभावना वाली चीज़ को हम कैसे जान सकते हैं? लक्ष्य तय करने के लिए उसे मापना होगा, लेकिन क्या software development में यह संभव है?
मुझे लगता है कि कुछ धारणाएँ पहले से मौजूद होनी चाहिए।
स्वाभाविक है कि नए कर्मचारी, या जिनके लिए यह प्रक्रिया पहली बार हो, उनके लिए सही तरीके से लक्ष्य तय करना मुश्किल होता है।
मैनेजर के लिए भी, अगर वह किसी कर्मचारी को पहली बार देख रहा हो, तो वह कुछ हद तक केवल अंदाज़े से ही काम करता है, इसलिए यह आसानी से नहीं हो पाता।
Sprint लागू करके Sprint यूनिट के हिसाब से goal achievement rate देखना और retrospective करना, या मासिक/त्रैमासिक लक्ष्य बनाकर achievement metrics को लगातार observe करना,
और परिणाम के आधार पर यह तय करना कि अगले लक्ष्य को थोड़ा ऊपर करना है या नीचे, ऐसे दोहराए जाने वाले process के जरिए औसत स्तर खोजा जाता है।
(अगर किसी कंपनी के पास इस तरह का बहुत अधिक data हो, तो यह process काफ़ी कम हो जाएगा।)
बेशक, नीचे की ओर समायोजन की भी एक उचित सीमा होनी चाहिए। जिसे देखकर कोई भी कह दे कि वह न्यूनतम स्तर भी पूरा नहीं कर पा रहा, तो वहाँ समस्या है, इसलिए डाँटना हो या कुछ और करना हो, करना पड़ेगा।
मुझे लगता है कि ऐसे लक्ष्य तय करने के लिए भी काफ़ी training और education की ज़रूरत होती है, लेकिन हक़ीक़त यह है कि ज़्यादातर कंपनियाँ ऐसी चीज़ों पर पैसा खर्च करना नहीं चाहतीं, हाय।
मैंने जिन कंपनियों में काम किया है, उनमें से सिर्फ़ लगभग एक कंपनी ऐसी थी जिसने इस तरह का मैनेजमेंट अच्छी तरह किया; बाकी जगहों पर सिर्फ़ बातों में OKR या किसी मैनेजमेंट मेथड की चर्चा होती थी, लेकिन असल में लोग खुद ही लक्ष्य तय करते थे, खुद ही metrics बनाते थे, और खुद ही evaluation भी कर लेते थे...
यह बात कहते हुए मुझे खुद भी शर्म आती है, लेकिन मेरे काम के अनुभव में ऐसे technical managers बहुत कम मिले हैं जो वास्तविक काम को समझते हों, उसे छोटे हिस्सों में बाँट सकें और उसके अनुसार फैसले लेना जानते हों। आम तौर पर लोग अपने career और वर्षों के अनुभव की वजह से managing role में आ जाते हैं, और कई बार ऐसा भी होता है कि बिल्कुल बिना किसी technical background वाला व्यक्ति पूरे developers को manage कर रहा होता है। Backend developer पृष्ठभूमि वाला manager एक project में frontend developers तक को manage करने लगता है, और ठीक-ठाक विस्तार वाले design या निर्देशों के बिना बस व्यावहारिक काम करने वालों को—अक्सर junior developers को—मशीनी ढंग से issue बनाकर फेंक देता है और सिर्फ feature का नाम बता देता है..
अब तो बस यही सवाल रह गया है कि क्या हमारे देश की developer संगठन संस्कृति कभी बदलेगी भी।
बिल्कुल, इसे मात्रात्मक रूप से मापना शायद मुश्किल होगा.
हर मैनेजर का तरीका अलग हो सकता है, लेकिन अगर मैं होता तो प्रतिभागियों के आत्मविश्वास के आधार पर गुणात्मक मापन करता।
उदाहरण के लिए, प्रतिभागी से अपने काम के बारे में खुद अपना आत्मविश्वास आकलित करने को कहें:
फिर जो काम उन्होंने 2 नंबर के रूप में self-assess किया हो, वह दें.
अगर 1 नंबर हो, तो उसे और कठिन बना दें (जैसे time limit जोड़ना, constraints जोड़ना आदि)
अगर 3 नंबर हो, तो उसे और आसान बना दें (जैसे coach जोड़ना, tools देना, specs कम करना आदि)
मैं शायद इस तरह से करता।
शानदार लेख के साथ शानदार टिप्पणी भी.. धन्यवाद।
आपको डबल थम्ब्स-अप देता हूँ. :)