"ভালো টিম" আর "দুর্দান্ত টিম" এর মধ্যে পার্থক্য কোথায়?

গত মাসে আমাদের একটা payment system এ বারবার একই সমস্যা আসছিল। Transaction fail হচ্ছে, একজন developer ঠিক করছে, ticket close হচ্ছে। তিনদিন পর আবার একই জিনিস।

আমি log গুলো দেখলাম। একই মূল কারণ। কিন্তু কেউ সেটা fix করেনি। সবাই শুধু symptom দূর করে চলে গেছে। ভেতরের অসুখটা ধরেনি।

মাস শেষে হিসাব করলাম। একই সমস্যায় টিম ১০+ ঘণ্টা নষ্ট করেছে। মূল কারণটা fix করতে ৫-৬ ঘণ্টা লাগতো।

সত্যি বলতে, এটা শুধু আমাদের টিমের সমস্যা না। Brain Station 23, Selise, TigerIT এর মত company গুলোতেও এই জিনিসটা দেখা যায়। প্রায় প্রতিটা software team এ।

Anton Zaides, Manager.dev newsletter এর লেখক এবং ১৫+ বছরের tech experience নিয়ে কাজ করছেন। তিনি এই বিষয়ে বিস্তারিত লিখেছেন (source)। উনার মতে, একটা "ভালো" টিম আর "দুর্দান্ত" টিমের মধ্যে পার্থক্য মোটে ৭টা ছোট অভ্যাসে।

কাজ দুগুণ করা না। ১০x engineer থাকা না। শুধু কিছু habit।

আমি উনার ১০টা article পড়েছি। নিজের ৫ বছরের experience মিলিয়ে, এই ৭টা habit, ২টা bonus point, আর FDE এর মত নতুন concept গুলো আমাদের দেশের software company গুলোতে কীভাবে কাজে লাগে, সেটা লিখছি।

কিছু শব্দ আগেই বুঝে নিই:
EM / Team Lead = Engineering Manager। আমাদের দেশে একে Team Lead, Project Lead, বা Tech Lead ও বলা হয় (যিনি টিম চালান)
PM = Product Manager (যিনি কী feature বানাবে ঠিক করেন)
Ticket = Jira/Trello তে কাজের একটা item
PR = Pull Request (code review এর জন্য কোড submit করা)
Deploy = code production server এ পাঠানো
Tech Debt = এমন code বা architecture যেটা পরে সমস্যা তৈরি করবে (ঋণের মতো, পরে শোধ করতে হয়)
Bottleneck = এমন একটা জায়গা যেটা পুরো কাজকে ধীর করে দেয়
AI Coding Tool = Cursor, Claude Code, GitHub Copilot এর মত tool যা code লিখতে, review করতে, debug করতে সাহায্য করে
FDE = Forward Deployed Engineer। engineer যিনি client এর কাছে সরাসরি থাকেন, তাদের সমস্যা বোঝেন, আর solution বানান

📌 Patch না, Root Cause

ভালো টিম bug fix করে। সামনে এগোয়। কিন্তু একই bug আবার আসে। আবার fix। আবার আসে।

আবার fix।

একটা উদাহরণ দিই। ধরুন, আপনার পেট ব্যথা হচ্ছে বারবার। আপনি প্রতিবার painkiller খেয়ে সামলাচ্ছেন। কিন্তু ডাক্তার দেখাচ্ছেন না। এক সময় ব্যথা আরো বড় হবে।

Software এও একই। bKash বা SSL Commerz integration এ কোনো timeout issue আসছে? alert ignore করছেন। test fail করলে restart দিচ্ছেন। manual কাজটা প্রতিদিন হাতে করছেন।

সবই patch। আর patch জমতে থাকে।

এখন যদি AI tool (Cursor, Copilot) ব্যবহার করেন? সেকেন্ডে bug ঠিক হয়ে যাচ্ছে। কিন্তু root cause? AI ও শুধু symptom ঠিক করছে। ভালো টিম এই trap এ পড়ে। দুর্দান্ত টিম প্রশ্ন করে, "AI কেন এটা ঠিক করলো? মূল সমস্যাটা কী?"

