प्रारंभिक चरण की कंपनी ऑफसाइट्स

यह पोस्ट ज्यादातर मेरे दिमाग के ऊपर से Wispr AI द्वारा निर्देशित की गई थी

एक दूरस्थ कंपनी चलाने के लिए आगे बढ़ते समय मैंने अपने लिए एक बुनियादी नियम बनाया कि हम कार्यालय किराये पर खर्च किए गए पैसे को तिमाही में कम से कम एक से तीन बार व्यक्तिगत रूप से मिलने के लिए यात्रा में खर्च करेंगे। हम अभी-अभी सेंट लुइस में पहली पूर्ण कंपनी (यानी 3 लोग ऑफ-साइट/ऑनसाइट) से बाहर आए हैं। यह केवल 2.5 दिन था, लेकिन यह अपेक्षाकृत उत्पादक लगा, और मैं उन चीज़ों पर कुछ विचार लिखना चाहता था जिन्हें मुझे लगा कि हम दोहराना चाहते थे और जिन्हें मैं दूसरों को सुझाऊंगा।

पहली चीज़ जो मैंने व्हाइटबोर्ड पर की, वह थी रिट्रीट के हर एक घंटे को चिह्नित करना और वह सब कुछ सूचीबद्ध करना जो हम ऑफसाइट के दौरान पूरा करना चाहते थे (मूल रूप से समय ब्लॉक योजना, लेकिन सिर्फ समूह के आधार पर)। हमने यह भी सुनिश्चित किया कि हर किसी के पास इनपुट हो कि वे ऑफसाइट पर क्या कवर करना चाहते हैं ताकि वे यह महसूस करके जा सकें कि उन्हें ऑफसाइट से वह मिल गया है जो वे चाहते थे।

इसके साथ क्लासिक समस्या कम आकलन त्रुटियों का मिश्रण है। जिस चर्चा में कथित तौर पर एक घंटा लगता है उसमें तीन घंटे लग सकते हैं, और यह पूरी तरह से स्वाभाविक है। आप दिन के अंत में अनियोजित विस्तार (उर्फ प्रश्न चिह्न) के लिए जगह छोड़कर इसे कम कर सकते हैं। चूँकि हम बहुत जल्दी हैं, इसलिए हमने इनमें से प्रत्येक सत्र के लिए पूर्व योजना नहीं बनाई है जिसमें हम अगले सत्र में जाने वाले हैं। बड़ी ऑफ-साइटों पर, मैंने देखा है कि लोग ऑफ-साइट से एक या दो दिन पहले यह सुनिश्चित कर लेते हैं कि जिस सत्र पर चर्चा की जा रही है, उसके लिए पर्याप्त संदर्भ निर्धारित किया जा रहा है।

हमारे बीच, हम 4-5 दूरस्थ कंपनियों का हिस्सा रहे हैं जो ऑफ-साइट काम करती थीं, लेकिन बहुत कम ही कंपनियां अपने दौरान पूर्ण वित्त समीक्षा करती हैं। मुझे संदेह है कि यह सभी अर्थशास्त्र (सभी के वेतन सहित) को उजागर नहीं करने और जब आपके पास बहुत सारे अलग-अलग ग्राहक और SKU हैं, तो लेखांकन की कठिनाई को उजागर नहीं करने के कारण है। यह हमारे लिए कोई समस्या नहीं है क्योंकि अभी हमारा वेतन पारदर्शी है, और फंडिंग स्रोत और ग्राहक/राजस्व स्रोत बहुत सीधे हैं।

इस बैठक का मूल लक्ष्य कंपनी में हर किसी के लिए यह जानना है कि पैसा कहाँ है, यह कहाँ से आता है/कहाँ जाता है, और भविष्य में हमें और अधिक कमाने की संभावना कहाँ है। इससे लोगों, विशेषकर कर्मचारियों को रनवे और व्यवसाय की मूलभूत व्यवहार्यता के संदर्भ में कुछ सुरक्षा मिलती है।

हमारे लिए, इसमें 15 मिनट लगे क्योंकि यह बहुत सरल था और इसे मेरे दिमाग के ऊपर से खींचा जा सकता था।

