Startup CTO's Handbook - स्टार्टअप CTO के लिए हैंडबुक

• Startup CTO's Handbook की नवीनतम पुस्तक सामग्री उपलब्ध कराता है, और मुख्य पाठ Markdown में देखा जा सकता है
• पुस्तक Amazon और Audible पर खरीदी जा सकती है
• नवीनतम Markdown संस्करण को PDF के रूप में render किया गया लिंक अभी Coming Soon स्थिति में है, और मूल पांडुलिपि फिलहाल पुराने संस्करण के रूप में Google doc में मौजूद है
• भविष्य के संस्करणों में जोड़, बदलाव, सुझाव और आलोचना को शामिल करने के लिए issue और pull request के माध्यम से योगदान को प्रोत्साहित किया जाता है
• लाइसेंस पुनर्विक्रय किए बिना, लेखक का नाम और attribution बनाए रखते हुए, और बाद के संस्करणों को समान या मिलते-जुलते लाइसेंस के तहत जारी करने की शर्त पर कॉपी, संशोधन और पुनर्वितरण की अनुमति देता है

[GN⁺]

Hacker News की रायें

• कुछ बातों से मैं निश्चित रूप से सहमत हूँ। उदाहरण के लिए, सभी meetings record करना मुझे सही लगता है। लेकिन performance management[0] जैसे हिस्सों में ऐसी कई बातें हैं जिनसे मैं व्यक्तिगत रूप से सहमत नहीं हूँ
  यह ज़रूरी नहीं कि आलोचना ही हो; मेरा मतलब है कि हर problem area के लिए approach और leadership style अलग हो सकते हैं। उम्मीद है कि इस guide को कोई अचूक सत्य की तरह नहीं मानेगा। अगर इसमें लिखी बातें आपके अनुभव से मेल नहीं खातीं, तो मैं सलाह दूँगा कि आप अपने अनुभव पर ज़्यादा भरोसा करें
  [0] https://twitter.com/bcantrill/status/1216491216356823040

  • अगर बात इस तरह की है कि “individual contributor software engineer की competency matrix में coding/feature output speed की एक row हो सकती है, और Level 1~Level 5 system में Level 1 engineer से प्रति सप्ताह X pull requests की अपेक्षा की जाती है”, तो मेरे हिसाब से यह बिल्कुल सही नहीं है
  • व्यक्तिगत रूप से, मैं सभी meetings record करने से बिल्कुल सहमत नहीं होऊँगा। ऊपर से दूसरों से इसकी सहमति माँगना भी मुझे बेहद खराब लगता है
    CTO के रूप में यह request बिना दबाव डाले कैसे की जा सकती है, समझ नहीं आता
  • समझ नहीं आता कि सभी meetings record क्यों करनी चाहिए। क्या वाकई उन्हें दोबारा सुना जाएगा? मेरे लिए यह समय और ऊर्जा की बर्बादी लगता है
  • मैंने Twitter thread पढ़ा, और इस नज़रिए से सच में जुड़ाव महसूस हुआ। मैं पूरी तरह सहमत हूँ कि manager के काम में ऐसे हालात बनाना भी शामिल है जहाँ intrinsic motivation पनप सके
    हालांकि व्यवहार में अक्सर असली skill gaps भी होते हैं, और मुझे लगता है कि अगर manager coach की भूमिका निभाए तो किसी व्यक्ति की growth और performance तेज़ हो सकती है
  • लगता नहीं कि दोनों लोग एक ही चीज़ की तुलना कर रहे हैं
    वे आगे performance कैसे सुधारनी है, इस पर forward-looking performance management की बात कर रहे हैं। लेकिन ज़्यादातर कंपनियों में performance review, compensation और promotion allocation की प्रक्रिया में पिछले performance को rank करने वाली backward-looking evaluation के ज़्यादा करीब होता है
    forward-looking process बढ़िया है, लेकिन अंततः किसी न किसी हद तक past performance rating भी ज़रूरी होती है

• मुझे लेखक के साथ दो कंपनियों में काम करने का मौका मिला है, और यहाँ लिखी चीज़ें जब वास्तव में लागू होती हैं तो कितना बड़ा फर्क डालती हैं, यह शब्दों में बताना मुश्किल है
  असर सिर्फ product या engineering तक सीमित नहीं रहता, बल्कि पूरे organization में फैलता है। कोई भी system या recommendation अंततः अपने organization के हिसाब से बदलनी ही पड़ेगी, लेकिन Zach जिस तरीके से सिखाते हैं उसे जितना हो सके उतना अपनाने की सलाह दूँगा