xkcd এর একটা famous table আছে। যে কাজে আপনার সপ্তাহে ১৫ মিনিট যায়, সেটা fix করতে ২ দিন লাগলেও ৫ বছরে সেটা লাভের।

একটু ভেবে দেখুন। আপনার টিমে কতগুলো এমন ছোট ছোট patch চলছে?

দুর্দান্ত টিম এই decision টা ভেবে নেয়। কতবার হচ্ছে, fix করতে কত সময়, সব হিসাব করে একটা clear decision। চুপচাপ মেনে নেওয়া না।

📌 কাজ করা না, Own করা

ভালো টিমে engineer কাজ করে। Team Lead decide করে কে কী করবে, engineer execute করে।

সোজা কথায়, Team Lead হয়ে যায় একটা "task routing machine।" টিকিট ঢুকছে, Lead assign করছে, engineer কাজ শেষ করছে। আবার নতুন ticket।

দুর্দান্ত টিমে engineer কাজ own করে। Anton একে বলেছেন "kingdom" (source)।

ধরুন, আপনার টিমে একটা notification service আছে। কে সেটার owner? যে engineer সেটা own করছে, সে-ই সেই service এর সব decision নেয়। কীভাবে চলবে, কখন update হবে, সব তার।

এখন সত্যি কথা হলো, আমাদের দেশের অনেক company তে hierarchy খুব strong। Junior বা Mid-level engineer কে decision দেওয়া খুব rare। Senior বা Lead সব নেন।

কিন্তু ছোট পরিসরে শুরু করা যায়। "তুমি এই module টা দেখো, তোমার decision" শুধু এটুকু বললেও একটা পরিবর্তন আসে।

AI যুগে এটা আরো বেশি গুরুত্বপূর্ণ। AI যখন boilerplate code লিখে দিচ্ছে, তখন engineer এর মূল কাজ হলো decision নেওয়া। "কোন architecture, কোন design pattern," এসব decision এখন মানুষের।

Anton আরেকটা article এ বলেছেন, developer রা কেন চাকরি ছাড়ে (source)। প্রথম কারণটা salary না। প্রথম কারণ হলো, তারা মনে করছে আর নতুন কিছু শিখছে না।

মানে, ownership দেওয়া শুধু ভালো কাজের জন্য না। ভালো engineer ধরে রাখার জন্যও।

📌 নিজেকে না, অন্যকে আগে

আমাদের দেশের company গুলোতে একটা জিনিস খুব বেশি দেখি। এক টিম আরেক টিমের code review তে সপ্তাহ খানেক সময় নেয়। যে টিম review চেয়েছে, তারা অপেক্ষা করতে করতে হতাশ। শেষে নিজেরাই merge করে ফেলে।

Anton এর নিজের একই experience আছে (source)। ঐ টিমের EM review তে ২ সপ্তাহ সময় নিয়েছেন। তারা হতাশায় নিজেরাই merge করে ফেলেছেন।

খেয়াল করুন, review নিয়ে actual data কী বলে। Weave (৪০০+ company এর data analyze করে) এর research (source):

যে টিম ৩ ঘণ্টার মধ্যে review করে, তারা ৮+ ঘণ্টা নেওয়া টিমের চেয়ে ২.১ গুণ বেশি productive।

আর এখন AI reviewer আছে। Sumanyu এর টিম (Hamming AI) একসাথে কয়েকটা AI reviewer ব্যবহার করে (source)। AI প্রথমে সব comment করে, engineer সেগুলো triage করে, তারপর human review আসে। ফলে PR merge এ সময় লাগে মাত্র ১-২ ঘণ্টা।

দুর্দান্ত টিম ৯০% ক্ষেত্রে অন্য টিমের কাজ আগে করে। খুব কঠিন, বিশেষ করে আমাদের দেশে যেখানে টিমগুলোর মধ্যে "এটা আমার কাজ না" মানসিকতা বেশি। কিন্তু যে টিম এটা করে, পুরো company তে তার নাম হয়ে যায়।

