तकनीकी फाउंडर का काम कैसे कोड लिखने से बेहतर निर्णय लेने की ओर बदलता है: बेट प्राथमिककरण, प्रोडक्ट समझ बनाना, और टीम‑अलाइनमेंट जैसे कौशल जो कंपनी के बढ़ते पैमाने पर प्रभाव डालते हैं।
शुरू में, तकनीकी फाउंडर की नौकरी अक्सर ऐसा लगती है: “सब कुछ बनाओ।” आप कोड का बड़ा हिस्सा लिखते हैं, मिनटों में फिक्स शिप कर देते हैं, और एडिटर खोलकर फैसले लेते हैं। यह चरण असली और मूल्यवान है—क्योंकि स्पीड और तकनीकी सामंजस्य पोलिश से ज़्यादा मायने रखते हैं। अगर आप बना सकते हैं, तो आप सीख सकते हैं।
लेकिन जब कंपनी काम करने लगती है (ज़्यादा यूज़र्स, ज़्यादा राजस्व, ज़्यादा अपेक्षाएँ), तो नौकरी धीरे-धीरे बदल जाती है—भले ही आपकी टाइटल न बदले। आप अब “क्या हम यह बना सकते हैं?” के लिए ऑप्टिमाइज़ नहीं कर रहे होते। आप “क्या हमें यह बनाना चाहिए, और इसके लिए हम क्या त्याग करते हैं?” के लिए ऑप्टिमाइज़ करते हैं। काम व्यक्तिगत रूप से फीचर प्रोड्यूस करने से कम और सिस्टम—प्रोडक्ट, टीम, और प्रोसेस—को आकार देने पर ज़्यादा हो जाता है ताकि सही फीचर बनें।
बिल्ड फेज़ में प्रोग्रेस ज्यादातर रैखिक होती है: अधिक घंटे कोड करने का मतलब अक्सर ज्यादा शिप्ड प्रोडक्ट। कम्युनिकेशन हल्का होता है, और फैसले रिवर्सिबल होते हैं क्योंकि सरफेस एरिया छोटा है।
स्केलिंग फेज़ में, प्रोग्रेस नॉन‑लिनियर हो जाती है। हर नया फीचर मौजूदा ग्राहकों, सपोर्ट लोड, सेल्स के वादों, इन्फ्रा‑लिमिट्स, और अन्य इंजीनियरों के काम के साथ इंटरैक्ट करता है। “बस शिप कर दो” छिपी लागतें पैदा करने लगता है: ज़्यादा बग्स, धीमा ऑनबोर्डिंग, कठिन डिप्लॉयमेंट्स, और एक ऐसा बैकलॉग जो आपकी पेडाउन क्षमता से तेज़ी से बढ़ता है।
आपका लीवरेज बदलता है। सबसे हाई‑इम्पैक्ट चीज़ शायद अब “अगला मॉड्यूल लिखना” नहीं है। यह तय करना है कि टीम को आगे क्या बनाना चाहिए, मानक निर्धारित करना (कहाँ क्वालिटी गैर‑समझौता है बनाम कहाँ स्पीड ठीक है), और स्पष्टता बनाना ताकि दूसरे बार‑बार सुधार के बिना निष्पादित कर सकें।
इसका मतलब है अधूरी जानकारी के साथ ज़्यादा फैसले लेना भी। आपके पास हर विकल्प की पूरी रिसर्च करने का समय नहीं होगा। निश्चितता का इंतजार खुद एक निर्णय बन जाता है—और अक्सर गलत निर्णय।
जैसे-जैसे आप स्केल करते हैं, “ज़्यादा कोड” के स्थान पर तीन कौशल आपके मुख्य उपकरण बन जाते हैं:
जैसे-जैसे ये मजबूत होते हैं, आपका आउटपुट कोड की लाइनों से बेहतर निर्णयों में बदल जाता है—ऐसे निर्णय जो पूरे कंपनी पर कंपाउंड करते हैं।
शुरू में, एक तकनीकी फाउंडर के रूप में आपकी बढ़त स्पष्ट होती है: आप बना सकते हैं। कंपनी तब आगे बढ़ती है क्योंकि आप व्यक्तिगत रूप से आइडियाज़ को वर्किंग सॉफ्टवेयर में बदलते हैं।
जब आपके पास असली यूज़र्स और बढ़ती टीम होती है, तो बोटलनेक अब यह नहीं रहता “क्या हम इसे इम्प्लीमेंट कर सकते हैं?” बल्कि यह रहता है “क्या हमें इसे अब, इस तरह इम्प्लीमेंट करना चाहिए?” यह शिफ्ट मूलतः आउटपुट से जजमेंट की ओर होती है।
जजमेंट अनिश्चितता में उच्च‑गुणवत्ता फैसले लेने की क्षमता है।
न कि परफेक्ट निर्णय। न कि स्प्रेडशीट‑समर्थ निर्णय जो रिस्क को मिटा दे। उच्च‑गुणवत्ता निर्णय वे हैं जो उपलब्ध जानकारी के आधार पर मामूली और तार्किक हों—और जब जानकारी बदले तो कंपनी को लचीला रखें।
टेक्निकल करेक्टनेस का जवाब देता है: “क्या यह सबसे साफ़ डिज़ाइन है? क्या यह स्केलेबल है? क्या यह एलेगेंट है?”
बिजनेस करेक्टनेस का जवाब देता है: “क्या यह इस क्वार्टर में कंपनी को आगे बढ़ाता है? क्या यह सही यूज़र्स की मदद करता है? क्या यह सीखने की स्पीड, राजस्व, रिटेंशन, या ट्रस्ट बढ़ाता है?”
एक तकनीकी रूप से सही निर्णय अभी भी बिजनेस‑गलत हो सकता है। उदाहरण के लिए: दो हफ्ते आर्किटेक्चर पर निवेश करना इंजीनियरिंग के लिहाज़ से “सही” हो सकता है पर अगर इससे फीचर देर हो जाता है जो डील क्लोज करता है या चर्न घटाता है, तो वह बिजनेस‑गलत होगा।
जैसे‑जैसे आप निर्णयकर्ता बनते हैं, आप तात्कालिक परिणाम के परे देखने लगते हैं। एक चुनाव प्रभावित करता है:
रीवर्सिबिलिटी: पूछें “अगर हम गलत हैं, तो उसे वापस करना कितना मुश्किल है?” वापस करने योग्य निर्णय छोटे बेट्स के साथ तेज़ी से किए जा सकते हैं। अपरिवर्तनीय निर्णयों के लिए अधिक बहस, प्रोटोटाइप, या स्टेज्ड रोलआउट चाहिए।
डिले की लागत: पूछें “इंतज़ार करने से क्या खो जाएगा?” कभी‑कभी सबसे बड़ी लागत पैसे नहीं होती—यह मिस्ड लर्निंग, प्रतियोगी बढ़त, या टीम के गलत चीज़ बनाने के हफ्ते होते हैं।
फाउंडर विकास इन लेंसों को लगातार लागू करना सीखना है, ताकि कंपनी कम हीरोइक स्प्रिंट करे—और ज़्यादा जानबूझकर, कंपाउंडिंग मूव करे।
शुरू में, “अच्छा इंजीनियरिंग” अक्सर “अच्छी कंपनी” के बराबर होता है। साफ़ कोड, ठोस आर्किटेक्चर, और पॉलिश्ड इन्फ्रास्ट्रक्चर आपको कल तेज़ चलने में मदद करते हैं।
जब आपके पास यूज़र्स, डेडलाइन, और सीमित रनवे होता है, तो यह संरेखण टूट सकता है। कोई चयन तकनीकी रूप से सही होकर भी बिजनेस के लिए गलत बन सकता है।
तकनीकी फाउंडर अक्सर उस काम की ओर झुकते हैं जो सुरक्षित और संतोषजनक लगता है: एलेगेंट सॉल्यूशन, परफेक्ट अब्स्ट्रैक्शन, वह टूल जिसे आप प्रयोग करना चाहते थे।
यह आलस्य नहीं है—यह एक बायस है। रोचक टेक तात्कालिक फीडबैक और प्रोग्रेस की अनुभूति देता है, जबकि गंदे ग्राहक‑समस्याएँ अस्पष्ट और भावनात्मक रूप से कठिन होती हैं।
एक लोकल ऑप्टिमाइज़ेशन सिस्टम के एक हिस्से (कोड क्वालिटी, टेस्ट कवरेज, लेटेंसी, आंतरिक टूलिंग) को बेहतर बनाता है। एक ग्लोबल आउटकम वह है जो कंपनी उस उद्देश्य को बेहतर बनाता है जिसके लिए वह काम कर रही है (रिटेंशन, राजस्व, एक्टिवेशन, कम सपोर्ट टिकट, तेज़ सेल्स सायकल)।
फँसना यह है कि “हमने सिस्टम बेहतर किया” को “हमने कंपनी बेहतर की” समझ लेना। अगर सुधार ग्राहक अनुभव या टीम की अगली महीने शिपिंग क्षमता को नहीं बदले, तो अभी शायद इसका महत्व कम है।
अवसर लागत वह है जो आप किसी चीज़ को चुनकर खो देते हैं। यह ठोस है:
आप अवसर लागत बाद में नहीं चुकाते—आप उसे तुरंत चुकाते हैं, मिस्ड लर्निंग और मिस्ड मोमेंटम के रूप में।
रिफैक्टर बनाम शिप: रिफैक्टर भविष्य का दर्द दूर कर सकता है, पर एक छोटा “अच्छा‑काफ़ी” सुधार शिप करना प्राइसिंग वेलिडेट कर सकता है, सेल्स को अनब्लॉक कर सकता है, या असली कॉन्स्ट्रेंट्स को उजागर कर सकता है।
इन्फ्रा अपग्रेड बनाम ग्राहक जीत: 50ms घटाना मापनयोग्य लगता है, पर कोई स्पष्ट वर्कफ़्लो या मुख्य पाथ में कम बग्स रिटेंशन के लिए कहीं ज़्यादा प्रभावी हो सकते हैं।
मकसद इंजीनियरिंग उत्कृष्टता को अनदेखा करना नहीं है। बल्कि इसे सही समय पर लागू करना है। महान फाउंडर यह पूछना सीखते हैं: “कंपनी को अगले क्या चाहिए—और अगर हम सही हैं तो सीखने का सबसे सस्ता तरीका क्या है?”
बैकलॉग आरामदेह लगता है क्योंकि यह “अच्छे विचारों” की सूची है। रणनीति कठिन है: यह आपको चुनने पर मजबूर करती है कि क्या नहीं करना है।
प्राथमिककरण परफेक्ट रैंकिंग खोजने के बारे में नहीं है; यह उस बारे में है कि कैसे कुछ चुनींदा बेट्स कंपनी के मौजूदा लक्ष्य से मेल खाते हैं।
जब केवल आप होते हैं, विकल्प ज्यादातर वही होते हैं जो आप अगला बना सकते हैं। जैसे‑जैसे टीम बढ़ती है, विकल्पों की संख्या बढ़ जाती है:
परिणाम: बैकलॉग कतार नहीं बल्कि जंक ड्रॉअर बन जाता है। बिना रणनीति के आप सबसे ज़ोरदार अनुरोध, सबसे रोचक तकनीकी प्रोजेक्ट, या जो सबसे आसानी से एस्टिमेट होता है उसे चुन लेंगे।
आपको जटिल स्कोरिंग स्प्रेडशीट की ज़रूरत नहीं है। दो सरल फ्रेम अक्सर काफी होते हैं:
इम्पैक्ट बनाम प्रयास। आइटमों को चार बक्सों में डालें: हाई‑इम्पैक्ट/लो‑एफ़र्ट (करें), हाई‑इम्पैक्ट/हाई‑एफ़र्ट (प्लान), लो‑इम्पैक्ट/लो‑एफ़र्ट (सिर्फ़ अगर कुछ अनब्लॉक करता है), लो‑इम्पैक्ट/हाई‑एफ़र्ट (ना करें)।
रिस्क बनाम रिवॉर्ड। कुछ काम तुरंत इम्पैक्ट के लिए नहीं बल्कि डाउनसाइड घटाने के लिए होते हैं (सिक्योरिटी, रिलायबिलिटी, कंप्लायंस)। स्पष्ट रूप से लेबल करें: “यह बीमा है,” और तय करें कि आप इस क्वार्टर कितना बीमा कर सकते हैं।
कुंजी है ट्रेडऑफ़्स को दिखाई देना। अगर आप यह नहीं बता सकते कि आप क्या छोड़ रहे हैं, तो आपने वास्तव में प्राथमिकता नहीं बनाई।
तकनीकी फाउंडरों के लिए एक उपयोगी नियम: अगले साइकिल के लिए एक शीर्ष लक्ष्य चुनें (उदा., एक्टिवेशन, रिटेंशन, सेल्स सायकल टाइम), फिर दो से चार शीर्ष बेट्स चुनें जो सीधे उसे आगे बढ़ाएँ।
बाकी या तो सहयोगी काम है (मस्ट‑डू) या पार्क किया गया। बैकलॉग रणनीति बन जाता है जब आप यह कह सकें: “ये वो बेट्स हैं जो हम बना रहे हैं—और ये चीज़ें हम जानबूझकर नहीं कर रहे हैं।”
“उत्पाद समझ” जरूरी नहीं कि मतलब हो स्टिकी नोट्स, फ्रेमवर्क्स, या PM की तरह बोलना। तकनीकी फाउंडर के लिए यह बस इस बात की क्षमता है कि वे समझें यूज़र कौन है, वह क्या हासिल करना चाहते हैं, और क्या आपका प्रोडक्ट वास्तव में मदद करता है—मापनीय तरीकों से।
एक उपयोगी परिभाषा: उत्पाद समझ उस आदत का नाम है जो काम को किसी मायनेखेत परिणाम से जोड़ती है।
अगर आप इम्प्लीमेंटेशन का ज़िक्र किए बिना एक वाक्य में वैल्यू नहीं बता सकते, तो आप अभी भी बिल्डर की तरह सोच रहे हैं।
शुरू में, फीचर बनाना प्रगति जैसा लगता है क्योंकि कोड शिप होता है और डेमो रोमांचक होते हैं। पर असली उपयोग आने पर, नौकरी बन जाती है यह चुनना कि कौन‑सी समस्याएँ हल करने लायक हैं—और सफलता को रिलीज नोट्स नहीं, परिणामों से आँकना।
“CSV एक्सपोर्ट जोड़ो” जैसा फीचर रिक्वेस्ट अक्सर एक लक्षण होता है। मूल समस्या हो सकती है “मेरी टीम वित्त के साथ परिणाम साझा नहीं कर सकती,” या “मैं डेटा पर भरोसा नहीं करता जब तक मैं उसे ऑडिट न कर सकूँ।” असली समस्या का हल CSV हो सकता है—या शेड्यूल्ड रिपोर्ट, API एंडपॉइंट, या डेटा क्वालिटी सुधार।
आपको जटिल एनालिटिक्स की ज़रूरत नहीं है। इन पर नजर रखें:
ये सिग्नल बताते हैं क्या मूल्यवान है, क्या अस्पष्ट है, और क्या गायब है।
आपका तकनीकी अन्तरजान आपको फायदे देता है: आप फ़िजिबिलिटी ट्रैप को पकड़ सकते हैं, आर्किटेक्चर सरल कर सकते हैं, और तेज़ प्रोटोटाइप कर सकते हैं। पर यह आपको एलेजेंस पर इम्पैक्ट को प्राथमिकता देने के लिए गुमराह कर सकता है—परफेक्ट अब्स्ट्रैक्शन्स, सामान्यीकृत सिस्टम, या “बाद में हमें इसकी ज़रूरत पड़ेगी” वाला इन्फ्रा।
प्रोडक्ट समझ इसका प्रतिशोध है: अभी वह बनाइए जो उपयोगकर्ता के परिणाम को बदलता है, और वास्तविकता—न कि अनुमान—यह निर्णय करे कि पहली बार इंजीनियरिंग उत्कृष्टता कहाँ चाहिए।
शुरू में, एक तकनीकी फाउंडर “अच्छे विचारों” को हाँ कहकर और कोड पुश करके उत्पादक महसूस कर सकता है। जैसे‑जैसे कंपनी बढ़ती है, काम पलटता है: आपकी मुख्य वैल्यू वह है जो उन सीमाओं का चुनाव करती है जो सबको फोकस में रखती हैं। सीमाएँ ऐसे गार्डरेइल हैं जो आपको तीन आधा‑बने उत्पाद बनाने से रोकते हैं।
शुरू करें 2–4 कंस्ट्रेंट्स सेट करके जो अगले पीरियड के हर निर्णय को आकार दें। उदाहरण:
फिर 1–2 लक्ष्य परिभाषित करें जिन्हें एक वाक्य में दोहराया जा सके। अगर आपकी टीम उन्हें दोहरा नहीं सकती, तो आप बहुत ज़्यादा ले रहे हैं।
विजन “क्यों” है। निष्पादन को “क्या कब” और “हमें कैसे पता चलेगा” चाहिए। एक सरल पैटर्न:
उदा.: “टाइम‑टू‑फर्स्ट‑वैल्यू 20 मिनट से 5 मिनट करें” साथ में “नया यूज़र पर सपोर्ट टिकट नहीं बढ़ना चाहिए।” इससे ट्रेडऑफ़्स चर्चा‑योग्य बनते हैं, व्यक्तिगत नहीं।
फाउंडर के रूप में आपको सीधे तय करना चाहिए:
सौंपीये:
अगर आप अभी भी हर एंडपॉइंट नाम पर बहस कर रहे हैं, तो आप अपनी टीम से लीवरेज छीन रहे हैं।
यह कैडेंस दबाव को स्पष्टता में बदल देता है—और ट्रेडऑफ़्स को इमरजेंसी बनने से पहले स्पष्ट कर देता है।
प्रारंभिक‑स्टेज टीमें तेज़ सीखकर जीतती हैं। इसलिए अक्सर “अच्छा‑काफ़ी” “परफेक्ट” से बेहतर होता है: ग्राहकों के हाथ में एक ठोस, प्रयोज्य वर्ज़न फ़ीडबैक, राजस्व और स्पष्टता पैदा करता है। परफेक्शन, जबकि, एक महंगा अनुमान हो सकता है—खासकर जब आप अभी यह वेलिडेट कर रहे हों कि यूज़र कौन है और वे क्या भुगतान करेंगे।
इसका मतलब यह नहीं कि क्वालिटी मायने नहीं रखती। इसका मतलब है कि क्वालिटी को चयनात्मक रूप से लगाया जाना चाहिए।
कुछ क्षेत्र हैं जहाँ फेलियर अपरिवर्तनीय नुकसान कर सकता है। इन्हें “बोरिंग होना चाहिए” के रूप में ट्रीट करें:
अगर इनमें से कुछ भी टूटता है, आप सिर्फ़ बग नहीं भेज रहे—आप भरोसा भेज रहे हैं।
गार्डरेल्स आपको बार‑बार बहस किए बिना तेज़ी से शिप करने देते हैं:
ये नौकरशाही नहीं हैं; ये शॉर्टकट हैं जो बार‑बार की बहस रोकते हैं।
स्पीड का मतलब गंदा काम नहीं होना चाहिए—बल्कि वापस करने योग्य निर्णय होना चाहिए।
उदाहरण:
एक उपयोगी नियम: किसी भी चीज़ पर कट‑कॉर्नर्स तब करें जिसे आप एक हफ्ते में बदल सकें—न कि ऐसी चीज़ पर जो एक दिन में कंपनी डूबा सकती हो।
यदि आप “छोटे बेट → सीखना → इटरेट” लूप को और भी तेज़ करना चाहते हैं, तो ऐसे टूल मदद कर सकते हैं जो त्वरित प्रोटोटाइपिंग और आसान रोलबैक सपोर्ट करें। उदाहरण के लिए, Koder.ai का प्लानिंग मोड और स्नैपशॉट/रोलबैक वर्कफ़्लो एक्सपेरिमेंट्स को सुरक्षित रूप से शिप करने के लिए डिज़ाइन किए गए हैं—खासकर जब आप नॉन‑क्रिटिकल एरिया में स्पीड और कोर पाथ्स में क्वालिटी दोनों को संभाल रहे हों।
एक तकनीकी फाउंडर के लिए सबसे तेज़ तरीका रनवे खत्म होने का पैसा नहीं—ये ध्यान है। आपकी नई लीवरेज आती है अच्छी हायरिंग, लगातार कोचिंग, और सिद्धांत सेट करने से जो टीम को आपके बिना भी अच्छे निर्णय लेने दें।
हेडकाउंट बढ़ने पर “सबसे अच्छा बिल्डर होना” मल्टीप्लायर रहना बंद कर देता है। आपका मल्टीप्लायर बनता है स्पष्टता: कुछ दोहराए जाने योग्य नियम जो दर्जनों छोटे फैसलों का मार्गदर्शन करते हैं।
स्केल करने वाले सिद्धांतों के उदाहरण:
ये सिद्धांत रिवर्क को कम करते हैं और बिना आपकी हर PR देखने के क्वालिटी बनाए रखते हैं।
बॉटलनेक्स तब बनते हैं जब एक व्यक्ति (अक्सर आप) ही “हाँ” कहने वाला एकमात्र व्यक्ति होता है। इसके बजाय, कंस्ट्रेंट्स के साथ ओनरशिप के लिए डिजाइन करें:
लक्ष्य सहमति नहीं है; यह तेज़, स्पष्ट निर्णय है जो काम के पास किए जाते हैं।
लेयर में डेलिगेट करें:
एक उपयोगी टेस्ट: अगर गलत कॉल की लागत ज़्यादातर रीवर्क है, तो उसे डेलिगेट करें। अगर यह भरोसा, राजस्व, या रणनीति को जोखिम में डालता है, तो करीब रहें।
1:1s का उपयोग स्टेटस‑चेक के बजाय निर्णय गुणवत्ता को तेज़ करने के लिए करें:
जैसे-जैसे आपकी टीम जजमेंट में बेहतर होती है, आपको वापस वही दुर्लभ संसाधन मिलता है जिसे आप खरीद नहीं सकते: आपका फोकस।
तकनीकी फाउंडर अक्सर शुरुआत जैसी ही “विजयी” बनते रहते हैं: तेज़ बनाते हुए, ज़्यादा सोचते हुए, और धक्का देते हुए। नीचे जिन जालों का विवरण है, वे तब होते हैं जब वही प्रवृत्ति कंपनी की ज़रूरतों से मेल नहीं खाती।
कमज़ोर प्रोडक्ट समझ का क्लासिक संकेत लगातार आउटपुट पर असंगत परिणाम होना है: रिलीज़ महत्वपूर्ण तरीके से एक्टिवेशन, रिटेंशन, राजस्व, या सपोर्ट लोड नहीं बदलती।
कैसे पहचानें: आप पिछली शिपिंग से क्या सीखने की उम्मीद रखते थे बता नहीं सकते, या सफलता को “यह शिप हुआ” के रूप में मापते हैं बजाय “इसने X मूव किया।”
सुधार: फीडबैक लूप तंग करें। हर रिलीज़ को एक प्रश्न का उत्तर बनाइए (“अगर हम X जोड़ें तो क्या टीमें सहकर्मियों को आमंत्रित करेंगी?”)। छोटे बेट्स को प्राथमिकता दें जिन्हें आप दिनों में मूल्यांकन कर सकें, महीनों में नहीं।
यह भविष्य की ऑर्ग के लिए सिस्टम बनाना दिखता है: माईक्रोसर्विसेस, जटिल अब्स्ट्रैक्शन्स, भारी प्रोसेस, या “एंटरप्राइज़‑ग्रेड” सब कुछ—उससे पहले कि आपके पास स्थिर उपयोग पैटर्न हों।
कैसे पहचानें: आपकी आर्किटेक्चर निर्णय काल्पनिक स्केल से प्रेरित हैं, जबकि आज की बाधा असल में अस्पष्ट प्रोडक्ट दिशा या कम मांग है।
सुधार: हर एरिया के लिए “अच्छा‑काफ़ी” मानक सेट करें। कोर पाथ्स को विश्वसनीय रखें, पर अन्य जगहों पर सरल समाधान स्वीकार करें। स्केलिंग का काम तब ही दोबारा देखें जब कोई असली बाधा बार‑बार दिखे।
बार‑बार प्राथमिकता बदलना चालाकी जैसा लग सकता है, पर अक्सर यह रणनीति की कमी का संकेत देता है। टीमें योजनाओं पर भरोसा करना बंद कर देती हैं और अगली पिवट का इंतजार करती हैं।
कैसे पहचानें: कई आधे‑बने प्रोजेक्ट, बार‑बार कॉन्टेक्स्ट स्विचिंग, और “अर्जेंट” काम जो किसी लक्ष्य से जुड़ा नहीं है।
सुधार: बेट को संकुचित करें। एक निश्चित विंडो (उदा., 4–6 सप्ताह) के लिए नतीजों से कमिट करें, और नए विचारों को इनपुट मानें, इंटरप्ट नहीं।
जब हर मायने रखता फैसला फाउंडर के पास रूट होता है, तो कंपनी के बढ़ने के साथ स्पीड घटती है।
कैसे पहचानें: लोग मंजूरी माँगते हैं बजाय फैसले करने के, मीटिंग्स बढ़ जाती हैं, और जब आप उपलब्ध नहीं होते तो काम रुका रहता है।
सुधार: केवल टास्क ही नहीं, निर्णय डेलिगेट करें। सरल निर्णय नियम (क्या अच्छा दिखता है, ट्रेडऑफ्स, सीमाएँ) लिखें, फिर दूसरों को निष्पादित करने दें और परिणामों की समीक्षा करें—हर स्टेप को अप्रूव न करें।
बेहतर जजमेंट व्यक्तित्व‑गुण नहीं है—यह दोहराए जाने योग्य आदतों का सेट है जो आपको सिग्नल नोटिस करने, अनावश्यक गलतियों को कम करने, और ऐसे निर्णय लेने में मदद करती है जो कंपनी बदलने पर भी अच्छे रहें।
इसे हर हफ्ते एक ही समय पर चलाएँ। इसे छोटा, लिखित, और अपने कोफाउंडर या लीड्स के साथ साझा रखें।
समीक्षा को समाप्त करें एक बेट नामित कर के जो आप अगले हफ्ते लगा रहे हैं और कैसे पता चलेगा कि यह काम कर रहा है।
ज्यादातर फाउंडर नतीजों को याद रखते हैं पर अनुमान भूल जाते हैं। एक निर्णय लॉग “अच्छी/खराब किस्मत” को सीखने में बदल देता है।
Decision:
Date:
Owner:
Context (what’s happening):
Options considered (and why not):
Rationale (why this is the best bet now):
Data used (links/notes):
Risks + mitigations:
Success metric (what changes if it works?):
Follow-up date (when we’ll review):
Result + what we learned:
हर महीने 2–3 पिछले निर्णयों की समीक्षा करें। आप पैटर्न ढूँढ रहे हैं: किन इनपुट्स पर आप ज़्यादा भरोसा करते हैं, किन रिस्क्स को आप कम आंकते हैं, और कहाँ आप बहुत देर से निर्णय लेते हैं।
जब सब कुछ संभव लगे, आपकी नौकरी है “अब नहीं” को सुरक्षित महसूस कराना।
अगर कोई टास्क उन परिणामों में से किसी से जुड़ा नहीं है, तो उसे बने रहने का मज़बूत कारण चाहिए।
लॉन्च, ग्राहक कॉल, और मुश्किल हफ्तों के बाद इनका उपयोग करें:
समय के साथ, ये आदतें आपकी प्रवृत्ति को स्वाद की बजाय परीक्षण-आधारित समझ में बदल देती हैं।
शुरुआती चरण में, प्रगति अक्सर रैखिक होती है: अधिक समय कोड करने का मतलब अक्सर अधिक शिप्ड प्रोडक्ट। जैसे-जैसे उपयोगकर्ता, राजस्व और टीम बढ़ती है, प्रगति गैर-रैखिक हो जाती है—हर बदलाव ग्राहकों, सपोर्ट, सेल्स के वादों, इंफ्रास्ट्रक्चर और अन्य इंजीनियरों के काम के साथ इंटरैक्ट करने लगता है。
आपकी सबसे बड़ी लीवरेज अब अगला चीज़ बनाना नहीं बल्कि निर्णय लेना होता है: टीम को क्या बनाना चाहिए और क्यों, मानक सेट करना, और दूसरों को बार-बार सुधारने की ज़रूरत के बिना काम करने के लिए स्पष्टता देना।
एक उपयोगी विभाजन:
एक तकनीकी तौर पर “सबसे अच्छा” चुनाव तब भी बिजनेस-राइट नहीं हो सकता जब वह उस फीचर को देरी कर दे जो किसी रिस्की अनुमान को वेलिडेट करे या डील्स क्लोज करे। उपलब्ध जानकारी के साथ ऐसे निर्णय लें जो यथार्थपरक हों और आपको बदलती स्थिति में फ्लेक्सिबल रखें।
तुरंत के आउटपुट से आगे देखिए और पूछिए कि यह विकल्प क्या करता है:
इसे लागू करने का त्वरित तरीका: कमिट करने से पहले एक संभावित डाउनस्ट्रीम कॉस्ट और एक डाउनस्ट्रीम बेनिफिट नामित करें।
दो सरल लेंस का उपयोग करें:
अगर निर्णय कठिन है वापस करने के लिए और देरी महंगी है, तो स्टेज्ड अप्रोच अपनाएँ: प्रोटोटाइप, सीमित रोलआउट, या एक छोटा आरम्भिक कमिट जो ऑप्शन्स बरकरार रखे।
परफेक्ट रैंकिंग खोजने का नहीं—बल्कि यह तय करने का कि आप क्या छोड़ रहे हैं। दो हल्के फ्रेम अक्सर काफी होते हैं:
फिर उस अवधि के लिए चुनें और उसे सीधे आगे बढ़ाने वाले चुनें। बाकी सपोर्टिंग या पार्क्ड।
प्रोडक्ट सेंस मूलतः उस आदत का नाम है जो इंजीनियरिंग काम को परिणामों से जोड़ती है:
एक व्यावहारिक टेस्ट: अगर आप एक वाक्य में वैल्यू समझा नहीं पाते बिना इम्प्लीमेंटेशन का ज़िक्र किए, तो आप अभी भी बिल्डर की तरह सोच रहे हैं।
भारी एनालिटिक्स के बिना आप बहुत कुछ सीख सकते हैं। इन पर नज़र रखें:
हर प्लान किए बदलाव को इन सिग्नल में से किसी एक से जोड़ें ताकि आप शिप करने के बाद देख सकें क्या आपने जो उम्मीद की वह मूव हुआ।
सरल त्रयी का उपयोग करें:
यह ट्रेडऑफ़्स को चर्चनीय बनाता है (नंबर और कंस्ट्रेंट्स), न कि व्यक्तिगत (“इंजीनियरिंग बनाम प्रोडक्ट”)।
चुनिंदा जगहों पर गुणवत्ता अनिवार्य रखें जहाँ फेलियर भरोसे को नुकसान पहुंचाए, जैसे:
दूसरी जगहों पर तेज़ी से चलने के लिए गार्डरेल्स लागू करें:
निर्णय को परतों में बाँट कर सौंपें:
फाउंडर बॉटलनेक से बचने के लिए कुछ सिद्धांत लिखिए जो स्केल हों (उदा., “बिलिंग के लिए रिलायबिलिटी, आंतरिक टूल के लिए स्पीड”), हर एरिया के लिए स्पष्ट मालिक (DRI) असाइन करें, और हर कदम को अप्रूव करने की बजाय परिणामों की समीक्षा करें।