स्टार्टअप CTO हैंडबुक

स्टार्टअप CTO हैंडबुक

उच्च-प्रदर्शन इंजीनियरिंग टीमों के लिए आवश्यक कौशल और सर्वोत्तम प्रथाएँ

परिचय

• हमेशा सीखते रहें: लेखक को बचपन से ही कंप्यूटर और software programming के प्रति गहरा लगाव था, और इसी से उन्हें निरंतर सीखने के महत्व का एहसास हुआ। एक तकनीकी leader के रूप में सफल होने के लिए लगातार सीखना और आगे बढ़ना महत्वपूर्ण है.
• स्टार्टअप तकनीकी लीडर की दुविधा: अधिकांश स्टार्टअप्स में एक technical co-founder होता है, जो शुरुआती codebase लिखता है और पहले engineers को hire करता है। लेकिन जैसे-जैसे टीम बढ़ती है, तकनीकी leader को management role में जाना पड़ता है, और इस प्रक्रिया में leadership skills की कमी महसूस हो सकती है.

लेखक परिचय

• लेखक ने कई स्टार्टअप्स में अनुभव प्राप्त किया है और तकनीकी leader के रूप में काम किया है। विभिन्न स्टार्टअप्स के अनुभव के माध्यम से उन्होंने तकनीकी leadership के लिए आवश्यक विविध कौशल और चुनौतियों को समझा है.

इस पुस्तक का उपयोग कैसे करें

• यह पुस्तक software engineering teams को manage करने वाले leaders के लिए एक reference guide है, जिसमें विभिन्न विषयों को स्वतंत्र अध्यायों के रूप में शामिल किया गया है। प्रत्येक अध्याय विषय का परिचय देता है, एक overview प्रदान करता है, और सर्वोत्तम प्रथाएँ प्रस्तुत करता है.

बिज़नेस प्रोसेस

• यह समस्या-समाधान के शुरुआती बिंदु के रूप में business process को समझाता है। टीम और कंपनी के आकार के अनुसार process को समायोजित और विस्तारित करने की आवश्यकता होती है.

लोग और संस्कृति

प्रबंधन के बुनियादी सिद्धांत

• प्रबंधन का स्वर्ण नियम: टीम का प्रदर्शन ही manager के प्रदर्शन को मापने का मानदंड है। टीम के सदस्यों को अपना सर्वश्रेष्ठ देने में सक्षम बनाने के लिए उनका समर्थन करना चाहिए.
• professional skills tree: तकनीकी leadership के लिए केवल तकनीक ही नहीं, बल्कि management skills में भी निवेश करना आवश्यक है.

निरंतर सुधार

• Kaizen: टीम और व्यक्ति, दोनों को निरंतर सुधार का लक्ष्य रखना चाहिए। गलतियों को सुधार के अवसर के रूप में लेना चाहिए.

कोचिंग

• manager को coach की भूमिका निभानी चाहिए, ताकि टीम के सदस्य अपना सर्वश्रेष्ठ दे सकें.

प्रबंधन mentor ढूँढना

• leadership transition के लिए management mentor ढूँढना महत्वपूर्ण है। उचित mentor के माध्यम से leadership skills को बेहतर बनाया जा सकता है.

1:1 मीटिंग

• 1:1 मीटिंग टीम सदस्य के साथ संबंध बनाने, उनकी ताकत और कमजोरियों को समझने, और उन्हें अपना सर्वश्रेष्ठ देने में मदद करने का अवसर है.

skip-level मीटिंग

• manager के direct reports के साथ नियमित रूप से मीटिंग करके विभिन्न दृष्टिकोण एकत्र किए जा सकते हैं, और इनके आधार पर business को बेहतर बनाया जा सकता है.

managers के लिए कोचिंग

• middle managers का प्रदर्शन संगठन के प्रदर्शन के लिए महत्वपूर्ण है। निरंतर प्रशिक्षण और समर्थन के माध्यम से managers को विकसित करना चाहिए.

engineers के साथ 1:1 मीटिंग