Anton, Adam Grant এর "Give and Take" book থেকে একটা জিনিস share করেছেন। মানুষ তিন রকমের হয়:

• Taker: যারা শুধু নিজের সুবিধা চিন্তা করে।
• Matcher: যারা help করে কিন্তু ভাবে, "আমি কালকে সাহায্য করলাম, আজকে সে আমাকে করবে।"
• Giver: যারা কোনো শর্ত ছাড়াই help করে।

খেয়াল করুন, সবচেয়ে কম perform করে কারা? Giver। কারণ তারা সবাইকে help করে নিজের কাজ করতে পারে না।

কিন্তু সবচেয়ে বেশি perform করে কারা?

আবার Giver।

📌 Execute না, Shape

ভালো টিম PM বা client এর roadmap execute করে। PM decide করে কী হবে, engineer বানায়।

দুর্দান্ত টিম roadmap বানাতে সাহায্য করে। Customer এর সাথে কথা বলে। Business বোঝে। যে feature টা make sense করে না, সেটায় push back করে।

খেয়াল করুন, আমাদের দেশের সংস্কৃতিতে senior বা manager কে question করা "disrespect" মনে হয়। Power distance বেশি। কিন্তু push back মানে fight করা না। push back মানে হলো, "এই feature টার পরিবর্তে যদি এটা করি, customer আরো বেশি happy হবে।" Data দিয়ে কথা বলা।

Anton নিজে একবার এই trap এ পড়েছিলেন। PM তাকে না জানিয়ে একটা deadline promise করেছিলেন। Anton রেগে যাওয়ার পরিবর্তে PM কে call করলেন। শান্তভাবে জিজ্ঞেস করলেন কেন। জানলেন PM ও ৩ জন executive এর pressure এ ছিলেন। তারপর দুজন মিলে plan বানালেন।

মানে, সমস্যার দিকে না তাকিয়ে, সমাধানের দিকে তাকালে অনেক সমস্যা ছোট হয়ে যায়।

Hamming AI এর CEO Sumanyu একটা দারুণ experiment করেছিলেন (source)। তিনি আগে customer এর সাথে নিজে কথা বলতেন, তারপর engineer দের বুঝিয়ে বলতেন। Engineer রা customer এর আসল সমস্যা feel করতো না।

তিনি engineer দের সরাসরি customer এর Slack channel এ যুক্ত করলেন। এখন engineer রা নিজে কথা বলে, নিজে সমস্যা বোঝে, আর অনেক সময় সেই দিনেই solution deploy করে দেয়।

"Maximize the bandwidth between the person who has the problem, and the person who can solve it।"

আমাদের দেশে offshore project এ এটা আরো বেশি relevant। Client এর সাথে engineer এর direct communication না থাকলে কাজ দ্রুত হবে না।

Palantir এর মত company গুলো এজন্য একটা role popularize করেছে, নাম Forward Deployed Engineer বা FDE। FDE টিমে বসে code লেখে না। সরাসরি client এর কাছে যায়। তাদের workflow বোঝে, আসল সমস্যা দেখে, তারপর solution বানায়। অর্ধেক engineer, অর্ধেক business analyst।

আমাদের দেশে এটা খুব কম দেখা যায়। অধিকাংশ offshore company তে engineer শুধু requirement document পায়। Client কে, তার business, তার আসল সমস্যা, কিছুই জানে না।

ধরুন, bKash এর মত একটা fintech কোম্পানিতে কাজ করছেন। Client বললেন, "আমাদের একটা report dashboard দরকার।" আপনি বসে বানালেন। ২ সপ্তাহ পর deliver করলেন। Client দেখে বললেন, "এটা তো আমার দরকার না, আমি তো চেয়েছিলাম transaction summary।"