• मुझे meetings record करना पसंद है। इसलिए नहीं कि जब team blame game शुरू करे तो उसे evidence की तरह इस्तेमाल किया जाए, बल्कि इसलिए कि meetings और discussions को दोबारा देख पाना सच में अच्छा है
  अगर किसी अहम discussion या alignment meeting में मुझे अपनी क्षमता का काफी हिस्सा लगाना पड़ रहा हो, तो topic पर focus करते हुए साथ-साथ notes लेना और सब कुछ याद रखना मुश्किल होता है। यह पता हो कि recording है, तो meeting के दौरान मैं पूरी तरह focus कर सकता हूँ, अच्छे सवाल पूछ सकता हूँ, और assumptions validate कर सकता हूँ
  अगले दिन call दोबारा सुनते हुए pause कर सकता हूँ, 2x·3x speed पर सुन सकता हूँ, personal notes बना सकता हूँ, minutes या internal summary लिख सकता हूँ, thinking में inconsistencies पकड़ सकता हूँ, या अपने schedule के हिसाब से AI note-taking tool चला सकता हूँ
  अगर कोई बीमार हो, सास को airport से लेने जाना हो, उसी समय दूसरी meeting हो, या किसी important alignment meeting के एक हफ्ते बाद join किया हो, तब भी यह मददगार होता है। अगर meeting important नहीं है तो उसे बस ignore कर सकते हैं, और reasonable auto-delete rules रख दिए जाएँ तो बात खत्म
  मुझे सच में नहीं लगता कि लोग उन जगहों में चुपके से ताक-झाँक करने में समय लगाते हैं जहाँ उन्हें नहीं जाना चाहिए, इसलिए मुझे यह बड़ा issue नहीं लगता

  • अगर meeting में inconsistencies ढूँढने के लिए उसे दोबारा देखना पड़ रहा है, तो यह meeting नाम के medium की समस्या है। शुरुआत में thinking की एक inconsistency पूरी meeting को invalidate कर सकती है, और meetings में speed बनाए रखनी होती है, इसलिए ऐसी inconsistency घुसने की संभावना और बढ़ जाती है
    Team meetings बातचीत को उन लोगों की तरफ झुका देती हैं जो बोलने में confident होते हैं। नए joiners या जिनकी primary language अलग है, उनके लिए यह खास तौर पर disadvantage है
    मैं meetings के खिलाफ नहीं हूँ। कुछ लोग लिखने की तुलना में voice से communicate करना कहीं ज़्यादा पसंद करते हैं, और अच्छी team को हर member के पसंदीदा working style को accommodate कर पाना चाहिए
    लेकिन अगर कोई team meeting important है और participants की क्षमता की बहुत मांग करती है, तो उसे meeting नहीं होना चाहिए। Meeting तभी करनी चाहिए जब सभी participants को लगे कि किसी खास conversation के लिए meeting सबसे अच्छा medium है
    Meeting किसी hose के सामने बैठने जैसी है, details छूट ही जाती हैं
  • पूरी तरह सहमत
    Meeting recording और search आसान होने की वजह से हम Google Workspace पर shift हुए। उदाहरण के लिए, calendar event के अंदर recording embedded होती है
    अगर कोई meeting record करने लायक important नहीं है, तो शायद उसे रखने लायक भी नहीं थी
    व्यक्तिगत रूप से मैं दूसरों से ज़्यादा घंटे दिन में लगाता हूँ, लेकिन यह synchronous तरीके से नहीं होता। Important meetings overlap कर सकती हैं, और सिर्फ minutes पढ़ने से बहुत सारी nuances छूट जाती हैं। ऊपर से लोग minutes भी ठीक से नहीं पढ़ते
    फिर भी अगर meeting record हो, तो minutes को जल्दी और सही तरह से review करना संभव होता है, इसलिए यह बहुत उपयोगी है। इसी वजह से मैं meeting recording को काफी strongly push कर रहा हूँ
  • सफल companies में blame game के लिए कोई जगह नहीं होती। CTO के रूप में मैं अपनी failures और अपनी team की failures की जिम्मेदारी लेते हुए lead करता हूँ
    असली कारण जितनी जल्दी समझ आएगा, problem उतनी जल्दी ठीक होगी। इस concept और इसे company में लागू करने का तरीका समझने के लिए पूर्व Navy SEAL Jocko Willink और Leif Babin की Extreme Ownership की मैं strongly recommendation करता हूँ
    ऊपर बताई वजहों से asynchronous meeting participation शानदार है। यह meetings की जानकारी को searchable बना देता है। अब meetings पर natural language processing से subtitles लगाए जा सकते हैं, और वह content LLM द्वारा खोजा जा सकता है
    फिलहाल हम internal chatbot को Confluence content पर train कर रहे हैं, और इसे recorded meeting content तक expand करने की कोशिश कर रहे हैं
  • आजकल time saving महत्वपूर्ण है, इसलिए इसमें मदद करने वाले कई tools होंगे
    थोड़ा promotion करूँ तो, मैं एक tool https://designpro.ai बना रहा हूँ जो कई sources के input को insights और tasks में बदलता है। Call transcripts से insights निकालने में मैंने इसे इस्तेमाल किया है और जानता हूँ कि यह सच में काम करता है
  • बस यह पक्का कर लेना चाहिए कि सामने वाले को पता हो कि recording हो रही है और उसने consent दिया है

