बड़ी कंपनियों में यह एक महत्वपूर्ण skill है। जब सभी व्यस्त हों और काम आसानी से भूल सकता हो, तब यह उपयोगी होता है। ईमेल में समस्या समझाकर यह कहना: "अगर [N] दिनों के भीतर जवाब नहीं मिला, तो [DAY N] को मैं XYZ करूँगा।" यह approval का इंतज़ार करने के बजाय सामने वाले को सूचित करने का तरीका है
कभी-कभी कुछ हफ्तों बाद कोई XYZ किए जाने पर नाराज़ होता है, लेकिन यह दिखाने के लिए रिकॉर्ड मौजूद होता है कि गलती उनकी थी
इसे "पूछो मत, बताओ" कहा जाता है, और इसे काम के अंदर और बाहर कई तरीकों से इस्तेमाल किया जा सकता है। यह स्पष्ट और निर्णायक नतीजे लाता है
मैं अपनी पत्नी के साथ भी अक्सर इस तरह की बातचीत करता हूँ। मेरी पत्नी पूछने वाली शैली अपनाती है। डिनर meetup में उसने पूछा, "आप कितने बजे पहुँचेंगे?" लेकिन मैंने बस बता दिया कि हम कब पहुँचेंगे और बार में इंतज़ार करेंगे। नतीजतन सब जल्दी पहुँच गए, और न्यूनतम संचार के साथ सब बढ़िया रहा
यह "माफी माँगो, अनुमति मत माँगो" वाले विचार से जुड़ा है। यह जोखिम भरा हो सकता है, और मैं मूलतः थोड़ा विद्रोही स्वभाव का हूँ। लेकिन GitHub जैसे collaborative environment में बिना सोचे-समझे बड़े बदलाव आज़माना अच्छा नहीं है
जब मैं सहकर्मियों को recommendation approval पाने के तरीकों पर सलाह देता हूँ, तो कुछ ऐसा ही कहता हूँ
"approval लेना आसान बनाओ"
समस्या को संक्षेप में समझाओ और बताओ कि समाधान सही क्यों है। अगर कोई और गहराई से जानना चाहे, तो document link दो। यह भी सुनिश्चित करो कि टीम के सदस्यों या product owner से approval मिल चुका है
"हम X को हल करने के लिए Y करेंगे। टीम के सभी लोग सहमत हैं। विवरण [लिंक] में है। अगर और feedback की ज़रूरत नहीं हुई, तो हम मंगलवार से शुरू करेंगे"
managers के पास हर detail पर समय देने की गुंजाइश नहीं होती, इसलिए अगर टीम का support मिल चुका है, तो वे आसानी से approval दे सकते हैं
एक तरीका "इरादे को प्रसारित करो" भी है। जो करना है और उसकी योजना बताओ, और stakeholders को साफ़ तौर पर विरोध करने का मौका दो। यह कुछ स्थितियों में काम करता है और इसके लिए बुनियादी भरोसा चाहिए
अगर पहली बार में ही कुछ तोड़ दिया, तो वह आपदा हो सकती है। yes या no मिलना कम से कम यह दर्शाता है कि बॉस को पता था
"किसने approval दिया?" इस सवाल पर यह जवाब दिया जा सकता है कि किसी ने approval नहीं दिया
यह तरीका शायद सिर्फ़ अमेरिकी कंपनियों में, या अमेरिकी बिज़नेस शैली के आदी बॉस के साथ ही काम करे। अगर बॉस को यह पसंद न आए, तो उल्टा असर हो सकता है। performance review में बॉस इसे अवज्ञा के रूप में चिह्नित कर सकता है। कभी-कभी अनुमति माँगना ही सबसे अच्छा होता है
"मैं यह काम करूँगा" वाली trick का एक हिस्सा यह है कि इसे सवाल की तरह न लिखा जाए। इससे receiver को reply लिखने की ज़रूरत नहीं पड़ती, और उसे अतिरिक्त ईमेल भी नहीं पढ़नी पड़ती
मुझे GitHub और Google Docs की emoji reaction सुविधाएँ पसंद हैं। वे सरल तरीके से सहमति दिखाने देती हैं। HN पर यह लोकप्रिय नहीं है, लेकिन emoji reactions आसान communication का तरीका हैं
मैं OP की बात समझता हूँ, लेकिन माफी को प्राथमिकता देना context पर निर्भर करता है। social networking website में आप तेज़ी से आगे बढ़ सकते हैं और गलतियाँ कर सकते हैं, लेकिन nuclear launch control system में "अनुमति मिलने तक launch नहीं" वाला system चाहिए
मैं बड़े collaborative projects में यह तकनीक इस्तेमाल करता हूँ। "अगर सहमति नहीं बनती, तो मैं default विकल्प अपनाऊँगा।" जब मैं छोटा था, तो सोचता था कि इसके लिए भयानक default चाहिए, लेकिन वह सिर्फ़ कुछ बार ही काम करता है
मैं इसे "उचित default बनाना" कहता हूँ। हर detail पर निर्णय माँगने के बजाय, स्थिति की समझ दिखाने वाला default चुनो और बताओ कि तुम उसे लागू करोगे। इससे trust बनता है, और जब सच में ज़रूरत हो तभी लोग ध्यान देते हैं
मुझे यह communication style पसंद है, लेकिन "deadline" वाला हिस्सा पसंद नहीं। मैं चाहूँगा कि रिपोर्ट मुझे बताए कि क्या वह ऐसा काम कर रही है जिसका मैं विरोध कर सकता हूँ। manager को deadline देना अजीब और चिढ़ाने वाली धमकी जैसा लगता है। मैं टीम के सदस्यों को autonomy देना चाहता हूँ
1 टिप्पणियां
Hacker News की राय