মাইক্রোম্যানেজ না করে ইঞ্জিনিয়ারিং টিম ভিজিবিলিটি
মাইক্রোম্যানেজ না করে ইঞ্জিনিয়ারিং টিম ভিজিবিলিটি – কীভাবে স্ট্যাটাস রিপোর্ট নয়, কাজ থেকেই বোঝা যায় কী চলছে।
By Ellis Keane · 2026-03-13
তোমাদের টিম যদি চারজনের হয়, একই রুমে বসো, আর প্রতিদিন সকালে standup করো – এই tab বন্ধ করে দাও। আমি যা বলতে যাচ্ছি সেটা তোমাদের সত্যিই দরকার নেই, আর সেটা না বলার ভান করা অদ্ভুত লাগবে।
একই কথা ছয়জনের টিমের ক্ষেত্রেও, যেখানে একটা issue tracker আর একটা shared Slack channel ব্যবহার করো। মাইক্রোম্যানেজ না করে ইঞ্জিনিয়ারিং টিম visibility এমন একটা সমস্যা যেটা শুনতে সবার লাগে মনে হয়, কিন্তু আসলে নির্দিষ্ট scale-এ, নির্দিষ্ট শর্তে তবেই ব্যথা দেয়। তোমার surface area যদি এত ছোট হয় যে একজন ভালো manager মাথায় পুরোটা ধরে রাখতে পারে, তুমি এখনো ওই scale-এ পৌঁছাওনি। হয়তো standup একটু ritualistic, হয়তো কেউ মাঝে মাঝে ticket move করতে ভোলে, কিন্তু ওই gap-এর খরচ সপ্তাহে ধরো পনেরো মিনিট। এর জন্য আলাদা infrastructure দাঁড় করানো যায় না।
আরও সামনে যাওয়ার আগে এই threshold নিয়ে সৎ থাকা দরকার মনে করি।
কখন সমস্যা আসলে real হয়ে ওঠে
শর্তগুলো মোটামুটি এমন: বারোজনের বেশি মানুষ, তিনটার বেশি core tool, আর অন্তত দুইটা timezone বা দুইটা টিম যাদের output একে অন্যের ওপর নির্ভরশীল কিন্তু যারা একই standup share করে না। তখন manually "এই সপ্তাহে কী হলো" জোড়া লাগানোর overhead প্রায় কাজ manage করার সময়ের সমান হয়ে যায়, আর তুমি উত্তর বানিয়ে শেষ করার আগেই সেটা পুরনো হয়ে যায়।
Standup ভেঙে পড়ে না। Standup ঠিকই আছে – পনেরো মিনিটের coordination ritual, দারুণ কাজ করে – যতক্ষণ না coordinate করার বিষয় পনেরো জন মানুষের পনেরো মিনিটে মুখে বলে সারার সীমা ছাড়িয়ে যায়। ওই point-এ এটা পুরো অন্য কিছু হয়ে যায়। Performance। প্রত্যেকে তার দুই লাইনের update দেয়, সবাই মাথা নাড়ে, আর আসল প্রশ্নগুলো (কে আটকে আছে, কোথায় handoff fail করেছে, ওই PR চার দিন ধরে open কেন) জিজ্ঞেস করা হয় না – কারণ বারোজনের সামনে প্রশ্ন করার একটা সামাজিক খরচ আছে, তার ওপর meeting আগেই লম্বা হয়ে গেছে।
স্পষ্ট করে বলি, এর জন্য আমি standup-কে দোষ দিচ্ছি না। Async update দাও, written check-in thread দাও, শুক্রবারের summary email দাও – failure mode একই। তুমি মানুষকে বলছো নিজের কাজ schedule মেনে এমনভাবে self-report করতে যেটা তার নিজের চেয়ে অন্য কারও জন্য বেশি useful। এটা আসল কাজ করা মানুষের ওপর বিশাল cognitive overhead ফেলে, আর যে তথ্য বের হয় সেটা filter হয়ে আসে – প্রত্যেকে ভাবে manager কী শুনতে চায় (আমার অভিজ্ঞতায়, সেটা manager আসলে কী জানতে চায় তার থেকে বেশ আলাদা)।
নজরদারি বনাম visibility spectrum
এই gap নিয়ে engineering manager-দের যে দুশ্চিন্তা, তাকে ঘিরে পুরো একটা industry দাঁড়িয়ে গেছে, আর এর কিছু অংশ – নরমভাবে বললে – বেশ অদ্ভুত।
Sprint progress dashboard বা PR metric aggregate করা tool-এর কথা বলছি না। ওগুলো ঠিক আছে, ওগুলো গোছানো তথ্য। আমি বলছি সেই software-এর কথা যেটা প্রতি ঘণ্টায় keystroke গোনে, দশ মিনিট পরপর desktop screenshot তোলে, কোন app foreground-এ তার ভিত্তিতে "productive time" মাপে, তারপর একটা score দেয় – হ্যাঁ, আসল সংখ্যায় score – যেন বলে দিতে পারে আজ কেউ কত "খেটেছে"। এই product-গুলো আছে, customer আছে, আর "trust but verify" টাইপ line দিয়ে advertise করে, যেন irony-টা দেখতেই পাচ্ছে না। (EFF এগুলোকে "bossware" বলে, যেটা অনেক বেশি সৎ নাম।) কিছু product-এর পুরো case study page ভরা "team accountability" বাড়ার গল্পে – একটা শব্দ যেটা দিয়ে কখনো কোনো engineer নিজের কাজ নিয়ে ভালো অনুভব করেনি।
এটা spectrum-এর একদিক। অন্যদিকে আছে সেই engineering manager যে Linear খোলে, তারপর GitHub, তারপর Slack, হয়তো Notion – চারটা browser tab মিলিয়ে মাথায় ছবি বানায়, আর ছবি বানানো শেষ করার আগেই চারটার মধ্যে দুটো source বদলে যায়। দুই দিকই খারাপ, শুধু কারণে পার্থক্য – একদিকে invasive, অন্যদিকে unsustainable। আর কোনোটাই তুমি যা চাও সেটা দেয় না – কম overhead-এ, ধারাবাহিকভাবে accurate sense যে জিনিস কোথায় দাঁড়িয়ে।
মাইক্রোম্যানেজ না করে ইঞ্জিনিয়ারিং টিম visibility থাকে একটা সরু band-এ – "নজরদারি software যেটা টিম স্বাভাবিকভাবেই অপছন্দ করবে" আর "সোমবার সকালে চারটা টুল manually মিলিয়ে দেখা"-র মাঝখানে। কার্যকর version আসে চলমান কাজের সিগন্যাল থেকে – অতিরিক্ত reporting থেকে না, আর keystroke counter থেকে তো একদমই না।
মাইক্রোম্যানেজ না করে ইঞ্জিনিয়ারিং টিম visibility আসলে কেমন দেখতে
কী কাজ করে বলি, কারণ এটা নিয়ে বিব্রতকর রকম বেশি সময় ভেবেছি (আর যথেষ্ট engineering lead-এর সাথে কথা বলেছি বুঝতে যে শুধু আমিই না)।
কার্যকর version একটা সোজা premise দিয়ে শুরু হয়: তোমার engineer-রা কাজ করলেই বিপুল পরিমাণ সিগন্যাল তৈরি করে – PR, issue update, Slack discussion, design comment, commit, meeting note। এই তথ্য তোমার টিমের প্রতিদিনের tool-এ আগে থেকেই আছে; শুধু পাঁচ-ছয়টা আলাদা system-এ ছড়ানো, প্রত্যেকটার নিজের mental model আর login, ফলে cross-tool ছবি পেতে মাথায় বসে manually বানাতে হয়।
"তোমার engineer-রা কাজ করলেই প্রচুর সিগন্যাল তৈরি করে। ওগুলো শুধু পাঁচ-ছয়টা আলাদা system-এ ছড়ানো – connect হওয়ার অপেক্ষায়।" – Ellis Keane
তাই কার্যকর version ওই tool-গুলোর সাথে connect করে, তৈরি হওয়া সিগন্যাল ingest করে, আর এমন summary দেয় যা engineering manager আসলে যে প্রশ্ন করে তার উত্তর দেয়:
- এই সপ্তাহে মানুষ আর project মিলিয়ে কী হয়েছে – keystroke না, meaningful সিগন্যাল: merged PR, completed issue, design review। প্রতিটা source-এ link করা, কিছু অস্বাভাবিক লাগলে detail-এ যাওয়া যায়।
- কোথায় জিনিস আটকে থাকতে পারে – ৭২ ঘণ্টা reviewer ছাড়া open PR, ছয় দিন "In Progress" থাকা issue কিন্তু linked commit নেই, Slack thread-এ blocking question আছে কিন্তু উত্তর নেই। Judgment না, তথ্য হিসেবে flag। Delay সমস্যা কিনা system জানে না – তুমি জানো।
- Issue tracker-এর বাইরে হওয়া সিদ্ধান্ত – কারণ API approach নিয়ে Slack thread-এ হওয়া বিতর্ক PR-এর মতোই গুরুত্বপূর্ণ, আর "এভাবে বানালাম কেন" প্রশ্ন উঠলে এটাই আগে হারিয়ে যায়।
- সময়ের সাথে pattern – কার ওপর review load অসামঞ্জস্যভাবে বেশি পড়ছে, কোন টিমের handoff বারবার আটকে যাচ্ছে, কোন project-এ churn বেশি। এগুলো performance metric না (এভাবে frame করা system-কে আমি নিজেই সন্দেহ করতাম); এগুলো system health indicator – আগে ধরতে পারলে burnout ঠেকায়, না পারলে resignation বাড়ায়।
এর কোনোটার জন্য কাউকে status update লিখতে, বাড়তি meeting-এ যেতে, বা form পূরণ করতে হয় না।
যে অংশগুলো সত্যিই কঠিন
Tool থেকে data বের করা তুলনামূলক সহজ – বেশিরভাগ engineering tool-এ API আর webhook আছে, যদিও schema change আর rate limit-এর কারণে ingestion vendor documentation যতটা সহজ দেখায় ততটা না।
কঠিন অংশগুলো হলো যেগুলোর পরিষ্কার technical solution নেই।
Granularity। কেউ গত সপ্তাহে তিনটা PR merge করেছে আর দুটো design review-তে অংশ নিয়েছে – এটা 1:1 কথোপকথনের জন্য useful context। কিন্তু দিনে গড়ে ৪.৭ commit আর median review turnaround ২.৮ ঘণ্টা – এটা performance monitoring-এর মতো শোনাতে শুরু করে, তোমার উদ্দেশ্য সেটা না হলেও। "Helpful context" আর "আমাকে নজরদারি করা হচ্ছে"-র সীমারেখা technical না – cultural। আর এটা টিম, manager, আর মানুষ system-কে descriptive না evaluative মনে করে তার ওপর বদলায়।
কে কী দেখবে। আমি full transparency-র দিকে ঝুঁকি – পুরো টিম একই তথ্য দেখলে dashboard coordination tool হয়, surveillance tool না, আর মানুষ blocker দ্রুত flag করে কারণ তারা দেখে অন্যরাও দেখছে। কিন্তু এমন lead-দের সাথেও কথা বলেছি যাদের টিমে ওই মাত্রার visibility anxiety বাড়াবে, কমাবে না – আর তারা ভুল না। টিমভেদে আলাদা। Configurable করাই সঠিক পথ মনে হয়, যদিও কখনো "configurable" মানে "আমরা সিদ্ধান্তে পৌঁছাতে পারিনি।"
ভিন্নভাবে কাজ করা মানুষ। কিছু engineer কয়েকদিন চুপচাপ থাকে – tool-এ activity কম – তারপর বিশাল, দারুণভাবে structured PR ship করে। Naive visibility system তখন peak productivity-তে থাকা মানুষকেই inactive flag করে। সঠিক approach হলো দিন ধরে না, সপ্তাহ ধরে pattern দেখা, আর individual activity level-এর ওপর ভিত্তি করে alert generate না করা। তবে সৎভাবে বলি, এখানে technology organizational design-এর চেয়ে এগিয়ে – false alarm এড়িয়ে system বানানো যায়, কিন্তু screen-এ তাকানো manager-কে তবুও নিজের instinct সামলাতে হয়, "ও এতদিন চুপ কেন" ভাবা থেকে।
আসলে adoption হওয়ার শর্ত
Cross-tool project visibility নিয়ে লেখালেখিতে যেটা হারিয়ে যায়: technical problem (tool connect করা, সিগন্যাল ingest করা, summary তৈরি করা) solved বা solvable। Adoption problem – টিমকে সত্যিই trust করিয়ে visibility system use করানো – এমন কিছু দরকার যা technology দিতে পারে না: এমন manager যে তথ্যটা coordination-এর জন্য ব্যবহার করতে genuinely committed, control-এর জন্য না। The visibility gap between modern work tools is a systems problem, not a people problem, and closing it means pairing engineering metrics derived from Git and CI rather than Jira with why most unified inboxes fail to connect related engineering signals – because neither metrics nor inboxes help when the underlying connections are missing.
তোমার টিমের কেউ যদি নিজের activity trail দেখে ভাবে "মঙ্গলবার চুপ ছিলাম বলে manager judge করবে," তাহলে system design যতই ভালো হোক, সেটা fail। আর তুমি যদি সত্যিই সেই ধরনের manager হও যে চুপ মঙ্গলবারের জন্য judge করবে, তাহলে মাইক্রোম্যানেজ না করে ইঞ্জিনিয়ারিং টিম visibility-র কোনো পরিমাণই সাহায্য করবে না – কারণ micromanaging tool-এর সমস্যা না, তোমার সমস্যা।
যে টিমগুলোকে এই ধরনের system থেকে সবচেয়ে বেশি value পেতে দেখেছি, সেগুলোতে manager স্পষ্টভাবে বলে (আর সত্যিই মানে) এরকম কিছু: "তুমি কী নিয়ে কাজ করছো সেটা জিজ্ঞেস না করতে হয়, এই জন্য এটা। তোমাকে check করার জন্য না।" এটা cultural statement, technical না – আর পৃথিবীর কোনো dashboard এটা substitute করতে পারে না।
তোমার টিম ইতিমধ্যে যে সিগন্যাল তৈরি করছে, সেখান থেকেই দেখো তারা কী নিয়ে কাজ করছে – status report না, নজরদারি না।
Q: মাইক্রোম্যানেজ না করে কীভাবে ইঞ্জিনিয়ারিং টিম visibility পাবো? A: Shift-টা হলো "মানুষকে report করতে বলো" থেকে "কাজকেই report করতে দাও।" তোমার engineer-রা যদি GitHub-এ commit করে, Linear-এ ticket move করে, Slack-এ decision নেয়, তাহলে দরকারি তথ্য আগেই আছে – শুধু connect করে summarise করতে হবে। Sugarbug এটা করে তোমার টুলগুলো জুড়ে নলেজ গ্রাফ বানিয়ে, তাই visibility আসে টিমের আগে থেকেই তৈরি করা সিগন্যাল থেকে, বাড়তি reporting overhead থেকে না।
Q: Sugarbug কি standup বা status meeting replace করে? A: সবসময় না, আর আমি এটাকে ওইভাবে frame করতে সাবধান থাকতাম। সাধারণত যা হয়, basic status তথ্য automatically flow করলে standup round-robin reporting থেকে সরে trade-off আর priority নিয়ে আসল আলোচনায় যায় – যেটা (হ্যাঁ, একটু ironic) standup-এর শুরুর উদ্দেশ্যই ছিল। রাখবে, ছোট করবে, নাকি বাদ দেবে, সেটা টিমের ওপর নির্ভর করে।
Q: টিম activity দেখাতে Sugarbug কোন সিগন্যাল ব্যবহার করে? A: GitHub থেকে PR, commit, code review। Linear থেকে issue movement আর sprint progress। Slack thread থেকে decision আর discussion। Figma থেকে design review comment। Notion update, email thread, calendar event-ও। প্রতিটা সিগন্যাল classify হয়ে সংশ্লিষ্ট মানুষ আর task-এর সাথে link হয় – টিম কাজ করতে থাকলে graph নিজে থেকেই connection তৈরি করে, তোমাকে manually সব tag করতে হয় না।
Q: টিম visibility data সবাই দেখবে, নাকি শুধু manager? A: এটা configurable, আর এর নিচে একটা আসল দার্শনিক প্রশ্ন আছে। আমরা মনে করি full transparency সাধারণত ভালো ফল দেয় – duplicate status update কমে, unblocking দ্রুত হয়, dashboard monitoring tool না হয়ে coordination tool হয়। তবে কিছু টিমের নির্দিষ্ট view সীমিত রাখার valid কারণ থাকে, আর আমরা সেটাও support করি, compromise মনে না হওয়ার মতো করে।
Q: Sugarbug কি দেখাতে পারে এই সপ্তাহে টিমের কেউ কী নিয়ে কাজ করেছে? A: হ্যাঁ – টুলজুড়ে per-person activity trail: খোলা PR, move করা issue, অংশ নেওয়া decision, completed review। এগুলো তোমার existing tool-এ ছড়ানো একই তথ্য, Sugarbug শুধু connect আর summarise করে যাতে মাথায় manually জোড়া লাগাতে না হয়। একটা বিষয় ইচ্ছে করেই করি: raw metric যেমন commit count বা "active hours" দেখাই না, কারণ এগুলো ভুল behaviour incentivise করে আর কাজের quality বা impact নিয়ে প্রায় কিছুই বলে না।
---
তুমি যদি ওই অস্বস্তিকর মাঝামাঝি অবস্থায় থাকো – manually synthesis করার জন্য টুল-মানুষ দুটোই বেশি, কিন্তু surveillance software বসানোর মতো নও – তাহলে ঠিক এই gap-টাই নিয়ে আমরা ভাবছি। আমরা এখনো শুরুর দিকে, আর publicly build করছি। ওয়েটলিস্টে যোগ দাও।