डेडलाइन का प्रभावी इस्तेमाल करके खुश और उत्पादक टीम बनाना

बिज़नेस यूनिट द्वारा तय की गई डेडलाइन आजकल लगभग बेअर्थ हो गई हैं। सॉफ़्टवेयर रिलीज़ करना अब बहुत आसान हो गया है, और इसलिए हर एक रिलीज़ की लागत बहुत कम हो गई है.

डोमेन-विशेष महत्वपूर्ण इवेंट्स (जैसे education में admission season, sports में league season, e-commerce में Black Friday) को छोड़ दें, तो लगभग हर डेडलाइन एक भ्रम है। यह डर और चिंता से पैदा हुई, नकली तात्कालिकता (false urgency) से जन्मी चीज़ है.

उल्टा कहें तो, अगर टीम के लिए सचमुच कोई चीज़ तात्कालिक है, और डेडलाइन निभाने से मिलने वाला लाभ बड़ा है, तो उसे तय करना चाहिए। लेकिन सिर्फ तय कर देने से काम खत्म नहीं होता। अगर टीम के सभी लोग एक ही मोड में काम करें, तो इस बात पर अच्छी तरह sync होना ज़रूरी है कि इस डेडलाइन को पूरा करना क्यों महत्वपूर्ण है। उदाहरण के लिए, अगर यह असहज बातचीत भी करनी पड़े कि funding से मिला पैसा खत्म हो रहा है, तो वह भी करनी चाहिए.

इसलिए डेडलाइन को प्रेरित करने वाली चाबुक की तरह इस्तेमाल करना अच्छा नहीं है। डेडलाइन का सही इस्तेमाल करने के मोटे तौर पर दो तरीके हैं.

1. रचनात्मकता को उभारने में मदद करने वाली बाधा के रूप में इस्तेमाल करना

• जब सीमाएँ लगाई जाती हैं, तो अक्सर उस स्थिति के अनुरूप, या उसे पार करने के लिए, रचनात्मकता बेहतर तरीके से उभरती है। खासकर product-market fit खोजने के शुरुआती चरण में, डेडलाइन अत्यधिक planning और design को रोकने में बहुत मदद करती है.

• एक और उदाहरण के तौर पर, infrastructure development team को lead करने के अनुभव में भी डेडलाइन उपयोगी रही.

  • infrastructure development का काम सामान्य product development की तुलना में कहीं अधिक समय लेता है, value साबित करने के लिए दिखाने वाली चीज़ें भी अधिक होती हैं, और यह अक्सर शुरुआती इरादे से कहीं ज्यादा संभावनाएँ खोल देता है। इसलिए infrastructure के काम में cost-effectiveness analysis करना कठिन होता है.

  • इसी वजह से कई infrastructure teams अपने lead को यह समझाने में कठिनाई महसूस करती हैं कि पूरे platform को 2 साल तक rewrite करने जैसे काम की वैधता क्या है। स्वाभाविक रूप से, ऐसे काम लगभग हमेशा व्यावहारिक नहीं होते.

  • इसलिए मैंने 6 हफ्ते में एक बार टीम को demo दिखाने की डेडलाइन तय की। पूरी तरह काम करने वाली कोई चीज़ दिखाना ज़रूरी नहीं था, लेकिन इतना ज़रूर बनाना था कि लोगों को भरोसा हो कि हम सही दिशा में जा रहे हैं.

2. "giving" को manage करने के टूल के रूप में इस्तेमाल करना

• दुनिया में तीन तरह के लोग होते हैं.

  • giver बिना लाभ की परवाह किए दूसरों की मदद करता है

  • taker दूसरों की परवाह किए बिना लाभ लेना चाहता है

  • matcher इन दोनों के बीच होता है। take करने के बाद give करना चाहता है, और give करने के बाद take करना चाहता है.

• कंपनी में performance के आधार पर ranking करें, तो high performer giver भी बहुत होते हैं, लेकिन low performer giver भी कम नहीं होते.

• यह अंतर किस वजह से बनता है, इसे देखने पर पता चलता है कि top giver यह जानते हैं कि कब give करना है और कब अपना काम करना है—यानी giving को कैसे manage करना है। यहाँ डेडलाइन एक उपयोगी टूल बनती है.

• हममें से अधिकांश लोग giver के साथ काम करना चाहते हैं, और जिन संगठनों में giver अधिक होते हैं, वहाँ attrition भी कम होता है। ऐसे संगठनों में यह महत्वपूर्ण है कि giver low performer न बन जाएँ, और इसके लिए डेडलाइन को एक टूल की तरह इस्तेमाल किया जा सकता है

