इंजीनियरों को जल्दी ऑनबोर्ड करें (बेहतर डॉक्स से नहीं)
इंजीनियरों को तेज़ी से ऑनबोर्ड करने का तरीका: असली बाधा को ठीक करें – Slack, GitHub और Linear में बिखरा कॉन्टेक्स्ट जिसे कोई wiki नहीं पकड़ता।
By Ellis Keane · 2026-03-31
जब मैं एक ऐसी टीम में शामिल हुआ जिसे खुद नहीं पता था वो कैसे काम करती है
अगर आप सोच रहे हैं कि इंजीनियरों को जल्दी ऑनबोर्ड कैसे करें, तो मुझे अपना ऑनबोर्डिंग अनुभव बताने दीजिए – क्योंकि शायद यही मेरा सबसे अच्छा तर्क है।
2019 में, मैं San Francisco की एक startup में उनके तीसरे इंजीनियर के रूप में शामिल हुआ। CTO – एक प्रतिभाशाली और शानदार तरीके से अव्यवस्थित इंसान – ने पहले दिन मुझे एक laptop थमाया और essentially कहा, "Codebase GitHub पर है। बाकी सब के लिए Slack use करते हैं। शुभकामनाएँ।"
यही था ऑनबोर्डिंग प्रोग्राम।
मैंने अपने पहले तीन हफ़्ते ऐसा काम करते हुए बिताए जिसका, पीछे मुड़कर देखें तो, engineering से कोई लेना-देना नहीं था: पुरातत्व। छह महीने पुराने Slack थ्रेड्स खोदना यह समझने के लिए कि authentication system इस तरह क्यों बनाया गया था। बंद GitHub PRs में स्क्रॉल करना database schema decisions के बारे में बातचीत ढूंढने के लिए जो किसी ने कहीं document नहीं की थी (ज़ाहिर है)। #general में सवाल पूछना जिनका जवाब मिलता था "ओह हाँ, वो – हमने जनवरी में अपना मन बदल लिया था, अपने designer के साथ थ्रेड देखो।"
कौन सा थ्रेड? किस designer के साथ? किस channel में?
वो बुरे manager नहीं थे। वो एक ऐसी दुनिया में काम कर रहे थे जहाँ institutional knowledge केवल लोगों के दिमाग में और चार अलग-अलग tools में बिखरी हुई थी – जो, अगर हम ईमानदार हों, अधिकतर engineering teams का हाल बयान करता है। मैं जो भी सवाल पूछता, उसमें किसी को अपना काम छोड़ना पड़ता, "ऑनबोर्डिंग मोड" में कॉन्टेक्स्ट स्विच करना पड़ता, संबंधित थ्रेड या document ढूंढना पड़ता, और फिर महीनों पहले लिए गए फ़ैसले के पीछे की सोच फिर से बनाने की कोशिश करनी पड़ती। आप लगभग mental gears की चरमराहट सुन सकते थे।
तीन हफ्ते एक इंजीनियर engineering की जगह पुरातत्व करता रहा, साथ में उन सब लोगों की cumulative interruption cost जो मेरे सवालों का जवाब दे रहे थे – यह असली पैसा है, भले ही यह कभी किसी balance sheet पर न दिखे।
वो अनुभव unique भी नहीं था। मैंने एक दशक Vulcan चलाने में बिताया, हमारी design और engineering agency, और उसका एक हैरान करने वाला बड़ा हिस्सा ऐसे organizations में जाने में जो मुझसे भी ज़्यादा अव्यवस्थित थे (एक कम मानक, सच में)। हर client, वही pattern: knowledge थी, बस लोगों के दिमाग में और उन tools में जिन्हें किसी ने connect करने के बारे में नहीं सोचा था।
इंजीनियरों को जल्दी ऑनबोर्ड कैसे करें: Search की समस्या ठीक करें, Docs की नहीं
अधिकतर onboarding playbooks engineer onboarding को content की समस्या मानते हैं। बेहतर docs लिखो! Notion wiki बनाओ! Color-coded milestones के साथ onboarding checklist बनाओ!
Checklists ठीक हैं। मैं आपको अपना "Day 1 – Day 30" template फेंकने के लिए नहीं कहूंगा। लेकिन असली बाधा यह नहीं है कि "हमारे पास पर्याप्त documentation नहीं है।" यह है कि उपयोगी कॉन्टेक्स्ट – गड़बड़, सूक्ष्म, असली चीज़ें – Slack थ्रेड्स, GitHub PR comments, Linear issue descriptions, और उस Figma annotation में रहता है जो एक designer ने नए कर्मचारी के आने से छह हफ्ते पहले छोड़ी थी। हमने collectively दो दशक ऐसे wikis बनाने में बिताए हैं जो बताते हैं कि software क्या करता है, और लगभग कोई समय यह पता लगाने योग्य बनाने में नहीं बिताया कि वो ऐसा क्यों करता है।
कोई wiki "क्यों" नहीं पकड़ता। Wikis वो पकड़ते हैं जो किसी ने लिखने लायक समझा – जो एक नए इंजीनियर को वास्तव में जो जानना चाहिए उससे बिल्कुल अलग बात है।
असली ऑनबोर्डिंग बाधा documentation नहीं है – यह है कि उपयोगी कॉन्टेक्स्ट उन tools में रहता है जिन्हें खोजने के बारे में किसी ने नहीं सोचा। attribution: Chris Calo
जब से मैंने इंजीनियरों को ऑनबोर्ड किया है – पहले एक design agency में, फिर Sugarbug बनाते हुए – मैंने वही pattern बार-बार दोहराते देखा है। नए कर्मचारी जो सवाल पूछते हैं वे लगभग चार categories में आते हैं, और उनमें से केवल एक को पारंपरिक onboarding docs address करते हैं:
Docs क्या cover करते हैं
- Architecture overview – system diagrams, service boundaries, deployment topology
- Local setup – clone, build, run और test कैसे करें
- Coding standards – linting rules, PR conventions, naming patterns
Docs क्या miss करते हैं
- निर्णय इतिहास – यह architecture क्यों, Slack पर discuss की गई तीन alternatives नहीं?
- Tribal knowledge – billing module का असली मालिक कौन है? वो CSS decision किसने लिया?
- Context chains – एक Linear issue जो PR से जुड़ा है जो design discussion से जुड़ा है जो product spec से जुड़ा है
- Active state – अभी किस पर काम हो रहा है, और क्यों?
"Docs क्या cover करते हैं" column वो है जिसके लिए अधिकतर teams optimize करती हैं। मेरे अनुभव में, "Docs क्या miss करते हैं" column वह जगह है जहाँ नए इंजीनियर अपना अधिकतर ramp-up time बिताते हैं – यहाँ असली जवाब रहते हैं, और यहाँ कोई नए कर्मचारियों को point नहीं करता।
यह जानकारी इसलिए नहीं गायब है क्योंकि किसी ने इसे लिखा नहीं। यह लिखी गई थी – एक Slack message में, एक GitHub review comment में, एक Linear issue update में। समस्या discoverability की है, documentation की नहीं।
वो Interruption Tax जिसका कोई बजट नहीं बनाता
जब भी एक नया इंजीनियर पूछता है "हमने यह इस तरह क्यों बनाया?" और एक senior इंजीनियर जो कर रहा था उसे छोड़कर जवाब देता है, तो दो चीज़ें होती हैं। नए कर्मचारी को जवाब मिलता है (अच्छा), और senior इंजीनियर अपनी productive focus का एक बड़ा हिस्सा खो देता है – वो 2 मिनट नहीं जो सवाल में लगे, बल्कि वो लगभग 15 मिनट जो संबंधित थ्रेड ढूंढने, reasoning याद करने, और पहले जो कर रहे थे उस पर वापस focus करने में लगते हैं।
stat: "दिन में कई बार" headline: "एक अकेले नए इंजीनियर की वजह से interruptions" source: "Sugarbug में हमारे अपने onboarding patterns के आधार पर"
जब आप एक ही quarter में दो इंजीनियर hire करते हैं (जो, अगर आप एक growing startup हैं, तो शायद कर रहे हैं), तो आपकी existing team हफ्तों तक genuinely अनुचित संख्या में interruptions absorb करती है। जिन लोगों को आपने velocity बढ़ाने के लिए hire किया था वे temporarily इसे घटा रहे हैं। कोई इसका बजट नहीं बनाता क्योंकि कोई इसे measure नहीं करता – यह बस एक अस्पष्ट एहसास के रूप में दिखाई देता है कि "team इस quarter slower लग रही है" बिना किसी के इसे onboarding से जोड़े।
और जो हिस्सा सबसे ज़्यादा चुभता है: इन सवालों के जवाब already कहीं मौजूद हैं। वे Slack में हैं, GitHub में हैं, Linear में हैं। जानकारी तब capture की गई जब निर्णय लिया गया था। बस वो एक ऐसे tool में है जिसे नए कर्मचारी को खोजने के लिए किसी ने नहीं बताया, एक ऐसे channel में जिसके बारे में उसे पता नहीं, एक ऐसे thread title के नीचे जो context के बिना कोई मायने नहीं रखता।
Connected Context: व्यवहार में इसका मतलब क्या है
इंजीनियर ऑनबोर्डिंग में Connected Context का मतलब है कि एक नया कर्मचारी एक ही interface से आपकी team के हर tool में खोज सकता है – Slack, GitHub, Linear, Notion। केवल keyword search नहीं (Slack की search, सच में कहें तो, सबसे अच्छे में पर्याप्त है और सबसे बुरे में actively hostile), बल्कि contextual search जो चीज़ों के बीच के relationships को समझे।
"Billing module refactor से जुड़ी हर चीज़ दिखाओ" returns करता है: Linear epic, GitHub पर छह PRs, Slack thread जहाँ team ने approach पर debate की, और Notion architecture doc – सब connected, सब chronological order में, कोई पुरातत्व नहीं।
यही concept है: एक नॉलेज ग्राफ़ जो हर tool में आपकी team के काम के बीच relationships map करता है, यह बताते हुए कि किसने क्या, कहाँ और क्यों decide किया – एक जीवंत index बनाता है।
Ben और मैंने यह इसलिए बनाया क्योंकि हम सालों से alternative जी रहे थे। Vulcan में, हम एक साथ कई organizations में design और engineering teams चला रहे थे, और बिना fail हुए, हमारी actual specialties एक चीज़ तक सिमट जाती थीं: glorified human information routers। दो लोग जिन्हें design और build करना चाहिए था, वे अपने दिन "वो चीज़ कहाँ है?" का जवाब देने में बिता रहे थे (एक soul-crushing realization, यकीन मानिए)। यह रुकना था।
Connected Context ज़्यादा documentation लिखने के बारे में नहीं है – यह उस context को discoverable, searchable और linked बनाने के बारे में है जो already आपके tools में मौजूद है। नए इंजीनियरों को यह नहीं जानना चाहिए कि किस Slack channel में खोजें या कौन सा GitHub repo check करें।
यही हम Sugarbug के साथ बना रहे हैं। नॉलेज ग्राफ़ Linear issues को GitHub PRs से, Slack conversations से, Notion docs से जोड़ता है, और पूरी चीज़ को searchable बनाता है। जब एक नया कर्मचारी join करता है, उसके पास team का decision history पहले दिन से available है। (हम onboarding-specific वर्कफ़्लो अभी भी refine कर रहे हैं, honestly – लेकिन underlying graph foundation है।)
इंजीनियर ऑनबोर्डिंग का 3-हफ्ते का Framework
यहाँ वो framework है जो मेरे पास होता तो अच्छा होता जब मुझे वो laptop थमाई गई और "शुभकामनाएँ" कहा गया। अगर आप यह पता लगाने की कोशिश कर रहे हैं कि इंजीनियरों को जल्दी ऑनबोर्ड कैसे करें, तो यह काम करता है क्योंकि यह असली बाधा (discoverability) को address करता है न कि काल्पनिक को (documentation volume)।
हफ्ता 1: Orient करें
नए कर्मचारी को एक "context buddy" दें – कोई mentor नहीं, बल्कि कोई ऐसा जो अच्छी तरह जानता हो कि जानकारी कहाँ रहती है (ज़रूरी नहीं कि सबसे senior person हो – कभी-कभी यह वो person होता है जिसने हाल ही में सबसे ज़्यादा सवाल पूछे हों और चीज़ें कहाँ हैं इसका सबसे ताज़ा नक्शा हो)। Context buddy का काम हर सवाल का जवाब देना नहीं है। उनका काम यह कहना है: "वो निर्णय #backend channel में फरवरी के आसपास लिया गया था, चलो thread ढूंढते हैं।"
अगर आप Sugarbug जैसा Connected Context tool use कर रहे हैं, तो context buddy का काम काफ़ी आसान हो जाता है: "'billing module refactor' खोजो और तुम्हें पूरी decision chain दिखेगी।"
हफ्ता 2: Navigate करें
नए कर्मचारी को अब अपने पहले PRs बनाने चाहिए, लेकिन इससे भी ज़्यादा ज़रूरी, उन्हें यह mental model बनाना चाहिए कि team कैसे communicate करती है। कौन सी discussions Slack में होती हैं? कौन सी Linear comments में? कौन सी GitHub PR reviews में? Communication topology को समझना codebase को समझने जितना ज़रूरी है – शायद पहले महीने में ज़्यादा। (मैंने ऐसे इंजीनियर देखे हैं जिन्होंने एक हफ्ते में codebase समझ ली लेकिन तीन हफ्ते बाद भी उन्हें पता नहीं था कि निर्णय कहाँ ढूंढें।)
हफ्ता 3: Contribute करें
हफ्ते तीन तक, अगर context की समस्या हल हो गई है, तो एक नए इंजीनियर को meaningful contributions देनी चाहिए – इसलिए नहीं कि उन्होंने codebase रट ली है, बल्कि इसलिए कि वे जानते हैं कि किसी को बाधित किए बिना जो चाहिए वो कैसे ढूंढें।
- [x] दिन 1: Local environment चल रहा है, सभी tools तक पहुँच दी गई
- [x] दिन 2–3: Context buddy assign किया गया, communication topology से परिचय कराया गया
- [x] हफ्ता 1: Context buddy के support के साथ 2–3 "good first issues" पूरे किए
- [ ] हफ्ता 2: Independent PRs बना रहे हैं, पूछने से पहले context खोज रहे हैं
- [ ] हफ्ता 3: Design discussions में contribute कर रहे हैं, दूसरों के PRs review कर रहे हैं
- [ ] महीना 2: Independently productive, context buddy के साथ साप्ताहिक check-ins
यह क्यों compound होता है (और Wikis क्यों नहीं)
Connected Context से इंजीनियर ऑनबोर्डिंग को solve करने और एक 47-page Notion wiki से solve करने में अंतर (जिसे कोई maintain नहीं करता – आप जानते हैं कौन सा – आठ महीने पहले किसी ने आखिरी बार update किया था जो तब से चला गया है) यह है कि Connected Context compound होता है। Slack में आपकी team की हर बातचीत, हर PR review, हर Linear issue update – सब index होता है, link होता है, और searchable बनता है। नॉलेज ग्राफ़ बिना किसी के extra काम किए समय के साथ समृद्ध होता जाता है।
आपका दूसरा hire आपके पहले hire के onboarding सवालों से जो uncovered हुआ उससे benefit करता है। आपके पाँचवें hire के पास और भी समृद्ध graph है। दसवें तक, institutional knowledge जो पहले exclusively आपके CTO के दिमाग में रहती थी, distributed, searchable और connected है।
और यही वो हिस्सा है जो मुझे इस approach के बारे में genuinely excite करता है! केवल efficiency gain नहीं – हालाँकि Connected Context try कर रही teams के साथ हमारी early conversations से, ramp-up compression real है। और यहाँ वो हिस्सा है जिसकी मुझे उम्मीद नहीं थी: Ben और मैं बहुत बातें करने वाले हैं, और हमारे बेहतर ideas का आधा हिस्सा day-to-day noise में गायब हो जाता है इससे पहले कि हममें से कोई उन्हें लिखे (बहुत professional, मुझे पता है)। Graph हमारी अपनी conversations से shortcuts और genuinely useful अंतर्दृष्टि निकालता रहता है जिन्हें हम पूरी तरह भूल चुके थे। अगर यह उन दो लोगों के context को बचा सकता है जिन्होंने इसे बनाया, तो सोचिए कि यह पंद्रह लोगों की team में join करने वाले नए कर्मचारी के लिए क्या करता है।
गहरा मूल्य, उन teams के लिए जो genuinely इंजीनियरों को जल्दी ऑनबोर्ड करने की कोशिश कर रही हैं, यह है कि जब लोग जाते हैं तो आप institutional knowledge खोना बंद कर देते हैं। उनके निर्णयों की context chain रहती है, searchable, उन सभी के लिए जो बाद में आते हैं। यह efficiency win नहीं है। यह organizational memory है।
सिग्नल इंटेलिजेंस सीधे अपने inbox में पाएँ।
अक्सर पूछे जाने वाले सवाल
Q: एक नए इंजीनियर को ऑनबोर्ड होने में कितना समय लगना चाहिए? A: हमारे अनुभव और अन्य engineering teams के साथ बातचीत के आधार पर, 2–3 महीने सामान्य है जब तक एक नया इंजीनियर पूरी तरह से productive न हो जाए। बाधा शायद ही कभी तकनीकी कौशल है – यह सीखना है कि निर्णय कहाँ रहते हैं, कौन किसका मालिक है, और आपकी team वास्तव में tools में कैसे communicate करती है। Connected context tools use करने वाली teams इसमें significant कमी की रिपोर्ट करती हैं, हालाँकि सटीक सुधार team size और tool complexity पर निर्भर करता है।
Q: क्या Sugarbug इंजीनियर ऑनबोर्डिंग में मदद करता है? A: हाँ। Sugarbug आपके Linear, GitHub, Slack और Notion अकाउंट्स में एक जीवंत नॉलेज ग्राफ़ बनाता है, ताकि नए इंजीनियर हर tool में पिछले निर्णयों, फ़ीचर्स के निर्माण के कॉन्टेक्स्ट और किससे क्या पूछना है – यह किसी को बाधित किए बिना खोज सकें।
Q: इंजीनियर ऑनबोर्डिंग में कनेक्टेड कॉन्टेक्स्ट क्या है? A: कनेक्टेड कॉन्टेक्स्ट का मतलब है टूल्स में जानकारी को जोड़ना ताकि एक नया कर्मचारी Linear issue से GitHub PR तक और Slack thread तक किसी निर्णय का पता लगा सके जहाँ team ने approach पर बहस की थी। जब वह chain searchable होती है, तो ramp-up time कम होता है क्योंकि नया कर्मचारी colleagues को बाधित किए बिना खुद जवाब ढूंढ सकता है।
Q: पारंपरिक onboarding wikis इंजीनियरों के लिए क्यों काम नहीं करते? A: Wikis वो capture करते हैं जो किसी ने लिखने लायक समझा – architecture overviews, setup guides, coding standards। असली ramp-up bottleneck वो messy, contextual stuff है जो Slack threads, PR comments और Linear issues में रहता है। यह इस तरह क्यों बनाया गया? वो निर्णय किसने लिया? वो context already आपके tools में capture है – समस्या इसे ढूंढने की है, लिखने की नहीं।
Q: क्या Sugarbug ऑनबोर्डिंग के लिए GitHub और Linear के साथ इंटीग्रेट होता है? A: हाँ। Sugarbug API के ज़रिए GitHub, Linear, Slack, Notion, Figma और Google Calendar से जुड़ता है, बातचीत, issues, PRs और दस्तावेज़ों को एक खोजने योग्य नॉलेज ग्राफ़ में index करता है जिसे नए इंजीनियर पहले दिन से query कर सकते हैं।