• हाल ही में CTO बना हूं, और सबसे बड़ी मुश्किलों में से एक CEO के साथ communication है। किताब में शायद इस बारे में लिखा हो, लेकिन मैंने सिर्फ़ index पढ़ा है।
  पिछले 8 महीनों से CEO alignment meetings नहीं चाहता, कुछ भी plan नहीं करना चाहता, vision lead नहीं करना चाहता, और सिर्फ़ killer feature पर focus करना चाहता है।
  वह users के साथ test करने के लिए mockup या prototype बनाना भी नहीं चाहता, और अगर बनाना है तो कहता है कि वह सुंदर होना चाहिए। जो काम एक हफ़्ते से ज़्यादा ले, वह नहीं करना चाहता, और effective meetings से भी इनकार कर चुका है।
  मेरा कहना यह है कि किताब में जो चीज़ें नहीं हैं, वही चीज़ें मुझे सबसे ज़्यादा कमी की तरह लगती हैं। वैसे, हम सिर्फ़ 3 cofounders हैं।

  • ऐसी स्थिति देखी है। कम-से-कम जिस context में मैंने इसे झेला, वह इसलिए हुआ क्योंकि CEO ने CTO को लगभग बराबरी का व्यक्ति नहीं माना।
    CTO, CEO का “tech person” था, और उनमें सबसे बेहतर या सबसे अहम tech person होने की वजह से उसे CTO title मिला था—कुछ ऐसा ही।
    सुनकर दुख होता है, लेकिन आपको यह संभावना सोचनी होगी कि CEO आपको बस एक शानदार title वाला another employee मान रहा हो। अगर mindset ऐसा है, तो CEO को अपने decisions में आपको शामिल करना waste लगेगा।
  • बहुत पहले, जब मैं ज़्यादा युवा था, YC Startup School गया था, और audience में किसी ने Marc Andreessen से पूछा कि cofounder से कब अलग होना चाहिए, यह कैसे तय करें।
    Marc का जवाब मुझे आज भी हूबहू याद है: “अगर शक है, तो शक करने की ज़रूरत नहीं।”
    मुझे पता है कि यह बहुत बड़ा decision है और internet पर किसी एक comment से आपको convince नहीं किया जा सकता, फिर भी कहूंगा: 8 महीने पहले ही बीत चुके हैं। शायद आपने ठीक करने लायक सब कुछ आज़मा लिया होगा।
    अब ऐसा क्या बचा है जो आपने नहीं किया? logically, आप यहां क्या होने की उम्मीद कर रहे हैं? जब आप आसानी से किसी productive जगह जा सकते हैं, तो सोचिए कि आप इस situation में अपनी ज़िंदगी और कितना invest करने वाले हैं।
  • मेरी मां की बात बताऊं तो, उन्होंने कहा था: “इससे तुम्हारा mood खराब है? चिंता मत करो। यह बस और खराब ही होगा! हाहाहा!” और फिर फोन काट दिया।
    गंभीरता से कहूं, तो आप अभी जिस चीज़ से टकराए हैं, वही इस काम को मुश्किल बनाती है।
    पहला, दूसरे executives के साथ 1:1 set करने की कोशिश करें। CEO के अलावा जिन executives के साथ आप काम करते हैं, अगर वे हैं, तो आप किस situation में आए हैं, इसका ज़्यादा context मिल सकता है। उनकी needs समझेंगे तो broader organization की needs भी दिखेंगी।
    आपको CEO की problems हटाने के लिए hire किया गया है, भले ही CEO explicitly request न करे। executive team में घुलने-मिलने की क्षमता आपकी capability साबित करने के सबसे अच्छे तरीकों में से एक है, और इसके लिए consistency, sincerity, open mind, और सच में मददगार सवाल पूछने की इच्छा चाहिए।
    दूसरा, अगर CEO और executive team regularly मिलते हैं, तो join करने की request करें; अगर ऐसा नहीं है, तो खुद plan करने की कोशिश करें। ideally, CEO के अलावा बाकी executives के साथ पहले alignment कर लें। CEO सभी या ज़्यादातर meetings में न भी आ पाए, तो भी वह initiative की कद्र करेगा और trust भी बनेगा।
    आपने कहा है कि वह पहले ही ऐसी meetings नहीं चाहता, इसलिए शायद आपको CEO पर influence रखने वाले किसी दूसरे executive के ज़रिए indirect तरीके से पहले कदम बढ़ाना पड़े।
    तीसरा, अगर आप CTO हैं, तो CEO कम-से-कम यह पक्का करने के लिए भी कि आप छोड़कर नहीं जा रहे, कुछ हद तक regular 1:1 चाहेगा। weekly, biweekly, monthly—CEO के schedule के हिसाब से कोई cadence ढूंढ लें।
    इस meeting का मकसद CEO के साथ align करना और उन areas पर feedback लेना है जहां आप अच्छा कर रहे हैं और जहां improvement चाहिए। अगर आप यह schedule नहीं कर पा रहे, तो इसे ऐसा environment मानें जहां आप सफल नहीं हो सकते, और छोड़ने की सलाह दूंगा।
    अगर यह meeting schedule करना मुश्किल हो, तो पहले ऊपर के दो approaches पर ज़ोर देकर relationship बनाएं, फिर कोशिश करें। अगर किसी भी frequency पर CEO और दूसरे executives के साथ regular time बिल्कुल set नहीं कर पा रहे, तो आप असल में CTO नहीं हैं, और आपको छोड़ने पर विचार करना चाहिए।
  • जैसा दूसरों ने लिखा है, लगता है आपके साथ founding engineer जैसा ज़्यादा व्यवहार हो रहा है।
    मैंने उस difference के बारे में यहां लिखा था: https://www.mooreds.com/wordpress/archives/2555
    हालांकि planning की कमी और vision drive न करना चिंताजनक है। दोनों early-stage CEO role के core हिस्से हैं। क्या आपको पता है कि वह इतना short-term पर ही focus क्यों कर रहा है? क्या वह funding या sales के लिए MVP push करना चाहता है, या फिर vision ही नहीं है? मैं उस हिस्से में गहराई से जाकर वजह समझने की कोशिश करूंगा। नहीं तो, जैसा दूसरों ने कहा, छोड़ना भी एक option है।
  • अरे, यह तो मेरी पिछली job है।
    क्या आप उस stage तक पहुंच गए हैं जहां आप ज़रूरी short-term steps व्यवस्थित करके बताते हैं और CEO कहता है, “हां ठीक है, हम यही करेंगे”?
    या यह वह शानदार stage है जहां आप SOC2 certification push करते हैं, CEO कहता है “अभी नहीं,” लेकिन sales pitch में कहता है “हम SOC2 certification की ओर बढ़ रहे हैं”?
    चिंता मत कीजिए। schizophrenic आप नहीं हैं।