[wonderer]

पहले बिंदु को लेकर मेरा नज़रिया थोड़ा नकारात्मक है। मेरा मानना है कि creativity सिर्फ deadline तय कर देने से नहीं आती, बल्कि Lean तरीके से development करने की क्षमता होने पर ही deadline के दौरान creativity उभरती है। अगर कोई संगठन यह सोचे कि चलो... अपनी creativity दिखाने के लिए deadline तय करके देखते हैं, तो क्या वास्तव में creativity उभरेगी? हाँ, अगर इसे iteration या sprint के concept के रूप में देखें तो कुछ हद तक समानता हो सकती है। लेकिन सच कहूँ तो मैंने ऐसे संगठन बहुत कम देखे हैं जो इसका भी सही तरह से उपयोग करते हों...

[kwon5604]

giver / taker / matcher के बारे में तो समझ आ गया, लेकिन जब इसे deadline से जोड़कर देखते हैं, तो यह क्यों deadline के उपयोग में मदद करता है, यह अभी भी मुझे पूरी तरह स्पष्ट नहीं हो रहा है...

क्या इसका मतलब यह है कि कम प्रदर्शन करने वाले giver की performance बेहतर करने और उन्हें burnout से बचाने के लिए deadline को एक tool की तरह इस्तेमाल करना अच्छा होता है?? बाकी लोगों ने इसे कैसे समझा, यह जानने की जिज्ञासा है.

[kwon5604]

थोड़ा और ध्यान से पढ़ने पर बात कुछ हद तक समझ में आती है। अगर deadline को एक तरीके के रूप में इस्तेमाल करने के concrete examples भी होते, तो समझना और आसान होता, ऐसी थोड़ी कमी महसूस हुई।

सारांश + राय

1. giver के 2 प्रकार होते हैं

   • low performer

   • high performer

2. high performer giver को देखें, तो वे यह manage करना जानते हैं कि कब और कैसे giving (दूसरों की मदद करना) करना है

3. दूसरी ओर, low performer giver, high performer giver की तुलना में giving (दूसरों की मदद करना) को manage करने में कमजोर होते हैं (जैसे, दूसरों की मदद करते-करते अपना काम ठीक से न संभाल पाना..)

4. हममें से ज़्यादातर लोग giver के साथ काम करना चाहते हैं, और जिन संगठनों में giver ज़्यादा होते हैं वहाँ job change भी कम होता है

   • अच्छे संगठन में giver ज़्यादा होते हैं, और संगठन को भी यह बनाए रखना चाहिए कि giver अधिक रहें

5. इसलिए managers को giver की संख्या बनाए रखते हुए, low performer giver को high performer giver बनने में मदद करनी चाहिए

   • वैसे भी अगर giver ज़्यादा हों, तो high performer giver ज़्यादा होना बेहतर है..

6. उसके तरीके के रूप में deadline को एक tool की तरह इस्तेमाल किया जा सकता है

7. ऊपर के लेख में इसे concretely कैसे इस्तेमाल करना है, यह नहीं बताया गया है, लेकिन लेख की बातों से अनुमान लगाएँ तो

   • deadline दिए बिना जब काम सौंपा जाता है, तो low performer giver में अपने giving को manage करने की क्षमता तुलनात्मक रूप से high performer से कम होती है (यह मानकर), इसलिए वे giving पर ही ज़्यादा ध्यान देकर अपना काम ठीक से न कर पाने की संभावना रखते हैं

   • इसे रोकने के लिए अगर manager के स्तर पर deadline साफ़-साफ़ तय कर दी जाए और guidance दिया जाए, तो low performer giver के लिए giving करते हुए भी deadline के हिसाब से अपना काम पूरा करना ज़रूरी हो जाता है, इसलिए उन्हें खुद priority तय करनी होगी, checklist बनानी होगी वगैरह, यानी schedule manage करना ही पड़ेगा

   • अगर यह प्रक्रिया बार-बार दोहराई जाए, तो low performer giver को high performer giver की तरह अपने giving को अच्छी तरह manage करना सिखाया जा सकता है

ऐसा सोचा जा सकता है

7वें बिंदु के बारे में बाकी लोग क्या सोचते हैं, यह जानने की भी उत्सुकता है haha :)

[wonderer]