• engineers के साथ 1:1 मीटिंग उनके सामने आने वाली समस्याओं को सुनने और समाधान खोजने में मदद करने का अवसर है। मीटिंग के उद्देश्य को स्पष्ट रखना चाहिए और उत्पादक बातचीत को आगे बढ़ाना चाहिए.

[GN⁺]

Hacker News की रायें

• ऐसे दस्तावेज़ देखते समय मैं आम तौर पर पहले उस हिस्से पर जाता हूँ जिसे मैं गहराई से जानता हूँ, और देखता हूँ कि वहाँ क्या कहा गया है। यहाँ कहा गया है कि PCI DSS या SOC 2 audit की तैयारी और उसे पूरा करने में आम तौर पर 6–12 महीने लगते हैं, इसलिए आखिरी समय में certification लेने की कोशिश न करें; लेकिन startups को मैं लगभग उलटी सलाह देना चाहूँगा
  खासकर SOC 2 attestation पाना आसान है, और purchase order अटकने से पहले ही proactive होकर पैसा खर्च करना waste है। बेशक, single sign-on setup या protected Git branches जैसी चीज़ें, जो बाद में attestation की नींव बनती हैं, जल्दी कर लेना अच्छा है; लेकिन ये वैसे भी ऐसी basic best practices हैं जिन्हें SOC 2 लेने की योजना न हो तब भी करना चाहिए। अगर कोई बड़ा customer मांग नहीं रहा है, तो मुझे नहीं लगता कि SOC 2 करना ज़रूरी है। अच्छा होगा अगर कोई इस दस्तावेज़ के बाकी हिस्सों को भी जाँच ले

  • अच्छा approach है। मैंने database वाला हिस्सा search किया और वह कुल मिलाकर ठीक लगा। हालांकि 2025 में किसी startup को SQL बनाम NoSQL पर focus करने की ज़रूरत नहीं लगती। popular SQL databases JSON को अच्छी तरह support करते हैं, इसलिए engineers जिन PostgreSQL या MySQL से ज़्यादा familiar हों, वही इस्तेमाल करें, और backup व replication के लिए CloudSQL या RDS इस्तेमाल कर लें
    BI के लिए read replica और कोई ठीक-ठाक visualization tool जोड़ दें, तो काफ़ी लंबे समय तक काम चल सकता है, और Snowflake जैसी चीज़ों पर 5–6 digit रकम खर्च करने से पहले यह पर्याप्त है
  • मेरे अनुभव में, जो companies early-stage startups के साथ deal करने को तैयार होती हैं और SOC 2 report चाहती हैं, वे आम तौर पर contract में 6 महीने के भीतर SOC 2 Type 1 हासिल करना डालकर आगे बढ़ने में ठीक रहती हैं, बस technical person सामने वाली IT team से call करके उन्हें यह भरोसा दिला दे कि capabilities ठीक हैं
  • जहाँ accounting और supply chain processes enterprise ERP के अंदर हों, सिर्फ उस case में मैं विनम्रता से असहमत हूँ। audit न हो सकने वाली processes को बाद में reverse करना बहुत समय और पैसा खाता है, और इस दौरान business चलता भी रहना होता है; इसलिए इस खास मामले में पहले दिन से audit-friendly बनाना सस्ता और बेहतर लगता है
  • यह सलाह industry के हिसाब से काफी अलग-अलग लागू हो सकती है। अगर आप personally identifiable information संभालने वाला B2B product बेच रहे हैं, तो pitch meeting में मज़ाक न बनने के लिए SOC 2 लगभग ज़रूरी है
    funding situation के हिसाब से Secureframe जैसी automated SOC 2 compliance checklist service का खर्च कुछ हजार dollars हो सकता है, और यह सिर्फ best practices follow कराने में ही मदद नहीं करती, बल्कि चीज़ों को SOC 2 के हिसाब से खास तरीके से व्यवस्थित करती है, जिससे audit भी आसान होता है। किसी ऐसी organization को, जहाँ non-compliant processes पहले से गहराई तक जमी हों, SOC 2 path पर लाने में लगने वाले development और project management time की तुलना में यह बड़ा investment नहीं है
  • compliance के बारे में मुझे बहुत नहीं पता, लेकिन यह काफी अजीब लगता है। SOC 2 को सरसरी तौर पर पढ़ने पर लगता है कि audit से पहले कई महीनों तक बहुत ज़्यादा evidence collection चाहिए होता है; अगर आपने पहले से time नहीं लगाया, तो बाद में कैसे पता चलेगा कि क्या-क्या तैयार रखना है
    SOC 2 attestation आसानी से मिल सकता है, यह बात भी इस topic पर दूसरों से सुनी बातों के ठीक उलट है। आम तौर पर मैंने सुना है कि यह बहुत मुश्किल और time-consuming होता है, इसलिए सोच रहा हूँ कि मैं क्या miss कर रहा हूँ। अगर सच में यह आसान काम है, तो उम्मीद है मैं गलत साबित होऊँ