• Wikipedia DevOps को software development और IT operations को मिलाने वाली practices बताता है, लेकिन इसे “developer machine के अलावा कहीं business software चलना सुनिश्चित करने वाले सारे काम” के रूप में translate करना original definition से थोड़ा अजीब अलग interpretation लगता है।
  खासकर DevOps expert वाला हिस्सा।

  • अच्छा feedback है। मैं यह बात convey करना चाहता था कि DevOps broad है, अक्सर invisible रहता है, और इसलिए अक्सर undervalued या priority से बाहर कर दिया जाता है।
    इसे बेहतर convey करने के लिए फिर से लिखूंगा।

• यहां mention की गई किसी company या person को मैं नहीं जानता। सोच रहा हूं कि क्या दूसरे लोग जानते हैं।
  पढ़ने में समय लगाने से पहले कहूं तो, मुझे शुरू से ही “Chief Technology Officer” कहलाने वाले लोगों पर instinctive suspicion है। क्या यह पढ़ने लायक है?

  • industry experience रखने वाले और entry-level engineering management तक पहुंचे किसी व्यक्ति के लिए इसमें कुछ नया नहीं दिखता।
    target readers शायद वे लोग हैं जिनके पास professional experience बहुत कम या बिल्कुल नहीं है, और जो startup के technical cofounder होने की वजह से CTO title पा गए हैं।
  • मेरी पहली प्रतिक्रिया थी, “author कौन है?” अगर proper CTO track record वाला व्यक्ति हो तो अच्छा होगा, लेकिन text से कुछ भी पता नहीं चलता।
    पिछले 10 सालों में तीन companies में CTO रहा हूं, और शायद अब बूढ़ा हो गया हूं और patience कम हो गई है, लेकिन जैसा दूसरे कह रहे हैं, यह किताब cofounder के रूप में अभी-अभी CTO बने fresh graduates के लिए ज़्यादा लगती है। मैं ऐसे लोगों को technical advice देता रहा हूं।
    मेरे अनुभव में, यह role जितना लंबे समय तक करते हैं, उतना ही Accelerate जैसी books की तरह ज़्यादा concrete information खोजने लगते हैं।

