सभी ने मुझसे कहा कि मैं रुक जाऊँ।
क्रूरता से नहीं — सच में, सलाह देते हुए, उस तरह की चिंता के साथ जो लोग किसी ऐसे व्यक्ति के लिए रखते हैं जिसे वह सोचते हैं कि वह अपना समय बर्बाद कर रहा है। "तुम अब संस्थापक हो, Gautam। कोड को किसी और को दे दो।" Seahawk Media में मेरे सह-संस्थापक ने 2018 के आसपास कुछ इसी तरह कहा था जब हम एक साथ सौ सक्रिय क्लाइंट प्रोजेक्ट पार कर गए। तर्क सही था: संस्थापकों को सिस्टम, नियुक्ति, पाइपलाइन के बारे में सोचना चाहिए। Pull requests नहीं।Seahawk Media said something similar around 2018 when we crossed a hundred active client projects simultaneously. The logic was sound: founders should think about systems, hiring, pipeline. Not pull requests.
मैंने वह सलाह नज़रअंदाज़ की। और मुझे खुशी है कि मैंने ऐसा किया।
---
वह पल जब मैंने कोडिंग छोड़ने वाला था (और नहीं छोड़ा)
2019 में एक क्लाइंट ने मुझे एक ब्रीफ दी जो आज भी मुझे हँसाती है। एक मध्यम आकार का ई-कॉमर्स ब्रांड — मैं नाम नहीं बताऊँगा — पूरी WooCommerce रीबिल्ड, कस्टम प्रोडक्ट कॉन्फ़िगरेटर, सब कुछ चाहता था। टाइट डेडलाइन थी। मैंने इसे टीम के एक डेवलपर को असाइन किया, यह सोचते हुए कि यह ठीक वही काम था जहाँ मुझे कदम पीछे खींचने चाहिए।
तीन हफ्ते में, वह डेवलपर चला गया। निजी कारण थे, बिल्कुल समझदारी की बात। लेकिन मेरे पास एक आधा-निर्मित कॉन्फ़िगरेटर था, एक क्लाइंट जो मेरे गले में था, और एक कोडबेस जिसे सिर्फ एक व्यक्ति पूरी तरह समझता था।
मैंने उस रविवार सुबह 7 बजे VS Code खोला और दोपहर 12 बजे तक नहीं बंद किया। मैं इसके आर-पार निकल गया। क्योंकि मैं एक हीरो हूँ इसलिए नहीं — क्योंकि मुझे कोड पैटर्न्स याद थे, WooCommerce हुक आर्किटेक्चर याद था, यह याद था कि woocommerce_before_add_to_cart_button कैसे व्यवहार करता है जब आपके पास एक कस्टम पोस्ट टाइप प्रोडक्ट वेरिएशन को फीड कर रहा हो। मैंने नहीं भूला था। मैं सिर्फ दिखावा कर रहा था कि आगे बढ़ गया हूँ।woocommerce_before_add_to_cart_button behaves when you've got a custom post type feeding product variations. I hadn't forgotten. I'd just been pretending I had moved on.
उस प्रोजेक्ट ने मेरी भूमिका के बारे में मेरी सोच को पूरी तरह बदल दिया।
---
"Founder Who Codes" का असली मतलब क्या है
इसका मतलब यह नहीं है कि मैं हर फीचर बना रहा हूँ। मैं नहीं कर रहा। Seahawk के डेवलपर्स मुझसे कहीं बेहतर हैं कुछ चीजों में — एनिमेशन, जटिल React स्टेट मैनेजमेंट, स्केल पर डेटाबेस ऑप्टिमाइजेशन। यह झूठी विनम्रता नहीं है। यह सच है।
लेकिन एक फाउंडर के रूप में कोडिंग का मतलब है कि मैं कभी काम की भावना नहीं खोता। एक प्रोजेक्ट को मैनेज करने और उसे समझने में फर्क है। जब कोई डेवलपर मुझे कहता है "इसमें दो हफ्ते लगेंगे," तो मैं सही सवाल पूछ सकता हूँ — "क्या दो हफ्ते इसलिए क्योंकि API ऑथेंटिकेशन सच में जटिल है, या क्योंकि हम कुछ ऐसा दोबारा बना रहे हैं जो एक WordPress प्लगइन में पहले से है?"feel of the work. There's a difference between managing a project and understanding one. When a developer tells me "this will take two weeks," I can ask the right question — "is that two weeks because the API authentication is genuinely complex, or because we're rebuilding something that already exists in a WordPress plugin?"
आप 10,000 फीट की ऊँचाई से यह सवाल नहीं पूछ सकते। आप पूछ ही नहीं सकते।
Estimation की समस्या
सॉफ्टवेयर अनुमान के बारे में बात यह है: ये वो कहानियाँ हैं जो डेवलपर्स अपने आप को सुनाते हैं, जितना कि वो क्लाइंट्स को सुनाते हैं। मैंने एक सीनियर डेवलपर को देखा है जिसने एक कस्टम WordPress REST API एंडपॉइंट के लिए चार दिन की अनुमान दी थी, लेकिन जब मैं उनके साथ बैठा और सही तरीके से स्कोप किया, तो वह छह घंटे में पूरा हो गया। यह इसलिए नहीं था कि वो आलसी थे। इसलिए कि हम दोनों ने ही यह नहीं खोजा था कि एंडपॉइंट को वास्तव में क्या करना था।WordPress REST API endpoint that took six hours once I sat down with them and scoped it properly. Not because they were lazy. Because neither of us had dug into what the endpoint actually needed to do.
जब आप नियमित रूप से कोड करते हैं, तो अनुमानों के लिए आपका BS डिटेक्टर सुधर जाता है। नाटकीय रूप से।
---
यह मुझे एक बेहतर क्लाइंट बनाता है, आंतरिक रूप से
किसी को एजेंसी चलाने के बारे में कोई नहीं बताता: आपके डेवलपर्स आपके आंतरिक क्लाइंट्स हैं। आपको उन्हें अच्छे निर्णयों पर बेचना होता है, ठीक वैसे ही जैसे आप बाहरी क्लाइंट्स को बेचते हैं। और जिस क्षण आप उनकी भाषा बोलना बंद कर देते हैं, आप वह क्षमता खो देते हैं।
मैं डिजाइन हैंडऑफ के लिए Figma का उपयोग करता हूँ। मैं Git का उपयोग करता हूँ (विशेष रूप से GitHub, हम 2021 में सब कुछ Bitbucket से वहाँ ले गए)। मैं Linear में वास्तविक टिकट लिखता हूँ जिसमें इतनी विशिष्टता होती है कि एक डेवलपर किकऑफ कॉल के बिना काम शुरू कर सकता है। अकेली यह आखिरी चीज़ ने हमें प्रायः 40 मिनट प्रति प्रोजेक्ट बचाई है, और हम बहुत सारे प्रोजेक्ट चलाते हैं।Figma for design handoffs. I use Git (specifically GitHub, we moved everything there from Bitbucket in 2021). I write actual tickets in Linear with enough specificity that a developer can start work without a kickoff call. That last one alone has saved us probably 40 minutes per project, and we run a lot of projects.
इनमें से कुछ भी संभव नहीं है अगर आप पूरी तरह "बिग पिक्चर" की ओर चले गए हैं। आपको यह जानना होगा कि एक डेवलपर को एक टिकट में क्या चाहिए। आप यह तभी जानते हैं जब आप दूसरी ओर बैठे हों।
कोड रिव्यू जिसकी बॉस से कोई उम्मीद नहीं करता
कभी-कभी मैं PR कमेंट ड्रॉप करता हूँ। माइक्रोमैनेज करने के लिए नहीं — मैं यह स्पष्ट करता हूँ। लेकिन एक नोट जैसे "यह फिल्टर हर पेज लोड पर चल रहा है, क्या हम परिणाम को कैश कर सकते हैं?" कुछ महत्वपूर्ण सिग्नल देता है: मैं उस स्तर पर ध्यान दे रहा हूँ जो मायने रखता है।
डेवलपर्स इसका सम्मान करते हैं। कुछ इससे हैरान होते हैं। और ईमानदारी से कहूँ, जो इससे नाराज़ हैं — यह मुझे कुछ उपयोगी बताता है।annoyed by it — that tells me something useful too.
---
2024 में मैं जो टूल्स असल में इस्तेमाल करता हूँ
मेरा स्टैक एक टेक फाउंडर के लिए शर्मनाक तरीके से अनाकर्षक है। VS Code कुछ एक्सटेंशन्स के साथ (Prettier, GitLens, PHP Intelephense)। LocalWP चला रहा एक लोकल डेवलपमेंट एनवायरनमेंट — मैंने 2020 में MAMP से स्विच किया और कभी पीछे नहीं देखा। Git से जुड़ी हर चीज़ के लिए Terminal क्योंकि मैंने किसी GUI पर पूरी तरह भरोसा कभी नहीं किया।LocalWP — I switched from MAMP in 2020 and never looked back. Terminal for everything Git-related because I never fully trusted any GUI.
जब मैं क्लाइंट प्रोजेक्ट्स पर काम करता हूँ, तब भी WordPress की ओर जाता हूँ। हमने Webflow, Shopify, कस्टम Laravel पर बनाया है — लेकिन WordPress वह जगह है जहाँ मैं सबसे तेज़ हूँ, और स्पीड मायने रखती है जब आप अंदर-बाहर आ-जा रहे हों, न कि 8 घंटे का फोकस्ड सेशन चला रहे हों।
मैंने पिछले मंगलवार Coolars.co इस्तेमाल किया एक क्लाइंट के लैंडिंग पेज पर क्विक फिक्स के लिए ब्रैंड पैलेट खींचने के लिए। मुझे कुल चार मिनट लगे। किसी डिज़ाइनर को ब्रीफ करने, इंतज़ार करने और रिव्यु करने में एक घंटा लगता।यह फाउंडर कोडिंग एडवांटेज छोटे पैमाने पर है।
---
जब आप रुकते हो तो तुम असल में क्या खो देते हो
ज़्यादातर फाउंडर्स जो एडिटर से दूर हट जाते हैं, वे खुद को मना लेते हैं कि वे ऑस्मोसिस के ज़रिए टेक्निकल रहेंगे। वे इसे स्टैंड-अप्स और Slack थ्रेड्स से सोख लेंगे। वह नहीं होगा।
असल में क्या होता है:
- आपकी शब्दावली बदल जाती है। "API," "webhook," "cache invalidation" — आप इन शब्दों को अपने स्टैक के मख़सूस कॉन्टेक्स्ट में जाने बिना इस्तेमाल करने लगते हो।
- आप प्रोटोटाइप बनाने की क्षमता खो देते हैं। दो घंटे का कोडिंग सेशन एक ऐसे प्रोडक्ट सवाल का जवाब दे सकता है जो तीन स्टेकहोल्डर मीटिंग नहीं दे सकीं।
- आप छोटे फैसलों के लिए डेवलपर की उपलब्धता पर निर्भर हो जाते हैं। कुछ ऐसा जो पहले आपको 20 मिनट में करना था, अब शेड्यूलिंग की जरूरत है।
- डेवलपर्स को यह पता चल जाता है। सभी इसे कहेंगे नहीं, लेकिन एक ऐसे फाउंडर के साथ एनगेजमेंट के तरीके में एक सूक्ष्म बदलाव होता है जिसने साल भर में स्पष्ट रूप से काम को छुआ नहीं है।
मैंने इसे ऐसे लोगों के साथ होते देखा है जिनका मैं सम्मान करता हूँ। अच्छे लोग जिन्होंने वाकई तकनीकी एजेंसियाँ बनाई थीं, फिर धीरे-धीरे अपनी खुद की विशेषज्ञता से खुद को अलग कर लिया। पाँचवें साल तक वे पूरी तरह से व्यवसाय चला रहे थे और वे इसमें अच्छे थे — लेकिन उन्होंने कुछ खो दिया था जिसे वे बिल्कुल नाम नहीं दे सकते थे।
---
प्रतिवाद (और मैं इससे क्यों असहमत हूँ)
फाउंडर-कोडिंग के खिलाफ सबसे मजबूत दलील अवसर लागत है। पॉल ग्राहम ने विभिन्न रूपों में इसके बारे में लिखा है — यह विचार कि फाउंडर्स को ऐसी चीजें करनी चाहिए जो स्केल नहीं करती, लेकिन यह भी कि फोकस ही एक अर्ली-स्टेज ऑपरेशन का एकमात्र असली फायदा है।Paul Graham has written about this in various forms — the idea that founders should do things that don't scale, but also that focus is the only real advantage an early-stage operation has.
सही है। सच में सही है।
लेकिन मुझे लगता है कि यह दलील वीसी-बैकड स्टार्टअप्स के प्रोडक्ट फाउंडर्स पर ज्यादा साफ-सुथरे तरीके से लागू होती है, एजेंसी फाउंडर्स और फ्रीलांसरों की तुलना में नहीं। हमारा संदर्भ अलग है। हमारे पास एक रनवे की समस्या नहीं है जिससे कोडिंग विचलित करे। हमारे पास एक गुणवत्ता और विश्वास की समस्या है — और कोडिंग इसे हल करने का एक हिस्सा है।
जब Seahawk एक एंटरप्राइज क्लाइंट के लिए एक जटिल WordPress माइग्रेशन का पिच करता है, तो यह तथ्य कि एक को-फाउंडर डेटाबेस टेबल स्ट्रक्चर और wp-config कॉन्स्टेंट्स के बारे में विस्तार से चर्चा कर सकता है, एक छोटी बात नहीं है। यह कमरे को बदल देता है।
---
मैं कोडिंग का समय कैसे सुरक्षित रखता हूँ बिना यह समस्या बने
मुझे यह समझने में साल लग गए। सच में। मैं प्रतिक्रियात्मक तरीके से कोड करता था — सिर्फ जब कोई चीज़ टूटती थी या कोई डेवलपर फँसा होता था। यह दोनों दुनियाओं का सबसे बुरा हिस्सा था। आप कोड में तो होते हो लेकिन तनावग्रस्त, कभी फ्लो में नहीं।
अब मैं यह करता हूँ:
- सोमवार और बृहस्पतिवार की सुबह 90 मिनट ब्लॉक करता हूँ। उन दिनों सुबह 9:30 से पहले कोई कॉल नहीं। गैर-परक्राम्य, 2022 से कैलेंडर में है। No calls before 9:30am those days. Non-negotiable, in the calendar since 2022.
- हर समय एक "संस्थापक परियोजना" चलाता हूँ। कोई छोटी चीज़ — एक व्यक्तिगत टूल, एक क्लाइंट माइक्रो-फीचर, एक आंतरिक ऑटोमेशन। अभी यह एक Python स्क्रिप्ट है जो Linear से हमारी प्रोजेक्ट स्थिति खींचती है और एक साप्ताहिक डाइजेस्ट बनाती है। 180 लाइनें, कुछ खास नहीं। Something small — a personal tool, a client micro-feature, an internal automation. Right now it's a Python script that pulls our project status from Linear and formats a weekly digest. 180 lines, nothing fancy.
- कम से कम एक PR प्रति सप्ताह समीक्षा करता हूँ। भले ही सिर्फ पढ़ने के लिए हो। डिफ में रहता हूँ। Even if it's just to read. Stay in the diff.
- त्रैमासिक में किसी चीज़ को शुरू से फिर से बनाता हूँ। एक लैंडिंग पेज, एक प्लगइन, एक छोटा इंटीग्रेशन। कुछ भी। बात यह है कि बुनियादी बातों पर तेज़ रहना। A landing page, a plugin, a small integration. Whatever. The point is staying sharp on fundamentals.
कुल समय प्रति सप्ताह शायद 4-5 घंटे है। बस इतना ही। कोई यह नहीं कह रहा कि आप स्प्रिंट चलाएँ।
---
सवाल-जवाब
क्या कोडिंग आपको एक बुरा सीईओ या को-फाउंडर बनाती है?
सिर्फ अगर आप इसे असली लीडरशिप की जिम्मेदारियों को भीड़ देने दें। समस्या कोडिंग नहीं है — यह कोडिंग को कठिन संस्थापक के काम से बचने की रणनीति के रूप में उपयोग करना है: मुश्किल बातचीत, नियुक्ति संबंधी निर्णय, व्यावसायिक सोच। अगर आप एडिटर खोल रहे हैं जब आपको किसी चर्न करने वाले क्लाइंट से बात करनी चाहिए, तो यह एक समस्या है। लेकिन गुरुवार की सुबह सप्ताह में 4 घंटे लीडरशिप की लापरवाही नहीं है।avoidance strategy for the harder founder work: difficult conversations, hiring decisions, commercial thinking. If you're opening the editor when you should be talking to a churning client, that's a problem. But 4 hours a week on a Thursday morning isn't leadership negligence.
अगर मेरी टीम मुझे कोडिंग करते देखे और सोचे कि मैं उन पर विश्वास नहीं करता?
इसके बारे में सीधे बात करें। मैंने अपनी टीम को स्पष्ट रूप से कहा है: "जब मैं कोड लिखता हूँ, यह एक संकेत नहीं है कि मुझे लगता है कि आप गलत हैं या धीमे हैं। यह वह तरीका है जिससे मैं उस चीज़ के संपर्क में रहता हूँ जो हम वास्तव में बनाते हैं।" वह बातचीत 90 सेकंड लेती है और आमतौर पर सिर्फ एक बार होनी चाहिए।
क्या यह बड़ी टीमों चलाने वाले संस्थापकों के लिए यथार्थवादी है?
ईमानदारी से कहूँ, 15 की तुलना में 50 लोगों पर कठिन है। लेकिन सिद्धांत बढ़ता है — भले ही व्यवहार बदलता है। एक निश्चित आकार पर, "कोडिंग" का मतलब आर्किटेक्चर निर्णयों की समीक्षा करना, त्रैमासिक में एक खोजी स्पाइक करना, या Lighthouse प्रदर्शन रिपोर्ट के अंदर गहराई से समझना हो सकता है बजाय इसे स्वयं ठीक करने के। मुद्दा यह है: तकनीकी निपुणता को पूरी तरह सड़ने न दें।Lighthouse performance report rather than writing the fix yourself. The point is: don't let technical fluency atrophy entirely.
एक संस्थापक को कब कोड से वास्तव में पीछे हटना चाहिए?
जब कोडिंग किसी और के विकास में बाधा डाल रही हो। अगर कोई डेवलपर अपने काम को merge करने के लिए आपकी PR समीक्षा का इंतज़ार कर रहा है, और आप लगातार बाधा हैं, तो यह संकेत है। महत्वपूर्ण पथ से पीछे हटें। आप अभी भी कोड लिख सकते हैं — बस मुख्य शाखा पर रात 2 बजे नहीं।critical path. You can still write code — just not on the main branch at 2am.
---
कोडिंग ने मुझे ईमानदार रखा। यह सबसे सरल तरीका है जो मैं इसे कह सकता हूँ। जब आप अभी भी एक diff पढ़ सकते हैं, किसी फीचर का अनुमान लगा सकते हैं, और अपने दम पर कोई छोटी चीज़ शिप कर सकते हैं — तो आप अपना खुद का बिज़नेस ज्यादा साफ़ देखते हैं। आप जानते हैं कि क्या वाकई मुश्किल है और क्या बस बुरी तरह समझाया गया है। वह स्पष्टता इसके लायक है कि इसमें हफ़्ते के चार घंटे खर्च होते हैं।
फिर भी एडिटर खोल रहा हूँ। शायद तब तक करता रहूँगा जब तक शारीरिक रूप से नहीं कर सकूँ।