• VP या CTO बनने पर coding बंद कर देने की बात मैं अक्सर देखता हूँ। मैं समझता हूँ कि management skill coding skill नहीं है, लेकिन यह समझना मुश्किल है कि लोग keyboard क्यों छोड़ देते हैं और अपनी पहली superpower क्यों waste करते हैं
  आप शुरुआत से अंत तक technical CTO बने रह सकते हैं। team और company को ऐसी service की तरह treat करें जिसे active contribution, maintenance और on-call support चाहिए, और साथ ही अकेले भी और team के साथ भी खुद हाथ गंदे करके बनाते रहें

  • VP/CTO level पर code contribute और maintain करने का time नहीं होता। अगर time है, तो वह title शायद symbolic होगा। जैसे 3 लोगों वाली startup team का “CTO”
    असली problem career की शुरुआत में ऐसा role लेने की है जिसमें coding का time न हो। जैसे architect role जिसमें बस whiteboard पर boxes बनाते हैं और meetings में घूमते रहते हैं, या ऐसा role जो असल में management है लेकिन नाम “tech lead” रखा गया है। code न लिखने की आदत पड़ जाती है, और कुछ साल बाद जब नई job ढूँढनी पड़ती है, तो coding role interviews में इस सच्चाई के साथ जाना पड़ता है कि programming career का बड़ा हिस्सा code लिखे बिना बीता है। बहुत लोगों के लिए rhythm जल्दी वापस नहीं आती
  • मेरे अनुभव में समस्या बस इतनी थी कि दिन में उतना ही time होता है। 7 साल तक मेरे direct और indirect responsibility में करीब 20–25 लोग थे, और code में उपयोगी काम कर पाने के लिए सच में बहुत कम time था
    मेरा time उन problems को solve करने में लगाना कहीं बेहतर था जिन्हें बाकी लोग solve नहीं कर सकते थे। कभी-कभी मैं बहुत simple changes लेता था ताकि हमारी process से खुद गुजरकर देख सकूँ कि कहाँ सुधार हो सकता है। रात या weekend में coding करता रहा, लेकिन वह वही feeling नहीं थी, और समय के साथ थोड़ा rust लगना तय है। फिर भी sabbatical के दौरान पूरे दिन hands-on coding करना सच में मज़ेदार था
  • अगर आप सिर्फ individual contributor नहीं हैं, तो दूसरी priorities आ जाती हैं। इसलिए individual contributor वाला काम कभी भी interrupt हो सकता है। तब आप critical path के करीब का काम नहीं ले सकते; अगर लेते हैं तो दूसरों को block करेंगे या काम hand off करना पड़ेगा
    reviews या design meetings हो सकती हैं, लेकिन core work लेने पर आखिरकार problem आती है
  • मुझे नहीं लगता कि इसका एक ही सही जवाब है, लेकिन एक point के बाद VP/CTO के code contribution की तुलना में अगले key engineer को hire करना, competition से आगे रहने के लिए technology roadmap बनाना, या engineering org को company के बाकी हिस्सों के साथ align करना कहीं ज्यादा leverage देता है
    VP/CTO जो code लिख सकता है, team में कोई और भी लिख सकता है, शायद बेहतर भी। जबकि ऊपर गिनाए गए दूसरे काम company में VP/CTO ही सबसे अच्छी तरह कर सकता है। team और company के लिए ज़्यादा महत्वपूर्ण कामों की खातिर hands-on technical work का बड़ा हिस्सा छोड़ देना काफी reasonable decision है
  • मेरा पिछला CTO role 40 लोगों की team के साथ था और पहले दिन से ही मैं पूरी तरह overloaded था। time management में अच्छा होने के बावजूद ऐसा था। संभव होता तो अपने time का 50% programming में लगाना चाहता, लेकिन उसके लिए time नहीं था, और ऐसा support structure भी नहीं था जिसे hand off कर सकूँ; उसे खुद मेहनत से बनाना पड़ा। वही अपने आप में time न होने की एक और वजह था
    coding जारी रखने का idea अच्छा है, लेकिन आम तौर पर आपको salary इसके लिए नहीं मिलती। मैं खुद को बहुत strong developer मानता हूँ, लेकिन ऐसे developers CTO salary से कम cost में मिल सकते हैं। ज्यादा महंगे CTO का वही काम करना inefficient है। संदर्भ के लिए, कुछ साल बाद मैं individual contributor role में वापस आ गया, और बाकी career भी ऐसे ही बिताने का सोच रहा हूँ