हमारे उत्पाद और इंजीनियरिंग प्राथमिकताएं अधिक स्पष्टता प्राप्त करती हैं, हम उन ग्राहकों को बेहतर ढंग से समझते हैं जिनके लिए हम निर्माण कर रहे हैं। मैं स्वीकार करता हूं कि यह कुछ ऐसा है जिसका हम अभी भी पता लगा रहे हैं, और मुझे यकीन नहीं है कि इस तथ्य के अलावा यहां क्या सलाह दी जाए कि मैं दृढ़ता से मानता हूं कि ग्राहक केंद्रितता और जुनून किसी कंपनी को विकसित करने का सही तरीका है – या कम से कम एक कंपनी को ईमानदार बनाए रखने का – प्रौद्योगिकी या अनुसंधान केंद्रितता या “वाइब्स” केंद्रितता जैसी अन्य चीजों के विपरीत।

संपूर्ण कोडबेस लें और इसे चैटजीपीटी में डालें, और इसे एक मरमेड आरेख बनाने के लिए कहें, जिसमें विभिन्न हिस्सों की ओर इशारा करने वाले बक्से और तीरों के साथ सभी प्रमुख अनुभाग दिखाए जाएं। उसे एक्सकैलिड्रॉ पर डालें, स्वाद के अनुसार बदलाव करें और स्वाद के अनुसार रंग दें, जिससे यह सब मोटे तौर पर समझ में आ जाए। फिर पूरी कंपनी को इसके माध्यम से चलाएं।

मूल सिद्धांत: आगे क्या करना है, इस पर राय रखने का हर किसी को अधिकार है, लेकिन आज जो कुछ मौजूद है, उसके बारे में हम सभी को बुनियादी जमीनी तथ्य साझा करने चाहिए.

मुझे चुनौती दी गई कि यह अभ्यास क्यों महत्वपूर्ण है। काल्पनिक रूप से एक बड़ी कंपनी में, सीईओ को तकनीकी टीम को एक ब्लैक बॉक्स के रूप में मानने में सक्षम होना चाहिए और अब कार्यान्वयन विवरण के बारे में इतना चिंतित नहीं होना चाहिए। टीम के आकार को कम करते हुए, मुझे अभी भी लगता है कि यह उन लोगों के लिए प्रासंगिक है जो सीधे तौर पर इंजीनियरिंग टीम में नहीं हैं, आर्किटेक्चर को समझें ताकि लगाए गए तकनीकी दांवों की सराहना की जा सके और हास्यास्पद/पागल फीचर अनुरोध न किए जाएं। और यदि संभव हो, तो सक्रिय रूप से सिस्टम के ऐसे डिज़ाइन तैयार करें जिन्हें सुविधाओं के रूप में तैयार किया जा सके।

निःसंदेह, एक तकनीकी संस्थापक के रूप में, मैं इस अवसर का उपयोग कुछ राय डालने के लिए भी करता हूं जो मेरे पास थीं जिन्हें मैं देखना चाहता था जो अगली चर्चा में ले जाती हैं…

व्यवसाय में काम करने के बजाय व्यवसाय पर काम करने के लिए दिनचर्या से एक जानबूझकर ब्रेक के रूप में ऑफसाइट उपयोगी होते हैं। यह एक अवधारणा है जिसे मैंने रिचर्ड गेरबर की ई-मिथ रीविज़िटेड पुस्तक से उठाया है, जिसे मैंने पढ़ा नहीं है, लेकिन मैंने कई लोगों को इसके बारे में बात करते हुए सुना है और मुझे लगता है कि मैंने इसे पढ़ा है। तो यह स्पष्ट रूप से इस बारे में एक बैठक है कि हम कैसे काम करते हैं और हम आगे कैसे काम करना जारी रखना चाहते हैं।