FDE হলে কী হতো? আপনি client এর সাথে ১ ঘণ্টা কথা বলতেন। বুঝতেন তার আসল কী দরকার। তারপর ৩ দিনে সেটা বানিয়ে দিতেন। সময় বাঁচতো, client happy হতো, আপনিও frustrated হতেন না।

AI যুগে কোড লেখা cheap হয়ে গেছে, কিন্তু "সঠিক সমস্যা চিনে নেওয়া" এখনো দামি skill। FDE টাইপ engineer রা এখন সবচেয়ে বেশি valuable।

📌 Plan মেনে চলা না, Plan বাতিল করা

Roadmap বানানো হলো। Phase ১, ২, ৩। Phase ১ এর পর customer feedback এলো, negative।

কিন্তু Phase ২ এর কাজ শুরু হয়ে গেলো। কেউ থামতে চায় না।

কেন? কারণ engineer রা শুনতেই চায় না যে কোড তারা লিখেছে সেটা বাদ দিতে হবে।

দুর্দান্ত টিম শুরুতেই প্রশ্ন করে। কীভাবে measure করবো? Phase ১ success এর definition কী? লক্ষ্য পূরণ না হলে কী হবে? কী হলে আমরা feature টাই বাদ দেবো?

শেষের প্রশ্নটা সবচেয়ে কঠিন। বেশিরভাগ company তে এর উত্তর নেই।

📌 Launch না, Land

ভালো টিম feature deploy করে। Production এ গেছে, PR merged, ticket closed। উৎসব।

দুর্দান্ত টিম deploy কে অর্ধেক পথ মনে করে।

কেউ কি আসলে use করছে? সংখ্যা কি এগোলো? কোনো সমস্যা আছে?

আমি নিজে দেখেছি, feature এর পর feature ship হচ্ছে। প্রতিটা "done।" কিন্তু product তে কোনো improvement হচ্ছে না।

Feature launch হলো। কিন্তু কাজে লাগলো না।

offshore project এ এটা সবচেয়ে বেশি। Client feature চায়, টিম deliver করে, ticket close হয়। কেউ চেক করে না যে এটা আসলে কাজে লাগলো কি না।

📌 Tech Debt কে অবহেলা না, Business Case

ভালো টিমে দুটো backlog থাকে। Product backlog আর tech backlog। Tech এর জিনিসগুলো সবসময় পিছিয়ে যায় যখনই কিছু "urgent" আসে।

দুর্দান্ত টিম tech এর প্রতিটা কাজ কে business value দিয়ে explain করে। "Monolith refactor করতে হবে" না। "এই logic টা আলাদা service এ নিলে আমরা ৩x দ্রুত feature ship করতে পারবো, অন্য টিমের জন্য অপেক্ষা করতে হবে না।"

এখন AI যুগে এটা সবচেয়ে বড় ঝুঁকি। Pragmatic Engineer এর data বলছে (source), developer রা এখন ৬ মাস আগের চেয়ে ২ গুণ বেশি code generate করছে। মানে ২ গুণ দ্রুত tech debt জমছে। যদি কেউ root cause না ভাবে, শুধু AI এর output accept করে, ৬ মাস পর সেই codebase এ কাজ করা দুঃস্বপ্ন হবে।

📌 যেটা দেখা যায় না

Anton এর আরেকটা article পড়লে একটা অদ্ভুত জিনিস জানা যায় (source)। একজন senior engineer এর ৪০% সময় এমন কাজে যায় যেটা কোনো ticket এ নেই।

Code review। Junior দের সাহায্য করা। হঠাৎ support এর request।

এসব কেউ দেখে না। Promotion এর সময় কেউ count করে না।

এটা আমাদেশে আরো বেশি খাটে। আমাদের অনেক company তে engineer এর performance evaluate করা হয় কতটা ticket close করলো, সেটা দিয়ে। Code review, mentorship, knowledge sharing, এসব কেউ count করে না।

মানে, যে কাজ টিমকে একসাথে ধরে রাখে, সেটাই সবচেয়ে কম দেখা যায়।

📌 সবচেয়ে বড় Bottleneck টা খুঁজুন