• बोरिंग टेक्नोलॉजी सच में बहुत अहम है। निजी क्षेत्र के startup पहले से ही अस्थिर होते हैं, तो बिना परखी हुई technology से जोखिम और क्यों बढ़ाना?
  उदाहरण के लिए, 2013 से 2016 के बीच एक दौर था जब MongoDB किसी अजीब तरह से default database जैसा बन गया था। ऐसा लगता था कि लगभग एक-तिहाई startups MySQL या Postgres से MongoDB पर चले गए हैं। यह वाकई पूरी तरह अफरा-तफरी और एक मूर्खतापूर्ण आपदा थी

  • पिछले कुछ महीनों में जिन ग्राहकों से मिला, वे सचमुच सभी MongoDB इस्तेमाल कर रहे थे, और उनका data relational था
    ऐसे मामलों में Mongo चुनने की वजह समझना मुश्किल है। schema बनाने और update करने की ज़रूरत न होने से development के शुरुआती कुछ दिन थोड़े तेज़ हो जाते हैं—इसके अलावा कुछ नहीं
    समस्या यह है कि जैसे ही data जटिल होता है और BI जैसी चीज़ों की ज़रूरत पड़ती है, उस शुरुआती फायदे को भारी ब्याज के साथ चुकाना पड़ता है
    वैसे भी data relational न हो, तब भी Postgres का JSON Mongo से बेहतर काम करता है
  • सही है। चमकदार नई technology के पीछे भागने से company business problems हल करने के बजाय उस technology और early-stage problems को सीखने पर focus करने लग सकती है
    कुछ नई technologies गायब हो जाती हैं, कुछ टिक जाती हैं
    मेरे career की शुरुआत में SQL चमकदार नई technology था। मैंने ज़ोर देकर कहा कि company को network databases छोड़कर SQL पर जाना चाहिए, और नतीजा बहुत अच्छा रहा
    traditional C की तुलना में object-oriented programming के साथ भी ऐसा ही था
    कुछ technologies आखिरकार अपने वादे के स्तर तक नहीं पहुंच पातीं, और उन्हें अपनाने वाली organizations के लिए बेड़ी बन जाती हैं
    एक समय ऐसा भी था जब LLM technology को जिम्मेदारी से अपनाने के लिए बहुत जल्दी थी। लेकिन जल्द ही ऐसा समय आएगा जब board पूछेगा कि इसे अपनाया क्यों नहीं गया। बाहरी use cases शायद, और internal use cases तो निश्चित रूप से ऐसे हो सकते हैं
    CTO की कठिन चुनौतियों में से एक नई technology अपनाने का सही समय तय करना है। कब boring technology company के लिए सबसे अच्छी है, कब early technology लाना ठीक है, और कब कोई नई technology इतनी बड़ी accelerator बन जाती है कि उसे अपनाना ही पड़ता है—यह判断 करना होता है
  • हां। Mongo या कुल मिलाकर NoSQL के trend वाले दिन याद हैं। आजकल वे सब meme बनकर रह गए हैं

