তোমার টিম ৫টা টুল ব্যবহার করলে টুল জুড়ে Decision কীভাবে Track করবে
Slack thread, Notion doc, Linear comment আর PR review জুড়ে ছড়িয়ে থাকা decision কীভাবে track করবে – decision log ছাড়াই।
By Chris Calo · 2026-03-13
"এটা কি আমরা আগেই সিদ্ধান্ত নিয়ে রাখিনি?"
Call-এ পাঁচজন। কেউ উত্তর দেয় না। কেউ unmute করে বলে Slack thread-এ উঠেছিল মনে হয়, তিন সপ্তাহ আগে, হয়তো #engineering-এ কিন্তু #backend-এও হতে পারে। আমাদের designer অর্ধেক মনে করে Notion-এ comment ছিল। একজন engineer Linear scroll করছে, কোনো issue-তে comment খুঁজছে যেটা হয়তো close হয়ে গেছে। বা archive। বা অন্য project-এ সরানো হয়েছে।
সিদ্ধান্তটা ছিল: future-এ কোন API versioning scheme ব্যবহার করবো। Company-শেষ-করে-দেওয়া ধরনের choice না। Architectural cliff edge না। শুধু একটা straightforward call – টুল জুড়ে decision কীভাবে track করবে, বা আরও specifically, পাঁচটা টুলের মাঝের ফাঁকে হারিয়ে যাওয়া একটা নির্দিষ্ট decision কীভাবে খুঁজবে যেটা definitely, provably, আগেই নেওয়া হয়েছিল।
Crime scene reconstruct করি।
একটা হারানো decision-এর ফরেনসিক টাইমলাইন
আসলে কী হয়েছিল, পরে গিয়ে টুকরো জোড়া দিয়ে বের করেছি (কারণ অবশ্যই শেষ পর্যন্ত সব খুঁজে পেয়েছি – প্রায় এক ঘণ্টা লেগেছে, যেটা বুধবার বিকেলের productive ব্যবহার মনে হয়েছিল)।
Day 1, সকাল ১০:১৪ – আমাদের একজন engineer #engineering-এ "API Versioning Options" শিরোনামের একটা Notion doc share করে। তিনটা option, প্রতিটার pros আর cons। পরিষ্কার formatting। ভালো thinking। এমন document যেটা দেখলে মনে হয় টিমের সব ঠিকঠাক আছে।
Day 1, সকাল ১০:২২ – Shared link-এর নিচে Slack thread-এ আলোচনা শুরু হয়। প্রথম বিশ মিনিটে ছয়টা reply। Backwards compatibility, client SDK implications, আর header-based versioning-এর debugging pain worth কিনা সেটা নিয়ে সত্যিকারের useful conversation। আর reply চারের আশেপাশে লাঞ্চ কোথায় খাবে নিয়ে সংক্ষিপ্ত tangent (যেটা, সত্যি বলতে, versioning debate-র চেয়ে দ্রুত consensus দিয়েছে)।
Day 1, সকাল ১১:৪৭ – আমাদের designer, যে lurk করছিল, এক লাইন দেয়: "path versioning keeps the API explorer readable, let's just do /v2/." দুটো thumbs-up react। কোনো dissent না। Decision নেওয়া হলো।
Day 1, দুপুর ২:৩০ – একজন teammate API refactor issue-তে Linear comment-এ outcome summarise করে। ভালো instinct। কিন্তু discoverability terrible, কারণ Linear comment issue close হলে functionally invisible হয়ে যায়।
Day 8 – /v2/ implement করা PR land করে। PR description Linear issue number reference করে কিন্তু versioning decision নিজে বা যে Slack thread-এ আসলে decision হয়েছে সে সম্পর্কে কিছু বলে না। পুরোপুরি normal। কেউ PR description-এ "by the way, here's the full genealogy of this decision" লেখে না, কারণ কেউ psychopath না।
Day 43 – নতুন কেউ related ticket তুলে নিয়ে জিজ্ঞেস করে: "আমরা কি path versioning করছি নাকি header versioning?" Notion doc? Outcome দিয়ে কখনো update হয়নি। Slack thread? ছয় সপ্তাহের message-র নিচে চাপা। Linear comment? Closed issue-তে, কেউ search করার কথা ভাবে না। PR? সেটা exist করে জানলেই তো খুঁজবে।
আর তাই পাঁচজন call-এ বসে একে অপরের দিকে তাকায়, ছয় সপ্তাহ আগে settle হয়ে যাওয়া decision আবার নতুন করে বের করে। Progress।
title: "একটা Decision, ছয় সপ্তাহ, পাঁচটা টুল" Day 1, 10:14 AM|ok|Notion doc "API Versioning Options" #engineering-এ share; তিনটা option Day 1, 10:22 AM|ok|Slack discussion শুরু; backwards compatibility আর SDK implications নিয়ে productive debate Day 1, 11:47 AM|ok|Decision নেওয়া: path versioning, /v2/ Day 1, 2:30 PM|amber|Linear comment-এ decision summarise; closed issue = poor discoverability Day 8|amber|/v2/ implement করা PR merge; description issue reference করে কিন্তু decision না Day 43|missed|নতুন developer জিজ্ঞেস করে "path নাকি header versioning?" – উত্তর চার জায়গায় আছে; কেউ খুঁজে পায় না
Decision কোথায় মরতে যায়
ব্যাপার হলো, কোনো টুলই fail করেনি। Slack যা করে সেটাই করেছে। Notion document দারুণভাবে ধরে রেখেছে। Linear issue track করেছে। GitHub code merge করেছে। প্রতিটা টুল isolation-এ flawlessly perform করেছে, যেটা complement-এর মতো শোনায় যতক্ষণ না বুঝো এটাই আসলে diagnosis।
| কোথায় হয়েছিল | কেন পরে খুঁজে পাওয়া যায় না | |---|---| | Slack thread | ছয় সপ্তাহ আগে কেউ ঠিক কী শব্দ ব্যবহার করেছিল মনে রাখতে হবে। Good luck। | | Linear comment | Closed issue-র comment সমুদ্রের তলায় খোদাই করা | | Notion doc | Doc আছে, কিন্তু outcome দিয়ে update করেনি, কারণ মানুষ | | GitHub PR | Merge-এর পর conversation collapse হয়ে যায় – কোন PR খুঁড়বে জানা লাগবে | | Meeting (verbal) | পুরোপুরি হারিয়ে গেছে, যদি না কেউ note নিয়ে থাকে আর findable কোথাও রাখে | | Email thread | Decent search, কিন্তু ঠিক chain-এ থাকলেই |
ছয়টা টুল। ছয়টা search engine। শূন্য shared memory।
প্রতিটা টুল isolation-এ flawlessly perform করেছে – যেটা complement-এর মতো শোনায় যতক্ষণ না বুঝো এটাই আসলে diagnosis। attribution: Chris Calo
Decision log: একটা সুন্দর মৃতদেহ
তুমি যদি মাথা নাড়াতে নাড়াতে এতদূর পড়ে থাকো, সম্ভবত তোমার মাথায় The Instinct এসেছে। যেটায় তুমি ভাবো: "ঠিক আছে, Decision Log বানাবো।" বড় হাতের D, বড় হাতের L। Notion-এ gorgeous database, Date, Decision, Context, Stakeholders আর Status column দিয়ে। টিম channel-এ announce করো। প্রথম তিনটা entry নিজে দাও, meticulous detail দিয়ে, আর সত্যিই দারুণ লাগে।
আমি এই exact artefact তিনটা কোম্পানিতে বানিয়েছি (আর হ্যাঁ, একই failed experiment বারবার করে ভিন্ন result আশা করার clinical name আছে জানি)। প্রতিবার absolutely নিশ্চিত ছিলাম এবার টিকবে। "এবার disciplined হবো!" হইনি। তুমিও হবে না। cruel হতে বলছি না – failure mode design-এই baked in।
কী হয়। Week one: beautiful। Week two: mostly populated। Week three: কেউ Slack DM-এ quick call নেয়, log জানতেও পারে না। Week four: একটা PR merge হয় review comment-এ buried implicit architectural decision নিয়ে, আর কেউ transcribe করার কথা ভাবে না। Week five: কেউ holiday-তে, বাকিরা lunch-এ কিছু decide করে (lunch tangent আবার strikes), আর log চুপ হয়ে যায়।
Week six-এ তোমার Decision Log একটা memorial। ভালো intention-এর tasteful monument, Notion sidebar-এ বসে, untouched, digital ধুলো জমাচ্ছে। আমার তিনটা আছে। gorgeous। আর পুরোপুরি useless।
Decision log fail করে টিম undisciplined বলে না, বরং decision হওয়ার মুহূর্তেই সেটাকে গুরুত্বপূর্ণ চিনতে বলে, pause করতে বলে, documentation টুলে কনটেক্সট সুইচিং করতে বলে, আর ছয় সপ্তাহ পরে useful হবে এমন detail দিয়ে লিখতে বলে। আসল কাজে ব্যস্ত মানুষের কাছে এটা absurd চাহিদা।
টুল জুড়ে decision আসলে কীভাবে track করবে
Manual log fail করে কারণ human nature। Per-tool search fail করে কারণ fragmentation। আসলে কাজ করে এমন কিছু যেটা তোমার টুলের পুরো surface area দেখে আর কাউকে কাজ থামাতে না বলেই dot connect করে।
বাস্তবে এর মানে চারটা জিনিস:
Automatic ingestion। টুল থেকে প্রতিটা সিগন্যাল – Slack message, Linear comment, PR review, Notion update, meeting transcript – কেউ আঙুল না নাড়িয়েই capture হয়। তুমি কাজ করতে থাকো। System দেখতে থাকে। কাউকে mid-thought pause করে spreadsheet খুলে record করতে হয় না (যেটা, আমরা establish করেছি, কেউ করে না)।
Classification। প্রতিটা message decision না। বেশিরভাগ status update, question, বা noise। System-কে পার্থক্য বুঝতে হবে "should we use path or header versioning?" (question), "let's just do /v2/" (decision), আর "/v2/ endpoint is deployed" (status update) – এদের মধ্যে। এখানেই LLM classifier কাজে আসে – যদিও infallible না। আমাদের একটা memorable সময় ছিল যখন "yeah let's just do that" বারবার major decision হিসেবে flag হচ্ছিল, আসলে কেউ coffee-তে রাজি হচ্ছিল। Confidence score ঠিক করতে temporal context আর sender-role weighting লেগেছে।
Linking। এই অংশটাই "better search"-কে actual decision tracking থেকে আলাদা করে। Slack thread-এর decision যখন Linear issue-র সাথে relate করে যেটা একটা GitHub PR produce করেছে – সেই connection থাকতে হবে কারণ system reference trace করেছে (issue ID, PR number, thread URL, temporal proximity), কেউ carefully হাতে আঁকেনি বলে না। Notion doc, Slack thread, Linear comment আর PR – সবকটা একে অপরকে point করবে, অটোমেটিকভাবে, কারণ আসলে সেটাই ঘটেছে।
Retrieval। "API versioning decision" search করলে পুরো trail ফিরে আসবে – শুধু যে টুলে প্রথমে search করেছো সেটা না। Option সহ Notion doc, যে Slack thread-এ call হয়েছে, সেটা summarise করা Linear comment, আর implement করা PR। সব connected। কেউ একটাও log entry না করে।
এখনই দুটো জিনিস চেষ্টা করতে পারো (সত্যিই, কোনো string attached না):
#decisions channel। Slack-এ একটা বানাও আর টিমকে বলো অন্য কোথাও decision হলে one-liner drop করতে। Manual, আর এক মাসের মধ্যে decay হবে (এই point-এ আমার credentials establish হয়ে গেছে), কিন্তু partial, decaying log-ও fragmented communication-এর pattern কষ্টদায়কভাবে visible করে তোলে।
- PR description habit। Decision implement করা PR খুললে description-এ এক লাইন যোগ করো: "Decision: [কী সিদ্ধান্ত হয়েছিল] – see [thread/doc link]।" দশ সেকেন্ড লাগে, code review survive করে, আর future-তোমাকে search করার কিছু দেয়। Slack DM-এ বা lunch-এ হওয়া decision ধরবে না, কিন্তু যেগুলো ধরবে সেগুলো সবচেয়ে important – যেগুলো codebase বদলায়।
Connected decision tracking কী বদলায়
Archaeology query হয়ে যায়। শুরুর versioning hunt? Cross-tool indexing থাকলে পাঁচ সেকেন্ডের search হয়ে যায় যেটা chain-এর প্রতিটা artefact linked অবস্থায় return করে। বুধবার বিকেলটা বাঁচতো। This is what visibility across your engineering tools actually means in practice. It’s closely related to a semantic approach to finding past Slack decisions and a connected view of tasks that span three or more tools – all three problems stem from the same fragmented-tools root cause.
Onboarding context যেটা পচে না। নতুন team member connected trail পায় জিনিস কেন এরকম, সেই wiki page-র বদলে যেটা তিন মাস আগে last update হয়েছে আর সবাই মোটামুটি জানে ভুল কিন্তু কেউ ঠিক করেনি। (তোমার একটা আছে। সবার আছে।)
একই debate-র rerun কমে। এটা আমাকে surprise করেছে। Decision findable হলে "didn't we already decide this?" সেকেন্ডে answerable হয়ে যায়, দশ মিনিটের group hallucination-এর বদলে যেখানে সবাই discuss করেছে মনে করে কিন্তু কেউ confirm করতে পারে না আসলে কী conclude হয়েছিল।
Pattern দেখা যায় যেটা আগে সম্ভব ছিল না। Decision aggregate-এ visible হলে দেখা যায় কোন topic সবচেয়ে লম্বা debate generate করে আর কোথায় decision stall হয়। Operational intelligence যেটা কোনো single টুল দিতে পারে না, কারণ কোনো single টুলের কাছে পুরো picture নেই।
Sugarbug এটা কীভাবে approach করে
Versioning hunt মোটামুটি সেই last straw ছিল যেটার পর আমি Sugarbug বানানো শুরু করি (সেটা আর তিনটা মৃত Decision Log-এর বোঝা)। এটা ওপরে বর্ণিত system – API দিয়ে existing টুলের সাথে connect করে, প্রতিটা সিগন্যাল নলেজ গ্রাফে feed করে, অটোমেটিকভাবে classify আর link করে। টিম কাজ করতে করতে graph নিজে বানায়। কেউ কিছু document করে না, কারণ capture কাজেরই side effect।
আমরা এখনও early (production-এ, pre-launch), আর কিছু কঠিন সমস্যা crack হয়নি – meeting-এ verbally হওয়া decision যেখানে কেউ note নেয়নি, বা "yeah, let's do that" genuine commitment নাকি coffee agreement (coffee incident থেকে confidence threshold নিয়ে অনেক শিখেছি) disambiguate করা। কিন্তু past decision খুঁজতে যে সময় লাগতো সেটা "regularly infuriating" থেকে "occasionally mild"-এ নেমে এসেছে, যেটা reasonable trajectory মনে হয়।
তোমার inbox-এ সিগন্যাল ইন্টেলিজেন্স পাও।
প্রায়শই জিজ্ঞাসিত প্রশ্ন
কয়েক সপ্তাহ আগে Slack thread-এ নেওয়া decision কীভাবে খুঁজবো?
Cross-tool index ছাড়া আমি যা করেছি তাই করতে হবে – scroll করা, বিভিন্ন keyword চেষ্টা করা, মোটামুটি কখন হয়েছে মনে করার আশা করা। Sugarbug Slack message-কে অন্য source-এর পাশাপাশি একটা নলেজ গ্রাফে ingest করে, তাই exact keyword-র বদলে concept দিয়ে search করা যায়। Magic না – conversation text-এ হয়ে থাকতে হবে – কিন্তু archaeological dig-এর চেয়ে ভালো।
Sugarbug কি অটোমেটিকভাবে টুল জুড়ে decision track করে?
করে। Connected টুল থেকে প্রতিটা সিগন্যাল classify হয় – decision, status update, question, blocker – আর relevant মানুষ আর task-এর সাথে link হয়। Slack thread-এ decision surface হলে যেটা Linear issue-র সাথে relate করে, graph কাউকে link copy-paste বা log update না করেই connect করে।
Decision log আর নলেজ গ্রাফের মধ্যে পার্থক্য কী?
Decision log-এ কাউকে লিখতে হয় কী decide হয়েছে, কখন, আর কে। নলেজ গ্রাফ সেই connection অটোমেটিকভাবে বানায় টুল আগে থেকেই যে সিগন্যাল produce করছে তা থেকে – Slack thread, Linear issue, implement করা PR। একটার দরকার discipline (যেটায়, আমি thoroughly establish করেছি, আমরা terrible); অন্যটার দরকার system।
Decision log কেন সবসময় fail করে?
কারণ tax ঠিক ভুল মুহূর্তে পড়ে। Decision হওয়ার সময়ই সেটাকে important চিনতে হয়, pause করতে হয়, আলাদা টুলে switch করতে হয়, সপ্তাহখানেক পরে useful হবে এমন detail দিয়ে লিখতে হয়, তারপর thread না হারিয়ে কাজে ফিরতে হয়। আমি যত টিম দেখেছি প্রতিটা ছয় সপ্তাহের মধ্যে ছেড়ে দিয়েছে – অলসতায় না, বরং process মানুষ আসলে যেভাবে কাজ করে তার বিরুদ্ধে যায় বলে।
ছোট টিমের লাভ আছে, নাকি শুধু বড় organisation-এর জন্য?
ছোট টিম আরও বেশি আক্রান্ত, আমার অভিজ্ঞতায়। Dedicated PM নেই documentation maintain করতে, আর "institutional memory" হলো এক-দুজন মানুষ যাদের স্মৃতি ভালো। পাঁচজনের startup সপ্তাহে ডজনখানেক micro-decision নেয় Slack, GitHub আর Notion জুড়ে – পঞ্চাশজনের org-এর মতোই fragmentation সমস্যা, শুধু কম মানুষ cost absorb করতে পারে যখন কিছু হারায়।
---
তুমি যদি কখনো call-এ বসে থাকো যেখানে পাঁচজন সপ্তাহখানেক আগে settle হওয়া decision reconstruct করার চেষ্টা করে, ঠিক এই সমস্যাটাই eliminate করতে আমরা Sugarbug বানিয়েছি। ওয়েটলিস্টে যোগ দাও।