টুল ক্লান্তি আসল সমস্যা: Engineering Manager-রা কী করতে পারে
Engineering manager-রা অনেক বেশি টুল নিয়ে কাজ করে। টুল ক্লান্তি আসলে কীভাবে কাজ করে, এর খরচ কত, আর systems-level কোন সমাধানগুলো কাজে আসে।
By Ellis Keane · 2026-03-31
মঙ্গলবার সকাল ৯:৪৭, আর engineering manager এখনও এক লাইন কোড লেখেনি, একটাও pull request review করেনি, বা টিমের কারও সাথে আসল engineering কাজ নিয়ে কোনো কথা বলেনি। সে Linear থেকে status নিয়ে Notion doc update করছে, একটা Slack thread দেখে বুঝতে চেষ্টা করছে কোনো সিদ্ধান্ত হয়েছে নাকি শুধু আলোচনা হয়েছে, আর গতকাল দেখা Figma comment v2 mockup-এ ছিল নাকি v3-তে সেটা মনে করার চেষ্টা করছে, কারণ notification-এ যথেষ্ট context ছিল না।
why context switching is so expensive
তুমি engineering manager হলে এই সকালটা চিনবে, "টুল ক্লান্তি" নাম না দিলেও।
সমস্যার আকৃতি
Engineering manager-দের টুল ক্লান্তি আসলে অনেক বেশি টুল থাকার সমস্যা না (যদিও সাধারণত সেভাবে frame করা হয়)। এটা হলো তথ্য কোথায় আছে, কে রেখেছে, আর সেটা এখনও current কিনা – এই mental model ধরে রাখার cognitive overhead। Stack-এর প্রতিটা টুল আলাদা source of truth, আর engineering manager-এর কাজ চুপচাপ এই source-গুলোকে সেলাই করে সিদ্ধান্ত নেওয়ার মতো coherent কিছু বানানো হয়ে গেছে।
বাস্তবে এটা কেমন দেখায়, ধরো তুমি ছয়জন engineer-এর টিম ম্যানেজ করছো, আর কোম্পানি ব্যবহার করে Linear (project tracking), GitHub (code), Slack (communication), Figma (design), আর Notion (documentation)। পাঁচটা টুল, যেটা বেশিরভাগ startup-এর তুলনায় সত্যি বলতে conservative দিকে।
title: "একজন Engineering Manager-এর মঙ্গলবার সকাল" 8:30 AM|ok|Linear খোলে, active sprint scan করে। তিনটা issue "in progress" মার্কড, কোনো recent update নেই। 8:42 AM|amber|GitHub-এ যায় দেখতে ওই issue-গুলোর PR আছে কিনা। দুটোর আছে। একটার নেই। 8:51 AM|ok|Missing PR-এর context Slack-এ খোঁজে। শুক্রবারের একটা thread পায় যেখানে engineer blocker mention করেছিল। 9:03 AM|amber|Blocker-টা Figma comment রেফার করে। Figma খোলে। Design file-এর comment thread scroll করে। 9:14 AM|missed|Comment পায়, কিন্তু Linear issue update না করেই resolve করা হয়েছিল। Engineer হয়তো জানেও না blocker clear হয়ে গেছে। 9:22 AM|amber|Slack-এ engineer-কে DM করে check করতে। Response-এর জন্য অপেক্ষা। 9:31 AM|ok|Notion status doc update করে এতক্ষণ যা জেনেছে তাই দিয়ে। তিন প্যারাগ্রাফ, বেশিরভাগটাই "আমি এখনও জানি না" ধরনের। 9:47 AM|missed|বুঝতে পারে কোনো আসল management কাজ করেনি। শুধু information archaeology করেছে।
কোনো এক সময়ে "Engineering Manager" title হয়ে গেছে "Human API Router"-এর ভদ্র প্রতিশব্দ – এমন কেউ যার প্রাথমিক কাজ হলো একে অপরের সাথে কথা বলতে রাজি না এমন system-গুলোর মধ্যে context আদান-প্রদান করা।
এটা কোনো outlier সকাল না। এটা baseline। Engineering manager-দের জন্য টুল ক্লান্তি মানে টিমে কী হচ্ছে বোঝার কাজ চুপচাপ full-time data integration exercise হয়ে গেছে, আর কেউ এটা plan করেনি।
stat: "৭৭ মিনিট" headline: "গড় দৈনিক context-stitching সময়" source: "আমাদের টিমের ৪ সপ্তাহের internal time tracking-এর ভিত্তিতে"
কেন এটা ভালো হওয়ার বদলে আরও খারাপ হয়
টুল ক্লান্তি compound করে (আর আমি এটা বলছি এমন কেউ হিসেবে যে নিজের টিমে এটা ঘটতে দেখেছে)। প্রতিটা নতুন টুল শুধু নিজের overhead যোগ করে না, existing টুলগুলোর মধ্যে যে connection রাখতে হয় তা multiply করে।
৫টা টুলে ১০টা সম্ভাব্য pairwise connection। ৮টায় ২৮টা। ১২টায় ৬৬টা। Engineering manager-কে সব connection actively ব্যবহার করতে হয় না, কিন্তু কোনগুলো আছে আর কোনগুলো ভাঙা সেটা জানা দরকার, কারণ ভাঙা connection মানে তথ্য হারানো।
আর engineering management-এ তথ্য হারানো abstract না। একজন designer জানতোই না তার blocker resolve হয়ে গেছে, তাই পরের iteration শুরু করতে দুই দিন অপেক্ষা করেছে। Sprint commitment ধরে নিয়েছিল dependency done কারণ Linear status বলছে "complete", কিন্তু actual PR এখনও review-তে। Weekly sync meeting-এর প্রথম পনেরো মিনিট গেছে establish করতে যেটা সবাই individually জানতো কিন্তু share করেনি, কারণ টুলগুলো সেই সিগন্যালগুলো connect করেনি।
টুল ক্লান্তি টুলের সংখ্যা নিয়ে না। এটা টুলগুলোর মাঝের ফাঁকের সংখ্যা নিয়ে, আর সেই ফাঁক বন্ধ করা engineering manager-এর unofficial দ্বিতীয় চাকরি হয়ে গেছে।
কী কাজ করে না
টুল ক্লান্তির তিনটা common response যেগুলো আসলে কাজ করে না:
Consolidation-এর জন্য consolidation। Instinct বোঝা যায়: সমস্যা যদি অনেক বেশি টুল হয়, তাহলে কম টুল ব্যবহার করো। কিন্তু engineering টিমের টুল নিয়ে strong opinion থাকে, ভালো কারণে। Linear-এর জায়গায় "[all-in-one platform X]-এর project management module" বসানোর চেষ্টা করো আর revolt দেখো। টুল সমস্যা না, টুলগুলোর মাঝের ফাঁক সমস্যা। এক set টুল বদলে আরেক set বসালে ফাঁকগুলো শুধু ঘুরে বসে।
Dashboard। জানি, জানি। "এক dashboard দিয়ে সব শাসন" – এই appeal প্রায় irresistible, আর প্রতিটা enterprise SaaS কোম্পানির এটা নিয়ে slide deck আছে। কিন্তু আমরা যত dashboard test করেছি বেশিরভাগ read-only state snapshot – দেখায় জিনিস কোথায় আছে, কিন্তু গতকাল থেকে কী বদলেছে, কেন বদলেছে, বা এখন কী করা উচিত সেটা বলে না। Dashboard দেখা engineering manager-কে তারপরেও প্রতিটা টুলে গিয়ে numbers-এর পেছনের actual context আনতে হয়।
আরও বেশি মিটিং। এটাই সবচেয়ে কষ্ট দেয় কারণ এটা এতটাই common। টুল যখন একে অপরের সাথে কথা বলে না, টিম ক্ষতিপূরণ দেয় synchronous communication দিয়ে (daily standup, weekly sync, ad-hoc check-in)। মিটিং সমস্যা solve করছে না, ভাঙা information flow-কে human bandwidth দিয়ে ঢাকছে। আর human bandwidth টিমের সবচেয়ে expensive resource।
যা মানুষ চেষ্টা করে
- টুল consolidation – ৫টা টুলের বদলে ১। Engineer revolt, all-in-one ৫টা কাজ মোটামুটি করে।
- Dashboard – Read-only snapshot যেটায় original টুল থেকেই context দরকার।
- আরও মিটিং – ভাঙা async flow-র ক্ষতিপূরণে synchronous information transfer।
যা আসলে সাহায্য করে
- Consolidation না, connection – টুল রাখো, মাঝের ফাঁক বন্ধ করো।
- সিগন্যাল routing – কী বদলেছে আর কিসে attention দরকার সেটা surface করো, সব কিছু না।
- Async context delivery – তথ্য সেখানে আর তখন পৌঁছায় যখন দরকার, জিজ্ঞেস না করেই।
আসলে কী সাহায্য করে
যেসব fix real engineering টিমের সংস্পর্শে টিকে থাকে, তাদের মধ্যে একটা common বৈশিষ্ট্য আছে: এগুলো মানুষকে ইন্টিগ্রেশনের কাজ করতে বলে না। System level-এ connection বানায় আর engineering manager-কে information gathering-এর বদলে judgment call-এ সময় দিতে দেয়।
Intentional notification routing। বেশিরভাগ টুল ক্লান্তি আসে ভুল জায়গায় ভুল তথ্য পৌঁছানো থেকে। Status update আর design feedback mix করা Slack channel। যে repo-তে actively কাজ করো না তার GitHub notification। সমাধান কম notification না, ভালোভাবে route করা notification। Channel convention সেটআপ করো (আমরা ব্যবহার করি #proj-[name]-eng engineering সিগন্যালের জন্য, #proj-[name]-design design-এর জন্য) আর aggressively prune করো। একটা concrete automation যেটা সাথে সাথে worth it: GitHub webhook সেটআপ করো যেটা project-এর Slack channel-এ PR status change post করে Linear issue ID সহ। এটাই সকালের ritual থেকে "এই issue-র PR আছে?" check eliminate করে। Glamorous কাজ না, কিন্তু noise meaningfully কমায়।
Weekly "information archaeology" budget। মেনে নাও যে কিছুটা cross-tool stitching এই মুহূর্তে অনিবার্য, আর timebox করো। আমরা সোমবার সকালে ত্রিশ মিনিট specifically রাখি "শুক্রবারের পর থেকে টুল জুড়ে কী হয়েছে" scan-এর জন্য। Schedule করা থাকলে সপ্তাহের বাকি সময়ে bleed করে না, আর timebox থাকলে সময় শেষ হলে থামো, rabbit-hole-এ না গিয়ে।
Cross-tool সিগন্যাল routing। এদিকেই category যাচ্ছে (আর হ্যাঁ, Sugarbug-এ আমরা এটাই বানাচ্ছি)। Engineering manager manually Linear, তারপর GitHub, তারপর Slack, তারপর Figma চেক করে world-এর state বানানোর বদলে, এমন একটা layer যেটা সব টুলের API-র সাথে কানেক্ট করে আর relevant change, decision আর blocker তোমার কাছে route করে। Dashboard না (যেটা passive), বরং এমন কিছু যেটা actively বলে তোমার attention কোথায় দরকার আর কেন – একজন experienced team lead তোমাকে brief করলে যেমন হতো, যদি সে গতকাল থেকে প্রতিটা Slack thread আর PR comment পড়ে থাকতো।
সৎ ভার্সন হলো: প্রথম দুটো fix এখনই কাজ করে, আর তৃতীয়টা Sugarbug-এ বানাচ্ছি। শেষ হয়নি – সিগন্যাল filtering কতটা aggressive হবে সেটা ঠিক করিনি, আর ranking model এখনও কিছু noise surface করে যেটা আমরা suppress করতে চাই। কিন্তু core architecture কাজ করছে: প্রতিটা টুলের জন্য API connector, LLM-based সিগন্যাল classification, আর একটা নলেজ গ্রাফ যেটা মানুষ, task আর discussion-কে source জুড়ে লিঙ্ক করে। "শুক্রবারের পর কী হয়েছে" scan সেকেন্ডে হয় সাতাত্তর মিনিটের বদলে, আর এই অংশটাই আমাদের চালিয়ে রাখে।
Engineering manager-এর কাজ পাঁচটা টুলকে সেলাই করে একটা coherent picture বানানো হওয়া উচিত না। সেটা machine-এর কাজ। মানুষের কাজ হলো picture দেখে সিদ্ধান্ত নেওয়া। attribution: Ellis Keane
প্রায়শই জিজ্ঞাসিত প্রশ্ন
তোমার inbox-এ সিগন্যাল ইন্টেলিজেন্স পাও।
প্রশ্ন: Engineering manager-দের জন্য টুল ক্লান্তি কী? উত্তর: টুল ক্লান্তি হলো অনেকগুলো disconnected SaaS টুল জুড়ে কাজ ম্যানেজ করার cognitive আর operational খরচ। Engineering manager-দের জন্য এর মানে Linear, Slack, GitHub, Figma আর Notion-এর মধ্যে তথ্য সরানোতে সিদ্ধান্ত নেওয়ার চেয়ে বেশি সময় যাওয়া।
প্রশ্ন: Sugarbug কি টুল ক্লান্তিতে সাহায্য করে? উত্তর: হ্যাঁ – নেটিভ API ইন্টিগ্রেশন দিয়ে existing টুলের সাথে কানেক্ট করে, প্রতিটা থেকে সিগন্যাল classify করে, আর যেটা matter করে সেটা এক জায়গায় surface করে। প্রথম কফির আগে পাঁচটা dashboard চেক করার বদলে, দরকারি context তোমার কাছে পৌঁছে। সিগন্যাল filtering ঠিক কীভাবে কাজ করবে সেটা নিয়ে আমরা এখনও iterate করছি (সত্যি বলতে, এটা আমাদের tackle করা কঠিনতম design problem-গুলোর একটা), কিন্তু core pipeline live আছে।
প্রশ্ন: একটা typical engineering টিম কতগুলো টুল ব্যবহার করে? উত্তর: আমরা যাদের সাথে কথা বলি তাদের বেশিরভাগ টিম সাইজ আর function অনুযায়ী ৮ থেকে ১৪টা SaaS টুল চালায়। সংখ্যা নিজে সমস্যা না, সমস্যা হলো টুলগুলোর মাঝের ফাঁকে কতটা context হারায়। আমরা তিন জনের টিম দেখেছি আটটা টুল নিয়ে, আর পঞ্চাশ জনের টিম দেখেছি নয়টা টুল নিয়ে। সংখ্যার চেয়ে গুরুত্বপূর্ণ হলো টুলগুলো আসলে তথ্য share করে কিনা।
প্রশ্ন: Engineering manager-দের কি টুল stack consolidate করা উচিত? উত্তর: কখনো কখনো, কিন্তু সাধারণত ভুল frame। পাঁচটা purpose-built টুলের বদলে একটা all-in-one বসালে যেটা পাঁচটা কাজ মোটামুটি করে, মূল সমস্যা ঠিক হয় না। আসল fix হলো আগে থেকে যে টুলগুলো আছে সেগুলো কানেক্ট করা যাতে কেউ manually context copy-paste না করেও তথ্য চলাচল করে। সত্যিকারের redundancy কমাতে পারলে (দুটো project tracker, উদাহরণস্বরূপ) সেটা করো। কিন্তু ছোট সংখ্যার জন্য consolidate করো না।