इंजीनियरिंग लीडरशिप के संशोधित नियम

• AI टूल बदलाव और hypergrowth माहौल में पिछले 1 साल में परखे और फिर से परिभाषित किए गए इंजीनियरिंग लीडरशिप के 5 प्रमुख नियमों और उन्हें समर्थन देने वाले वास्तविक प्रोजेक्ट उदाहरणों का सारांश
• माइग्रेशन अब टीम के बजाय कोई व्यक्ति 95% तक लीड कर सकता है और इसे पहले के 10% समय में पूरा किया जा सकता है; शुरुआती लागत घटने पर व्यक्तिगत निर्णय के प्रभाव बढ़ जाते हैं
• पहला ड्राफ्ट कोड लगभग मुफ्त है, लेकिन काम करने वाले कोड की लागत tests, CI/CD जैसे डेवलपमेंट harness पर निर्भर करती है, इसलिए वह मुफ्त नहीं है
• अधिकांश processes के default cases को agents से पूरी तरह automate किया जा सकता है, और code review का पहला pass भी अच्छे harness के साथ इंसान से तेज और अधिक प्रभावी होता है
• AI के फायदे सच में पाने के लिए domain context वाली स्थायी टीमें और तेज, मजबूत decision-making prerequisites हैं

---

पृष्ठभूमि

• 2014 की शुरुआत से 2020 के अंत तक hypergrowth माहौल में काम किया; hypergrowth की सबसे बड़ी वैल्यू यह है कि गलतियां अगले साल नहीं, अगले महीने सामने आ जाती हैं (तेजी से चलेंगे तो समस्याएं बड़े रूप में फूटती हैं)
• हाल में hypergrowth फिर याद आने की वजह Imprint की तेज business growth, पिछले साल की बड़े पैमाने पर hiring, और AI टूल बदलाव है, जिससे काम करने की संभव गति बदल गई है
• यह लेख दोबारा परिभाषित leadership rules और पिछले 1 साल के उन ठोस projects को साथ में संक्षेपित करता है जिनसे ये भरोसा बना

संशोधित नियम

1. माइग्रेशन टीम नहीं, व्यक्ति भी कर सकता है

• जटिल और बड़े बदलाव भी lead करने वाला व्यक्ति या टीम 95% ownership ले सकता है और पहले की तुलना में 10% समय में पूरा कर सकता है
• शुरुआती लागत जितनी कम होती है, हर migration की quality के reward/penalty उतने बड़े हो जाते हैं
  • छोटा defect भी साथ में maintain करने वाले सहकर्मियों के software mental model को तोड़ देता है
• कंपनी पर व्यक्तिगत निर्णय का प्रभाव पहले से कहीं अधिक बड़ा है

2. पहला ड्राफ्ट कोड लगभग मुफ्त है, लेकिन काम करने वाले कोड की लागत development harness पर निर्भर करती है

• यह वह दौर है जब सभी को code लिखना चाहिए, लेकिन messy edge cases से बचते हुए अच्छी तरह काम करने वाला code लिखना अब भी कठिन है
• यह कठिनाई tests, CI/CD, validation environments, change previews जैसे development harness पर निर्भर करती है
• भले ही कंपनी में "सब coding करें", बात यह नहीं कि marketing team server allocation घटा दे; असली मुद्दा यह है कि क्या ऐसी boundaries मौजूद हैं जिनके भीतर वे सुरक्षित रूप से contribute कर सकें (software लिखकर customization की अनुमति देने वाले SaaS products जैसा)
• 2 साल पहले engineering speed बढ़ाने के लिए जो चीजें सबसे valuable थीं, वे आज भी उतनी ही valuable हैं

3. processes के default cases को agents के लिए optimize करें