• मैं कहना चाहूँगा कि synchronous chat जैसी कोई चीज़ नहीं होती
  अगर कुछ synchronous होना चाहिए, तो उसे chat window में नहीं करना चाहिए। कम से कम तब तक नहीं, जब तक यह सहमति न हो कि “कुछ मिनटों तक real-time chat पर focus करते हैं।” remote हैं तो call करें, onsite हैं तो आमने-सामने बात करें। chat में message डालकर तुरंत जवाब की उम्मीद नहीं करनी चाहिए

• जानना चाहूंगा कि क्या “दो टीमों” वाले सिस्टम में कभी ऐसा उदाहरण रहा है जहां नाराज़गी नहीं हुई। पता नहीं क्या ऐसे मामले भी थे जहां लोग स्वाभाविक रूप से future team में जाना नहीं चाहते थे
  कागज़ पर यह अच्छा idea लगता है, लेकिन व्यवहार में यह सचमुच ठीक से चलेगा, इस पर भरोसा करना मुश्किल है। मैंने इसका सबसे करीब रूप एक library team में देखा है, जो design system और components जैसी services बनाती थी ताकि दूसरी teams उनका इस्तेमाल कर सकें

  • मेरी पिछली नौकरी में एक on-premises product version था जिसके end-of-support होने वाले version के लिए company ने बहुत लंबे समय का extended support बेचा था। एक छोटी team, शायद करीब 3 लोग, सिर्फ यह सुनिश्चित करने के लिए जिम्मेदार थी कि वह version supported रहे, pipelines चलती रहें, और जरूरत पड़ने पर बड़े fixes भी deploy किए जा सकें
    जब तक वे यह जिम्मेदारी निभाते थे, बाकी समय में वे company के लिए मूल्यवान समझे जाने वाले काम स्वतंत्र रूप से कर सकते थे। यह काफी अच्छा सौदा था। बाकी लोग उस छोटी team के आभारी थे कि वह गंदा काम संभाल रही थी, और maintenance team खुश थी कि बचे हुए समय में वे उन चीजों को ठीक कर सकते थे जो हमेशा खटकती थीं, या research कर सकते थे। details याद नहीं हैं, लेकिन याद है कि कुछ काफी बढ़िया improvements और research outcomes निकले थे। उस team के लोग बहुत काबिल और self-driven थे, इससे success में मदद मिली, लेकिन cost भी ज्यादा आई
  • किताब में लगता है कि इस समस्या का समाधान regular rotation बताया गया है। Microsoft blog post हर हफ्ते कुछ team members को दोनों teams के बीच बदलने की सलाह देता है, और customer team को temporary team के रूप में define करने को कहता है
    असल में मैंने कुछ जगहें देखी हैं जहां पूरी तरह अलग teams ने अच्छा काम किया। games में engine team और game team के बारे में सोचिए। मेरी एक पुरानी role में, game team के भीतर भी हम 6–12 weeks की features लेते, उन्हें release करते, फिर maintenance, updates और technical debt संभालते थे। अभी release की गई चीज़ मुख्य focus होती थी, लेकिन पुराने काम पर वापस जाने का समय भी था, और दूसरी teams भी इसी cycle में रहती थीं, फिर 6–8 weeks बाद नए feature पर onboarding होती थी, और यह दोहराया जाता था
  • पहले कभी दो-team वाले system का experiment किया था। feature development Red Team करती थी, और stability व bug fixes Blue Team संभालती थी
    इसे fixed teams की तरह नहीं, बल्कि एक workflow की तरह treat किया था, जहां लोग हर sprint, यानी हर 2 weeks में इधर-उधर जाते थे। करीब 3 months तक यह अच्छा चला, लेकिन उसके बाद fit नहीं बैठा, और तब तक organization बढ़ चुकी थी, इसलिए teams को business capabilities या domains के around फिर से organize किया गया
  • इसी तरह, एक rotation system आजमाया था जिसमें engineers एक-एक हफ्ते support और bug reports संभालते थे। पूरी तरह अलग “दो teams” वाले जाल से काफी हद तक बचा जा सका। https://news.ycombinator.com/item?id=43337703#43339972 में थोड़ा और लिखा था
  • अगर “customer team” के पास पर्याप्त resources हों और compensation भी उचित हो, तो शायद वे “future team” में जाना ही न चाहें। लेकिन अलग न करने पर भी आम तौर पर maintenance भूखी रह जाती है और नए features सारी attention और resources ले जाते हैं। दो teams में बांटने से तो उल्टा यह और खराब होने की संभावना ज्यादा लगती है

