- कई CTO मैनेजमेंट-केंद्रित भूमिका में चले जाते हैं, लेकिन कुछ अब भी खुद कोड लिखकर प्रोडक्ट बनाना जारी रखते हैं
- प्रयोगात्मक प्रोजेक्ट, तात्कालिक ग्राहक अनुरोध और bug fixes जैसी तीन तरह की डेवलपमेंट गतिविधियों के ज़रिये संगठन के भीतर उच्च leverage पैदा किया जा सकता है
- लगातार coding करते रहने से AI tools की वास्तविक उपयोगिता और सीमाओं को सीधे महसूस किया जा सकता है, और तकनीकी निर्णय अधिक यथार्थवादी बने रहते हैं
- मैनेजमेंट से अधिक समस्या-समाधान और प्रोडक्ट बनाने में अपनी ताकत और जुनून लगाते हुए, उसे संभव बनाने वाली संगठनात्मक संरचना तैयार की जाती है
- CTO की भूमिका का कोई तयशुदा साँचा नहीं है; असली बात है अपनी ताकत और कंपनी की स्थिति के मुताबिक नेतृत्व का तरीका खोजना
CTO के रूप में मैं कोड लिखना क्यों जारी रखता हूँ
- कई CTO समय के साथ coding छोड़ देते हैं, लेकिन मैं अब भी खुद features बनाकर deploy करने का तरीका बनाए हुए हूँ
- पिछले 12 महीनों में बिना किसी direct report के कई महत्वपूर्ण features रिलीज़ किए
- यह सिर्फ शौक़ के लिए coding नहीं, बल्कि वास्तविक प्रोडक्ट में जाने वाले मुख्य feature developer की भूमिका है
- मैं इसे “तकनीकी लीडर के रूप में सबसे उच्च leverage वाली गतिविधियों में से एक” मानता हूँ
मैं वास्तव में जिन तीन तरह के प्रोजेक्ट बनाता हूँ
1. दीर्घकालिक प्रयोगात्मक प्रोजेक्ट (Long-horizon experimental projects)
- किसी संगठन में वास्तव में नया प्रोडक्ट बना सकने वाले लोग बहुत कम होते हैं
- क्योंकि ज़्यादातर संगठन मौजूदा प्रोडक्ट को बनाए रखने और scale करने पर केंद्रित होते हैं
- केवल founders, कुछ executives, और high-performing individual contributors (IC) के पास नए प्रोडक्ट आज़माने की गुंजाइश होती है
- संगठनात्मक संरचना, roadmap incentives, और सीमित risk budget के कारण ज़्यादातर engineers कई महीनों तक अनिश्चित प्रोजेक्ट आगे नहीं बढ़ा सकते
- CTO, ग्राहकों के pain points और architecture की गहरी समझ के आधार पर, अनिश्चित लेकिन प्रयोगात्मक प्रोजेक्ट को तेज़ी से आगे बढ़ाने की अनोखी स्थिति में होता है
- कुछ असफलताएँ रहीं, लेकिन बड़ी सफलताएँ भी मिलीं
- AI chat प्रोडक्ट का उदाहरण: टीम उसकी value समझती थी, लेकिन समय और अतिरिक्त क्षमता न होने से उसे टाल रही थी; तब Thanksgiving की छुट्टियों में उसका prototype बनाया गया
- बाद में टीम के साथ मिलकर उसे मिलियन-डॉलर ARR प्रोडक्ट के रूप में व्यावसायिक सफलता तक पहुँचाया गया
2. तात्कालिक ग्राहक अनुरोध संभालना (Critical customer asks)
- कभी-कभी किसी बड़े ग्राहक को तुरंत चाहिए feature, बड़े contract या renewal के लिए blocker बन जाता है
- उस समय मौजूदा sprint में लगे engineers को हटाने के बजाय, CTO तेज़ निर्णय क्षमता और पूरे सिस्टम की समझ के आधार पर इसे सीधे संभालता है
- एक वास्तविक उदाहरण: सालाना मिलियन-डॉलर ग्राहक की compliance ज़रूरत के लिए data redaction feature का अनुरोध
- टीम की शुरुआती समीक्षा में लगा कि ग्राहक को खुद API integration बनानी पड़ेगी, या फिर product, legal और engineering के बीच कई बैठकों की ज़रूरत होगी
- लेकिन CTO ने एक दिन में काम करने वाला version बनाकर deploy कर दिया और ग्राहक संबंध बनाए रखा
3. bug fixes
- बहुत लोगों को यह चौंकाता है, लेकिन bug fix करना codebase का mental map बनाए रखने के मेरे पसंदीदा तरीकों में से एक है
- जैसे search results के page 3 पर pagination क्यों टूटती है, या WebSocket connection ठीक 60 सेकंड बाद क्यों कट जाता है—इसे trace करते समय पूरे सिस्टम से होकर गुजरना पड़ता है
- इससे technical debt की सहज समझ मिलती है, जो code review या architecture discussion से हासिल करना मुश्किल है
- यही अनुभव तकनीकी निवेश की दिशा और प्राथमिकताएँ तय करने के लिए ज़रूरी intuition बनाए रखता है
मैं coding क्यों जारी रखता हूँ
1. यह समझने के लिए कि वास्तव में कौन-सी तकनीक काम करती है
- Claude Code, Codex, Cursor जैसे AI tools का रोज़ उपयोग करने का अनुभव, tool strategy और hiring strategy तय करते समय वास्तविकता और hype में फर्क करने में मदद करता है
- हाल का उदाहरण: एक जटिल integration से जुड़ा feature vibe-coding से बनाने की कोशिश की, लेकिन कोई खास प्रगति नहीं हुई; फिर उसे खुद हाथ से लिखने पर काम बहुत तेज़ी से आगे बढ़ा
- code की मात्रा ज़्यादा नहीं थी, लेकिन logic बिल्कुल सटीक चाहिए था, जो LLMs के लिए कमज़ोर क्षेत्र है
- दूसरी ओर, एक बड़ा feature लगभग पूरा Claude Code से बन गया
- AI कहाँ शानदार है (CRUD, tests, boilerplate) और कहाँ विफल होता है (precision, system nuance), इसे सीधे समझना Twitter hype के आधार पर निर्णय लेने से बेहतर है
- जब आप code के भीतर रहते हैं, तो कब दबाव बढ़ाना है और कब ढील देनी है, यह महसूस कर पाते हैं
- कब architecture ज़रूरत से ज़्यादा जटिल हो रही है, या technical debt वास्तव में समस्या बन रही है, यह पकड़ में आता है
- जो manager केवल reports पर निर्भर रहते हैं, वे बहुत कुछ चूक सकते हैं
2. उस काम पर ध्यान देने के लिए जिसमें मैं अच्छा हूँ और जिसे मैं पसंद करता हूँ
- मुझे संगठन बनाना और people management विशेष रूप से पसंद नहीं है
- engineering management में interpersonal dynamics, performance evaluation और organizational design की ज़रूरत होती है
- यह महत्वपूर्ण काम है, लेकिन मेरी मुख्य ताकत का क्षेत्र नहीं
- इसलिए मैं बेहतरीन engineering managers और leaders को hire करता हूँ
- वे यह काम मुझसे बेहतर करते हैं और उसे पसंद भी करते हैं
- इससे CTO के रूप में मैं प्रोडक्ट डेवलपमेंट, तकनीकी समस्या-समाधान और coding पर ध्यान दे पाता हूँ
- startup एक “sprint-आधारित marathon” की तरह है, इसलिए भूमिका को ऐसे काम के आसपास डिज़ाइन करना ज़रूरी है जो रुचि बनाए रखे और लंबे समय तक तेज़ी से चलने दे
- यही तरीका कई वर्षों तक टिकाऊ है, और कंपनी के लिए भी बहुत महत्वपूर्ण है
3. क्योंकि AI tools ने leverage को और बढ़ा दिया है
- कुछ साल पहले रणनीतिक काम संभालते हुए coding के लिए समय निकालना मुश्किल था
- कंपनी के बढ़ने के साथ दिन भर meetings में फँसा रहता था, और अपनी ताकत से बाहर के काम करता था
- यह पेशेवर जीवन के सबसे कठिन दौरों में से एक था
- आधुनिक AI tools ने इस समीकरण को मूल रूप से बदल दिया है — खासकर पिछले कुछ महीनों में
- productivity पहले से 2–3 गुना बढ़ गई है
- ये tools judgment या technical knowledge की जगह नहीं लेते, बल्कि उन्हें और अधिक मूल्यवान बना देते हैं
- अगर आप AI tool से कहें: "मौजूदा CSV export format से मेल खाने वाला data export बनाओ, लेकिन user profile table से तीन अतिरिक्त fields भी शामिल करो", तो वह अधिकतर code सही बना देता है
- बशर्ते आपके पास यह गहरा context हो कि वास्तव में क्या चाहिए और वह कहाँ मिलेगा
- जिस engineer को codebase के उस हिस्से की जानकारी नहीं है, उसे वही बारीकियाँ समझने में काफी समय लग सकता है
- काम “हर line of code खुद लिखने” से बदलकर “context देना, निर्णय लेना, और solution का मूल्यांकन करना” बन गया है
- सौभाग्य से, मेरे पास context बहुत है
अपने लिए सही तरीका खोजना
- CTO की भूमिका को समझते समय Greg Brockman की Stripe में CTO role को परिभाषित करने वाली ब्लॉग पोस्ट उपयोगी रही
- कई CTOs से बात करने के बाद यह साफ़ हुआ कि इस भूमिका के स्वरूप में बहुत बड़ा अंतर होता है
- कुछ CTO तकनीकी visionaries होते हैं, कुछ organization builders, और कुछ infrastructure-केंद्रित
- समान बात यह है कि बेहतरीन CTO अपनी खास क्षमताओं, रुचियों और कंपनी की स्थिति को ध्यान में रखकर वह क्षेत्र पहचानते हैं जहाँ वे सबसे अधिक मूल्य पैदा कर सकते हैं
- मेरे मामले में इसका मतलब है बहुत सारा code लिखना
- मुझे organizational design की तुलना में software बनाना अधिक पसंद है
- ग्राहकों और codebase की गहरी समझ के कारण मैं इसमें खास तौर पर प्रभावी हूँ
- और मैं मज़बूत engineering managers को hire करता हूँ
- लेकिन यह एक व्यक्तिगत रास्ता है, कोई prescribed formula नहीं
- CTO की भूमिका बेहद लचीली है
- organization बनाना, product strategy तैयार करना आदि—तकनीकी नेतृत्व ताकत, ऊर्जा के स्रोत और कंपनी की ज़रूरतों के अनुसार अलग-अलग हो सकता है
- उन engineers के लिए जो चिंतित हैं कि leadership का मतलब तकनीकी काम छोड़ देना है: ऐसे कई रास्ते मौजूद हैं
- असली बात है यह पहचानना कि आप किस क्षेत्र में अनोखे तौर पर उत्कृष्ट हैं
अभी कोई टिप्पणी नहीं है.