सभी ने मुझसे कहा कि मैं रुक जाऊँ।
न क्रूरता से, सच में, समझदारी से, उस तरह की चिंता के साथ जो लोग किसी ऐसे व्यक्ति के लिए रखते हैं जिसे वे समय बर्बाद करते हुए सोचते हैं। "तुम अब संस्थापक हो, Gautam। कोड को दूसरों को सौंप दो।" Seahawk Media में मेरे सह-संस्थापक ने 2018 के आसपास कुछ ऐसा ही कहा था जब हम एक साथ सौ सक्रिय ग्राहक प्रोजेक्ट्स पार कर गए। तर्क सही था: संस्थापकों को सिस्टम, हायरिंग, पाइपलाइन के बारे में सोचना चाहिए। पुल रिक्वेस्ट नहीं।
मैंने वह सलाह नज़रअंदाज़ की। और मुझे खुशी है कि मैंने ऐसा किया।
---
वह पल जब मैंने कोडिंग छोड़ने वाला था (और नहीं छोड़ा)
2019 में एक ग्राहक ने मुझे एक ब्रीफ दी जो अब भी मुझे हँसाती है। एक मध्यम आकार का ई-कॉमर्स ब्रांड, मैं नाम नहीं बताऊँगा, एक संपूर्ण WooCommerce रीबिल्ड चाहता था, कस्टम प्रोडक्ट कॉन्फ़िगरेटर, सब कुछ। कड़ी डेडलाइन। मैंने इसे टीम के एक डेवलपर को सौंप दिया, आश्वस्त कि यह बिल्कुल उस तरह की चीज़ है जहाँ मुझे पीछे हटना चाहिए।
तीन हफ्ते में, वह डेवलपर चला गया। निजी कारण थे, बिल्कुल समझदारी की बात। लेकिन मेरे पास एक आधा-निर्मित कॉन्फ़िगरेटर था, एक क्लाइंट जो मेरे गले में था, और एक कोडबेस जिसे सिर्फ एक व्यक्ति पूरी तरह समझता था।
मैंने उस रविवार को सुबह 7 बजे VS Code खोला और दोपहर तक इसे बंद नहीं किया। मैंने इसे पूरा कर लिया। क्योंकि मैं कोई नायक हूँ नहीं, बल्कि क्योंकि मुझे वास्तव में कोड पैटर्न याद आ गए, WooCommerce हुक आर्किटेक्चर, woocommerce_before_add_to_cart_button का व्यवहार जब आपके पास कस्टम पोस्ट टाइप प्रोडक्ट वेरिएशन्स को फीड कर रहा हो। मैं भूला नहीं था। मैं बस यह नाटक कर रहा था कि मैं आगे बढ़ गया हूँ।
उस प्रोजेक्ट ने मेरी भूमिका के बारे में मेरी सोच को पूरी तरह बदल दिया।
---
"Founder Who Codes" का असली मतलब क्या है
इसका मतलब यह नहीं है कि मैं हर फीचर बना रहा हूँ। नहीं हूँ। Seahawk के पास मुझसे कहीं बेहतर डेवलपर्स हैं विशिष्ट चीज़ों में, एनिमेशन, जटिल React स्टेट मैनेजमेंट, बड़े पैमाने पर डेटाबेस ऑप्टिमाइज़ेशन। यह झूठी विनम्रता नहीं है। यह सच है।
लेकिन संस्थापक के रूप में कोडिंग करने का मतलब है कि मैं कभी भी काम की अनुभूति नहीं खोता। प्रोजेक्ट को मैनेज करने और किसी को समझने के बीच एक अंतर है। जब कोई डेवलपर मुझसे कहता है "इसमें दो हफ्ते लगेंगे," मैं सही सवाल पूछ सकता हूँ, "क्या वह दो हफ्ते इसलिए है क्योंकि API ऑथेंटिकेशन सच में जटिल है, या इसलिए क्योंकि हम किसी ऐसी चीज़ को रीबिल्ड कर रहे हैं जो पहले से WordPress प्लगइन में मौजूद है?"
आप 10,000 फीट की ऊँचाई से यह सवाल नहीं पूछ सकते। आप पूछ ही नहीं सकते।
Estimation की समस्या
सॉफ्टवेयर अनुमान के बारे में बात यह है: ये वो कहानियाँ हैं जो डेवलपर्स अपने आप को सुनाते हैं, जितना कि वो क्लाइंट्स को सुनाते हैं। मैंने एक सीनियर डेवलपर को देखा है जिसने एक कस्टम WordPress REST API एंडपॉइंट के लिए चार दिन की अनुमान दी थी, लेकिन जब मैं उनके साथ बैठा और सही तरीके से स्कोप किया, तो वह छह घंटे में पूरा हो गया। यह इसलिए नहीं था कि वो आलसी थे। इसलिए कि हम दोनों ने ही यह नहीं खोजा था कि एंडपॉइंट को वास्तव में क्या करना था।
जब आप नियमित रूप से कोड करते हैं, तो अनुमानों के लिए आपका BS डिटेक्टर सुधर जाता है। नाटकीय रूप से।
---
यह मुझे एक बेहतर क्लाइंट बनाता है, आंतरिक रूप से
किसी को एजेंसी चलाने के बारे में कोई नहीं बताता: आपके डेवलपर्स आपके आंतरिक क्लाइंट्स हैं। आपको उन्हें अच्छे निर्णयों पर बेचना होता है, ठीक वैसे ही जैसे आप बाहरी क्लाइंट्स को बेचते हैं। और जिस क्षण आप उनकी भाषा बोलना बंद कर देते हैं, आप वह क्षमता खो देते हैं।
मैं डिजाइन हैंडऑफ के लिए Figma का उपयोग करता हूँ। मैं Git का उपयोग करता हूँ (विशेष रूप से GitHub, हम 2021 में सब कुछ Bitbucket से वहाँ ले गए)। मैं Linear में वास्तविक टिकट लिखता हूँ जिसमें इतनी विशिष्टता होती है कि एक डेवलपर किकऑफ कॉल के बिना काम शुरू कर सकता है। अकेली यह आखिरी चीज़ ने हमें प्रायः 40 मिनट प्रति प्रोजेक्ट बचाई है, और हम बहुत सारे प्रोजेक्ट चलाते हैं।
इनमें से कुछ भी संभव नहीं है अगर आप पूरी तरह "बिग पिक्चर" की ओर चले गए हैं। आपको यह जानना होगा कि एक डेवलपर को एक टिकट में क्या चाहिए। आप यह तभी जानते हैं जब आप दूसरी ओर बैठे हों।
कोड रिव्यू जिसकी बॉस से कोई उम्मीद नहीं करता
कभी-कभी मैं PR कमेंट छोड़ूँगा। माइक्रो-मैनेज करने के लिए नहीं, मैं वह स्पष्ट करता हूँ। लेकिन एक नोट जैसे "यह फिल्टर हर पेज लोड पर चल रहा है, क्या हम परिणाम को कैश कर सकते हैं?" कुछ महत्वपूर्ण सिग्नल करता है: मैं उस स्तर पर ध्यान दे रहा हूँ जो मायने रखता है।
डेवलपर्स इसकी सम्मान करते हैं। कुछ इससे आश्चर्य चकित हैं। और सच में, जो लोग इससे नाराज़ हैं, वह भी मुझे कुछ उपयोगी बताता है।
---
2024 में मैं जो टूल्स असल में इस्तेमाल करता हूँ
मेरा स्टैक एक टेक संस्थापक के लिए शर्मनाक रूप से असेक्सी है। VS Code कुछ एक्सटेंशन्स के साथ (Prettier, GitLens, PHP Intelephense)। एक लोकल डेवलपमेंट एनवायरनमेंट LocalWP चला रहा हूँ, मैंने 2020 में MAMP से स्विच किया और कभी पीछे नहीं देखा। Git से संबंधित सब कुछ के लिए टर्मिनल क्योंकि मैंने किसी GUI पर पूरी तरह विश्वास कभी नहीं किया।
जब मैं क्लाइंट प्रोजेक्ट्स पर काम कर रहा होता हूँ, तो भी मैं WordPress की तरफ जाता हूँ। हमने Webflow पर, Shopify पर, कस्टम Laravel पर बनाया है, लेकिन WordPress वह जगह है जहाँ मैं सबसे तेज़ हूँ, और स्पीड मायने रखती है जब आप इधर-उधर कूद रहे हों, 8 घंटे फोकस्ड सेशन करने की जगह।
मैंने पिछले मंगलवार Coolars.co इस्तेमाल किया एक क्लाइंट के लैंडिंग पेज पर क्विक फिक्स के लिए ब्रैंड पैलेट खींचने के लिए। मुझे कुल चार मिनट लगे। किसी डिज़ाइनर को ब्रीफ करने, इंतज़ार करने और रिव्यु करने में एक घंटा लगता।यह फाउंडर कोडिंग एडवांटेज छोटे पैमाने पर है।
---
जब आप रुकते हो तो तुम असल में क्या खो देते हो
ज़्यादातर फाउंडर्स जो एडिटर से दूर हट जाते हैं, वे खुद को मना लेते हैं कि वे ऑस्मोसिस के ज़रिए टेक्निकल रहेंगे। वे इसे स्टैंड-अप्स और Slack थ्रेड्स से सोख लेंगे। वह नहीं होगा।
असल में क्या होता है:
- आपकी शब्दावली बदलती रहती है। "API," "webhook," "cache invalidation"—आप इन शब्दों का उपयोग करने लगते हैं, बिना यह जाने कि आपके स्टैक के विशेष संदर्भ में इनका मतलब क्या है।
- आप प्रोटोटाइप बनाने की क्षमता खो देते हैं। दो घंटे का कोडिंग सेशन एक ऐसे प्रोडक्ट सवाल का जवाब दे सकता है जो तीन स्टेकहोल्डर मीटिंग नहीं दे सकीं।
- आप छोटे फैसलों के लिए डेवलपर की उपलब्धता पर निर्भर हो जाते हैं। कुछ ऐसा जो पहले आपको 20 मिनट में करना था, अब शेड्यूलिंग की जरूरत है।
- डेवलपर्स को यह पता चल जाता है। सभी इसे कहेंगे नहीं, लेकिन एक ऐसे फाउंडर के साथ एनगेजमेंट के तरीके में एक सूक्ष्म बदलाव होता है जिसने साल भर में स्पष्ट रूप से काम को छुआ नहीं है।
मैंने देखा है कि यह उन लोगों के साथ होता है जिनका मैं सम्मान करता हूँ। अच्छे लोग जिन्होंने असली तकनीकी एजेंसियाँ बनाईं, फिर धीरे-धीरे अपनी खुद की expertise से खुद को अलग कर लिया। पाँचवें साल तक वे पूरा बिज़नेस चला रहे थे और वह अच्छे थे, लेकिन उन्होंने कुछ खो दिया था जिसे वे नाम भी नहीं दे पाए।
---
प्रतिवाद (और मैं इससे क्यों असहमत हूँ)
founder-coding के खिलाफ सबसे मजबूत दलील opportunity cost है। Paul Graham ने इस पर कई रूपों में लिखा है—यह विचार कि founders को ऐसे काम करने चाहिए जो स्केल न करें, लेकिन यह भी कि फोकस ही एक early-stage ऑपरेशन का असली फायदा है।
सही है। सच में सही है।
लेकिन मुझे लगता है कि यह दलील product founders को VC-backed startups में ज्यादा साफ तरीके से लागू होती है, agency founders और freelancers को नहीं। हमारा कॉन्टेक्स्ट अलग है। हमारे पास runway की समस्या नहीं है जो coding से विचलित करे। हमारे पास quality और trust की समस्या है, और coding उसे हल करने का एक हिस्सा है।
जब Seahawk एक एंटरप्राइज क्लाइंट के लिए एक जटिल WordPress माइग्रेशन का पिच करता है, तो यह तथ्य कि एक को-फाउंडर डेटाबेस टेबल स्ट्रक्चर और wp-config कॉन्स्टेंट्स के बारे में विस्तार से चर्चा कर सकता है, एक छोटी बात नहीं है। यह कमरे को बदल देता है।
---
मैं कोडिंग का समय कैसे सुरक्षित रखता हूँ बिना यह समस्या बने
मुझे यह समझने में साल लगे। सच में। मैं प्रतिक्रिया के आधार पर कोडिंग करता था, सिर्फ जब कुछ टूट जाता था या कोई developer फँस जाता था। यह दोनों दुनियाओं का बुरा हिस्सा है। आप कोड में हैं लेकिन स्ट्रेस्ड, कभी flow में नहीं।
अब मैं यह करता हूँ:
- सोमवार और बृहस्पतिवार की सुबह 90 मिनट ब्लॉक करता हूँ। उन दिनों सुबह 9:30 से पहले कोई कॉल नहीं। गैर-परक्राम्य, 2022 से कैलेंडर में है।
- एक "founder's project" हर वक्त चलती रहने दें। कुछ छोटा, एक personal tool, एक client micro-feature, कोई internal automation। अभी यह एक Python script है जो Linear से हमारी project status निकालता है और एक साप्ताहिक digest फॉर्मेट करता है। 180 लाइनें, कुछ खास नहीं।
- कम से कम एक PR प्रति सप्ताह समीक्षा करता हूँ। भले ही सिर्फ पढ़ने के लिए हो। डिफ में रहता हूँ।
- त्रैमासिक में किसी चीज़ को शुरू से फिर से बनाता हूँ। एक लैंडिंग पेज, एक प्लगइन, एक छोटा इंटीग्रेशन। कुछ भी। बात यह है कि बुनियादी बातों पर तेज़ रहना।
कुल समय प्रति सप्ताह शायद 4-5 घंटे है। बस इतना ही। कोई यह नहीं कह रहा कि आप स्प्रिंट चलाएँ।
---
सवाल-जवाब
क्या कोडिंग आपको एक बुरा सीईओ या को-फाउंडर बनाती है?
सिर्फ अगर आप इसे actual leadership responsibilities को दबाने दें। मुद्दा coding नहीं है, बल्कि coding को avoidance strategy के रूप में उपयोग करना है—कठिन founder के काम के लिए: मुश्किल conversations, hiring decisions, commercial thinking। अगर आप editor खोल रहे हैं जब आप किसी churn करने वाले क्लाइंट से बात कर रहे हों, तो वह समस्या है। लेकिन हर सप्ताह गुरुवार की सुबह 4 घंटे, यह leadership negligence नहीं है।
अगर मेरी टीम मुझे कोडिंग करते देखे और सोचे कि मैं उन पर विश्वास नहीं करता?
इसके बारे में सीधे बात करें। मैंने अपनी टीम को स्पष्ट रूप से कहा है: "जब मैं कोड लिखता हूँ, यह एक संकेत नहीं है कि मुझे लगता है कि आप गलत हैं या धीमे हैं। यह वह तरीका है जिससे मैं उस चीज़ के संपर्क में रहता हूँ जो हम वास्तव में बनाते हैं।" वह बातचीत 90 सेकंड लेती है और आमतौर पर सिर्फ एक बार होनी चाहिए।
क्या यह बड़ी टीमों चलाने वाले संस्थापकों के लिए यथार्थवादी है?
ईमानदारी से कहूँ, 50 लोगों पर 15 लोगों से ज्यादा कठिन है। लेकिन सिद्धांत स्केल करता है, भले ही प्रैक्टिस बदले। एक निश्चित आकार पर, "coding" का मतलब architecture decisions की समीक्षा करना, एक quarter में एक exploratory spike करना, या Lighthouse performance report में क्या है इसे गहराई से समझना हो सकता है, न कि खुद fix लिखना। मुद्दा यह है: technical fluency को पूरी तरह सड़ने न दें।
एक संस्थापक को कब कोड से वास्तव में पीछे हटना चाहिए?
जब coding किसी और की growth को रोक रहा हो। अगर कोई developer आपके PR review का इंतजार कर रहा है अपना काम merge करने के लिए, और आप consistently bottleneck हैं, तो वह सिग्नल है। critical path से हट जाइए। आप अभी भी कोड लिख सकते हैं, बस main branch पर 2am को नहीं।
---
कोडिंग ने मुझे ईमानदार रखा। यह सबसे सरल तरीका है जो मैं इसे कह सकता हूँ। जब आप अभी भी एक diff को पढ़ सकते हैं, किसी फीचर का अनुमान लगा सकते हैं, और अपने आप से कोई छोटी चीज़ ship कर सकते हैं, तो आप अपने बिज़नेस को ज़्यादा साफ़-साफ़ देख पाते हैं। आप जानते हैं कि क्या वाकई मुश्किल है और क्या बस ख़राब तरीके से समझाया गया है। यह clarity उस चार घंटे के लायक़ है जो इसमें हर हफ़्ते लगता है।
फिर भी एडिटर खोल रहा हूँ। शायद तब तक करता रहूँगा जब तक शारीरिक रूप से नहीं कर सकूँ।