1. ‘जटिल काम delegate करना’ मुश्किल क्यों है
- साधारण कामों को checklist के साथ सौंपना आसान होता है, लेकिन जटिल कामों में अक्सर बहुत-सा tacit knowledge (context, decision criteria, exception handling) शामिल होता है जो केवल किसी एक व्यक्ति के दिमाग में होता है, इसलिए उसे शब्दों में समझाना कठिन होता है।
- इसी वजह से अक्सर स्थिति यह बन जाती है कि “इससे अच्छा मैं खुद ही कर लूं”, और किसी खास व्यक्ति पर निर्भरता से key person risk बढ़ जाता है।
2. लेख में सुझाया गया मुख्य लक्ष्य
- लक्ष्य है ऐसी स्थिति बनाना जिसमें “मेरे बिना भी output की quality बनी रहे” (= key person risk में कमी + scale हो सकने वाला संगठन)।
- इसके लिए लेख जटिल काम सौंपते समय इस्तेमाल की जा सकने वाली ठोस training और delegation structure का प्रस्ताव रखता है।
3. मुख्य framework का सार
-
- Exponential training (घातीय training): एक व्यक्ति अंत तक “ठीक से” सीखता है, और फिर वही व्यक्ति अगले व्यक्ति को सिखाता है, इस तरह leverage बढ़ता जाता है।
-
- (अगर दूसरी विधि हो) उदाहरण: role और responsibility की इकाइयों में बांटकर delegate करने की संरचना, या धीरे-धीरे authority बढ़ाने का तरीका; यानी एक बार में पूरी delegation करने के बजाय चरणबद्ध तरीके से जटिल जिम्मेदारियां बांटी जाती हैं।
4. Exponential training (घातीय training)
- जटिल काम (जैसे incident response, core architecture decisions आदि) एक व्यक्ति को full-stack जिम्मेदारी के साथ सौंपे जाते हैं, और real-world practice, review और feedback को दोहराते हुए ऐसा व्यक्ति तैयार किया जाता है जो “वास्तव में जिम्मेदारी ले सके”।
- इसके बाद यही व्यक्ति mentor और trainer बनता है, और अपने पिछले वास्तविक अनुभवों/incident/case studies के आधार पर अगले व्यक्ति को train करता है, जिससे लोगों की संख्या घातीय रूप से बढ़ती है।
5. वास्तविक training design के मुख्य बिंदु
- पिछले incidents और घटनाओं को ज्यों का त्यों दोहराने वाले अभ्यास (“rehearsal”) के जरिए, वास्तविक जैसी दबावपूर्ण परिस्थितियों और context में decision-making की training दी जाती है।
- केवल सिद्धांत समझाना पर्याप्त नहीं है; व्यक्ति को “वास्तविक जिम्मेदारी वाला role” देना जरूरी है, और गलतियों की संभावना स्वीकार करते हुए पहले से ऐसे safety measures design करने होते हैं जिनसे recovery संभव रहे।
6. दूसरी विधि: structured delegation
- जटिल काम को पूरा का पूरा एक साथ सौंपने के बजाय,
- लक्ष्य (Outcome),
- decision-making authority की सीमा,
- reporting और check-in की आवृत्ति,
- वे constraints जिनमें failure नहीं होना चाहिए
इन चार हिस्सों में बांटकर स्पष्ट किया जाता है।
- शुरुआत में “सिर्फ research करो और recommendation दो (Research & recommend)” → “निर्णय लो और रिपोर्ट करो (Decide & inform)” → “पूर्ण autonomy (Act independently)” की तरह **delegation level को चरणबद्ध तरीके से बढ़ाया जाता है।
7. जटिल काम सौंपते समय ज़रूर शामिल किए जाने वाले तत्व
- सफलता की परिभाषा: किस तरह का परिणाम आने पर कहा जा सके कि “काम अच्छी तरह हुआ”, इसे ठोस उदाहरणों के साथ दिखाया जाता है।
- समय और resource limits: अधिकतम समय/बजट पहले से तय कर guardrail लगाया जाता है ताकि काम अंतहीन गहराई तक न चला जाए।
- check-in structure: शुरुआती कुछ बार कम अंतराल पर मध्य समीक्षा रखी जाती है, ताकि दिशा भटके तो तुरंत course correction किया जा सके।
8. गलत delegation में दिखने वाले आम failure patterns
- “बस मोटा-मोटी समझाया, अब result लेकर आओ” वाले तरीके से काम सौंपने पर,
- सामने वाला जरूरत से ज्यादा समय और ऊर्जा खर्च करता है,
- और result अपेक्षा से भटक जाता है, जिससे दोनों थक जाते हैं; यह pattern बार-बार दोहरता है।
- दूसरी ओर, अगर बहुत ज्यादा बारीकी से control किया जाए, तो वह आखिरकार micromanaging बन जाता है, और delegation के बजाय सिर्फ “remote control” जैसा संचालन रह जाता है।
9. इस लेख के अनुसार ‘अच्छी delegation’ की स्थिति
- काम संभालने वाला व्यक्ति खुद context और priorities को समझ सके, और अप्रत्याशित परिस्थितियों में भी तर्कसंगत निर्णय ले सके।
- leader “हर काम खुद करने वाला व्यक्ति” नहीं रहता, बल्कि “ऐसा व्यक्ति बनता है जो लोगों और systems के जरिए जटिल कामों को बार-बार हल करने वाली संरचना design करता है”।
अभी कोई टिप्पणी नहीं है.