Sumanyu একটা সহজ framework দিয়েছেন (source)। আপনার টিমকে একটা প্রশ্ন করুন। "তোমরা সময় সবচেয়ে বেশি কোথায় নষ্ট করো?"

উত্তরটা আপনার roadmap হবে। সবচেয়ে বড় bottleneck টা fix করুন। তারপর পরেরটা।

"The goal isn't to optimize everything. It's to remove the biggest source of waste, then move to the next one।"

Sumanyu এর টিম ১০,০০০+ unit test লিখেছে। এটা শুনে হয়তো ভাবছেন, "আমার company তে তো ১০০ test ও নেই।" সেটাও ঠিক আছে। শূন্য থেকে শুরু করুন। AI দিয়ে দ্রুত ship করলে bug ও দ্রুত আসে, তাই test লেখা এখন আগের চেয়ে বেশি দরকারী।

আজই কী করবেন?

একটু ভেবে দেখুন, এই habit গুলোর কোনটা আপনার টিমে নেই?

১. একটা বারবার আসা issue খুঁজুন। হিসাব করুন। যদি লাভ হয়, আজই root cause fix করার কথা টিমে রাখুন।

২. একজনকে একটা module বা service এর দায়িত্ব দিন। ছোট হলেও ঠিক আছে। Decision তার।

৩. একটা feature identify করুন যেটা সম্প্রতি launch হয়েছে। সেটা আসলে কেউ use করছে কি না, data চেক করুন।

৪. Tech debt কে business impact দিয়ে explain করুন। "এতে feature delivery ৩x slow হচ্ছে।"

৫. টিমকে প্রশ্ন করুন। "সময় সবচেয়ে বেশি কোথায় নষ্ট হয়?" সবচেয়ে বড় bottleneck টা এই সপ্তাহে fix করুন।

৬. FDE mindset নিয়ে কাজ শুরু করুন। পরের বার client কে কিছু ask করলে, শুধু requirement না নিয়ে তার সাথে ১৫ মিনিট কথা বলুন। "আপনি এটা কেন চাচ্ছেন, আপনার আসল সমস্যাটা কী?" এই একটা প্রশ্ন পুরো কাজ বদলে দিতে পারে।

শেষ করি সেই payment gateway issue এর কথা দিয়ে। আমরা সেই মাসেই root cause fix করলাম। ৬ ঘণ্টা লাগলো। এরপর থেকে সেই issue আর কখনো আসেনি।

৬ ঘণ্টা। ১০+ ঘণ্টার বারবার নষ্ট হওয়া সময়ের বদলে।

প্রশ্ন হলো, আপনার টিমে কোন patch টা আজই root cause fix করার দরকার? আর সবচেয়ে গুরুত্বপূর্ণ, আপনি নিজে কোন দিকে যাচ্ছেন, ভালো নাকি দুর্দান্ত?

---

Sources

1. Anton Zaides - "Okay vs Excellent Engineering Teams" - newsletter.manager.dev
2. Anton Zaides - "Give Your Engineers a Kingdom" - newsletter.manager.dev
3. Anton Zaides - "Shadow Work in Engineering Teams" - newsletter.manager.dev
4. Anton Zaides - "Why Developers Quit" + "The Victim Engineering Manager" - newsletter.manager.dev
5. Anton Zaides - "When Your PM Drives You Crazy" + "The Delayed Opinions Givers" - newsletter.manager.dev
6. Anton Zaides - "The Best Engineering Manager I Know" (Give and Take) - newsletter.manager.dev
7. Anton Zaides & Sumanyu Sharma - "Engineering Velocity on Steroids (10x Team)" - newsletter.manager.dev
8. Anton Zaides - "The Price of Mandatory Code Reviews" - newsletter.manager.dev
9. Gergely Orosz - "Slow Down to Speed Up with AI Agents" (Pragmatic Engineer) - newsletter.pragmaticengineer.com
10. Peopleware by Tom DeMarco & Timothy Lister + Give and Take by Adam Grant (book references)