• CTO को technology-oriented, people-oriented और external-oriented तीन प्रकारों में बांटना दिलचस्प है
  एक बहुत early-stage startup CTO role offer कर रहा है। अभी product नहीं है, बस कुछ basic demos हैं, और वे pre-seed funding की तैयारी में हैं
  सोच रहा हूं कि इस role में सबसे ज़्यादा क्या चाहिए होगा। technology CTO या people CTO? शुरुआत में product बनाना होगा, इसलिए लगता है कि यह मुख्यतः technical role होगा। लेकिन कब तक people-focused CTO में transition करना होगा, यह जानना चाहता हूं। इससे जुड़ी कोई insight या experience हो तो सुनना चाहूंगा

  • सवाल उल्टा भी हो सकता है। पहला, आप क्या बनना चाहते हैं? अभी के आधार पर सोचिए, और करीब एक साल बाद फिर से evaluate कर लीजिए। तय करना होगा कि आप technology person हैं, people person हैं, या बस वही व्यक्ति हैं
    मुख्य रूप से वही role बनिए, बाकी चीज़ों को जैसे-तैसे संभालिए, और जब वे काम बहुत ज़्यादा या महत्वपूर्ण हो जाएं, तो बाकी दो क्षेत्रों में से एक या अधिक संभालने के लिए किसी को hire कर लीजिए
    दूसरा सवाल, जिसका जवाब देना ज़्यादा मुश्किल है, यह है कि वे—यानी दूसरे CXO—आपसे क्या बनना चाहते हैं। यह पहले सवाल के रास्ते में आ सकता है। कुछ मामलों में यह C के बिना CTO होता है: यानी बस एक technical person जिसे क्या करना है बताया जाता है, show-off demos चलवाए जाते हैं, और business का “क्यों” सुनने को नहीं मिलता
    “आखिर CTO होता क्या है” पर मेरे पास bookmark किए हुए कुछ links हैं
    http://www.startuplessonslearned.com/2008/09/what-does-start...
    https://www.allthingsdistributed.com/2007/07/the_different_c...
    Camille Fournier की The Manager’s Path भी recommend करूंगा

• कहा गया है कि “debt को proactively चुकाना overall engineering health के लिए ज़रूरी investment है”, लेकिन कुछ technical debt को चुकाने के बजाय default कर देना overall ज़्यादा सस्ता भी पड़ सकता है
  बशर्ते product manager उसे वसूलने न आ जाए

  • सहमत हूं। अगर project काफी छोटा हो और debt काफी बड़ा, तो कभी-कभी rewrite करना सही होता है
    लेकिन कुछ scale और complexity वाले project का technical bankruptcy तक पहुंचना तभी होता है, जब किताब की सलाह न मानी गई हो। features ship करने के लिए technical debt को ignore करेंगे, तो releases धीरे-धीरे मुश्किल होते जाएंगे और bugs भी बार-बार आने लगेंगे
  • यह analogy एक हद तक ही काम करती है, और यहां मतलब साफ नहीं है। technical debt पर default करने का मतलब क्या है? rewrite? या हार मानकर system बदलते समय आने वाली लागत को बस स्वीकार कर लेना?

• किताब के publish होने पर बधाई
  मैं एक छोटे startup के CTO और एक listed company के VPoE के experience के आधार पर practical ideas share करने के लिए Opinionated Launch(https://opinionatedlaunch.com) लिख रहा हूं
  लिखना शुरू किया तो महसूस हुआ कि topics दो हिस्सों में बंटते हैं: management·team·people वाला हिस्सा और technical हिस्सा। मैं जिस technical side को लेकर ज़्यादा passionate हूं, उसी पर focus करने लगा, और खुशी है कि किसी ने बाकी हिस्सा संभाल लिया