CTO के रूप में मैं कोड क्यों लिखता हूँ
(assembled.com)- कई 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 का मतलब तकनीकी काम छोड़ देना है: ऐसे कई रास्ते मौजूद हैं
- असली बात है यह पहचानना कि आप किस क्षेत्र में अनोखे तौर पर उत्कृष्ट हैं
5 टिप्पणियां
मैं वर्तमान में CTO हूँ और इस लेख से बिल्कुल सहमत नहीं हूँ.
मैं 100% सहमत हूँ कि coding नहीं छोड़नी चाहिए, लेकिन इसके लिए कंपनी के product से असंबंधित open source पर काम करना काफ़ी है. मुझे लगता है कि यह बात केवल उस नज़रिए से ही मान्य है कि शुरुआती startup के technical founder के रूप में आपको all-rounder बनकर काम करना चाहिए.
खुद के लिए तो अच्छा ही होगा… लेकिन कंपनी का क्या?
जितनी सैलरी मिलती है, उसके हिसाब से काम करना चाहिए…
यह थोड़ा अजीब लगता है कि CTO खुद किसी experimental project पर सीधे काम कर रहे हैं। अगर व्यावहारिक टीम को पर्याप्त समय दिया जाए, तो वे इसे अच्छी तरह कर सकते हैं। सबसे ज़्यादा हैरानी इस बात पर है कि लंबे समय वाले experimental project को सिर्फ CTO ही आगे बढ़ाएँ—यह काफी अटपटा है। अगर उनके पास resources इस्तेमाल करने का अधिकार है, तो experimental project के लिए अलग से resources जुटाकर व्यावहारिक टीम को पर्याप्त समय देना ही बेहतर होता।
व्यक्तिगत सफर.. बस यह देखना होगा कि संगठन प्रबंधन से जुड़ी ज़िम्मेदारियां बढ़ती न जाएं, और उसे अच्छी तरह संभालना पड़ेगा..
Hacker News राय
अगर मैं यह तय कर रहा होता कि किस कंपनी में apply करना है, और मुझे CTO का ऐसा ब्लॉग पोस्ट दिखता जिसमें वह हर वीकेंड code commit करने पर गर्व कर रहा हो, तो मैं भागने की तैयारी करता।
एक लीडर की भूमिका स्वस्थ organization culture बनाना है, और वीकेंड में काम करने का दिखावा करना उसका उल्टा है।
इसके अलावा legal या engineering review छोड़कर एक दिन में customer problem हल करने की बात सार्वजनिक रूप से कहना भी एक ख़तरनाक संकेत है।
शुरुआती startup में culture पूरी तरह अलग होता है, और ऐसे लेख उलटे उपयुक्त लोगों को छाँटने वाले filter की तरह काम करते हैं।
जो code मैं लिखता हूँ, वह ज़्यादातर internal DevEx सुधार या technical debt साफ़ करने के लिए होता है।
legal review छोड़ा नहीं जाता, और production code की बजाय मैं इसे सिर्फ PoC स्तर तक ही रखता हूँ।
founder CTO के लिए code के क़रीब रहना ज़रूरी है, लेकिन संतुलन न खोना ही सबसे अहम है।
CTO की भूमिका हर कंपनी में अलग होती है।
Greg Brockman के Stripe उदाहरण की तरह, कोई CTO technical visionary होता है, कोई organization designer, और कोई infrastructure-केंद्रित होता है।
मेरे मामले में मुझे coding पसंद है और मैं customer और codebase दोनों में गहराई से शामिल रहता हूँ, इसलिए वही value create करने का मेरा सबसे बड़ा तरीका है।
“CTO” जैसी title की परिभाषा काफ़ी अस्पष्ट है।
कोई CTO founder background से आकर खुलकर coding करता है, तो कोई customer-केंद्रित काम करते-करते code access ही खो देता है।
दूसरी ओर, कुछ authoritarian CTO भी होते हैं।
आख़िरकार पहले यह साफ़ होना चाहिए कि CTO किस प्रकार का है, तभी ‘वह coding क्यों करता है’ जैसा सवाल अर्थपूर्ण बनता है।
इस स्थिति में CTO नाम केवल role distinction भर होता है।
CTO strategy और direction पर ध्यान देता है, जबकि VP रोज़मर्रा की engineering management पर फोकस करता है।
यह काम organization build करके हो या सीधे coding करके, इससे फ़र्क नहीं पड़ता।
जब management में बैठा व्यक्ति खुद code लिखता है, तो code review विकृत हो सकता है और टीम भ्रमित हो सकती है।
आख़िरकार संभव है कि वह CTO कम और मन से अब भी developer ज़्यादा हो।
मैं CTO के coding करने का पूरी तरह विरोध नहीं करता, लेकिन इस मामले में CTO की भूमिका ठीक से निभती हुई नहीं लगती।
असली technical leadership founding engineer संभाल रहा है, जबकि compensation structure में उसे काफ़ी कम मिलता है—यही समस्या है।
अगर किसी CTO के पास reporting structure नहीं है और वह सिर्फ coding कर रहा है, तो वह strategy की तुलना में ज़्यादा senior developer की भूमिका के क़रीब लगता है।
मुझे भी ऐसा प्रस्ताव मिला था, लेकिन आख़िर में वह सिर्फ औपचारिक title निकला।
organization बड़ा होगा तो लगता है कि role बदल जाएगा।
छोटे startup में टीम के साथ sprint चलाना, schedule फिसलने पर वजह सुलझाना, और burnout हुए लोगों का ध्यान रखना—यही मेरा काम है।
लेकिन लेख को देखें तो अगर टीम के पास hot AI project तक आज़माने की भी फुर्सत नहीं है, तो वह organization की समस्या है।
CTO को खुद coding करने के बजाय ऐसे systemic bottleneck हल करने चाहिए।
हर कंपनी में “senior” या “head” की भूमिका पूरी तरह अलग होती है।
CTO जब coding में बहुत ज़्यादा डूब जाता है, तो उससे पैदा होने वाली समस्याएँ साफ़ हैं।
PR review distortion, अपने मुख्य काम की उपेक्षा, role confusion, टीम की autonomy में दखल आदि।
“CTO को coding नहीं करनी चाहिए, सिर्फ strategy करनी चाहिए” जैसी सोच यांत्रिक सोच है।
तकनीकी कंपनी का सार value deliver करना है, और कभी-कभी CTO का सीधे एक बड़ा feature एक दिन में बना देना ही सबसे मूल्यवान काम हो सकता है।
वह KPI meeting से कहीं ज़्यादा productive दिन हो सकता है।
कभी-कभी C-level के लिए सीधे ज़मीनी समझ वापस पाना भी ज़रूरी होता है।
कुछ लोग CTO सिर्फ इसलिए बने हो सकते हैं क्योंकि वे co-founder हैं।
अगर वे इसी approach के साथ किसी दूसरी कंपनी में जाएँ, तो संभव है कि वे staff engineer स्तर तक भी न पहुँचें।
आख़िर में, कंपनी website के pricing page पर असली कीमतें नहीं होना भ्रम पैदा कर सकता है, इसलिए उसे ठीक करने की ज़रूरत है।