কীভাবে ইঞ্জিনিয়ারদের দ্রুত অনবোর্ড করবে (এটা Better Docs-এর ব্যাপার না)
ইঞ্জিনিয়ারদের দ্রুত অনবোর্ড করার আসল উপায় হলো আসল bottleneck ঠিক করা: Slack, GitHub, আর Linear-এ ছড়িয়ে থাকা context, যা কোনো wiki পুরোটা ধরতে পারে না।
By Ellis Keane · 2026-03-31
যখন এমন একটা টিমে যোগ দিলাম, যারা নিজেরাই জানত না তারা কীভাবে কাজ করে
তুমি যদি ভাবো কীভাবে ইঞ্জিনিয়ারদের দ্রুত অনবোর্ড করা যায়, তাহলে আমার নিজের onboarding অভিজ্ঞতাটা বলি – কারণ এটাই সম্ভবত আমার সবচেয়ে শক্তিশালী যুক্তি।
২০১৯ সালে আমি San Francisco-র একটা startup-এ third engineer হিসেবে যোগ দিই। CTO – অসাধারণ মেধাবী আর একইসাথে অবিশ্বাস্য রকম অগোছালো ভদ্রলোক – প্রথম দিন আমাকে একটা laptop দিয়ে মোটামুটি বলল, "Codebase GitHub-এ আছে। বাকি সবকিছুর জন্য আমরা Slack ব্যবহার করি। Good luck।"
এটাই ছিল onboarding programme।
প্রথম তিন সপ্তাহ আমি এমন কিছু করেছি, যেটার সাথে পরে বুঝেছি engineering-এর প্রায় কোনো সম্পর্কই ছিল না: archaeology। ছয় মাস আগের Slack thread খুঁড়ে খুঁড়ে দেখছি, authentication system ওইভাবে কেন বানানো হয়েছিল সেটা বুঝতে। পুরোনো closed GitHub PR scroll করছি, database schema decision নিয়ে conversation খুঁজতে, যেগুলো কেউ কোথাও document করেনি (স্বাভাবিকভাবেই করেনি)। #general-এ প্রশ্ন করে উত্তর পাচ্ছি: "ও হ্যাঁ, ওটা – January-তে আমরা মত বদলেছি, আমাদের designer-এর সাথে যে thread ছিল সেটা দেখো।"
কোন thread? কোন designer-এর সাথে? কোন channel-এ?
সে খারাপ manager ছিল না। সে এমন বাস্তবতায় কাজ করছিল যেখানে institutional knowledge থাকত শুধু মানুষের মাথায় আর চারটা আলাদা টুলে ছড়ানো – সত্যি বলতে, বেশিরভাগ engineering team-ই এমন। আমার প্রতিটা প্রশ্নের জন্য কাউকে নিজের কাজ থামাতে হতো, "onboarding mode"-এ কনটেক্সট সুইচিং করতে হতো, relevant thread বা document বের করতে হতো, তারপর মাস আগে নেওয়া সিদ্ধান্তের reasoning reconstruct করতে হতো। প্রায়ই মনে হতো মাথার gear ঘুরছে আর ঘষা খাচ্ছে।
একজন engineer-এর তিন সপ্তাহ engineering না করে archaeology করা, তার ওপর আমার প্রশ্নের উত্তর দিতে সবার cumulative interruption cost – এগুলো আসল টাকা, যদিও কোনো balance sheet-এ কখনো দেখা যায় না।
ওই অভিজ্ঞতা unique ছিল না। আমি এক দশক Vulcan চালিয়েছি, আমাদের design আর engineering agency, আর সেই সময়ের অবাক করার মতো বড় অংশ কেটেছে এমন organisation-এ ঢুকে যেগুলো আমার থেকেও বেশি অগোছালো ছিল (সেটা যে কত নিচু bar, সেটা সত্যি)। প্রতিটা client, একই pattern: knowledge ছিল, কিন্তু সেটা মানুষের মাথায় থাকত, আর এমন টুলে পড়ে থাকত যেগুলো কেউ connect করার কথা ভাবেনি।
কীভাবে ইঞ্জিনিয়ারদের দ্রুত অনবোর্ড করবে: Docs না, Search সমস্যাটা ঠিক করো
বেশিরভাগ onboarding playbook engineer onboarding-কে content problem হিসেবে দেখে। ভালো docs লেখো! Notion wiki বানাও! Colour-coded milestone দিয়ে onboarding checklist তৈরি করো!
Checklist খারাপ না। তোমার "Day 1 – Day 30" template ফেলে দাও বলছি না। কিন্তু আসল bottleneck "documentation কম আছে" এটা না। Useful context – messy, nuanced, real জিনিসগুলো – থাকে Slack thread-এ, GitHub PR comment-এ, Linear issue description-এ, আর মাঝে মাঝে কোনো designer ছয় সপ্তাহ আগে যে Figma annotation রেখেছিল সেখানে। আমরা সবাই মিলে দুই দশক ধরে wiki বানিয়েছি software কী করে বোঝাতে, কিন্তু কেন করে সেটা discoverable করতে প্রায় কোনো সময় দিইনি।
কোনো wiki "why" ধরে রাখতে পারে না। Wiki-তে থাকে কেউ কী লিখে রাখার দরকার মনে করেছে – কিন্তু নতুন engineer-এর আসলে কী জানা দরকার সেটা সম্পূর্ণ ভিন্ন জিনিস।
Onboarding-এর আসল bottleneck documentation না – useful context এমন tool-এ পড়ে থাকে, যেগুলোতে search করতে কেউ ভাবেই না। attribution: Chris Calo
তারপর থেকে যখনই আমি engineer অনবোর্ড করেছি – আগে design agency-তে, পরে Sugarbug বানাতে গিয়ে – একই pattern বারবার দেখেছি। নতুন hire-রা যে প্রশ্ন করে, সেগুলো মোটামুটি চার category-তে পড়ে, আর traditional onboarding docs তার মধ্যে মাত্র একটাই cover করে:
Docs যা cover করে
- Architecture overview – system diagram, service boundary, deployment topology
- Local setup – clone, build, run, test কীভাবে করবে
- Coding standards – linting rule, PR convention, naming pattern
Docs যা miss করে
- Decision history – Slack-এ আলোচিত তিনটা alternative বাদ দিয়ে এই architecture কেন?
- Tribal knowledge – billing module আসলে কে own করে? ওই CSS decision কে নিয়েছিল?
- Context chains – একটা Linear issue থেকে PR, তারপর design discussion, তারপর product spec
- Active state – এই মুহূর্তে কী নিয়ে কাজ হচ্ছে, আর কেন?
"Docs যা cover করে" column-টাই বেশিরভাগ টিম optimise করে। আমার অভিজ্ঞতায়, "docs যা miss করে" column-এই নতুন engineer-দের ramp-up time-এর বড় অংশ যায় – আসল উত্তর ওখানেই থাকে, আর কেউ নতুনদের সেদিকে point করে না।
ওই তথ্য missing না, কারণ কেউ লেখেনি। লেখা হয়েছিল – Slack message-এ, GitHub review comment-এ, Linear issue update-এ। সমস্যা documentation না, discoverability।
যে Interruption Tax-এর বাজেট কেউ ধরে না
প্রতিবার নতুন engineer জিজ্ঞেস করে "এটা এভাবে কেন বানানো?" আর একজন senior engineer নিজের কাজ থামিয়ে উত্তর দেয়, দুটো জিনিস হয়। নতুন hire উত্তর পায় (ভালো), আর senior engineer meaningful productive focus হারায় – প্রশ্নের ২ মিনিট না, relevant thread খুঁজতে, reasoning মনে করতে, আর আগের কাজে ফিরতে যে ১৫ মিনিটের মতো লাগে, সেটার জন্য।
stat: "দিনে কয়েকবার" headline: "Ramp-up-এ থাকা একজন engineer থেকে interruption" source: "Sugarbug-এ আমাদের onboarding pattern-এর পর্যবেক্ষণ"
একই quarter-এ দুজন engineer hire করলে (growing startup হলে সাধারণত এটাই হয়), তোমার existing team সপ্তাহের পর সপ্তাহ অযৌক্তিক মাত্রার interruption absorb করে। যাদের velocity বাড়াতে hire করেছিলে, তারাই সাময়িকভাবে velocity কমিয়ে দেয়। কেউ এটা budget করে না কারণ কেউ measure করে না – শুধু একটা অস্পষ্ট অনুভূতি আসে, "এই quarter-এ টিম ধীর লাগছে," onboarding-এর সাথে কেউ connect করে না।
আর যে অংশটা সবচেয়ে বেশি বিঁধে: এই প্রশ্নগুলোর উত্তর ইতিমধ্যেই কোথাও আছে। Slack-এ আছে, GitHub-এ আছে, Linear-এ আছে। সিদ্ধান্ত নেওয়ার মুহূর্তেই তথ্য capture হয়েছিল। শুধু পড়ে আছে এমন tool-এ যেখানে search করতে নতুন hire-কে কেউ বলেনি, এমন channel-এ যার অস্তিত্বই সে জানে না, এমন thread title-এর নিচে যেটা context ছাড়া কোনো মানে রাখে না।
Connected Context: বাস্তবে এর মানে কী
Engineer onboarding-এ connected context মানে নতুন hire তোমার টিমের সব tool জুড়ে – Slack, GitHub, Linear, Notion – একটাই interface থেকে search করতে পারবে। শুধু keyword search না (Slack-এর search, সত্যি বলতে, ভালো অবস্থায়ও মোটামুটি আর খারাপ অবস্থায় প্রায় শত্রুভাবাপন্ন), বরং contextual search যেটা জিনিসগুলোর সম্পর্ক বোঝে।
"Billing module refactor সম্পর্কিত সব দেখাও" দিলে ফল আসে: Linear epic, GitHub-এর ছয়টা PR, approach নিয়ে debate হওয়া Slack thread, আর Notion architecture doc – সব connected, সব chronological order-এ, archaeology লাগবে না।
এটাই concept: একটা নলেজ গ্রাফ যেটা তোমার টিমের কাজের সম্পর্ক সব tool জুড়ে map করে, কে কী সিদ্ধান্ত নিল, কোথায়, কেন – তার living index তৈরি করে।
Ben আর আমি এটা বানিয়েছি কারণ আমরা বছরের পর বছর alternative-টাই বেঁচে দেখেছি। Vulcan-এ আমরা একসাথে বেশ কয়েকটা organisation-এর design আর engineering team চালাতাম, আর শেষ পর্যন্ত আমাদের আসল speciality নেমে আসত একটাতে: glorified human router of information। যে দুজনের design আর build করা উচিত ছিল, তারা সারাদিন ব্যস্ত "ওই জিনিসটা কোথায়?" এর উত্তর দিতে (আত্মা শুকিয়ে যাওয়ার মতো realisation, বিশ্বাস করো)। এটা থামাতেই হতো।
Connected context মানে বেশি documentation লেখা না – তোমার tool-এ আগে থেকেই থাকা context-কে discoverable, searchable, আর linked করা। নতুন engineer-কে জানতে হবে না কোন Slack channel-এ search করবে বা কোন GitHub repo দেখবে।
এটাই আমরা Sugarbug দিয়ে বানাচ্ছি। নলেজ গ্রাফ Linear issue-কে GitHub PR-এর সাথে, Slack conversation-এর সাথে, Notion doc-এর সাথে connect করে, তারপর পুরোটা searchable করে। নতুন hire যোগ দিলে প্রথম দিন থেকে টিমের decision history তার হাতে। (Onboarding-specific workflow এখনো refine করছি, সত্যি কথা – কিন্তু underlying graph-টাই foundation।)
৩ সপ্তাহের Engineer Onboarding Framework
ঠিক আছে, এবার সেই framework যেটা আমি চাইতাম কেউ আমাকে দিক যখন laptop পেয়ে "good luck" শুনেছিলাম। তুমি যদি বের করতে চাও কীভাবে ইঞ্জিনিয়ারদের দ্রুত অনবোর্ড করবে, এটা কাজ করে কারণ এটা কাল্পনিক bottleneck (documentation volume) না, আসল bottleneck (discoverability) address করে।
Week 1: Orient
নতুন hire-এর সাথে একটা "context buddy" pair করো – mentor না, বরং এমন কেউ যে জানে তথ্য কোথায় থাকে (সবচেয়ে senior হলেই হবে না – অনেক সময় যে সবচেয়ে সম্প্রতি বেশি প্রশ্ন করেছে, তার কাছেই freshest map থাকে)। Context buddy-এর কাজ সব প্রশ্নের উত্তর দেওয়া না। তার কাজ বলা, "ওই decision February-র দিকে #backend channel-এ হয়েছিল, চলো thread-টা বের করি।"
Sugarbug-এর মতো connected context tool ব্যবহার করলে context buddy-এর কাজ অনেক সহজ: "billing module refactor search করো, পুরো decision chain দেখতে পাবে।"
Week 2: Navigate
এই সময়ে নতুন hire-এর প্রথম PR আসা উচিত, কিন্তু তার চেয়ে গুরুত্বপূর্ণ হলো টিম কীভাবে communicate করে তার mental model তৈরি হওয়া। কোন আলোচনা Slack-এ হয়? কোনটা Linear comment-এ? কোনটা GitHub PR review-এ? Communication topology বোঝা codebase বোঝার মতোই গুরুত্বপূর্ণ – প্রথম মাসে সম্ভবত আরও বেশি। (আমি এমন engineer দেখেছি যারা এক সপ্তাহে codebase বুঝে ফেলেছে, কিন্তু তিন সপ্তাহ পরেও decision কোথায় খুঁজবে জানত না।)
Week 3: Contribute
তৃতীয় সপ্তাহে, context problem solve থাকলে, নতুন engineer-এর meaningful contribution আসা উচিত – codebase মুখস্থ করেছে বলে না, বরং কাউকে interrupt না করে যা দরকার নিজে খুঁজে পেতে পারে বলে।
- [x] Day 1: Local environment running, সব tool-এ access granted
- [x] Day 2-3: Context buddy assigned, communication topology walkthrough সম্পন্ন
- [x] Week 1: Context buddy support নিয়ে ২–৩টা "good first issue" সম্পন্ন
- [ ] Week 2: Independent PR তৈরি, প্রশ্ন করার আগে context search
- [ ] Week 3: Design discussion-এ contribute, অন্যের PR review
- [ ] Month 2: Independently productive, context buddy weekly check-in
কেন এটা Compound করে (আর Wiki কেন করে না)
Connected context দিয়ে engineer onboarding solve করা আর ৪৭ পাতার Notion wiki দিয়ে solve করার পার্থক্যটা (তুমি ওইটাকে চেনো – আট মাস আগে last update, এমন কেউ করেছিল যে আর টিমেই নেই) হলো connected context compound করে। তোমার টিম Slack-এ যে প্রতিটা conversation করে, প্রতিটা PR review, প্রতিটা Linear issue update – সব index হয়, link হয়, searchable হয়। কারও extra কাজ ছাড়াই নলেজ গ্রাফ সময়ের সাথে richer হয়।
তোমার দ্বিতীয় hire, প্রথম hire-এর onboarding প্রশ্ন থেকে বের হওয়া সব context পায়। পঞ্চম hire আরও rich graph পায়। দশম hire-এর সময়, যে institutional knowledge আগে শুধু CTO-র মাথায় ছিল, সেটা distributed, searchable, connected হয়ে যায়।
আর এই অংশটাই আমাকে সত্যিই উত্তেজিত করে! শুধু efficiency gain না – যদিও connected context চেষ্টা করা টিমগুলোর সাথে আমাদের শুরুর কথাবার্তায় ramp-up compression বাস্তব। আর একটা জিনিস যেটা আমি expect করিনি: Ben আর আমি খুব chatty, আর আমাদের অর্ধেক ভালো idea day-to-day noise-এ হারিয়ে যায় লিখে রাখার আগেই (খুব professional, জানি)। Graph বারবার আমাদের নিজেদের conversation থেকে shortcut আর genuinely useful idea তুলে আনছে যেগুলো আমরা পুরো ভুলে গিয়েছিলাম। যারা tool বানিয়েছে, তাদের context-ই যদি এটা বাঁচাতে পারে, ভাবো ১৫ জনের টিমে নতুন hire-এর জন্য এটা কী করতে পারে।
যে টিম সত্যিই ইঞ্জিনিয়ারদের দ্রুত অনবোর্ড করতে চায়, তাদের জন্য deeper value হলো মানুষ চলে গেলেও institutional knowledge হারায় না। তাদের decision-এর context chain থেকে যায়, searchable, পরের সবার জন্য। এটা শুধু efficiency win না। এটা organisational memory।
The tools that make connected context possible are covered in wiring up your engineering toolchain – Linear, GitHub, Figma, and Slack working as one layer.
তোমার inbox-এ সিগন্যাল ইন্টেলিজেন্স পৌঁছে দাও।
Frequently Asked Questions
Q: একজন নতুন ইঞ্জিনিয়ারকে অনবোর্ড করতে কত সময় লাগা উচিত? A: আমাদের অভিজ্ঞতা আর অন্য engineering team-এর সাথে আলোচনায় দেখা যায়, ২–৩ মাস সাধারণত লাগে পুরোপুরি productive হতে। Bottleneck সাধারণত technical skill না – bottleneck হলো সিদ্ধান্ত কোথায় আছে, কে কী own করে, আর টিম tool-এর মধ্যে আসলে কীভাবে communicate করে সেটা শেখা। Connected context tool ব্যবহার করা টিম এই সময় উল্লেখযোগ্যভাবে কমাতে পারে, যদিও exact improvement টিমের size আর tool complexity-র ওপর নির্ভর করে।
Q: Sugarbug কি engineer onboarding-এ সাহায্য করে? A: হ্যাঁ। Sugarbug তোমার Linear, GitHub, Slack, আর Notion account জুড়ে একটি living নলেজ গ্রাফ তৈরি করে, যাতে নতুন engineer-রা সব tool-এ পুরোনো decision, feature কেন ওইভাবে build হয়েছে তার context, আর কাকে কী জিজ্ঞেস করবে তা খুঁজে পায় – কাউকে interrupt না করেই।
Q: Engineering onboarding-এ connected context বলতে কী বোঝায়? A: Connected context মানে tool-এর তথ্য link করা, যাতে নতুন hire Linear issue থেকে GitHub PR, তারপর Slack thread পর্যন্ত decision trail trace করতে পারে – যেখানে approach নিয়ে debate হয়েছিল। Chain searchable হলে ramp-up time কমে, কারণ নতুন hire সহকর্মীদের interrupt না করে নিজেই উত্তর খুঁজে নিতে পারে।
Q: Engineer-দের জন্য traditional onboarding wiki কেন কাজ করে না? A: Wiki-তে থাকে কেউ কী লিখে রাখার দরকার মনে করেছে – architecture overview, setup guide, coding standard। কিন্তু ramp-up-এর আসল bottleneck হলো messy, contextual জিনিস যেগুলো Slack thread, PR comment, আর Linear issue-তে থাকে। এটা কেন এভাবে বানানো? ওই call কে নিয়েছিল? Context আগেই তোমার tool-এ capture করা আছে – সমস্যা লেখা না, সমস্যা খুঁজে পাওয়া।
Q: Onboarding-এর জন্য Sugarbug কি GitHub আর Linear-এর সাথে ইন্টিগ্রেশন করে? A: হ্যাঁ। Sugarbug API দিয়ে GitHub, Linear, Slack, Notion, Figma, আর Google Calendar-এর সাথে কানেক্ট করে; conversation, issue, PR, আর document index করে searchable নলেজ গ্রাফে রাখে, যেটা নতুন engineer-রা প্রথম দিন থেকেই query করতে পারে।