सफल Risk-Taking संस्कृति बनाने के लिए टिप्स

Okta के सह-संस्थापक की किताब "Zero to IPO" में शामिल बातें

उद्यमी मानसिकता वाले लोगों को भर्ती करें (कम-से-कम पहले 100 कर्मचारियों तक)

• पहले 10 कर्मचारी कंपनी की संस्कृति को परिभाषित करते हैं, और अगले 90 उसे मज़बूत करते हैं
• बेशक, कंपनी का आकार बढ़ने के साथ आप मनोवैज्ञानिक रूप से अधिक रूढ़िवादी लोगों को लाना शुरू करेंगे
• लेकिन, पहले 100 कर्मचारियों द्वारा बनाई गई संस्कृति कर्मचारी संख्या 500, 1000 होने पर भी बनी रहेगी
• शुरुआती लोग जितने अधिक entrepreneurial होंगे, उतना ही उनका ethos कंपनी की संस्कृति में गहराई से घुल जाएगा

टीम को बताइए कि प्रोजेक्ट जोखिमभरा है

• Minted के CEO ने कहा, "मुझे ठीक से नहीं पता कि यह सफल होगा या नहीं। लेकिन इसे मज़े के साथ करके देखते हैं"
• अगर मैनेजर यह मानता है कि यह शायद सफल न हो, तो लोग भी आत्मविश्वास के साथ प्रोजेक्ट पर काम कर पाते हैं

इसे मज़ेदार बनाइए

• छुट्टी वाले "मज़े" की तरह नहीं, बल्कि शरारती, खुले और रोमांच से भरे "मज़े" की तरह
• शोध के अनुसार, mindset जितना अधिक playful होता है, उतनी ही अधिक creative innovation होती है
• जब लोगों से कुछ नया आज़माने को कहें, तो किसी खास परिणाम देने की तुलना में "exploration" और "discovery" पर अधिक ज़ोर दें

जिस प्रोजेक्ट में विफलता हुई हो, उसके कर्मचारियों को "सज़ा" मत दीजिए

• विफलता पर दंड देने वाली संस्कृति संस्थापकों का काम और कठिन बना देती है
• लोग तर्कसंगत आत्म-सुरक्षा के लिए बुरी ख़बर छिपाने लगेंगे
• अगर टीम किसी चीज़ में असफल हो जाए, तो दोष देने के बजाय यह सोचें कि अगला कौन-सा प्रोजेक्ट देना है
• असफल टीम को महत्वहीन (backwater) प्रोजेक्ट में भेजना एक ख़तरनाक संदेश देता है
• लोग यह मानने लगेंगे कि केवल वही प्रोजेक्ट करने चाहिए जिनमें सफलता लगभग तय हो, जो बहुत दिखाई दें और जिनमें जोखिम कम हो
• धीरे-धीरे कंपनी वास्तव में innovative और रोचक काम करना बंद कर देगी

guardrails सेट कीजिए

• आपको और आपकी टीम को यह हिसाब लगाना चाहिए कि कितना जोखिम लिया जा सकता है, और प्रोजेक्ट का आकार व्यक्ति या टीम के अनुभव के अनुरूप होना चाहिए
• प्रोजेक्ट के आकार, बजट और समय-सीमा के लिए guardrails तय कीजिए
• ऐसे milestones तय कीजिए जिन पर प्रगति और मिली हुई जानकारियों की रिपोर्ट ली जा सके
• किन परिस्थितियों में प्रोजेक्ट बंद करना चाहिए, उसके parameters परिभाषित कीजिए

Post-mortem कीजिए और सीखी गई बातों का जश्न मनाइए

• "विफल" प्रोजेक्ट तब तक ख़त्म नहीं होता जब तक टीम यह न सीख ले कि क्या अच्छा हुआ और क्या नहीं, और पूरी कंपनी के लिए सीखने योग्य insights न निकाल ले
• यही तरीका Google X बनाने वाले Sebastian Thrun ने अपनाया था
  "हम हमेशा लोगों से कहना चाहते थे कि विफलता सीखने के बारे में है। अगर आप कुछ ऐसा सीखते हैं जो महत्वपूर्ण insights देता है, तो वह शानदार है।"

[yuno815]

बहुत अच्छी तरह पढ़ा। धन्यवाद!

[curioe]

मैं ऑपरेटर हूँ। आपके लिखे हर कमेंट पर रिपोर्ट आई है, इसलिए जाँच करके यह कमेंट कर रहा हूँ.
कृपया GeekNews की साइट उपयोग विधि में ‘कमेंट करना’ अनुभाग को देखें.
संभव हो तो केवल वर्तनी की गलतियाँ बताने के बजाय विषय से संबंधित कमेंट करें.