• सही harness, controls, domain context और designer के अच्छे judgment के साथ अधिकांश processes के default cases को पूरी तरह automate किया जा सकता है
• इंसानी code review का default case, अच्छे harness के code review से धीमा और कम प्रभावी है
  • harness भी चीजें चूकता है, लेकिन इंसान भी चूकते हैं, और अधिकांश क्षेत्रों में changes अपेक्षाकृत safe होते हैं
  • हालांकि कुछ high-risk areas अपवाद हैं; अगर यह distinction सही पकड़ी जाए तो बिना risk बढ़ाए speed बढ़ती है, और असफल होने पर अनगिनत समस्याएं पैदा होती हैं
• इसके corollary के तौर पर, weekly/biweekly sprints जैसे planning processes बहुत कम altitude पर काम कर रहे हैं, और इंसानी collaborative planning को higher level पर होना चाहिए

4. domain context वाली स्थायी, high-ownership टीमें और भी महत्वपूर्ण हैं

• Uber से मिली सीख: स्थायी और मजबूत टीमें domain context जमा करती हैं, camaraderie बनाती हैं, और strong ownership से जादुई नतीजे देती हैं
• execution cost सस्ती होने के दौर में भी सही काम करना जरूरी है; यह थोड़ा आसान हुआ है, बहुत ज्यादा नहीं
  • उदाहरण: production optimization के लिए जरूरी data कभी collect ही नहीं किया गया था, इसलिए harness का solution reasonable लेकिन गलत था, और एकमात्र समाधान missing information को instrument करना था
• इस आम धारणा से असहमति है कि AI-first companies कुछ genius engineers से चलती हैं; high-judgment individuals भी domain context की कमी से limits पर अटक जाते हैं, इसलिए स्थायी team ही मूल unit है

5. तेज, अच्छी और मजबूत decision-making AI लाभों की prerequisite है

• legal review को automation से replace करना हो तो Legal को उस change के लिए commit करने में सक्षम होना चाहिए, और यह thoughtful design और team की सहयोग करने की इच्छा पर निर्भर करता है
• execution speed बढ़ने का लाभ तभी संभव है जब तेज, मजबूत और अच्छे decisions लिए जा सकें
• यही मुख्य वजह है कि average CTO role 1 साल पहले की तुलना में कहीं अधिक technical और कम bureaucratic हो गया है
  • teams के बीच disagreement होने पर अक्सर वही एक व्यक्ति होता है जो binding decision ले सकता है, इसलिए speed बनाए रखने के लिए लगातार decisions लेने पड़ते हैं
  • यह दावा नहीं कि executives बेहतर decision-makers होते हैं, बल्कि जब executives आपस में aligned हों और decisions का सम्मान करें, तो binding executive decision uniquely powerful होता है

वास्तविक उपयोग के उदाहरण

माइग्रेशन

• 1 साल पहले manual deploys से लगभग हफ्ते में 6 बार deployment → अब हफ्ते में 200–400 deployments; engineers की संख्या 2x है लेकिन YoY 20–30x बढ़ोतरी, deployment और migration operations के पूरे तरीके का overhaul infrastructure team के 2 लोगों ने दो महीने तक 90% किया
• 1 जनवरी को लगभग 25% लोग रोज Claude Code या Cursor इस्तेमाल करते थे → फरवरी के अंत तक 100%; top-down directive के बिना tool quality सुधारकर और non-adopters से बात करके friction हटाया गया, अब लगभग हर PR का first draft harness करता है
• अलग-अलग configuration तरीकों को दो configuration mechanisms में unify किया गया (लगभग कभी न बदलने वाले client/server constants के लिए, और product-specific व अक्सर बदलने वाली values के लिए), individual engineers के independent projects के रूप में
  • एक व्यक्ति ने architecture साफ किया → दूसरे ने reference architecture implement किया → कई लोगों ने इसे दूसरे areas में apply किया; पहले यह कई साल का project होता, लेकिन एक quarter से कम में पूरा हुआ, engineers और non-engineering teams के values manage करने के लिए internal tool सहित