किसी न किसी तरह मैं इसे अपने अनुभव के उदाहरणों के संदर्भ में ही देखता हूँ। जिस टीम में मैं था, उसमें एक टीम सदस्य था जो बेहद जुनूनी था। उसे दूसरों की मदद करना बहुत पसंद था और वह ऊर्जा से भरा रहता था, इसलिए वह अक्सर तरह-तरह के काम शुरू कर देता था। समस्या यह थी कि ऐसा करते-करते वह कभी अकेले बहुत आगे निकल जाता था या काम जरूरत से ज्यादा बड़ा हो जाता था। आखिरकार कई बार चीजें ठीक से पूरी नहीं हो पाती थीं, या जो बनाया गया वह बेकार साबित होता था। नतीजतन, उस व्यक्ति ने जितनी ऊर्जा और समय लगाया उसके मुकाबले अच्छे परिणाम नहीं मिलते थे, और ऐसी स्थिति बार-बार दोहराई जाती थी। मुझे नहीं लगता कि सिर्फ deadline से यह समस्या हल हो सकती है, लेकिन व्यक्तिगत रूप से मैं इस बात पर सोचता रहा हूँ कि ऐसी ऊर्जा को सही दिशा में कैसे ले जाया जाए, और उस नजरिए से यह मुझे एक संदर्भ के तौर on useful लगा.

[spilist2]

मैंने भी 7वें बिंदु के बारे में कुछ ऐसा ही सोचा था। ज़रूरी नहीं कि डेडलाइन ही असली मुद्दा हो, बल्कि यह ज़्यादा इस बात के करीब लगता है कि givers को इस तरह काम मैनेज करके दिया जाए कि वे समय पर अपने काम में नतीजे दे सकें.

मैंने अभी तक नहीं देखा है, लेकिन givers/takers/matchers के बारे में एक लंबा वीडियो मिला, इसलिए सोच रहा हूँ कि शायद यहाँ से कुछ और संकेत मिलें। (हालाँकि किताब पढ़ना शायद ज़्यादा तेज़ हो सकता है.) https://www.youtube.com/watch?v=-egUK2zaZlo

[roxie]

मुझे ठीक से समझ नहीं आ रहा कि 1 नंबर का पारंपरिक agile methodology से क्या फर्क है। शायद मैंने सिर्फ सारांश पढ़ा, इसलिए..? अगर कोई थोड़ा और विस्तार से समझा दे तो आभारी रहूँगा, हा हा

मुझे लगता है 2 नंबर वाला हिस्सा थोड़ा ज़्यादा दिल को छूता है। यह giving को स्कोर करने के लिए एक अच्छा शुरुआती बिंदु लगता है। 2 नंबर में जिन giver, taker, matcher की बात की गई है, उसके बारे में आप यहाँ थोड़ा और विस्तार से देख सकते हैं: https://www.youtube.com/watch?v=YyXRYgjQXX0। यह एक TED वीडियो है जो एक बेहद दिलचस्प शोध-परिणाम समझाता है: संगठन में सबसे कम प्रदर्शन करने वाला व्यक्ति भी giver होता है, और सबसे अधिक प्रदर्शन करने वाला व्यक्ति भी giver होता है.

[spilist2]

आपकी बदौलत बहुत अच्छा वीडियो देख पाया। परिचय के लिए धन्यवाद। असली वीडियो देखना बेहतर होगा, लेकिन दूसरों के लिए मैंने इसका सारांश बना दिया है। https://www.youtube.com/watch?v=YyXRYgjQXX0

===

30,000 लोगों का सर्वे किया गया। इंजीनियर, नर्स, सेल्सपर्सन आदि

• वितरण लगभग giver 25, taker 19, matcher 56 है

taker जल्दी ऊपर जाते हैं और जल्दी बर्बाद भी हो जाते हैं

• matcher ज़्यादा होते हैं, इसलिए "आंख के बदले आंख" रणनीति से taker को गिरा देते हैं

giver उच्च-प्रदर्शन करने वालों और निम्न-प्रदर्शन करने वालों, दोनों में पाए जाते हैं। कम-प्रदर्शन करने वाले giver इसलिए पीछे रह जाते हैं क्योंकि वे दूसरों की मदद करते-करते अपना काम नहीं कर पाते

giver वाले संगठन कई तरह से अधिक उत्पादक होते हैं और संतुष्टि भी अधिक होती है। ऐसा संगठन कैसे बने जहाँ giver उच्च प्रदर्शन करें और उन्हें पहचान भी मिले?

1. giver को burnout होने से बचाइए

• giver दूसरों की मदद करते-करते आसानी से थक जाते हैं। इन्हें बचाकर रखना ज़रूरी है