पहली बार के संस्थापक के रूप में, मुझे यह बहुत ताज़ा लगा कि जिस तरह की कंपनी में मैं हमेशा काम करना चाहता था उसे बनाने के लिए और उन सिद्धांतों को सार्वजनिक रूप से व्यक्त करने के लिए यह सबसे अधिक उत्तोलन वाली बैठक थी, जिनमें मैं सबसे दृढ़ता से विश्वास करता हूं ताकि समग्र सफलता की आदतें बनाने के लिए इसके लिए जवाबदेह हो सकूं। दूसरे शब्दों में, मैं जिस प्रकार की कार्य संस्कृति में विश्वास करता हूं, उसे अस्तित्व में लाने के बारे में बोल सकता हूं और हम या तो अपनी असहमति व्यक्त कर सकते हैं या अधिकतर इसके साथ चल सकते हैं।

सिद्धांतों के मिलन के दो प्राथमिक प्रभाव संभवतः सिद्धांतों पर अमेज़ॅन लीडरशिप प्रिंसिपल्स रे डेलियो की पुस्तक हैं। रे का शीर्ष सिद्धांत यह है कि “दर्द + प्रतिबिंब = प्रगति”। अमेज़ॅन में, 14 नेतृत्व सिद्धांत हैं जो जेफ बेजोस द्वारा विकसित विभिन्न मजबूत राय को परिभाषित करते हैं। मुझे लगता है कि इसका एक मूल्य है सिद्धांतों की कंजूसी – इसलिए हमें सिद्धांतों में प्रत्येक शब्द को महत्व देने की आवश्यकता है क्योंकि तब उनका महत्व होता है। यदि बहुत सारे सिद्धांत हैं, तो हम उन्हें याद नहीं रख सकते और उनका पालन न करने का बहाना बनाना बहुत आसान है। हम 5 सिद्धांतों के साथ आए, जो शायद एक या दो बहुत अधिक हैं क्योंकि कंपनी में मौजूद लोगों की संख्या से अधिक लोग हैं। निःसंदेह, सबसे कठिन काम उचित परिवर्धन को न कहना है।

एक मूल, अस्थिर सिद्धांतों पर बहस

वर्तमान में, एआई में मेरा विश्वास करने वाला सबसे मजबूत सिद्धांत यह है कि “उत्पाद लीड प्रोसेस लीड प्लेटफ़ॉर्म“। दूसरे शब्दों में, हम पहले सिद्धांतों से तर्क करेंगे कि हमारे ग्राहक के लिए सबसे अच्छा उत्पाद क्या है और सर्वोत्तम उत्पाद को संभव बनाने के लिए जो कुछ भी करना होगा वह करेंगे – चाहे वह सॉफ्टवेयर या मानव श्रम का मिश्रण हो। फिर हम मानव श्रम को एक प्रक्रिया में व्यवस्थित करेंगे और जहां तक ​​संभव हो, अंत में, हम उन प्रक्रियाओं को सॉफ्टवेयर में व्यक्त/एनकोड/सामान्यीकृत करने का प्रयास करेंगे।

यह कुछ अन्य स्टार्टअप्स के बिल्कुल विपरीत है, जिन्हें मैंने पहले प्लेटफॉर्म पर रखते हुए देखा है। उदाहरण के लिए, एक ओपन सोर्स उत्पाद बनाना जो सब कुछ कर सकता है या क्लाउड उत्पाद बनाना जो सब कुछ कर सकता है और फिर ग्राहकों की खोज करना और मामलों का उपयोग करना।

मेरी सामान्य समझ यह है कि एआई में सबसे सफल नेताओं ने एक ऐसा उत्पाद बनाया है जो एक जादुई या सीमांत अनुभव को समाहित करता है, और लोग वास्तव में हुड के तहत एपीआई तक पहुंच के बारे में परवाह नहीं करते हैं। वे केवल अंतिम परिणाम की परवाह करना चाहते हैं।