• multi-repo frontend को करीब एक महीने में monorepo architecture में consolidate किया गया; 95% काम एक frontend engineer ने lead किया, shared frontend harness मिला और friction की वजह रहे npm package hosting से पूरी तरह छुटकारा मिला
• frontend code, जिसमें अधिकतर types नहीं थे, उसे पूरी तरह statically typed बनाया गया; एक engineer ने बहुत सारे tokens के साथ कई हफ्तों में यह किया
• बेहतर security defaults और तेज deployment के लिए npm से pnpm पर switch किया गया; एक engineer ने कुछ दिनों तक रोज कुछ घंटे काम किया

काम करने वाले code की लागत development harness पर निर्भर करती है

• design docs या PRs को दूसरी team के engineer की ओर "दीवार के पार फेंकने" वाला तरीका कामयाब नहीं होता; sloppy PRs और design docs सस्ते होते हैं, लेकिन उल्टा नुकसान करते हैं
  • उन्हें साफ और fix करना पड़ता है, और वह context LLM को contaminate कर देता है, जिससे नतीजा शुरुआत से शुरू करने से भी खराब हो जाता है
• जब तक managers खुद changes verify करते हैं, deploy के बाद dashboards देखते हैं और आने वाली समस्याएं हल करते हैं, manager की code contribution बड़ी success है; वरना कोई positive effect नहीं

process default cases का agent optimization

• customer operations team के सभी incoming issues को ऐसे harness से triage किया गया जो teams और open tickets जानता है और data warehouse तक सीमित access रखकर impact estimate करता है; complex, high-skill लेकिन कम रोचक labor को तेजी से handle किया गया
  • edge cases अब भी इंसान triage करते हैं, और human workflow बदले बिना उसी flow में केवल कुछ steps automate किए गए
• code review का first pass वही harness करता है जिसने change implement किया था, लेकिन writing context clear करके; इंसान higher-value feedback पर focus करते हैं
• पिछले quarter में Claude Code और Cowork को पूरी कंपनी में deploy किया गया; fraud team ने खास तौर पर manual work को first-pass automation से replace करने में सक्रियता दिखाई और potential attacks की initial investigation automate की (data से ही आने वाली attribution सहित)
• Jira से Linear पर migration किया गया; ज्यादा powerful MCP और बेहतर Slack integration से agent-first workflow infrastructure मजबूत हुआ, Linear से issues लेकर उन्हें automatically resolve करने वाले internal harness का alpha test लगभग पूरा है

domain context वाली स्थायी, high-ownership टीमें

• joining के समय talented लोग project के हिसाब से areas में तेजी से rotate करते थे और बहुत responsive थे, लेकिन अब हर important area में dedicated small team लगाई गई है जो लगातार invest करती है, और ये teams खुद नई AI techniques का उपयोग करती हैं
• SierraAI launch के बाद team ने लगातार improvement करके इसे सच में उत्कृष्ट स्तर तक विकसित किया; dedicated, focused team के बिना यह outcome संभव नहीं था

तेज, अच्छी और मजबूत decision-making

• configuration approach बदलना विवादित था, इसलिए approach को बार-बार समझाना पड़ा; हर team पर impact अलग था और benefit केवल ecosystem level पर (एक व्यक्ति पूरी team की configuration बना सके) मिलता था, इसलिए bottom-up तरीके से यह कठिन था
• CI/CD pipeline rework भी controversial था क्योंकि उसने deployment और release के mental model को बदला; feature flagging के जरिए deploy और release को स्पष्ट रूप से अलग करने को enforce किया गया
• web monorepo consolidation भी divided opinions वाला controversial decision था, जिसमें unified decision का benefit बड़ा था
• SierraAI adoption में competitors और non-adoption option के साथ कठिन discussions हुए, और cross-functional debate खत्म करने के लिए executive approval की जरूरत पड़ी

समापन

• ऊपर दिए गए examples केवल कुछ representative cases हैं; इनके अलावा भी बहुत कुछ किया गया, और संभव काम का दायरा हर महीने लगातार बढ़ रहा है
• जिन चीजों से गति रुकती है वे बहुत नहीं बदलीं: organizational misalignment, clarity की कमी, खराब technical architecture