- अगर आप किसी सहकर्मी की उपलब्धि और प्रभाव ऐसी स्थिति में उनके मैनेजर तक पहुंचाते हैं जब मैनेजर ने उसे सीधे नहीं देखा, तो यह performance review और promotion चर्चा में महत्वपूर्ण आधार बन सकता है
- अच्छा feedback भी अगर संबंधित व्यक्ति की सहमति के बिना साझा किया जाए, तो वह उनके growth goals और role expectations से टकराकर उल्टा असर कर सकता है
- cross-functional collaboration, 1:1 मदद, problem prevention, documentation·code review, remote work, और support roles जैसे कम दिखाई देने वाले काम को जानबूझकर सामने लाना पड़ता है, तभी उन्हें पहचान मिलना आसान होता है
- “अच्छा काम किया” कहने से बेहतर है कि किसने क्या किया और उसका क्या परिणाम निकला, यह ठोस रूप से लिखा जाए, और यह भी बताया जाए कि कहाँ उसने अपेक्षित स्तर से ऊपर प्रदर्शन किया, ताकि वह promotion के आधार के रूप में उपयोगी हो
- email, public praise, peer bonus, और internal feedback system—सभी तरीके संभव हैं, लेकिन सार्वजनिक रूप और किसके साथ साझा करना है, यह पहले संबंधित व्यक्ति से पूछ लेना अधिक सुरक्षित है
मैनेजर को बताने से पहले पहले पूछ लें
- किसी सहकर्मी के अच्छे काम के बारे में उसके मैनेजर को बताना मददगार हो सकता है, लेकिन संबंधित व्यक्ति की सहमति के बिना ऐसा करने पर अनपेक्षित समस्याएँ पैदा हो सकती हैं
- सकारात्मक बात भी परिस्थिति के अनुसार उल्टा असर कर सकती है
- जो व्यक्ति domain technical expert के रूप में बढ़ना चाहता है, उसके बारे में केवल project management क्षमता पर ज़ोर देना उसके मौजूदा growth goals से मेल नहीं खा सकता
- किसी बहुत senior engineer के बारे में यह कहना कि उसने साधारण और रोज़मर्रा का काम अच्छी तरह किया, ऐसा लग सकता है जैसे आप role expectations को समझे बिना निम्न-स्तरीय प्रशंसा कर रहे हों
- अगर किसी व्यक्ति को किसी खास project पर फोकस करना चाहिए, लेकिन उसकी दूसरी टीम की मदद के लिए प्रशंसा हो रही है, तो मैनेजर इसे मुख्य काम पर ध्यान न देने के रूप में देख सकता है
- कुछ मैनेजर सहकर्मी के उत्कृष्ट प्रदर्शन को अपने लिए खतरे की तरह महसूस कर सकते हैं
- कुछ लोग इस तरह सार्वजनिक रूप से सामने लाए जाना या नाम लेकर उल्लेख किया जाना नहीं चाहते
- बहुत से लोग यह नियंत्रित करना चाहते हैं कि उनके मैनेजर उनके बारे में किस तरह का feedback सुनें
- आप पहले इस तरह पूछ सकते हैं: “X project में तुम्हारा काम मुझे बहुत प्रभावित कर गया, और चूँकि मैनेजर उस project में गहराई से शामिल नहीं था, हो सकता है उसने तुम्हारा contribution न देखा हो, इसलिए मैं यह बात उसे भेजना चाहता हूँ—क्या यह ठीक है?”
यह खास तौर पर कब महत्वपूर्ण होता है
- मैनेजर हमेशा अपने reportees का हर काम नहीं देख पाते, और जो उत्कृष्ट काम दिखाई नहीं देता वह promotion की गति को भी प्रभावित कर सकता है
- यह खासकर ऐसे काम को सामने लाने में प्रभावी है जिसे पहचान मिलना मुश्किल होता है
- जब किसी दूसरे विभाग के व्यक्ति ने कंपनी के लिए बहुत महत्वपूर्ण contribution किया हो, लेकिन उसके मैनेजर को उसके प्रभाव का ठीक से पता न हो
- जब किसी ने private channel या 1:1 में कई घंटों तक मदद की हो और उससे project की सफलता में बड़ा योगदान हुआ हो
- incident response जैसे दिखने वाले काम की तुलना में कम नज़र आने वाला problem prevention work
- नस्लवाद, लैंगिक भेदभाव आदि के कारण कम आंके जाने वाले समूहों का contribution
- documentation, code review, और programming के बाहर के महत्वपूर्ण काम
- जब कंपनी में remote workers का काम कम दिखाई देता हो
- support work जैसी भूमिकाओं का contribution, जिन्हें आम तौर पर कम मान्यता मिलती है
- जब junior सहकर्मी अच्छा कर रहा हो, तो उसके contribution को उभारना भी एक अच्छा तरीका है
promotion का आधार बनाने का तरीका
- promotion के लिए यह साबित करने वाला प्रमाण चाहिए कि किसी ने मूल्यवान काम किया है, और मैनेजर के पास हमेशा इतना समय नहीं होता कि वह यह सारा प्रमाण खुद इकट्ठा करे
- व्यक्ति खुद brag document लिख सकता है, लेकिन सहकर्मी द्वारा उसकी उपलब्धियों के मूल्य को समझाने वाला बयान विश्वसनीयता बढ़ाने में मदद करता है
- अगर आपको पता है कि सहकर्मी promotion review के दायरे में है, तो ऐसा feedback खास तौर पर उपयोगी होता है
- इससे यह संभव होता है कि किसी के शानदार काम को एक साल बाद पहचान मिलने के बजाय, सही समय पर मान्यता मिल सके
अच्छा feedback कैसे लिखें
- “अच्छा काम किया” कहने की बजाय यह स्पष्ट और ठोस रूप से बताना बेहतर है कि किसने क्या किया और उसका क्या प्रभाव पड़ा
- उदाहरण: “X ने इस system design को शानदार ढंग से पूरा किया, और release के बाद 6 महीनों तक इस आकार के project के लिए असामान्य रूप से बड़े operational issues नहीं आए”
- अगर feedback को promotion में मददगार बनाना है, तो उसमें यह दिखना चाहिए कि उस व्यक्ति ने अपने level expectations को कहाँ पार किया
- उदाहरण: वह अभी senior engineer नहीं है, लेकिन वह वैसा काम कर रहा है जिसकी अपेक्षा एक senior engineer से की जाती है
- अगर आपने feedback system के जरिए मैनेजर को संदेश भेजा है, तब भी संभव है कि संबंधित व्यक्ति उसे तुरंत न देख पाए, इसलिए संदेश सीधे उसे भी भेज देना अच्छा है
- संबंधित व्यक्ति उस feedback का बाद में फिर उपयोग भी कर सकता है
सार्वजनिक मान्यता और peer bonus
- Slack channel या team meeting में किसी के अच्छे काम को सार्वजनिक रूप से मान्यता देना भी मददगार हो सकता है
- सार्वजनिक मान्यता सहकर्मी की विश्वसनीयता बनाने में मदद करती है, और अगर उपलब्धि collaborative effort हो, तो जिसे मान्यता मिल रही है वह बातचीत में शामिल हो सकता है या feedback देने वाले को जवाब दे सकता है
- कुछ लोग सार्वजनिक प्रशंसा पसंद नहीं करते, इसलिए इस स्थिति में भी पहले पूछ लेना बेहतर है
- Google जैसी या peer bonus प्रणाली वाली कंपनियों में कुछ लोग अधिक औपचारिक मान्यता के रूप में peer bonus को प्राथमिकता देते हैं
- email की जगह आप अपनी कंपनी के अनुसार उचित feedback system या recognition method का उपयोग कर सकते हैं
ऐसा सहयोग जो कोई भी कर सकता है
- भले ही आप नए हों या आपको लगे कि आप किसी अधिक senior व्यक्ति की कार्य-प्रभावशीलता का मूल्यांकन करने की स्थिति में नहीं हैं, फिर भी आप यह बता सकते हैं कि उसने आपकी सीधे कैसे मदद की
- उदाहरण: “इस व्यक्ति ने मुझे ऐसा project करने में मदद की जो मेरी comfort zone से बाहर था”
- केवल अपने दोस्तों की उपलब्धियों को आगे बढ़ाने तक सीमित न रहें; समय के साथ अधिक व्यापक दायरे के सहकर्मियों पर भी ध्यान दिया जा सकता है
- जो सहकर्मी शानदार काम कर रहे हैं, उन पर नज़र रखना और यह सुनिश्चित करना कि उनके काम को मान्यता मिले, यही महत्वपूर्ण अभ्यास है
व्यापक sponsorship के तरीके
- सहकर्मियों को आगे बढ़ाने के तरीके सिर्फ उनके मैनेजर को उनके अच्छे काम के बारे में बताने तक सीमित नहीं हैं
- Lara Hogan की what does sponsorship look like? sponsorship के कई उदाहरणों पर बात करती है
- Mekka Okereke की “difficulty anchor” Twitter thread कम प्रतिनिधित्व वाले समूहों का समर्थन करने के एक और तरीके पर चर्चा करती है
2 टिप्पणियां
यह 2 साल पहले पोस्ट किया गया लेख है, और मुझे याद है कि इसे GeekNews पर अनुवाद करके भी पोस्ट किया गया था।
अगर किसी सहकर्मी ने अच्छा काम किया है, तो उसके मैनेजर को बताइए
Hacker News की राय
पहले यह पूछ लेना कि क्या यह ठीक है, काफी पैनी सलाह है। हर किसी को सार्वजनिक जगह पर तारीफ पाना पसंद नहीं होता, और हो सकता है कि वे न चाहें कि कोई बहुत micro-manage करने वाला manager यह जाने कि उन्होंने अपने काम के दायरे से बाहर जाकर मदद की थी।
तारीफ कब और किस संदर्भ में करना उचित है, इसका ध्यान रखना चाहिए। फिर भी, अगर आप किसी सहकर्मी के अच्छे काम के लिए धन्यवाद नहीं कहते और उसकी तारीफ नहीं करते, तो team में समस्या पैदा करने वाले आप ही हैं।
अगर आप किसी सहकर्मी के खराब output या “मेरे तरीके वाला नहीं” output को सार्वजनिक रूप से निशाना बना रहे हैं, तो उसे दिशा देने वाली तारीफ में बदलकर देखें, जैसे “मुझे यह बात सचमुच अच्छी लगी कि आपने इसे इस तरह approach किया, क्या आपने यह तरीका भी सोचा है?” मतलब यह कि यह “आपने इसे ऐसे क्यों नहीं किया?” से बेहतर है।
किसी result की जगह behavior की तारीफ करना क्यों बेहतर है, इस पर काफी दिलचस्प material भी है; हालांकि यह बच्चों के संदर्भ में है, एक अच्छा summarized video यह है: https://youtu.be/59gx55bNunU
सामने वाले को बेवकूफ कहना या बेवजह objectivity का दिखावा करना बुरा है, लेकिन जबरन मुस्कुराकर तारीफ करने का नाटक करने की जरूरत नहीं है।
तारीफ हमेशा ठीक होनी चाहिए। खराब output पर feedback को तारीफ जैसा बना देना भी अच्छा विचार नहीं है। मेरे अनुभव में negative feedback ईमानदार, स्पष्ट, constructive और निजी तौर पर देना चाहिए।
वह research है “Praise for intelligence can undermine children's motivation and performance”, Dweck & Mueller: https://pubmed.ncbi.nlm.nih.gov/9686450/
विवाद का overview: https://en.wikipedia.org/wiki/Carol_Dweck#Criticism
उस paper पर पुरानी HN चर्चा: https://news.ycombinator.com/item?id=12233571
मैं तारीफ पाने के लिए काम नहीं करता, और अपनी personal work ethic के कारण high standards बनाए रखता हूं। सहकर्मी मुझे recognize करें या नहीं, इससे मुझे बहुत कम फर्क पड़ता है, और management effort से ज्यादा profit-and-loss देखता है।
यह भी हैरानी की बात नहीं कि video बच्चों से जुड़ा है। यह emotion-centric approach ऐसे professional workplace में फिट नहीं बैठती, जहां adults को पता होना चाहिए कि वे वहां क्यों हैं, employment terms क्या हैं, और वे किस लक्ष्य की ओर काम कर रहे हैं। basic communication का इस तरह बचकाना हो जाना उल्टा अपमानजनक लगता है।
यह भी दिखता है कि “आपने इस तरीके से क्यों नहीं किया?” सुझाए गए alternative से कहीं छोटा है। सामान्य तौर पर भी, audience के हिसाब से adjusted communication accuracy, brevity और clarity के सिद्धांतों पर चलने वाली communication से कहीं ज्यादा लंबी और लिखने में कठिन होती है।
बस कल्पना कीजिए कि ऐसे organizations phrasing को लगातार बदलने में कितना समय बर्बाद करते होंगे। emotional state को manage करना सुनने या पढ़ने वाले की जिम्मेदारी होनी चाहिए, और बोलने वाले का काम ideas को जितना हो सके स्पष्ट और संक्षेप में पहुंचाना होना चाहिए। वही ज्यादा efficient है।
“पहले पूछो” वाले नजरिए से मैं सहमत नहीं हूं। वजह यह है कि context में की गई तारीफ मददगार होती है।
अगर किसी ने शानदार काम किया है, तो यह सिर्फ उसके manager को न बताएं, सबको बताएं। standup में उस व्यक्ति ने कल या पिछले हफ्ते क्या किया, यह बताने के तुरंत बाद सार्वजनिक रूप से और साफ तौर पर कह दें।
“मैं कहना चाहता हूं कि Joe ने उस module पर जो काम किया, वह सचमुच शानदार था। शुक्रिया!” कहना बहुत आसान है, और इसका अच्छा प्रभाव हो सकता है।
अगर आप अच्छे काम की बराबरी से तारीफ करने वाले व्यक्ति बनते हैं, तो दूसरे लोग बेहतर महसूस करते हुए काम करते हैं, बेहतर काम करते हैं, और असली दोस्तियां बनाना भी आसान होता है। जब लोग मेहनत कर रहे होते हैं, तो आम तौर पर उन्हें इसका पता होता है।
तारीफ सार्वजनिक रूप से, सुधार निजी तौर पर करना चाहिए।
मुझे भरोसा है कि मैं समय, जगह और wording देखकर ऐसी तारीफ कर सकता हूं जिसके लिए पहले पूछना जरूरी न हो, और यह भी काफी ठीक से समझ सकता हूं कि कब पहले पूछना चाहिए। मैं लोगों को जानने में भी अच्छा हूं, और खुद को open और well-intentioned दिखाने में भी। बड़े शब्दों में कहें तो मैं trust relationship बनाने में अच्छा हूं।
लेकिन कुछ लोगों के लिए social interaction और situational judgment सचमुच कठिन होता है। जो लोग जटिल स्थितियों का ठीक से आकलन नहीं कर पाते, उनके लिए “बस पूछ लो” वाली सलाह बहुत valuable है। बस यह सब पर लागू नहीं होती।
principle के तौर पर, जिसने आपकी मदद की है उसके बारे में अच्छी बात कह दें। यह इतना complicated नहीं है।
मेरा मतलब यह नहीं कि सार्वजनिक रूप से तारीफ न करें। बस माहौल पढ़ना चाहिए। हमेशा की तरह, खासकर social interactions में, context सबसे अहम है, और आपको सामने वाले को जानना चाहिए।
बिना पूछे लोगों को असहज कर देने का अनुभव मुझे हो चुका है। group में तारीफ मिलने पर लोगों की प्रतिक्रिया अलग-अलग होती है।
“पहले पूछें” वाली सलाह से सहमत नहीं हूँ। वह प्रक्रिया में friction जोड़ती है, इसे कम स्वाभाविक बनाती है, और सच में तारीफ़ करने की motivation घटा सकती है
इसके बजाय ऐसा feedback दें जिससे तारीफ़ पाने वाले कर्मचारी को नुकसान न हो। ऐसा लिखने का एक तरीका होता है: आम तौर पर इसे अपनी स्थिति और मेरी समस्या कैसे आसान हुई, इस पर केंद्रित रखना चाहिए
मेरा मतलब उस उदाहरण से है जिसमें “दूसरी team के व्यक्ति की मदद करके spot peer bonus पाने पर manager ने डाँटा”
यह ऐसा सिद्धांत है जिस पर मैं अंत तक कायम रहूँगा। $this_company के लोग एक team हैं, और एक-दूसरे की मदद करना healthy team और organization बनाने के लिए core है। schedule में slack होना चाहिए, और उस slack का इस्तेमाल एक-दूसरे की मदद में होना चाहिए
बेशक balance ज़रूरी है, लेकिन “मैं unblock करने में एक घंटा मदद नहीं कर सकता, और [schedule देखने के बाद] शायद… अगले quarter में हो पाए” जैसी प्रतिक्रिया organization को अपेक्षा से कहीं ज़्यादा नुकसान पहुँचाती है
ऐसी स्थिति में सार्वजनिक रूप से तारीफ़ करना उस निर्देश को कमजोर कर देता है, और भले ही manager ने इस बार ठीक समझा हो, वह यह advertise नहीं करना चाहेगा कि “X चाहिए तो John के पास जाओ”
एक employee की कहानी भी है जिसे online positive review आने के बाद निकाल दिया गया। कुछ ऐसा: “हमारी server Marie वाकई कमाल की थी! उसने मेरे बेटे के birthday पर free ice cream भी दी!”
पहली तरह की organization में काम करने वाले लोग डर सकते हैं कि बिना किसी benefit के उन्हें बस और काम assign कर दिया जाएगा। कभी-कभी assigned काम उन दूसरे लोगों का होता है जो अपना हिस्सा नहीं कर रहे होते
सही है। ऐसी हरकतें वैसी organization बनाने में मदद करती हैं जहाँ मैं काम करना चाहूँगा
इसे reinforce करना चाहिए। company को material incentive नहीं दे सकते। हाँ, अगर आप company के सबसे बड़े customer भी हों तो अलग बात है। इसके बजाय leadership को reinforcing feedback दिया जा सकता है
XYZ सहकर्मी क्यों मददगार था, इसे quantify कर दें
अगर leadership नहीं सुनती, तो परवाह छोड़ दें। जिस पल manager सच में गलत तरीके से react करे, उसे नोटिस करें, और अगली बार अपने पैरों से vote करें
यह सिर्फ सहकर्मियों पर लागू नहीं होता
अगर customer support agent ने मेरी समस्या वाकई अच्छी तरह solve की हो, तो मैं पूछता हूँ कि क्या मैं manager को बता सकता हूँ कि उस दिन मिली मदद के लिए मैं कितना आभारी हूँ
अब तक सभी लोग काफी खुश लगते थे
मैं manager से कहता हूँ कि उस व्यक्ति ने मेरी समस्या वाकई अच्छी तरह solve की और मुझे customer के रूप में खुश किया। managers भी ऐसी बात सुनकर काफी खुश लगते थे, और कुछ ने तो कहा कि वे यह feedback employee file में जोड़ेंगे
जिस lab में मैं अभी शामिल हूँ, शुरुआत में उसका माहौल अच्छा था, लेकिन कुछ लोग ऐसे भी थे जिनके साथ काम करना कम pleasant था। supervisor ने सही लोगों को चुनने में बड़ी भूमिका निभाई, लेकिन हमने भी एक-दूसरे को बहुत support किया है
नहीं पता किसने पहले शुरू किया, लेकिन सबने एक-दूसरे के बारे में अच्छा बोला, और एक-दूसरे के काम की आलोचना करते समय भी समय के साथ माहौल बेहतर हुआ। यह देखते हुए कि हमने पूरी pandemic के दौरान human-subject data के साथ काम किया, यह काफी मायने रखता है
अब lab में ऐसा कोई व्यक्ति याद नहीं आता जिसके साथ मैं काम नहीं करना चाहूँ
मज़ेदार बात है, मैं team lead हूँ और team का एक co-developer साफ तौर पर मुझे replace करना चाहता है या किसी तरह मेरा lead बनना चाहता है। उसने कई बार मज़ाक भी किया है
कभी-कभी वह मेरे काम की तारीफ़ करता है, लेकिन ऐसा सुनाई देता है मानो मैं अब जाकर उसकी expertise के level के करीब पहुँचा हूँ। समझाना मुश्किल है, और कहा जा सकता है कि मैं ज़्यादा सोच रहा हूँ, लेकिन मुझे पूरा यकीन है कि सच में ऐसा है
मैंने अलग से react नहीं किया। वैसे भी वह काफी skilled है और उसके साथ काम करना fun भी है। बस ऐसी ही चीज़ों में से एक मानता हूँ
यहाँ के comments अच्छी तरह दिखाते हैं कि यह विषय cultural context पर कितना निर्भर करता है
संदर्भ के लिए, लेखक North American background वाला व्यक्ति है
2020 का thread देखकर दिलचस्प लगा कि बातचीत काफी अलग दिशा में गई थी। खासकर stack ranking को लेकर company की process पर ज़्यादा focus था। यहाँ यह कहीं ज़्यादा “personal” है, और “मैं तो बस straightforward तरीके से सुनना चाहता हूँ” या “तारीफ़ अनजाने में किसी को नुकसान पहुँचा सकती है” वाली दिशा में है
objectively यह कहना मुश्किल है कि कौन सा बेहतर या खराब है, लेकिन एक दूसरे की तुलना में थोड़ा ज़्यादा सतही लगता है
North American culture में लगता है हम kindergarten जैसी stage पर पहुँच गए हैं। सर्वोच्च निर्देश भावनाओं की रक्षा करना और “harm” कम करना बन गया है। मुझे शक है कि private sector पर academia के बढ़ते प्रभाव की वजह से भी ऐसा हो सकता है
अगर आप अभी feedback नहीं दे रहे हैं, तो शुरू करने के फायदे बहुत बड़े हैं। बिना पूछे feedback देने से सामने वाले को नुकसान होने का risk बहुत छोटा है
अगर आप यह advice follow करना चाहते हैं लेकिन डरते हैं कि feedback “backfire” कर सकता है, तो इसे इस तरह देखना चाहिए। risk शून्य नहीं है, लेकिन मुख्य बात यह नहीं है कि “feedback backfire होकर लोगों को नुकसान पहुँचा सकता है!”, बल्कि यह है कि feedback देना शुरू करना चाहिए
managers तक ज़्यादा तारीफ़ पहुँचाने का benefit गलत तरीके से पहुँची तारीफ़ के risk से बहुत अधिक है
इसलिए doubt हो तो कर डालना बेहतर है। पूछना भी मदद करता है, और जब मुझे certainty नहीं होती, तो मैं आम तौर पर पहले संबंधित व्यक्ति को feedback draft भेजता हूँ और पूछता हूँ कि वे इसे किस तरह edit करना चाहेंगे। अगर वे किसी और पहलू पर focus करना चाहें तो ठीक है। मुख्य बात gratitude express करना और उस व्यक्ति की मदद करना है
इसमें एक बात और जोड़ूँगा: जब किसी सहकर्मी ने बढ़िया काम किया हो, तो उसे सीधे बताना चाहिए। जब कोई मेरे अच्छे काम को notice करता है तो अच्छा लगता है
हर चीज़ manager को report करने की ज़रूरत नहीं। कभी-कभी बस उस व्यक्ति के काम की तारीफ़ करना या उसकी मेहनत के लिए धन्यवाद देना काफी होता है