• अगर कोई व्यक्ति दूसरों की जरूरत से ज़्यादा मदद करने की कोशिश करता है, तो उसे कुछ सिद्धांत दिए जा सकते हैं। जैसे, "Mother Teresa बनने की ज़रूरत नहीं है, बस 5 मिनट की सद्भावना दिखाकर देखो" जैसी बात।

2. मदद मांगने को प्रोत्साहित कीजिए। ऐसी संस्कृति बनाइए जहाँ giver से मदद लेना मूल्यवान समझा जाए।

• जब उनसे किसी काम के लिए कहा जाता है, तो giver परिणाम दे पाते हैं, धन्यवाद पाते हैं, और खुश होते हैं

• और 75~90% giver जब मदद करना चाहते हैं, तो वे "सवाल" से शुरुआत करते हैं। यानी बहुत सी मदद पूछने से शुरू होती है, इसलिए सवाल पूछने को प्रोत्साहित करेंगे तो दूसरे लोगों के लिए भी giver बनना आसान होगा

• लेकिन आम तौर पर लोग पूछते नहीं हैं। उन्हें डर होता है कि वे अयोग्य लगेंगे, अच्छा सवाल नहीं पूछ पाएंगे, या सामने वाला व्यस्त दिख रहा है इसलिए उस पर बोझ नहीं डालना चाहते

3. taker को टीम में मत आने दीजिए, और उन्हें छांटकर बाहर कीजिए। एक taker टीम में आ जाए तो कई giver चले जाते हैं या मदद करना बंद कर देते हैं।

• matcher माहौल के हिसाब से चलते हैं, इसलिए सिर्फ taker को छांट दें तो giver संस्कृति बनाई जा सकती है

• समस्या यह है कि taker को छांटना आसान नहीं है। "agreeableness" giver का एक अच्छा संकेत है, लेकिन taker भी मिलनसार हो सकते हैं और giver भी रूखे लग सकते हैं

• किसी रूखे giver को जल्दबाज़ी में taker मत मान लीजिए। ये वही लोग होते हैं जो ऐसी महत्वपूर्ण feedback देते हैं जिसे कोई सुनना नहीं चाहता, लेकिन सबको सुनना चाहिए

• मिलनसार taker को छांटने के लिए इंटरव्यू में मैं अक्सर एक सवाल पूछता हूँ: "उन चार लोगों के नाम बताइए जिन्होंने आपके करियर को बुनियादी रूप से बेहतर बनाया।"

• आम तौर पर taker चापलूसी पाने के आदी होते हैं, इसलिए वे प्रभाव और अधिकार वाले लोगों के नाम बताते हैं

• आम तौर पर giver power structure के निचले हिस्से में मौजूद लोगों के नाम ज़्यादा लेते हैं

[budlebee]

सार के लिए धन्यवाद।

क्या "takers are great at kissing up" का ज़्यादा सटीक अनुवाद यह नहीं होगा कि वे चापलूसी पाने के आदी होने के बजाय चापलूसी करने में ज़्यादा माहिर होते हैं?

[spilist2]

आह, सही है। यह kissing up / kicking down था.. धन्यवाद

[magicianwoo]

अच्छे संकलन के लिए धन्यवाद.

[spilist2]

असल में मुझे भी दूसरा बिंदु ज़्यादा relatable लगा। haha;

मेरे लिए पहला बिंदु इस तरह था कि, मैनेजर के रूप में deadline तय करते समय उसे किस नज़रिए से देखना चाहिए—एक mental model की तरह। लगभग इस अर्थ में कि, "सिर्फ schedule पूरा करवाने के लिए दबाव डालने के बजाय, सीमित resources के भीतर बेहतर choices करने में मदद करने वाले tool के रूप में deadline को देखना अच्छा है।"

मूल लेख भी इतना लंबा नहीं है... इसलिए इसमें कोई और गहरी परत है या नहीं, यह पक्का नहीं कह सकता। एक तरह से देखें तो यह "छोटे-छोटे हिस्सों में बाँटकर deploy करना" के फ़ायदों को दूसरे तरीके से कहने जैसा भी लगता है।

[roxie]

काफी समय बाद यह वीडियो फिर से देखने का ख़याल आया, और 8:20 से जो बात कही गई है, वह सच में कमाल की है। "giver को भर्ती करने की मत सोचो, taker को छोड़ने की सोचो"। मुझे लगता है, यह वाकई बहुत अच्छी बात है.

[xguru]

वाह, यह बहुत अच्छा लेख है। डेडलाइन का प्रभावी इस्तेमाल करने वाला हिस्सा मुझे पसंद आया। सारांश के लिए धन्यवाद!