यदि भविष्य में आप ओपन सोर्स उत्पाद या एपीआई प्लेटफॉर्म पेश करते हैं जो आपके अनुभव को सशक्त बनाते हैं, तो उपयोगकर्ता उत्पाद की ब्रांडिंग से प्रभावित होकर आपके प्लेटफॉर्म को उसी तरह अपनाने के लिए प्रेरित होंगे जैसे Amazon.com बाद में लॉन्च होने पर Amazon वेब सेवाओं पर अपनी छाप देने में सक्षम था। बेशक, इस नियम के अपवाद होंगे। दोनों इस अर्थ में कि जो लोग कैरेक्टर एआई जैसे उत्पादों को प्राथमिकता देते हैं, भले ही वे अग्रणी उत्पाद हों, जरूरी नहीं कि वे जीतें और अपने उत्पादों या अपने प्लेटफॉर्म से सफलतापूर्वक मुद्रीकरण करने का प्रबंधन नहीं करते हैं। साथ ही ऐसे प्लेटफ़ॉर्म जो बिना किसी कट्टर विरोधी उत्पाद के अपेक्षाकृत सफल हो जाते हैं- जैसे टुगेदर एआई, ब्रेनट्रस्ट और फायरवर्क्स।

मुझे चिंता है कि ग्राहक पहले के बजाय उत्पादों को पहले रखने से हमें ग्राहक-केंद्रित के बजाय उत्पाद-केंद्रित होने का मौका मिलता है। और यह मौजूदा सिद्धांत की एक खामी है जिसे मैंने कंपनी के लिए पहचाना है।

एक सरल सिद्धांत

मैंने जो आसान सिद्धांत प्रस्तावित किया उस पर कुछ बहस हुई लेकिन अंततः स्वीकार कर लिया गया कि हम ऐसा करेंगे हर दिन जहाज कोड. यह सैद्धांतिक/व्यावसायिक रणनीति के बजाय एक व्यवहारिक सिद्धांत है, लेकिन गति के मामले में मुझे यह पसंद है।

यहां प्रेरक कहानी यह है कि नेट फ्राइडमैन ने गिटहब सीईओ के रूप में पदभार कैसे संभाला क्योंकि अधिकांश नए सीईओ आगे बढ़ने से पहले अपने वरिष्ठ प्रबंधन के साथ 3-6 महीने के श्रवण दौरे पर जाते हैं। इसके बजाय, नेट ने कहा, “हम अगले 100 दिनों में 100 चीजें भेजेंगे और बाधाओं का पता लगाएंगे” – या ऐसा करके सीखेंगे कि कंपनी कैसे काम करती है।

जाहिर है, एक छोटी कंपनी में, यह एक कम विवादास्पद बयान है, लेकिन मुझे लगता है कि कोड के करीब होने के साथ-साथ उत्पादों के करीब होने की प्रतिबद्धता ने हमें तेजी से आगे बढ़ने में मदद की। स्टार्टअप्स में, स्टार्टअप होने का मतलब तेजी से आगे बढ़ना और नई प्रौद्योगिकियों और ग्राहकों की मांगों पर तेजी से प्रतिक्रिया देना है।

यह सिद्धांत सीधे तौर पर हमारी टाइम ब्लॉक योजना में व्यक्त हुआ, जिसका उल्लेख हमने इस पोस्ट की शुरुआत में किया था। हमने ऑफसाइट के हर दिन कोड करने के लिए जगह छोड़ी, इस चिंता को संबोधित करते हुए कि जब हम यह मेटा कार्य कर रहे थे तो काम रुक जाएगा।

फिर, यह एक ऐसी बैठक है जो संभवतः किसी एसएमओएल कंपनी में सबसे उपयोगी है। इस बैठक का लक्ष्य सबसे अधिक जानकार व्यक्ति को पूरे सिस्टम को चलाने, अनुमतियाँ और एडमिन लॉगिन प्राप्त करने और सिस्टम प्रशासन से परिचित कराने के माध्यम से सभी को मार्गदर्शन कराना है। इस तरह, अगर हममें से कोई छुट्टी पर हो, तो कोई भी वहीं से शुरू कर सकता है जहां हमने छोड़ा था। यदि कोई अन्य व्यक्ति अनुपलब्ध था, तो कोई अन्य व्यक्ति सिस्टम को वापस लाने में सक्षम होगा, भले ही इसमें अधिक समय लगे।

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