• ऐसे resources को Bible की तरह इस्तेमाल करने के लिए नहीं, बल्कि responsibilities और concerns का व्यापक overview देने के लिए अच्छा माना जाना चाहिए
  अगर आपके पास कोई अच्छा advisor नहीं है, या आपने किसी सचमुच शानदार व्यक्ति के under काम नहीं किया है, तो इस position पर पहुंचने पर कोई आपके बगल में बैठकर यह list नहीं बताता कि किन चीजों का ध्यान रखना है। हर section आपको पूछने पर मजबूर करता है: “हमारा जवाब क्या है?”, “क्या हम सहमत हैं?”, “क्या हमारा process बेहतर है?”, “मैं क्या miss कर रहा हूं?” — और यही मददगार है

• “दो teams” का separation इतना स्पष्ट लिखा है, यह देखकर हैरानी है। यह ठीक-ठाक चीजें release करते रहने का शानदार तरीका है, जब तक कि उनका cost बहुत ज्यादा न हो जाए
  अगर software बनाने वाले मूल लोगों तक लौटने वाला feedback loop काट दिया जाए, तो वे लोग थोड़े समय के लिए खुश हो जाते हैं और बाकी लोग थोड़े समय के लिए दुखी। फिर feature team दोबारा disturb नहीं होना चाहती, और customer team को किसी चीज़ को ठीक से fix करने के लिए resources नहीं मिलते
  इससे भी बुरी बात यह है कि feature team line ship करने के अलावा कुछ सीखती ही नहीं। समय के साथ चीजें धीमी और महंगी इसलिए होती जाती हैं क्योंकि आपने अच्छे software development का इकलौता fitness function हटा दिया है: negative feedback को development के source में वापस integrate करना। एक असली CTO leadership handbook को साफ कहना चाहिए: “developers को release करते हुए भी बेहतर होने में मदद करना आपकी जिम्मेदारी है, और developers हमेशा इसे पसंद नहीं करेंगे”

  • “feature team को customer support work से बाधित हुए बिना future पर 100% focus करने देता है” का मतलब करीब-करीब यह है कि feature team को अपने छोड़े हुए विनाश के बारे में कुछ पता न रहे और ship iceberg से पूरी तरह टकराने तक चलती रहे
    sales-backed feature team और customer-facing लोगों द्वारा push की गई maintenance team के बीच merge conflicts भी पैदा होते हैं। जब तक “customer team” को किसी बाद में निकल जाने वाले phase की तरह दिखाया जाता है, priority fight में कौन जीतेगा यह साफ है। “individual engineers, खासकर juniors, के सीखने और बढ़ने का एक और रास्ता” आखिरकार “seniors गंदगी साफ नहीं करना चाहते, इसलिए juniors से करवाते हैं” जैसा सुनाई देता है
  • related बात यह है कि जिन companies में मैंने काम किया और जहां platform team थी, वे आम तौर पर over-engineering से संक्रमित थीं। यहां platform team से मतलब tools, practices और common code manage करने वाली तीसरी support team जैसी चीज़ है
    ऐसी teams उन लोगों को आकर्षित करती हैं जो features deploy करने और bugs fix करने के काम को नीचा समझते हैं और problems को जरूरत से ज्यादा abstract करना चाहते हैं। bug fix करने के बजाय वे कहते हैं कि bugs शुरू से पैदा ही न हों, इसके लिए वे लगातार और complex abstractions बनाते हैं, और नतीजा जाहिर है
  • यह PM का काम है। customers के साथ काम करने और feedback के आधार पर यह vision तय करने के लिए एक या कुछ लोगों की जरूरत होती है कि सभी features कैसे एक साथ fit होंगे
    customers, खासकर non-technical customers, के पास coherent product vision नहीं होता, और वे अक्सर बाकी plans की परवाह किए बिना बस तुरंत वाला fix चाहते हैं। customers आपस में communicate नहीं करते, इसलिए feedback conflict भी कर सकता है। अगर यह burden developers पर डाल दें, तो developers को codebase जानने और उसे अच्छी तरह maintain करने की technical capability के साथ-साथ सारी communication भी manage करनी होगी, और thoughtful decisions लेने के लिए सभी developers के पास वही consistent vision होना चाहिए। आजकल जब developers infrastructure तक manage करते हैं, तो practically एक ही व्यक्ति दो-तीन jobs कर रहा होता है
  • इसे compensate करने के लिए हर sprint या कुछ sprints के बाद teams बदली गईं। लोगों को ज्यादा diverse experience मिला, और अगर वे bug-heavy features बनाते, तो अंत में उन्हें खुद ही fix करना पड़ता, इसलिए feedback भी लगातार मिलता रहा
    लगता है लोगों को यह तरीका कहीं ज्यादा पसंद आया। क्योंकि वे हमेशा सिर्फ bugs fix करते-करते थकते नहीं थे, और आपने जिस feedback break को insightfully बताया, उससे भी बचा जा सका
  • developers को अपना बनाया software operate और maintain करना चाहिए। principle इतना ही सरल है

