प्रॉम्प्ट और लागू होने वाला संदर्भ
मुझे उस समय के बारे में बताएं जब आप किसी टीम के साथी, लीड या क्रॉस-फंक्शनल पार्टनर द्वारा लिए गए तकनीकी निर्णय से असहमत थे। प्रतिस्पर्धी विकल्पों, वास्तविक जोखिम, आपने प्रस्ताव को कैसे चुनौती दी, अंतिम निर्णय का अधिकार किसके पास था, और निर्णय लिए जाने के बाद आपने क्या किया, इसे विस्तार से समझाएं।
यह व्यवहार संबंधी (behavioral) प्रश्न सॉफ्टवेयर इंजीनियरों के लिए आम है और डेटा, प्रोडक्ट तथा इंजीनियरिंग प्रबंधन भूमिकाओं पर भी लागू होता है। साक्षात्कारकर्ता केवल यह नहीं पूछ रहा है कि कौन सी तकनीक बेहतर थी। सबसे महत्वपूर्ण संकेत यह है कि क्या आप कार्यात्मक कार्य संबंधों को बनाए रखते हुए दबाव, प्रतिस्पर्धी प्राथमिकताओं या पद के अंतर के बीच किसी राय को एक परीक्षण-योग्य निर्णय में बदल सकते हैं।
एक वास्तविक अनुभव का उपयोग करें। आप कंपनी, प्रोजेक्ट और सहकर्मी का नाम बदल सकते हैं, लेकिन एक साधारण कोड-समीक्षा टिप्पणी को किसी बड़े विवाद के रूप में पेश न करें और न ही यह बदलें कि अंतिम निर्णय किसने लिया था। STAR प्रारूप कहानी का ढांचा प्रदान करता है। Action (कार्रवाई) अनुभाग में लक्ष्य, साक्ष्य, निर्णय मानदंड, निर्णय के अधिकार और निर्णय के बाद आपके कार्यान्वयन को भी स्पष्ट रूप से सामने लाना होगा।
साक्षात्कारकर्ता क्या मूल्यांकन करता है
पहला, क्या असहमति वास्तविक और महत्वपूर्ण थी? एक उपयोगी कहानी में कम से कम दो व्यावहारिक विकल्प होते हैं, जिसमें प्रत्येक पक्ष डिलीवरी समय, विश्वसनीयता, रखरखाव लागत या अनुपालन जोखिम जैसी किसी वैध चिंता की रक्षा कर रहा होता है। यदि दूसरा व्यक्ति स्पष्ट रूप से गलत या नासमझ था, तो आपने एक परिपक्व टकराव को प्रदर्शित करने के बजाय एक आसान विरोधी को चुना है।
दूसरा, आपने निर्णय को कैसे चुनौती दी? एक मजबूत उत्तर "मैंने टीम को मनाने के लिए डेटा का उपयोग किया" से कहीं आगे जाता है। यह साक्ष्य की पहचान करता है, वह तथ्य जो आपके अपने दृष्टिकोण को बदल सकता था, और क्या आप दूसरे पक्ष की सबसे मजबूत चिंता को सटीक रूप से व्यक्त कर सकते थे। यह अंतर सत्य की खोज को केवल जीतने की भावना से अलग करता है।
तीसरा, क्या निर्णय प्रक्रिया की स्पष्ट सीमाएं थीं? बताएं कि किसने सलाह दी, परिणाम की जिम्मेदारी किसकी थी, और निर्णय कब तक लिया जाना था। बहस अनिश्चित काल तक जारी नहीं रह सकती, और पद या अधिकार को महत्वपूर्ण साक्ष्यों को दबाना नहीं चाहिए। यदि अंतिम निर्णय आपके खिलाफ गया, तो विरोध जारी रखने के बजाय एक विश्वसनीय निष्पादक बनना इस प्रश्न का एक प्रमुख संकेत है।
अंत में, साक्षात्कारकर्ता आपकी सीमाओं का परीक्षण करता है। निर्णय के बाद प्रतिबद्ध होना बिना शर्त आज्ञाकारिता नहीं है। यदि नया साक्ष्य पहले से सहमत सुरक्षा, कानूनी, डेटा-सटीकता या पेशेवर-नैतिकता की सीमा को पार करता है, तो जोखिम का दस्तावेजीकरण करें और उचित माध्यम से इसे आगे बढ़ाएं (escalate करें)। एक परिपक्व उत्तर में प्रतिबद्धता और एक स्पष्ट स्टॉप लाइन (सीमा रेखा) दोनों शामिल होते हैं।
उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न
- क्या साक्षात्कारकर्ता तकनीकी असहमति जानना चाहता है या कार्यस्थल का कोई भी विवाद? वास्तविक तकनीकी समझौते (tradeoff) वाली कहानी को प्राथमिकता दें। यदि प्रश्न व्यापक है, तो स्कोप या क्रॉस-टीम प्राथमिकता विवाद भी काम कर सकता है यदि वह एक स्पष्ट निर्णय पर समाप्त होता है।
- आपके पास कौन सा अधिकार था? सिफारिश करने, निर्णय लेने और कार्यान्वयन के अधिकार को अलग-अलग रखें। अंतिम निर्णय का अधिकार न होना कहानी को कमजोर नहीं बनाता; औपचारिक अधिकार के बिना सही निर्णय को प्रभावित करना और भी मजबूत उदाहरण हो सकता है।
- परिणाम के रूप में क्या गिना जाता है? प्रोडक्शन मेट्रिक्स उपयोगी हैं, लेकिन समय पर निर्णय लेना, अंतहीन बहस को समाप्त करना, किसी धारणा को सत्यापित करना, या भविष्य की समीक्षा प्रक्रियाओं में सुधार करना भी परिणाम ही हैं। किसी कमी को पूरा करने के लिए राजस्व या प्रदर्शन के मनगढ़ंत आंकड़े न बनाएं।
- क्या आपके प्रस्ताव की जीत होना आवश्यक है? नहीं। एक अस्वीकृत प्रस्ताव भी उच्च गुणवत्ता वाले मतभेद, दृष्टिकोण बदलने की इच्छा और विश्वसनीय निष्पादन का प्रदर्शन कर सकता है। यह अक्सर "मैं हमेशा सही होता हूँ" वाली बनावटी कहानी से बचने में मदद करता है।
- आपको कब केवल चुपचाप सहमत नहीं होना चाहिए? सुरक्षा कमजोरियों, गैर-कानूनी अनुरोधों, डेटा अखंडता के खतरों या गंभीर नैतिक मुद्दों को तुरंत उच्च स्तर पर ले जाएं। किसी साधारण प्राथमिकता को लाल रेखा बनाने के बजाय साक्ष्य, प्रभाव और एस्केलेशन के रास्ते का वर्णन करें।
30-सेकंड उत्तर ढांचा
"[परियोजना और समय-सीमा] के दौरान, [निर्णय के लिए ज़िम्मेदार व्यक्ति] [विकल्प A] के पक्ष में थे। मुझे चिंता थी कि इससे [विशिष्ट जोखिम] होगा, इसलिए मैंने [विकल्प B] की सिफारिश की। मैंने पहले पुष्टि की कि हमारा साझा लक्ष्य [लक्ष्य] था और [बाधा] के बारे में उनकी चिंता को पुनः स्पष्ट किया। फिर मैंने [डिज़ाइन रिकॉर्ड, प्रयोग या ऐतिहासिक प्रमाण] का उपयोग करके [मानदंड] के आधार पर विकल्पों की तुलना की। अंततः [निर्णय के लिए ज़िम्मेदार व्यक्ति] ने [अंतिम विकल्प] को चुना; मैंने [निष्पादन का चरण] की जिम्मेदारी ली और हम [निर्णय फिर से खोलने की सीमा] पर सहमत हुए। इसका परिणाम [सत्यापन योग्य परिणाम] रहा, और मैंने [विशिष्ट सुधार] सीखा।"
यह शुरुआती हिस्सा असहमति, जवाबदेही और अंतिम परिणाम को स्थापित करता है। पूरे उत्तर को लगभग दो से तीन मिनट का रखें। उस समय का अधिकांश हिस्सा इस बात पर लगाएं कि आपने निर्णय का परीक्षण कैसे किया, प्रतिकूल साक्ष्यों पर क्या प्रतिक्रिया दी, और निर्णय के बाद कैसे कार्य किया।
चरण-दर-चरण विस्तृत उत्तर
कहानी का चयन सावधानी से करें। एक उपयुक्त उदाहरण चार शर्तों को पूरा करता है: असहमति ने एक वास्तविक परिणाम को प्रभावित किया, दोनों पक्षों के पास उचित आधार था, आपने प्रत्यक्ष कार्रवाई की, और प्रक्रिया एक स्पष्ट निर्णय तक पहुंची। केवल शैली की पसंद, कोई ऐसा विरोध जो आपने कभी व्यक्त ही नहीं किया, या किसी प्रबंधक द्वारा बिना किसी फॉलो-थ्रू के चर्चा समाप्त कर देना बहुत कमजोर उदाहरण हैं।
Situation (स्थिति) और Task (कार्य) को संक्षिप्त रखें। उद्देश्य, समय सीमा, आपकी जिम्मेदारी, दूसरे व्यक्ति की जिम्मेदारी और प्रतिस्पर्धी विकल्पों को स्पष्ट करें। टेक स्टैक को गिनाने में एक मिनट बर्बाद न करें। केवल उतना ही तकनीकी विवरण रखें जितना कि उस विशेषज्ञता से बाहर के साक्षात्कारकर्ता के लिए जोखिम को समझने के लिए आवश्यक हो।
Action (कार्रवाई) को इस क्रम में तैयार करें:
- लक्ष्य पर संरेखित हों: बताएं कि टीम संयुक्त रूप से किस बात की रक्षा कर रही थी। साझा लक्ष्य के बिना, प्रत्येक विकल्प एक अलग समस्या को अनुकूलित कर रहा होता है।
- आपत्ति को पुनः स्पष्ट करें: दूसरे व्यक्ति की बाधा के सबसे मजबूत पक्ष को ऐसे शब्दों में वर्णित करें जिसे वे स्वीकार करें। यह साबित करता है कि आपने ध्यान से सुना।
- तथ्यों को धारणाओं से अलग करें: कौन से इनपुट प्रोडक्शन साक्ष्य, ग्राहक प्रतिबद्धताएं या अनिवार्य समय सीमाएं थीं? कौन से केवल अनुमान थे? अपनी पसंद का भी इसी तरह परीक्षण करें।
- मानदंडों पर सहमत हों: निष्कर्ष देखने से पहले डिलीवरी, विश्वसनीयता, दीर्घकालिक लागत, प्रतिवर्तीता (reversibility), और अन्य बाधाओं का महत्व तय करें। बाद में मापदंडों को न बदलें।
- सबसे छोटा उपयोगी परीक्षण चलाएं: एक समयबद्ध (time-boxed) प्रोटोटाइप, डिज़ाइन समीक्षा, पिछली घटनाओं का इतिहास, या सीमित प्रयोग का उपयोग करें। इसे उस प्रश्न का उत्तर देना चाहिए जो निर्णय को बदलने की सबसे अधिक संभावना रखता है।
- निर्णय के अधिकारों को स्पष्ट करें: अंतिम निर्णय कौन लेगा और कब तक? किसी भी सुरक्षा या अनुपालन संबंधी वीटो अधिकार को भी स्पष्ट होना चाहिए।
- निर्णय के बाद कार्यान्वयन करें: निर्णय को दोहराएं, अनसुलझे जोखिमों को दर्ज करें, और एक ठोस कार्य की जिम्मेदारी लें। बहस को केवल तभी फिर से शुरू करें जब नया साक्ष्य किसी सहमत सीमा को पार कर जाए।
समझौते को डिफ़ॉल्ट विकल्प न बनाएं। दो असंगत आर्किटेक्चर को मिलाने से दोनों की लागत संरचनाएं बनी रह सकती हैं। साझा मानदंडों के आधार पर चयन करना या प्रतिबद्धता को सीमित करना बेहतर है ताकि निर्णायक धारणा का परीक्षण किया जा सके। यदि एक हाइब्रिड मॉडल चुना जाता है, तो बताएं कि यह किस स्वतंत्र बाधा को हल करता है, न कि इसे सभी को थोड़ा-बहुत खुश करने के तरीके के रूप में प्रस्तुत करें।
Result (परिणाम) को कम से कम तीन प्रश्नों का उत्तर देना चाहिए: निर्णय से क्या हासिल हुआ, उसके बाद आपने और दूसरे व्यक्ति ने मिलकर कैसे काम किया, और आपका कौन सा दृष्टिकोण बदला। आपको यह साबित करने की आवश्यकता नहीं है कि आप जीते थे। "रोलबैक को लेकर मेरी चिंता वैध थी, लेकिन मैंने दो रास्तों को प्रमाणित करने की लागत को कम आंका था" यह कहना "परिणाम ने साबित कर दिया कि मैं सही था" की तुलना में कहीं बेहतर परिपक्वता को दर्शाता है।
अभ्यास के दौरान, किसी से कहें कि वह आपसे तीन बातों पर सवाल पूछे: "किस साक्ष्य ने आपका विचार बदल दिया होता?", "अंतिम निर्णय का अधिकार किसके पास था?" और "जब आपके प्रस्ताव को नहीं चुना गया तो आपने क्या किया?" जिन उत्तरों का आप बचाव नहीं कर सकते, वे आपकी कमियों को उजागर करते हैं। प्रत्येक संख्या की परिभाषा की पुष्टि करें और उस सटीकता को हटा दें जिसे आप प्रमाणित नहीं कर सकते।
उच्च गुणवत्ता वाला नमूना उत्तर
निम्नलिखित एक काल्पनिक उदाहरण है जो संरचना को प्रदर्शित करता है। परियोजना का हर विवरण और संख्या प्लेसहोल्डर डेटा है जिसे बदला जाना चाहिए; इसे व्यक्तिगत अनुभव के रूप में प्रस्तुत न करें।
"नवीनीकरण ऑडिट से बारह सप्ताह पहले (प्लेसहोल्डर; इसे बदलें), तकनीकी लीड ने हमारी बिलिंग-रूल्स सेवा को पूरी तरह से फिर से लिखने (rewrite करने) का प्रस्ताव रखा। मैं माइग्रेशन योजना का प्रभारी था और नियमों को धीरे-धीरे अलग करने के पक्ष में था क्योंकि टीम लेगेसी सिस्टम के विशेष मामलों (edge cases) को पूरी तरह से नहीं समझती थी। मुझे चिंता थी कि एक ही बार में पूरा बदलाव करने से विफलता का जोखिम क्षेत्र बढ़ जाएगा। लीड को चिंता थी कि दो सक्रिय नियम पथों को बनाए रखने से ऑडिट और रखरखाव की लागत बढ़ जाएगी। अंतिम निर्णय का अधिकार उनके पास था, जबकि मैं माइग्रेशन-जोखिम की लिखित सिफारिश देने के लिए जिम्मेदार था।
मैंने एक वन-ऑन-वन बैठक तय की और हमारे साझा उद्देश्य को 'ऑडिट समय सीमा से पहले नियमों का एक सत्यापन-योग्य स्रोत' के रूप में लिखा। मैंने उनसे यह पुष्टि करने के लिए कहा कि क्या मैंने दोहरे पथ की लागत को सटीक रूप से प्रस्तुत किया है। फिर मैंने डिलीवरी समय, सत्यापन के दायरे, रिकवरेबिलिटी और दीर्घकालिक रखरखाव पर एक पेज का निर्णय रिकॉर्ड लिखा, जिसमें पूर्ण पुनर्लेखन की तुलना वृद्धिशील (incremental) माइग्रेशन से की गई। मैंने शुरुआत में रिकवरेबिलिटी को सबसे अधिक महत्व दिया और चार सप्ताह में पहले माइग्रेशन हिस्से को पूरा करने का प्रस्ताव दिया (प्लेसहोल्डर; इसे बदलें)।
लीड ने बताया कि मैंने ऑडिट के दायरे का सत्यापन नहीं किया था। मैंने समीक्षा में एक अनुपालन पार्टनर को आमंत्रित किया और दो इंजीनियरों के साथ दो दिवसीय न्यूनतम परीक्षण किया (इंजीनियरों की संख्या और अवधि प्लेसहोल्डर हैं; इन्हें बदलें)। अनुपालन टीम ने पुष्टि की कि दो सक्रिय नियम इंजनों के लिए दो सत्यापन मैट्रिक्स की आवश्यकता होगी। प्रोटोटाइप ने यह भी दिखाया कि पूर्ण पुनर्लेखन में लगभग नौ सप्ताह लगेंगे, न कि बारह सप्ताह जिसका हमें पहले डर था (प्लेसहोल्डर; इन्हें बदलें)। उस साक्ष्य ने मेरी सिफारिश को कमजोर कर दिया। लीड ने पूर्ण पुनर्लेखन का विकल्प चुना। मैंने स्पष्ट रूप से निर्णय को स्वीकार किया और शैडो तुलनाओं (shadow comparisons) तथा कटओवर चेकलिस्ट की जिम्मेदारी ली।
कार्यान्वयन के दौरान, मैंने समीक्षा बैठक के बाहर वृद्धिशील माइग्रेशन के लिए दबाव बनाना जारी नहीं रखा। मैंने राउंडिंग अंतरों के बारे में अपनी बची हुई चिंता को एक स्टॉप लाइन में बदल दिया: यदि किसी भी 30 मिनट की अवधि में परिणाम 0.2% से अधिक भिन्न होते, तो हम लीड द्वारा समीक्षा किए जाने तक कटओवर को रोक देते (प्लेसहोल्डर; इन्हें बदलें)। शैडो तुलना में दो राउंडिंग एज केस मिले। सुधारों के बाद, टीम ने ऑडिट की समय सीमा तक सिस्टम को लॉन्च कर दिया और पहले 30 दिनों में कोई भी सेवेरिटी-वन (severity-1) घटना नहीं हुई (संख्या और अवधि प्लेसहोल्डर हैं; इन्हें बदलें)।
इस अनुभव ने दिखाया कि रोलबैक के बारे में मेरी चिंता उपयोगी थी, लेकिन मैंने शुरुआत में अनुपालन-सत्यापन लागत को कम आंका था। तब से, किसी आर्किटेक्चर निर्णय को चुनौती देने से पहले, मैं मानदंडों, बाहरी वीटो और अंतिम निर्णयकर्ता की पुष्टि करता हूँ। इससे मुझे निर्णय से पहले पूरी तरह से असहमति व्यक्त करने और बाद में टीम को एक ही दिशा में आगे बढ़ाने में मदद मिलती है।"
अपने अनुभव को शामिल करते समय, पुनर्लेखन, ऑडिट और संख्याओं को हटा दें। डिज़ाइन दस्तावेज़ों, टिकट्स, मीटिंग नोट्स और मॉनिटरिंग रिकॉर्ड से वास्तविक विकल्पों और साक्ष्यों को निकालें। यदि परिणाम गुणात्मक है, तो केवल एक आकर्षक प्रतिशत जोड़ने के बजाय यह पहचानें कि सुधार को किसने देखा और किस व्यवहार में बदलाव आया।
सामान्य गलतियां
- दूसरे व्यक्ति को तकनीकी रूप से अक्षम दिखाना → कहानी में कोई वास्तविक ट्रेडऑफ नहीं होता और यह सम्मान की कमी को दर्शाता है → उस वैध लक्ष्य को समझाएं जिसकी वे रक्षा कर रहे थे और उसने आपके विश्लेषण को कैसे बदला।
- केवल यह कहना कि "मैंने उन्हें डेटा से मना लिया" → साक्ष्य अप्रासंगिक हो सकते हैं, और आपका दृष्टिकोण अप्रमाणिक लग सकता है → स्रोत, तुलना मानदंड और वह साक्ष्य बताएं जो आपकी राय बदल सकता था।
- बहस को समाप्त करने के लिए पद/रैंक का उपयोग करना → चिंता का परीक्षण किए बिना ही बैठक समाप्त हो जाती है → निर्णय का अधिकार होने पर भी, असहमति, तर्क और समीक्षा के ट्रिगर को दर्ज करें।
- हमेशा ऐसी कहानी सुनाना जिसमें आप जीते हों → यह पहले से गढ़ी गई कहानी लगती है और यह साबित नहीं करती कि आप किसी निर्णय को स्वीकार कर सकते हैं → ऐसा उदाहरण चुनें जिसमें आपने अपना विचार बदला हो या आपकी पहली पसंद न चुनी गई हो।
- निर्णय के बाद भी विरोध जारी रखना → टीम को दो दिशाओं और निष्पादन में घर्षण की कीमत चुकानी पड़ती है → उस साक्ष्य पर सहमति बनाएं जो निर्णय को फिर से खोल सके; तब तक, पूरी तरह से कार्य का निष्पादन करें।
- शांति बनाए रखने के लिए विकल्पों को मिलाना → हाइब्रिड दृष्टिकोण दोनों प्रकार की जटिलता और रखरखाव को बढ़ा सकता है → पहले से तय मानदंडों के आधार पर चुनें; किसी भी हाइब्रिड विकल्प से एक स्वतंत्र बाधा को हल करने की मांग करें।
- प्रतिबद्धता को पूर्ण आज्ञाकारिता समझना → यह सुरक्षा, कानून, डेटा और नैतिक सीमाओं की अनदेखी करता है → स्टॉप लाइन, दस्तावेज़ीकरण और औपचारिक एस्केलेशन पथ का उल्लेख करें।
- पूरी कहानी में "हमने" का उपयोग करना → साक्षात्कारकर्ता आपके व्यक्तिगत प्रभाव की पहचान नहीं कर पाता → आपने क्या प्रस्तावित और परीक्षण किया, निर्णयकर्ता ने क्या अनुमोदित किया, और टीम ने क्या निष्पादित किया, इसे अलग-अलग रखें।
- सटीक परिणामों को मनगढ़ंत बनाना → जब मेट्रिक्स की परिभाषाओं की गहराई से जांच की जाती है तो उत्तर लड़खड़ा जाता है → वास्तविक रिकॉर्ड का उपयोग करें; संख्याओं के बिना, एक ठोस और सत्यापन-योग्य गुणात्मक परिणाम दें।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: यदि बाद में घटनाओं ने आपको सही साबित कर दिया तो आप क्या करेंगे?
पहले प्रभाव पर ध्यान दें और "मैंने तो पहले ही कहा था" जैसी प्रतिक्रिया से बचें। उस नए साक्ष्य की पहचान करें जिसने सहमत सीमा को पार किया, उचित माध्यम से निर्णय को फिर से खोलें, और समस्या को ठीक करने की जिम्मेदारी लें। समीक्षा में, परिणाम को अपनी व्यक्तिगत श्रेष्ठता साबित करने के बजाय मूल साक्ष्यों और प्रक्रिया की जांच करें।
फॉलो-अप 2: क्या होगा यदि अंतिम निर्णय आपकी सिफारिश के विरुद्ध गया हो?
समझाएं कि आपने निर्णय की पुष्टि कैसे की, शेष जोखिम को दर्ज किया, और एक ठोस निष्पादन कार्य को स्वीकार किया। प्रतिबद्धता के लिए सहमत होने का नाटक करने की आवश्यकता नहीं है। इसका मतलब है कि महत्वपूर्ण नए साक्ष्यों के बिना, आप देरी करके या निजी तौर पर विरोध करके कोई दूसरी दिशा नहीं बनाते हैं।
फॉलो-अप 3: आपको निर्णय लेने वाले से उच्च स्तर पर कब एस्केलेट करना चाहिए?
जब जोखिम सुरक्षा, कानून, डेटा अखंडता या गंभीर पेशेवर नैतिकता से संबंधित हो और सामान्य निर्णयकर्ता ने सत्यापन-योग्य साक्ष्यों पर कार्रवाई न की हो, तब संगठनात्मक मार्ग का उपयोग करें। पहले तथ्यों, प्रभाव, तात्कालिकता और पूर्व संचार को लिखित रूप में दर्ज करें। एक सामान्य आर्किटेक्चर प्राथमिकता या व्यक्तिगत निराशा कोई आपातकालीन एस्केलेशन नहीं है।
फॉलो-अप 4: जब कोई डेटा मौजूद न हो तो आप किसी निर्णय को कैसे चुनौती दे सकते हैं?
निर्णय में जबरन निश्चितता का दिखावा न करें। ज्ञात बाधाओं, प्रासंगिक उदाहरणों, प्रतिवर्तीता (reversibility), और सबसे खराब स्थिति के प्रभाव की तुलना करें, फिर सबसे छोटा उपयोगी परीक्षण डिज़ाइन करें। यदि महत्वपूर्ण साक्ष्य अभी भी समय सीमा से पहले नहीं मिल सकते हैं, तो मान्यताओं और विश्वास के स्तर को स्पष्ट करें और परिणाम के लिए जिम्मेदार व्यक्ति को निर्णय लेने दें।
फॉलो-अप 5: आप अपने से अधिक वरिष्ठ व्यक्ति से कैसे असहमत होते हैं?
साझा लक्ष्य और निर्णय मानदंडों के संदर्भ में बात करें। निजी तौर पर जांचें कि क्या आपसे कोई संदर्भ छूट रहा है, फिर उचित मंच पर साक्ष्य प्रस्तुत करें। वरिष्ठता निर्णय के अधिकारों को बदलती है; यह तथ्यों को गायब नहीं करती। अपनी बात को सीधा और सामग्री को परीक्षण-योग्य रखें।
फॉलो-अप 6: क्या होगा यदि असहमति व्यक्तिगत संघर्ष में बदल गई हो?
तकनीकी निर्णय को व्यवहार संबंधी समस्या से अलग करें। दूसरे के इरादों पर लेबल लगाना बंद करें, उनके दृष्टिकोण को पुनः स्पष्ट करें, और गलतफहमी की जांच करें। एक तटस्थ मध्यस्थ चर्चा के नियमों को बहाल करने में मदद कर सकता है। यदि व्यवहार में अपमान, भेदभाव या प्रतिशोध शामिल है, तो तथ्यों का दस्तावेजीकरण करें और किसी तकनीकी समझौते में छिपाने के बजाय औपचारिक एचआर प्रक्रिया का उपयोग करें।