नियमित कार्य के दौरान, बहुत सारे विचार सामने आते हैं कि क्या करना है और क्या किया जा सकता है – मुख्य उत्पाद के दृष्टिकोण से और साथ ही उत्पाद विस्तार या अन्य प्रयोगों से जो हम करना चाहते हैं। यह बैठक लोगों को विचार-मंथन करने और रचनात्मक रस लाने के लिए जगह प्रदान करती है, लेकिन दुर्भाग्य से विचलन से अभिसरण पर स्विच करना बहुत मुश्किल है।

मैं प्राथमिकता निर्धारण के लिए एक अलग बैठक स्थापित करने की अनुशंसा करता हूं, जो हमने ऑफसाइट के अंत में की थी जहां हम जुटे थे।

अंततः, प्राथमिकता देने का कार्य संस्थापकों/सीईओ/उत्पाद प्रबंधकों का काम है, इसलिए यह पूरी तरह से एक लोकतांत्रिक अभ्यास नहीं है। यह सोचना उपयोगी है कि हम जो करना चाहते हैं उसे एक बोर्ड पर रखें और स्वीकार करें कि उन सभी को करने के लिए कभी भी पर्याप्त समय नहीं होगा, इसलिए, कुछ कठोर निर्णय लेने होंगे।

रैखिक और जेआईआरए-शैली रेटिंग सहित कई प्राथमिकता निर्धारण स्कीमों में मुझे जो चुनौती मिलती है, वह यह है कि वे इस तथ्य पर ध्यान नहीं देते हैं कि प्राथमिकताएं समय के साथ बदल सकती हैं। जब छोटे आसान चरणों के साथ जानकारी प्राप्त करने की बात आती है तो रेटिंग सिस्टम या आइजनहावर मैट्रिक्स स्टाइल रेटिंग सिस्टम में प्रयोग के मूल्य और युद्ध के कोहरे को शामिल नहीं किया जाता है। मैंने अनुरोध किया कि हमारे पास विचार की सहजता और विचार की क्षमता के आधार पर 2-संख्या रेटिंग प्रणाली है, रेटिंग 1 से 10 तक। फिर हम रेटिंग की सीमाओं पर सीमाएं बनाने का प्रयास करेंगे (यानी, 1 का क्या मतलब है और आसान पैमाने पर 10 का क्या मतलब है) और संभावित पैमाने पर 1 का क्या मतलब है और 10 का क्या मतलब है, इस पर सीमाएं बनाने की कोशिश करेंगे।

फिर हम इसका उपयोग उन विचारों की बिंदु प्रणाली रैंकिंग के लिए अंकों को गुणा करने या जोड़ने के लिए करेंगे जिन्हें हम आगे बढ़ाना चाहते थे। हम आसान पैमाने के आदी नहीं हैं…

हर किसी को आसान पैमाने के साथ सबसे अधिक संघर्ष करना पड़ा क्योंकि हमने ‘ई’ की व्याख्या प्रयास के रूप में की थी, लेकिन हम बेहतर चीजों का प्रतिनिधित्व करने के लिए उच्च संख्याएं चाहते थे, साथ ही इस तथ्य को स्वीकार करते हुए कि हम केवल कम लटकने वाले फलों को नहीं चुनते हैं। हम कम-लटकाने वाले फलों का एक मिश्रण चुनना चाहते हैं जिनसे अच्छा लाभ मिलने की उम्मीद है और कठिन चीजें जिनसे लंबी अवधि में लाभ मिलने की उम्मीद है।

अधिकांश लोग क्रिंग टीम निर्माण गतिविधियों से थक गए हैं। सच कहूँ तो, हमने एक साथ भोजन करने और ब्लूबेरी हिल का दौरा करने के अलावा सामाजिक गतिविधियों के मामले में कुछ भी नहीं किया, मैं हर किसी को सेंट लुइस में जाने की सलाह देता हूँ। मुझे लगता है कि यह ठीक है, लेकिन मैं निश्चित रूप से हमारी जैसी छोटी टीमों के लिए बेहतर सामाजिक विचारों के लिए तैयार हूं।