उनका थोड़ा-सा अस्पष्ट अनुरोध उनके समय की बड़ी बर्बादी है

अस्पष्ट अनुरोध और दायरा

• कई टिप्पणियाँ सहमत हैं कि नेताओं के अस्पष्ट अनुरोधों से मेहनत की बर्बादी, दोबारा काम, और तनाव पैदा होता है।
• संदर्भ की कमी (“यह क्यों ज़रूरी है?”) भी उतनी ही हानिकारक है जितनी विवरण की कमी; लोग अक्सर गलत समस्या हल कर देते हैं (क्लासिक “XY problem”)।
• कई लोगों ने नोट किया कि कोई भी “offhand” अनुरोध परोक्ष रूप से प्राथमिकताओं को फिर से क्रमबद्ध कर देता है; नेता अक्सर इसे कम आँकते हैं।
• सुझाई गई अच्छी प्रथा: पूछें कि वास्तव में क्या चाहिए बनाम क्या माँगा जा रहा है, अपेक्षित आउटपुट गुणवत्ता स्पष्ट करें, और पुष्टि करें कि इसका बाकी काम पर क्या असर पड़ेगा।

Hierarchy, juniors, and power distance

• वरिष्ठ नेताओं द्वारा तकनीकी नेतृत्व को बायपास करके सीधे जूनियर्स से बात करने पर बार-बार चिंता व्यक्त की गई।
• जूनियर्स के पास अक्सर सिस्टम संदर्भ और मोलभाव की शक्ति नहीं होती; वे अवास्तविक अनुरोधों और समय-सीमाओं के लिए “हाँ” कह देते हैं, जिससे burnout और खराब code बनता है।
• अन्य लोगों ने कहा कि जब हर चीज़ सख्ती से कई परतों के माध्यम से रूट होती है, तो “telephone game” जैसा असर होता है; सुझाया गया समझौता यह है कि दोनों ICs और उनके managers को शामिल किया जाए और विरोध करने के लिए psychological safety बनाई जाए।

Timeboxing, estimates, and research

• timeboxing (“20 मिनट बिताओ और वापस रिपोर्ट करो”) पर मिश्रित विचार हैं।
  • Pro: टीमों को अज्ञात चीज़ों की सस्ती खोज करने देता है, cost/benefit निर्णय बेहतर करता है, और यह सामने लाता है कि कुछ rabbit hole है या नहीं।
  • Con: समय दायरे का अच्छा proxy नहीं है; लोग दिखावे को optimize करने के लिए दबाव महसूस करते हैं, या चुपचाप सीमा से अधिक चले जाते हैं।
• कई लोग इस बात पर ज़ोर देते हैं कि timebox के परिणाम fail-safe होने चाहिए और उन्हें commitments नहीं, बल्कि जानकारी माना जाना चाहिए।

Backlogs, tickets, and written requests

• कुछ लोग पुराने tickets को आक्रामक रूप से बंद करने या backlog में डालने की वकालत करते हैं; अन्य इसे destructive कहते हैं क्योंकि tickets documentation होते हैं और उनकी priority फिर से बढ़ सकती है।
• “हर” अनुरोध को ticket system से गुज़ारने के लिए मजबूत समर्थन है ताकि priorities ट्रैक हों और engineers को ad‑hoc interruptions से बचाया जा सके।
• अनुरोधों को लिखित में माँगना दोनों तरह से प्रस्तुत किया गया है: स्वस्थ (memory, clarity, audit trail) और, कुछ orgs में, इस बात का संकेत कि trust पहले ही टूट चुका है।

Communication styles & relationships

• व्यक्तिगत संबंधों से कई analogies दी गईं: literal बनाम inferential communication, अनुरोधों को ज़रूरत से ज़्यादा या कम specify करना, और initiative के गलत पड़ जाने पर निराशा।
• सहमति यह है कि “जहाँ तक reasonable हो, assumptions पर कम से कम छोड़ें,” लेकिन यह भी कि बहुत verbose specs पढ़े नहीं जाते। “सही स्तर” खोजना कठिन है और व्यक्ति-निर्भर है।

Culture, good faith, and coping

• कई लोगों का तर्क है कि मूल समस्या culture है: सवाल पूछने का डर, उच्च power distance, और blame games।
• दोनों पक्षों से “good faith” की अपील की जाती है: नेता पूछने से पहले सोचें; reports “human command line” या malicious compliance से बचें।
• coping tactics: discovery के लिए timebox करें, priorities स्पष्ट रूप से बताएं, कुछ लागतें requester पर वापस डालें, और यदि culture toxic बनी रहे, तो छोड़ने पर विचार करें.