Delegation 101: क्या delegate करना है, यह पहचानना

टू-डू लिस्ट आखिर लगातार बढ़ती ही क्यों रहती है? बस 10 मिनट यह अभ्यास करके देखें और चुनें कि क्या delegate किया जा सकता है.

चरण 1: टू-डू लिस्ट बनाइए (a few minutes)

• कौन-से repeat होने वाले काम हैं जिन्हें आप अब बंद करना चाहते हैं?

• हर बार जब कोई टीम में नया जुड़ता है या टीम छोड़ता है, तब आप कौन-सा काम manually करते हैं?

• अगर आप अगले हफ्ते लंबी छुट्टी पर जाएँ, तो लौटने पर कौन-सी ठीक एक समस्या हल हुई मिले तो आपको खुशी होगी?

चरण 2: टू-डू लिस्ट को 'वे काम जो सिर्फ आप कर सकते हैं' और 'delegate करने के उम्मीदवार' में बाँटिए (a couple of minutes)

'सिर्फ आप कर सकते हैं' वाले कामों को अलग करने का तरीका

- मैनेजर के रूप में काम: खर्च approve करना, छुट्टी approve करना, performance review, offer letter लिखना, और वे मामले जहाँ confidential जानकारी संभालने वाले सिर्फ आप ही हों. (→ आप अपने मैनेजर या सहकर्मी से मदद माँगकर देख सकते हैं)

- permissions से जुड़े काम: जब request को review, approve और वास्तव में grant करने वाले सिर्फ आप ही हों. (→ approvers की संख्या बढ़ाकर आपको अकेला व्यक्ति न रहने देना भी संभव है)

- context से जुड़े काम: जब किसी meeting में सिर्फ आप शामिल हुए हों और टीम के साथ साझा करने लायक जानकारी हो, या किसी टीम सदस्य की performance के लिए बेहद अहम feedback सिर्फ आपने ही सुना हो. (→ इस जानकारी या context को document करके रखा जा सकता है)

- deadlines से जुड़े काम: जब कोई काम तुरंत करना हो और delegate करने का समय न हो. (→ deadlines अक्सर आपकी सोच से ज्यादा flexible होती हैं. timeline आगे बढ़ सकती है या नहीं, यह पूछने में कोई नुकसान नहीं है)

जो काम देखने में सिर्फ आप करने वाले लगते हैं, लेकिन वास्तव में delegate किए जा सकते हैं

- कई लोगों वाली meeting से निकले action items: भले आपने कहा हो कि यह काम आप करेंगे, अगर समय पर पूरा होना मुश्किल लग रहा है तो अपनी availability फिर से आँकें और delegate करें.

- feedback: सिर्फ इसलिए कि किसी ने आपसे feedback माँगा है, इसका मतलब यह नहीं कि feedback सिर्फ आप ही दे सकते हैं. अगर आप feedback देने के लिए किसी नए उपयुक्त व्यक्ति से उस requester का परिचय करा दें, तो delegate करना ठीक है.

- announcements: एक healthy team में महत्वपूर्ण खबर कई लोगों की तरफ से आ सकती है. इसे जानबूझकर अभ्यास में लाइए.

- वे काम जो आपसे सीधे माँगे गए हों: सीधे आपसे कहा गया काम भी delegate किया जा सकता है. यह बताने का अवसर हो सकता है कि दूसरे अच्छे लोग भी यह काम कर सकते हैं.

चरण 3: और ज़्यादा items को delegate करने वाले कॉलम में ले जाएँ

• उन कामों को priority के हिसाब से सजाएँ जो सिर्फ आप कर सकते हैं, और उनमें से सिर्फ 5 रहने दें.

• अभी के लिए सिर्फ वही 5 काम आपके हैं. बाकी सबको delegate करने वाले उम्मीदवारों में डाल दें.

चरण 4: delegate करने वाले उम्मीदवारों को 'effort' और 'impact' के आधार पर rank करें (a couple of minutes या उससे कम)

• यह अलग करके देखें कि कौन-सा काम (आपके बिना भी) कम effort से हो सकता है, और पूरा होने पर किसका impact बड़ा होगा. इसका कोई एक सही जवाब नहीं है, इसलिए बिल्कुल सटीक बाँटने की कोशिश न करें; अपनी पहली instinct पर जाएँ.

• More impact, More effort: ये वे काम हैं जिन्हें delegate करके आप सबसे ज़्यादा समय बचा सकते हैं. इन्हें पहले delegate करें.

• More impact, Less effort: आप भी इन्हें आसानी से कर सकते हैं, लेकिन अगर कोई टीम सदस्य challenge चाहता है तो delegate किया जा सकता है.

• Less impact, More effort: automation पर विचार करें.

• Less impact, Less effort: इन्हें सूची से हटाने पर विचार करें.

चरण 5: delegate करने के लिए 5 items चुनें

• delegate करने वाले उम्मीदवारों को priority के क्रम में रखें और उनमें से सिर्फ 5 चुनकर delegate करें.

• 'high impact लेकिन moderate effort वाले काम' और 'moderate impact लेकिन low effort वाले काम' के बीच, दूसरे वाले को अधिक प्राथमिकता दें.

अगले चरण

• अगर यह अभ्यास कठिन लगा, तो सिर्फ आपके लिए नहीं था. लेखक के लिए भी कठिन था, और लगभग सभी के लिए कठिन होता है.

• developer से leader बनने की प्रक्रिया में delegation सबसे कठिन चीज़ों में से एक है. अक्सर इसलिए कि जिन कामों को हम खुद करने वाले थे, उन्हें delegate करते समय guilt और disappointment महसूस होता है.

• लेकिन अगर आप इस भावना से आगे निकल जाते हैं, तो आप leader के रूप में अधिक महत्वपूर्ण काम पर ध्यान दे पाएँगे: टीम को और सफल बनाना.

• यह अभ्यास महीने में एक बार करके patterns खोजने की कोशिश करें. शुरुआत में छोटा शुरू करें, और जैसे-जैसे सहज हों, और ज़्यादा delegate कर पाएँगे.

• अगला लेख इस बारे में है कि किसे और कैसे सफलतापूर्वक delegate करें. ← अभी प्रकाशित नहीं हुआ

[nicewook]

यह इससे सीधे तौर पर जुड़ा हुआ तो नहीं है, लेकिन हाल में मैं जिस बात पर सोच रहा हूँ, वह यह है:

• जैसे-जैसे अनुभव बढ़ता है, domain knowledge, अलग-अलग projects का ज्ञान, और history जमा होती जाती है

• संबंधित कामों से आने वाले interruptions बढ़ते जाते हैं

इसे कैसे पार किया जाए, यही मेरी चिंता है

[spilist2]

(हो सकता है यह बहुत साधारण बात लगे,) लेकिन मेरे मामले में, इंटरप्ट आने पर सिर्फ उसे संभालने से आगे बढ़कर मैं guideline documents जैसी deliverables बनाता हूँ ताकि अगली बार ऐसे मिलते-जुलते इंटरप्ट कम हों, और इससे थोड़ा सुधार हुआ। दोहराए जाने वाले कामों को automate करने जैसी चीज़ों से इंटरप्ट के कारण को ही हटाना भी संभव लगता है.

[nicewook]

बहुत अच्छी बात है।