छोटे और अस्पष्ट अनुरोध टीम का बहुत समय बर्बाद करते हैं
(staysaasy.com)- मैनेजर और लीडर के अस्पष्ट अनुरोध छोटे सवाल जैसे लग सकते हैं, लेकिन वे टीम के समय, प्राथमिकताओं और execution की दिशा को बड़े स्तर पर हिला सकते हैं
- “इसे चेक कर दो”, “इसे modern होना चाहिए” जैसी अभिव्यक्तियाँ रिपोर्ट, स्लाइड, वीकेंड का काम, या बड़े upgrade जैसी अत्यधिक प्रतिक्रिया में बदल सकती हैं
- अनुरोध करने वाले को अपेक्षित समय निवेश, प्राथमिकता पर असर, क्या सिर्फ मौजूदा सामग्री देखनी है या नया काम करना है, और परिणाम का उपयोग कहाँ होगा — यह सब साथ में बताना चाहिए
- अनुरोध पाने वाले व्यक्ति को भी अपेक्षित effort level दोबारा पूछना चाहिए और जो बातें स्पष्ट नहीं हैं उन्हें पुष्टि करनी चाहिए, और यह मानकर नहीं चलना चाहिए कि लीडर व्यस्त होने की वजह से जवाब नहीं दे पाएगा
- शुरुआत में थोड़ी असहज लगने लायक हद तक भी अगर ठोस और स्पष्ट रूप से बात की जाए, तो बाद में होने वाली उलझन, गलत काम और लागत की बर्बादी को काफी कम किया जा सकता है
छोटे अनुरोध बड़े काम में कैसे बदल जाते हैं
- किसी संगठन में छोटे और हल्के दिखने वाले अनुरोध बार-बार उम्मीद से कहीं बड़े काम में बदल जाते हैं
- जब कोई मैनेजर पूछता है, “क्या तुम X कर सकते हो?”, तो उसका direct report अपेक्षा से 10 गुना ज्यादा समय लगा सकता है, और मैनेजर कह सकता है, “मैंने इतना समय लगाने के लिए नहीं कहा था”
- किसी मीटिंग में किसी executive का छोटा-सा “क्या तुम इसे चेक कर सकते हो?” 24 लोगों द्वारा 4 versions की slide deck बनाने और वीकेंड तक काम करने की स्थिति पैदा कर सकता है
- जबकि उसी मीटिंग में executive सिर्फ पहली slide के पहले वाक्य का summary देखकर कह सकता है, “पूरा presentation ज़रूरी नहीं है”
- “बिना बहाने modern होना चाहिए” जैसी बात भी, अगर उसका मतलब साफ न किया जाए, तो बड़े पैमाने के तकनीकी upgrade के रूप में समझी जा सकती है
- जबकि असली इरादा कई वर्षों में नई version पर API syntax अपडेट करने जितना सीमित हो सकता है
- इस बीच महत्वपूर्ण project launches टल सकते हैं
अनुरोध करने वाले को पहले क्या तय करना चाहिए
- लीडर को अनुरोध करते समय अपेक्षित समय सीमा सीधे बतानी चाहिए
- उदाहरण: “20 मिनट से ज़्यादा मत लगाना, और 20 मिनट बाद जो भी हो वह लेकर आना”
- इसका प्राथमिकताओं पर क्या असर होना चाहिए, यह भी साथ में स्पष्ट करना चाहिए
- उदाहरण: “मुझे उम्मीद है कि इसमें लगभग 2 हफ्ते लगेंगे, और इससे दूसरे बड़े कामों की प्राथमिकता बहुत नीचे नहीं जानी चाहिए”
- अगर वास्तविक timeline अलग हो या दूसरे कामों से टकराव हो, तो तुरंत बताने को कहना चाहिए
- यह भी अलग से बताना चाहिए कि सिर्फ मौजूदा सामग्री देखनी है या नया analysis / creation करना है
- उदाहरण: “बस इतना बताओ कि इस विषय पर हमारे पास पहले से कुछ है या नहीं. अगर हमने इस पर अभी तक सोचा ही नहीं है, तो वह जानना भी पर्याप्त है”
- अगर परिणाम का उपयोग कहाँ होगा यह बता दिया जाए, तो सामने वाला effort level बेहतर तरीके से सेट कर सकता है
- उदाहरण: किसी sales prospect को भेजा जाने वाला जवाब, अगली All Hands की Q&A तैयारी, या अगली board meeting के मुख्य विषय
अनुरोध पाने वाले को क्या स्पष्ट करना चाहिए
- अनुरोध पाने वाले व्यक्ति को स्पष्टीकरण वाले प्रश्न पूछने चाहिए
- “क्या आप कई घंटों की बहुत thorough output चाहते हैं, या सिर्फ एक छोटा summary?” जैसे सवालों से effort level स्पष्ट करना चाहिए
- सवाल पूछने से कोई मूर्ख नहीं दिखता; बिना पूछे पूरी तरह गलत काम कर देना उससे कहीं अधिक जोखिम भरा है
- लीडर के email या messenger संदेशों को किसी प्राचीन शिलालेख की तरह पढ़ते रहने में समय लगाने से बेहतर है कि उसी लीडर से सीधे पुष्टि कर ली जाए
- अगर लीडर के पास अनुरोध करने का समय है, तो उसके पास उसे स्पष्ट करने का समय भी है
1 टिप्पणियां
Hacker News टिप्पणियाँ
मुझे सबसे ज्यादा बुरा तब लगता है जब कोई non-technical leader एक-दो steps skip करके, स्पष्टता वाले सवाल पूछने या timeline/deliverables define करने का अनुभव रखने वाले senior technical लोगों के बजाय सीधे junior technical staff से बात करता है
यह pattern मैंने कई campaign organizations और political tech organizations में अक्सर देखा है
junior technical staff भी chain of command समझते हैं, इसलिए ऊपर वाला चाहे जानबूझकर करे या नहीं, उसे तोड़ने पर confusion और chaos पैदा होता है
असली physical काम करने वाला व्यक्ति अक्सर junior engineer होता है, और वह कुछ खास सवालों के जवाब high-level से देखने वाले व्यक्ति से बेहतर दे सकता है
मुझे लगता है कि बेवजह telephone game खेलने की जरूरत नहीं है
बिना अनुभव वाले vendor का project coordinator, ऐसे vendor technicians जो coordinator से काम निकलवाने के आदी हैं, और इस field में नए customer—ये मिल जाएँ तो काफी बड़ा confusion हो सकता है
“सवाल न पूछकर पूरी तरह गलत काम कर देना जाहिर तौर पर बेवकूफी जैसा दिखता है”, और “कभी यह assume न करें कि सामने वाला काम के दौरान clarifying questions का जवाब देने के लिए बहुत busy होगा” — इन बातों पर, मैं सोचता हूँ कि remote काम करते समय और online chat भी उपलब्ध न हो तो क्या करना चाहिए
आमने-सामने हो तो छोटे, तेज और roughly organized सवाल बहुत सारे पूछना आसान होता है, लेकिन email ज्यादा formal और interrupt करने जैसा लगता है, इसलिए क्या confused कर रहा है यह समझाने और expected answers को पहले से cover करने में ज्यादा समय लगता है
video call schedule करने में समय लगता है और overhead भी बड़ा होता है
client projects में हम Google Doc में हर छोटे सवाल के पैदा होते ही उसे जोड़ देते हैं, और कभी-कभी client से document check करने को कहते हैं या client को edit notifications subscribe करने देते हैं
client जवाब सीधे document में लिखता है, और काम आगे बढ़ते हुए यह process repeat होता रहता है
फायदे यह हैं कि client को एक ही बार में सबका जवाब नहीं देना पड़ता, notifications कम होती हैं, दोनों तरफ कम formal लिखना भी ठीक रहता है, collaboration जैसा feel आता है, relevant हिस्से के पास follow-up questions जोड़ना आसान होता है, document comments में छोटी discussion या छोटे task assignment/tracking भी हो सकते हैं, और दूसरों के लिए पढ़ना व contribute करना भी आसान होता है
यहाँ मैं ऐसे scenarios की बात सोच रहा हूँ जहाँ बहुत सारे छोटे सवाल उठते हैं, जैसे किसी ऐसे non-technical client के साथ contract work जिसे आप ज्यादा नहीं जानते
दूसरे लोग email पर ऐसी constraints नहीं लगाते
अगर CEO को नहीं भेज रहे हैं, तो जो सवाल दिमाग में आए, लिखकर तुरंत भेज सकते हैं
“ओह, यह सवाल भी भूल गया था। धन्यवाद! $QUESTION” जैसे तुरंत दूसरा email भेजने से भी डरने की जरूरत नहीं
https://twitter.com/TechEmails पर senior executives के emails देखें तो ज्यादातर बहुत informal होते हैं
Bill Gates और Microsoft executives के बीच हुए कुछ पुराने emails high-school students के texts से बहुत ज्यादा polished भी नहीं हैं
इसका मतलब यह नहीं कि आप अपने boss के boss के boss के boss को emoji भेजें, लेकिन quick informal email आपके career का अंत नहीं करेगा
मैं समझता हूँ कि कई लोगों को यह ज्यादा बड़ा लगता है, लेकिन पता नहीं कि यह दोनों पक्षों के लिए सच में ज्यादा annoying है या नहीं
अगर सवाल clear करने के लिए back-and-forth conversation चाहिए, तो वही करें
shared document approach भी अच्छा idea है, और उसके दो extra फायदे हैं
लिखने की क्रिया सवाल को और clear करने का एक additional step बनती है, और सवाल-जवाब future के लिए documented हो जाते हैं
बाद में फिर से लिखनी पड़ने वाली quick conversation की तुलना में ये दोनों बड़े फायदे हैं
cognitive load सामने वाले पर डाल दें
क्योंकि दिन में कई बार interrupt करने की तुलना में एक बार interrupt करना बेहतर है
कोई नया issue मिलने पर पहले उसे scan करता हूँ, plan बनाता हूँ कि क्या करना है, potential problems या conflicts पर mentally dig करता हूँ और कभी-कभी बहुत बड़ी questions list बना लेता हूँ, फिर यह divide करता हूँ कि कौन किस सवाल का जवाब देने की संभावना रखता है, और उसके बाद online conversation शुरू करता हूँ
कंपनी के अंदर आमतौर पर Slack जैसे internal messenger पर छोटी 5-minute video call request कर सकते हैं
अगर closely काम करने वाला colleague है तो कभी-कभी बिना notice सीधे call भी कर लेते हैं
external client के साथ भी अगर पहले से agree किया गया हो तो actual phone number या video call से कुछ ऐसा ही कर सकते हैं
उदाहरण के लिए kickoff meeting में तय कर लें कि client किस frequency से contact चाहता है, और कौन से सवालों पर immediate communication चाहिए व कौन से सवालों के लिए slow asynchronous communication काफी है
समय मेहनत·असल काम·दायरे का प्रतिनिधित्व करने वाले संकेतक के रूप में बहुत खराब है
उदाहरण के लिए, “बस 20 मिनट देखो, और 20 मिनट बाद जो मिला हो वह लेकर आओ” जैसी request देखें, तो हर व्यक्ति 20 मिनट में जितना हासिल करता है वह थोड़ा-थोड़ा अलग होता है
भले ही उस अंतर को नजरअंदाज कर दें, इस बात की कोई गारंटी नहीं कि request करने वाले manager को उन 20 मिनट की मेहनत से वह मिल ही जाएगा जिसकी उसे जरूरत है
Agile environment में discovery·investigation के काम को “spike” कहना और उसे “timebox” देना अक्सर दिखता है, लेकिन “अगर उस समय के भीतर मनचाही चीज़ न मिली तो क्या होगा?” पूछने पर आम तौर पर अच्छा जवाब नहीं होता
असल में timebox तब तक बढ़ता रहता है जब तक जरूरी चीज़ पता न चल जाए
इसलिए समय, मेहनत या असल काम या scope का खराब proxy metric है
लेख के बाद वाले उदाहरण “क्या आप कई घंटे लगाकर बहुत thorough चीज़ की उम्मीद कर रहे हैं, या quick summary काफी है?” को मैं बेहतर मानता हूं
क्योंकि यह लगने वाले समय की नहीं, बल्कि काम के दायरे की बात करता है
समय से मापने पर इस बात की गारंटी नहीं कि उस समय में मनचाही चीज़ मिल जाएगी, और अंततः और समय जोड़ना पड़ता है
“अगर उस समय के भीतर मनचाही चीज़ न मिली तो?” का जवाब यह है कि हमें पता चलता है कि अपेक्षित समय में जवाब नहीं मिला, और इस investigation work के लिए जरूरी effort को लेकर expectations adjust की जाती हैं
Manager के तौर पर यही जानकारी उन core सूचनाओं में से एक है जिसे वह जानना चाहता है
इसलिए project को पटरी से उतरकर कूड़ेदान में जाने से रोकना हो तो किसी भी चीज़ के लिए timebox जरूरी है
यह personal work या solo work पर भी लागू होता है
किसी भी चीज़ को हमेशा पकड़े रखा जा सकता है, इसलिए जबरन एक stopping point बनाना और feedback लेना या release करने के बाद यह तय करना कहीं बेहतर है कि आगे जारी रखना worth है या नहीं
यहां काम करने वाला mechanism लोगों पर prioritization थोपना है
अगर आप priority judgment बहुत अच्छा करते हैं तो timebox की जरूरत कम हो सकती है, लेकिन उस स्थिति में भी timebox न हो तो जरूरी level से ज्यादा quality तक काम जारी रखने के temptation को रोकना मुश्किल हो सकता है
ऐसा work pattern तब उपयोगी है जब जो चीज़ें पता हैं उनसे कहीं ज्यादा चीज़ें अज्ञात हों
लक्ष्य जंगली अंदाजा लगाना नहीं, बल्कि “पता चीज़ों” का हिस्सा थोड़ा-थोड़ा बढ़ाना है ताकि अनुमान information पर आधारित हो
उदाहरण के लिए किसी legacy codebase में bug है, लेकिन replacement system लगभग तैयार है और दो महीने बाद launch होना है, तो उस bug को कैसे handle करेंगे
उसे ignore कर सकते हैं, या किसी से कह सकते हैं “किसी भी तरह fix करो”, लेकिन दोनों अच्छे विकल्प नहीं हैं
इसलिए कहते हैं “इस bug की जांच करो, लेकिन एक घंटे से ज्यादा मत लगाना, और बताना कि कहां तक पहुंचे”
खत्म होने के बाद problem की shape बेहतर समझ में आती है
अगर कोई लौटकर कहे “problem area मिल गया है, लेकिन इसे fix करने के लिए business logic अच्छी तरह जानने वाले व्यक्ति के साथ मिलकर solve करना होगा”, तो appropriate resources लगाकर fix की ओर बढ़ सकते हैं
अगर कहे “code का यह हिस्सा है और काफी साफ-सुथरा है, लेकिन अभी पूरी तरह trace नहीं कर पाया”, तो इस भरोसे के साथ कि यह कोई बहुत बड़ा काम नहीं होगा, और समय दिया जा सकता है
उलट, अगर कहे “यह इस अजीब spaghetti में कहीं है, और झांककर देखा तो abyss ने मुझे घूरकर वापस देखा, रोंगटे खड़े हो गए और दीवारों की तस्वीरों से खून के आंसू बहने लगे, इसलिए कृपया मुझे दोबारा मत भेजना”, तो साफ हो जाता है कि आगे trace करने लायक नहीं है और इसे छोड़ सकते हैं
मैं मानता हूं कि आपको ऐसा अनुभव हुआ कि जो चाहिए था वह समय के भीतर नहीं मिला तो और समय जोड़ दिया गया, लेकिन यह universal नहीं है
समस्या “जो चाहिए” उसे ही final goal मान लेने में है
इसलिए लेख भी कहता है “बताइए कि इसकी जरूरत क्यों है”
“सबसे बड़े customer को contract renewal से पहले जानना है” पर “बस curiosity थी” की तुलना में ज्यादा पैसा और ज्यादा staff time खर्च करना worth है
Leadership level पर यह समझना पड़ता है कि हर लाभ के पीछे नहीं भाग सकते, और cost-effectiveness सबसे अच्छी हो, ऐसी चीज़ों पर strategically focus करना चाहिए
इसका मतलब केवल किसी काम पर किसी व्यक्ति को लगाना नहीं, बल्कि सही skills वाले व्यक्ति को सही काम assign करना भी है
Startup CEO ने कुछ request किया था, और request शायद एक-दो वाक्यों जितनी छोटी थी
नतीजे में 14-page report बन गई, कई घंटे लगे और अधिकतर काम personal time में किया
CEO को report भेजी, लेकिन उसके बाद कोई जवाब नहीं आया और कुछ भी नहीं हुआ
इसके बाद मैंने अपने लिए एक नया rule बनाया
request की cost, उस request को communicate करने की cost के proportional होनी चाहिए
अब अगर high-cost request आती है तो मैं wait करता हूं, delay करता हूं, और escalation मांगता हूं
request करने वाले को due diligence करनी होगी और higher-ups की approval लेकर दिखाना होगा कि यह cost चुकाने लायक है
अगर request nonsense है तो फिर कभी सुनाई नहीं देगी, और अगर valuable request है तो उसे handle किया जाएगा; साथ ही एक extra फायदा यह है कि वह effort appropriate visibility के बिना चुपके से नहीं होगा
पहला, पहली request पर कभी कुछ नहीं करता
अगर important होगा तो वे फिर request करेंगे, और तब सोचूंगा
दूसरा, अगर मुझे overtime करना पड़े तो सामने वाले को भी overtime करना होगा
अगर वह overtime नहीं करना चाहता, तो बात उतनी important नहीं थी
इंजीनियरिंग में जूनियर से लेकर C-level तक कई स्तरों पर रहकर मैंने कुछ बातें सीखी हैं
पहली, सभी को अच्छी नीयत से काम करना चाहिए
मैंने ऐसे leader देखे हैं जो 5 सेकंड भी सोचे बिना तुरंत अपने direct report से कुछ मांग लेते हैं, और इसके उलट ऐसे direct report भी देखे हैं जो “human command line” की तरह तभी चलते हैं जब उन्हें बिल्कुल सही syntax दिया जाए
दोनों ही ठीक नहीं हैं
दूसरी, manager या leader के लिए “one-off request” जैसी कोई चीज़ नहीं होती
कोई भी request बाकी सभी कामों पर implicit priority ले लेती है
आपको पूरे system और context के भीतर काम करना होता है; नहीं तो आप वह चुनाव team पर थोप रहे होते हैं
तीसरी, अगर आप request पाने वाली तरफ हैं, तो requester को यह समझने में मदद करनी चाहिए कि उसे असल में क्या चाहिए
implicit assumptions हटानी होंगी, क्योंकि असली खतरा वहीं छिपा होता है
communicate करें, inform करें, सिखाएं, requester क्या चाहता है इसे पक्का करें और यह सुनिश्चित करें कि दोनों पक्ष सहमत हैं
ऐसी चीज़ें अक्सर efficiency की वजह से होती हैं—अगर ज़रूरत न हो तो समय बर्बाद न किया जाए—लेकिन requester और receiver अगर एक-दूसरे की मदद करने की कोशिश करें, तो आम तौर पर जीवन कहीं ज़्यादा सहने लायक हो जाता है
जो leader limits को धकेलकर देखता है कि कितना चल सकता है, और जो leader team के साथ अच्छी नीयत वाला रिश्ता बनाना चाहता है—इन दोनों में जमीन-आसमान का फर्क है
जो manager लगातार बिना सोचे-समझे demands करते हैं, वे अपने सबसे अच्छे employees को लगातार खोते रहते हैं
अनुभव से कहूं तो पर्याप्त समय बीतने पर ऐसे leader के नीचे सिर्फ junior लोग रह जाते हैं, क्योंकि अनुभवी लोग उस team से बचते हैं
“human command line” team member भी bad faith में काम करने का अच्छा उदाहरण है
मैंने ऐसे लोगों के साथ काम किया है जो बहुत छोटी request शुरू करने से पहले भी अपने बनाए form या document भरने की मांग करते थे, और फिर कई दिनों तक debate, critique या circulation के बाद ही छोटे काम पर सोचते थे
उन्हें लगता है कि उन्होंने छोटे requests से खुद को बचा लिया, क्योंकि अब कोई भी सवाल को बिल्कुल सही ढंग से पूछने की मेहनत नहीं करना चाहता; लेकिन समय के साथ उनकी reputation ऐसे इंसान की बनती है जिसके साथ काम करना मुश्किल है
एक और रूप वह है जो हर request की ambiguity का फायदा उठाता है
उन्हें मोटे तौर पर पता होता है कि उनसे क्या मांगा गया है, फिर भी “सबक सिखाने” के लिए ऐसा output देते हैं जो request के अक्षरशः तो सही होता है, लेकिन वे जानते हैं कि वह वह चीज़ नहीं है जिसकी किसी को ज़रूरत थी या जिसे कोई चाहता था
संयोग नहीं कि ऐसे game खेलने वाले ज्यादातर लोग पिछले एक साल में निकाले जा चुके हैं
लोग कुछ हद तक काम कर लेने वाले खराब colleague को कुछ समय तक सह लेते हैं, लेकिन layoffs के समय वे हटाए जाने वालों की list में सबसे ऊपर आ जाते हैं
एक महीने पहले मुझे समझ आया कि leader के तौर पर मैं कहां fail हो रहा था
ऊपर से मेरा इरादा team को ownership देना था, और मैंने करने के लिए ढेर सारे काम उन पर डाल दिए, लेकिन असल में मैं “इस वक्त क्या करना चाहिए” वाला stress team पर डाल रहा था
यह एक चालाक trap है जिसमें यह सोचना आसान है कि “मैं team को बहुत ज्यादा delegation दे रहा हूं!”, जबकि असल में इससे team stress में आती है और उसकी focus घटती है
OED के मुताबिक इसका noun के रूप में इस्तेमाल Australian colloquial speech से शुरू हुआ था
https://www.oed.com/search/dictionary/?q=ask
हम सब जानते हैं कि language लगातार बदलने वाला biosocial cognitive product है और असल में कोई नियम नहीं होते, लेकिन जब अच्छे synonyms पहले से मौजूद हैं और ठीक-ठाक काम कर रहे हैं, तो यह इस्तेमाल रेत चबाने जैसा खटकता है
क्योंकि मैं नहीं चाहता था कि वह जानकारी decision को प्रभावित करे
मुझे लगा कि हमें वह करना चाहिए जो business और end user के लिए सबसे अच्छा हो, न कि जो मेरे लिए आसान हो
लेकिन सामने वाले ने लंबा और मुश्किल option चुना, और बाद में पता चला कि वह असल में दूसरा option चाहता था, लेकिन उसे लगा था कि वह मेरे लिए ज्यादा कठिन होगा
वास्तविक जीवन में भी यही होता है
नई kitchen cabinets बनाते समय मैंने अपनी पत्नी को दरवाजे की top rail के दो options दिए; उनमें से एक ज्यादा कठिन था, लेकिन मैं चाहता था कि वह जो पसंद करे वही चुने, इसलिए मैंने नहीं बताया
जाहिर है, पत्नी ने कठिन वाला चुना, और बाद में पता चला कि उसे लगा था वह आसान होगा, जबकि असल में उसे दूसरा वाला ज्यादा पसंद था
इसलिए हमेशा सामने वाले को सारी जानकारी देनी चाहिए
management ने जो सवाल पूछा है वह बेकार है, यह हम क्यों नहीं कह सकते
जवाब जाहिर है: hierarchy के खिलाफ न जाने के लिए
लेकिन ऐसी hierarchy compliance असल में business की मदद नहीं करती
यह ऐसी value लगती है जिसे और आसानी से छोड़ा जा सके
“क्या आप बहुत thorough चीज़ expect कर रहे हैं, या बस quick summary चलेगी?” वाला सवाल मजेदार है
अगर engineer किसी non-engineer को ईमानदारी से बता दे कि किसी काम में कितना समय लगेगा, तो non-engineer चौंक जाएगा और कहेगा कि यह नहीं चलेगा
“20 मिनट से ज्यादा मत लगाना, और 20 मिनट बाद जो हो वह ले आना” वाली request पागलपन जैसी लगती है
20 मिनट वाले काम होते ही नहीं
बेहतर होगा कि कहें, “इसे मत देखो, coffee पीकर आओ और एक rough estimate दे दो”
हम complex work कर रहे हैं और सोचने के लिए समय चाहिए
अगर आप नहीं चाहते कि सोचने में समय लगे, तो बस पूछिए ही मत
समस्या का एक हिस्सा यह है कि आप boss से दफा हो जाने को कहना भी नहीं चाहते, और यह भी नहीं कहना चाहते कि जिस काम को boss 20 मिनट का मानता है उस पर आपने 6 घंटे लगाए
इसलिए इसके बजाय बाकी सारे काम पीछे खिसक जाते हैं
यही वजह है कि अच्छा engineering management engineers को उन लोगों से जितना हो सके दूर रखता है जो अनजाने में technical लोगों को झपटकर खींच लेंगे
कमजोर management का एक आम संकेत है ऐसी reports मांगना या काम assign करना, जिनके पूरे निहितार्थ वह खुद नहीं समझता
कमजोर engineering का एक आम संकेत है उस request पर “हाँ” कहना
जब कोई कमजोर manager किसी मामूली तौर पर संभाले जा सकने वाले दायरे से बाहर की चीज़ मांगता है, तो worker को technical और social context के हिसाब से इन तीन में से एक करना चाहिए
A) पूछना, “यह कैसे करना है?”
यह तब काम करता है जब manager technical हो और अपनी technical अक्षमता की भरपाई करने के लिए अस्पष्ट तरीके से काम उछाल रहा हो
उस बकवास को उसी पर वापस डालने से वह जो मांग रहा है उसके scope और mechanism की reality से उसका सामना होता है
B) बताना, “इस काम में X resources लगेंगे। expectations क्या हैं?”
यहाँ X भारी man-hours, पैसा, पुराने RuneScape GP वगैरह कुछ भी हो सकता है
यह non-technical manager के लिए ठीक है, और A की तरह ही उसे यह सामना कराता है कि यह मौके पर approve करने वाली चीज़ नहीं, बल्कि normal process से गुजरने वाली बड़ी request है
C) “नहीं” कहना
यह हर organization या हर social context में संभव नहीं होता, लेकिन high-performance organizations इसे संभव बनाते हैं
high-performance engineering environment में engineering organization के पास बेतुके busywork पर मजबूत veto होता है, जिसे सिर्फ C-level leadership ही पलट सकती है
इस veto को कब और कैसे इस्तेमाल करना है, यह जानना भी एक अहम skill है जिसे engineering को विकसित करना चाहिए
इसलिए उस बारे में कुछ भी कहना आपको दरवाजे की तरफ धकेलने जैसा हो सकता था
जब भी “ask” को noun की तरह इस्तेमाल होते देखता हूँ, मेरी भाषा-समझ खटकने लगती है; खोजने पर यह पोस्ट मिली
https://english.stackexchange.com/questions/4246/can-or-shou...
जिन्हें यह इसी तरह खटकता है, उनके लिए मददगार हो सकती है
request में context गायब होना time waste की सबसे बड़ी वजहों में से एक है
ऐसा लगता है जैसे सिर्फ जरूरी लोगों को बताकर time बचाने की कोशिश की जा रही हो, लेकिन “क्यों” और context अच्छे solution तक पहुँचने के लिए सचमुच जरूरी हैं
इनके बिना यह पता नहीं चलता कि सामने वाले ने पहले से क्या-क्या सोचा है
उदाहरण के लिए, अगर कहा जाए “X देश से आने वाली requests block करनी हैं”, तो ज्यादातर firewall services से यह मुश्किल नहीं है
लेकिन ऐसा क्यों करना है
अगर मकसद यह contractual guarantee देना है कि किसी खास देश से traffic नहीं आएगा, तो यह तरीका काम नहीं करेगा, क्योंकि कोई भी VPN से 2 मिनट में country code detection को bypass कर सकता है
user X करना चाहता है लेकिन तरीका नहीं जानता, उसे लगता है Y काम करेगा इसलिए वह Y पर help मांगता है, और बाकी लोग Y को अजीब देखकर confused हो जाते हैं
https://xyproblem.info/
उस पहाड़ी पर पहले ही बहुत लोग मारे जा चुके हैं, और फिर भी इसे implement किया गया
बेहतर है कि आप एक और casualty न बनें
आखिरकार यह काफी हद तक company culture पर निर्भर करता है, और इस पर कि लोग senior leaders से असहमति जताने में कितना comfortable महसूस करते हैं
यह बोझ senior leaders पर है कि वे नीचे के लोगों के लिए असहमति जताना आसान बनाएं
मेरे अनुभव में सबसे अच्छे leaders humble होते हैं और सुनने की इच्छा रखते हैं
हालांकि कभी-कभी बेकार का काम करना भी job का हिस्सा होता है
अगर यह बहुत ज्यादा हो, तो जाहिर है कोई और काम खोज सकते हैं, लेकिन हमेशा management पर शक करने और पलटकर सवाल पूछने वाले व्यक्ति न बनना ही बेहतर है