• इस समय तक मैंने कितने interviews किए हैं, गिनना मुश्किल है, इसलिए इससे थोड़ा सहमत होना कठिन है। एक मुश्किल यह है कि intake stage में applicants बहुत ज़्यादा हो सकते हैं या होने की संभावना रहती है, और इस stage पर आम तौर पर recruiting team ही applicant से interact करती है
  उदाहरण वाले सवाल डालना ठीक है, लेकिन unqualified candidates को filter करने के लिए yes/no या scale-type सवालों के बजाय अलग तरह के सवाल चाहिए। मुझे ऐसे बहुत आसान सवाल पसंद हैं जिनका साफ़ जवाब हो। हैरानी की बात है कि कई लोग JavaScript में “बहुत comfortable” बताते हैं, फिर भी नहीं जानते कि === क्या है। इसलिए मैं “JavaScript का strict equality operator क्या है” जैसा सवाल पूछता हूँ। कोई भी JavaScript programmer यह जानता होगा, लेकिन सिर्फ़ ऐसा एक सवाल भी applicant pool के 50% को filter कर देता है और organization का बहुत सारा समय बचाता है

• culture fit की बात बहुत होती है, लेकिन उसका बड़ा हिस्सा कंपनी को नुकसान पहुँचाने वाली छिपी discrimination की परत को ऊपर लाता हुआ लगता है। मुझे लगता है कि cultural openness सफलता का factor है, और discrimination उलटी दिशा में ले जाता है
  “सबसे अच्छे leaders success rate track करते हैं, hiring mistakes स्वीकार करने से नहीं डरते, धीरे hire करते हैं और जल्दी fire करते हैं” वाली पंक्ति पढ़कर मन करता है कि वह image पोस्ट करूँ जो JWZ(Jamie Zawinski) तब दिखाते हैं जब वे इस site की ओर इशारा करने वाला referrer header detect करते हैं। Google पर देख लें कि Jamie Zawinski ने Y Combinator के बारे में क्या कहा था। वे Netscape के उस decision के लिए भी credit पाने वाले व्यक्ति हैं जिसमें Netscape Navigator को open source किया गया, और उस browser rendering engine तक पहुँचे अधिकांश काम के लिए भी। इसलिए Firefox मौजूद है

  • “culture fit” को छिपी discrimination मानना एक cynical interpretation है, और मैंने जिन मामलों में देखा है, वहाँ इसका इस्तेमाल ज़्यादा अक्सर candidates को ऐसे काम से बचाने के लिए हुआ जिसे वे पसंद नहीं करेंगे
    मेरी शुरुआती नौकरियों में से एक में, hiring criteria में culture fit जैसा कहा जा सकने वाला सब कुछ ban करने की कोशिश हुई थी। नतीजा यह हुआ कि कुछ लोग join करते ही कंपनी से नफ़रत करने लगे और कुछ हफ्तों या महीनों में छोड़कर चले गए। एक candidate planning और predictability पर ज़ोर देता था, और शिकायत करता था कि पिछली कंपनियाँ बहुत तेज़ चलती थीं। हम startup थे, और उम्मीद के मुताबिक उसे कंपनी पसंद नहीं आई। लेकिन hiring decision process में ऐसी चिंता बताने की अनुमति नहीं थी, क्योंकि इसे “culture fit” मानकर discrimination की ओर ले जाने वाला समझा गया था। इसी तरह की कुछ और घटनाओं के बाद वह policy चुपचाप गायब हो गई, और फिर से engineering culture के साथ compatibility assess करना संभव हो गया
  • हर employment process discrimination करता है। अहम बात यह है कि किन traits को favor या disadvantage किया जा रहा है, और क्या exclude किया जा रहा है
    “culture fit” कुल मिलाकर communication efficiency और high trust पाने के बदले thought diversity का कुछ हिस्सा छोड़ने वाला trade-off है। लोगों को पहले से पता होता है कि कैसे behave करना है और एक-दूसरे से क्या expect करना है, इसलिए बहुत guidelines बनाने की ज़रूरत नहीं पड़ती, लेकिन वे groupthink और related cognitive biases के लिए ज़्यादा vulnerable हो जाते हैं। बात कुछ ऐसी है: “इस जहाज़ में इंद्रधनुष के सभी रंग हैं, लेकिन हमारे Klingon भी सोचते हैं कि Klingon बुरे हैं।”
  • इस digression को follow करते हुए search किया, लेकिन first page के results सारे Hacker News पर Jamie Zawinski का ज़िक्र करने वाले comments ही थे, इसलिए वहीं हार मान ली। इसलिए अच्छा होगा अगर कोई बता दे कि बात क्या है

• “explanation video library बनाओ” वाली सलाह कितनी अच्छी है, यह पक्का नहीं है। UI या animation जैसी specific चीज़ों के लिए यह समझ में आ सकता है
  लेकिन generally text पढ़ना video देखने से ज़्यादा efficient होता है। जल्दी में text में important हिस्से पर jump करना भी video की तुलना में कहीं आसान है

  • कुछ लोगों को video पसंद होता है, कुछ लोगों को text। दोनों ही effort और effect की मांग करने वाले investments हैं। अब generative AI की वजह से दोनों बनाना आसान हो गया है