چرا یک Engineering Manager نباید Code Review انجام دهد؟

وقتی در مورد سازمان‌دهی تیم ها صحبت می‌کنم، اغلب از من می‌پرسند: «چرا فردی که Technical Lead تیم است، مدیر تیم نمی‌شود؟» و یا اینکه «با توجه به اینکه شما می‌خواهید مدیران در تیم‌ها حضور داشته باشند، آیا مدیر هنوز می‌تواند بررسی کد (Code Review) انجام دهد؟»

این سوالات همیشه مطرح می‌شود. اما بیایید کمی عمیق‌تر به این سوال و پاسخ های آن فکر کنیم.

• چرا Technical Lead نباید مدیر تیم باشد؟
• چرا Engineering Manager نباید بررسی کد انجام دهد؟

مانند همه‌چیز در فناوری، پاسخ به موقعیت بستگی دارد. در اینجا سعی می‌کنم به این سوال همیشگی پاسخ دهم که «چرا Technical Lead نباید تیم را مدیریت کند و چرا یک Engineering Manager با تیمی به اندازه کافی بزرگ نباید Code را بررسی کند؟»

برای پاسخ به این سوال، سه جنبه را در نظر می‌گیریم: تعریف نقش، پیچیدگی ارتباطات تیمی و اندازه تیم. بیایید استدلال‌هایم را با کمک نمودارها بازگو کنم.

تفاوت بین نقش Engineering Manager و Technical Lead

ابتدا به تعریف نقش می‌پردازیم. Engineering Manager و Technical Lead دو نقش با مهارت‌های متفاوت هستند. ممکن است فردی در یک نقش عالی باشد اما در نقش دیگر نه (و برعکس). به عنوان نمونه، بهترین برنامه‌نویس تیم همیشه بهترین فرد برای سازمان‌دهی همه‌چیز نیست.

با این حال، تیم به هر دو نقش نیاز دارد تا بهینه عمل کند. بنابراین بیایید این نقش‌ها را مقایسه و تفاوت‌هایشان را بررسی کنیم.

وقتی یک مهندس می‌خواهد مدیر شود، من با یک سری سوال شروع می‌کنم: «آیا مطمئنی؟»، زیرا این‌ها نقش‌های بسیار متفاوتی هستند.

این جدول نشان‌دهنده یک مشارکت بین Technical Lead و Engineering Manager است. تقسیم کار بین کار سازمانی و ارتباطی از یک سو و تفکر عمیق فنی از سوی دیگر. این نقش‌ها از نظر سطح و دامنه در تیم برابر هستند، اما فعالیت‌های متفاوتی انجام می‌دهند تا موفقیت تیم را تضمین کنند.

برای اینکه این مشارکت بین Engineering Manager و Technical Lead به درستی اتفاق بیفتد، باید بین آن‌ها اعتماد ایجاد شود.

• مدیر مهندسی باید رهبری فنی تیم را به Technical Lead واگذار کند و از جزئیات فنی دور بماند. مدیران نباید از اتوبوس بیفتند و دهه‌ها تجربه فنی را فراموش کنند. اما مدیریت اساساً یک شغل سیاست‌گذاری است، و مدیران باید مرزها را رعایت کنند. هر چیز دیگری، همانند Micromanaging (مدیریت جزئی‌نگر) باعث از بین رفتن اعتماد می شود.
• یک Technical Lead باید کارهای مربوط به رشد شغلی، رشد تیم، ارتباطات و هماهنگی را به Engineering Manager واگذار کند و روی معماری، انتخاب‌های فنی، جهت‌گیری فنی و کمک به اجرا متمرکز شود.

با این حال، این تمایز بین Engineering Manager و Technical Lead تا زمانی که تیم حداقل ۴ نفر نداشته باشد، لازم نیست. در یک تیم با تعداد ۴ نفر و بیشتر، نقش‌ها تقسیم می‌شوند و Engineering Manager باید روی تیم متمرکز شود و یک مشارکت مبتنی بر اعتماد با Technical Lead ایجاد کند.

بیایید ببینیم چرا تیم با تعداد ۴ نفر و بیشتر یک نقطه عطف است.

پیچیدگی ارتباطات O(n²)

یک مدیر، تیمی را می‌سازد که بر اساس اصول ارتباطی قوی کار می‌کند. با اضافه شدن اعضای جدید به تیم، مسیرهای ارتباطی در تیم چند برابر می‌شوند. ما به طور شهودی فکر می‌کنیم که پیچیدگی ارتباطات تیمی به صورت O(n) رشد می‌کند،

پیچیدگی ارتباطات در یک تیم به صورت (2/((1-n)*n) رشد می‌کند، یا به عبارت دیگر، O(n²) (زمان درجه دوم).

• در ابتدا، شما تنها نفر در تیم هستید، بنابراین تمام روز با خودتان صحبت می‌کنید و تعداد مسیر ارتباطی صفر می باشد.
• شما یک نفر (A) به تیم اضافه می‌کنید. حالا شما با A صحبت می‌کنید و A با شما صحبت می‌کند، ۱ مسیر ارتباطی.
• شما یک نفر دیگر (B) به تیم اضافه می‌کنید. حالا شما ۳ مسیر ارتباطی دارید، شما با A، شما با B، و A با B.
• شما یک نفر دیگر (C) به تیم اضافه می‌کنید. حالا شما ۶ مسیر ارتباطی دارید.
• و به همین ترتیب.

وقتی تیمی با ۵ نفر (۶ نفر در کل، شما + ۵ مهندس) ایجاد کنید و یک مدیر محصول و یک Data Scientist اضافه کنید، مدیر تیم باید ۲۶ مسیر ارتباطی (2/(7 * 8)) را مدیریت کند تا تیم بتواند کارها را پیش ببرد. اگر چند تیم همکار و ارتباط با بازاریابی، فروش و خدمات مشتریان را اضافه کنید، مدیریت تیم ناگهان به یک شغل تمام‌وقت تبدیل می‌شود.

همه این ارتباطات نشان‌دهنده سرمایه‌گذاری در زمان هستند. مدیر مانند عنکبوتی در یک تار پیچیده از ارتباطات است، از جمله:

• ایجاد وضوح کامل در اولویت‌بندی‌ها،
• هدایت اجرای تیم،
• هماهنگی وضعیت و انتشار با ذینفعان،
• مدیریت روان فرآیندهای تیم،
• ارتباط اهداف، انتظارات و عملکرد تیم و افراد برای رشد شغلی،
• باز کردن گره‌های ارتباطی تیم،
• و غیره.

حتی مدیریت جلسات تیم با رشد تیم پیچیده می‌شود. جنبه منفی رشد تیم، «نارسایی‌های مقیاس پذیر» نامیده می‌شود. هر چه مقیاس سیستم بیشتر شود، هزینه پیچیدگی افزایش می‌یابد. این پیچیدگی به این دلیل است که جلسات استندآپ با افزایش تعداد افراد به تدریج متوقف می‌شوند و تیم نمی‌تواند بی‌نهایت بزرگ شود.

اضافه کردن افراد زیاد به تیم باعث فروپاشی آن می‌شود. وقتی ارتباطات به عدد دانبار (Dunbar’s number) برسند، مدیر دیگر نمی‌تواند پیچیدگی ارتباطات را به تنهایی مدیریت کند. این آستانه حدود ۱۷ نفر (۱۳۶ ارتباط) است، پس از آن مدیر باید شروع به اولویت‌بندی روابط کند، تیم را به دو بخش تقسیم کند یا بیشتر وظایف را واگذار کند.

بیایید این را به صورت نمودار ترسیم کنیم و ببینیم چه اتفاقی می‌افتد.

منحنی اندازه تیم

ما همه اینجا مهندس هستیم. اگر بتوانیم کاری انجام دهیم، ترسیم نمودار است.

ما پیچیدگی ارتباطات و اندازه تیم را ترسیم می‌کنیم تا ببینیم Engineering Manager چه زمانی باید خود را از فناوری دور کند و روی سربار ارتباطات لازم برای یک تیم سالم متمرکز شود. (ما مدیر را در شمارش‌ها لحاظ می‌کنیم، بنابراین این اعداد شامل Engineering Manager + مهندسان است.)

در تیم‌های ۱ تا ۳ نفره، ارتباطات توسط گروه قابل مدیریت است، تیم هنوز کوچک و سبک است. و در این اندازه، رهبر تیم می‌تواند نقش یک Technical Lead - Manager (TLM) را انجام دهد. رهبر یک تیم فنی کوچک که هنوز می‌تواند کد بنویسد و وظایف فنی انجام دهد، در حالی که بسیاری از جنبه‌های نقش مدیر را نیز حفظ می‌کند: رشد مهندسان، انجام بررسی‌های عملکرد، مدیریت سربار همکاری با تیم‌های مجاور و غیره.

زمانی که ۶ مسیر برای هماهنگی وجود دارد. ۶ مسیر ممکن است زیاد به نظر نرسد، اما وقتی به رشد، عملکرد، اولویت‌بندی و هماهنگی برای ۴ نفر فکر می‌کنید، این کار به اندازه‌ای زمان می‌برد که خروجی فنی شروع به کاهش می‌کند و چیزی باید قربانی شود (یا خروجی یا دقت ارتباطات). اگر یک نفر هر دو نقش را انجام دهد. مهندسان رشد نمی‌کنند، کدها ارسال نمی‌شوند، تیم در مورد مهم‌ترین موضوعات سردرگم می‌شود.

۴ عدد جادویی است که در آن TLM باید بین Technical Lead یا Engineering Manager یکی را انتخاب کند، اما نه هر دو.

وقتی تعداد اعضای تیم به عدد ۵ رسید، TLM بودن کاملاً منتفی است. اگر هیچ‌کس نقش ارتباطات تیم را بر عهده نگیرد چه اتفاقی می‌افتد؟ بیشتر اوقات، تیم دچار هرج‌ومرج می‌شود و از پیشروی در اولویت‌هایش بازمی‌ماند. تیم و ذینفعانش بیش از حد سردرگم می‌شوند. فردی باید فرآیندی ایجاد کند تا مهندسان بتوانند بهترین کار خود را انجام دهند: ساخت محصولات عالی. این نقش یک شغل تمام‌وقت است.

پیچیدگی ارتباطات همچنین دلیل این است که تیم‌های بزرگ به طور طبیعی به زیرتیم‌های ۱ تا ۳ نفره تقسیم می‌شوند تا روی یک پروژه متمرکز شوند. در اندازه تیم ۱ تا ۳ نفر، سربار ارتباطات قابل مدیریت است و کار فنی انجام می‌شود. اما با اضافه کردن نفر چهارم، وارد دنیای منحنی اندازه تیم می‌شویم.

در مورد TLM بودن

به نظر می‌رسد که نقش TLM نقش ایده‌آلی است که به یک رهبر اجازه می‌دهد هم مدیریت افراد و هم کار فنی انجام دهد. علاوه بر این، برای شرکت‌های کوچک، تبدیل یک Technical Lead به TLM یک راهکار سریع برای ساخت تیم است.

اما TLM یک موقعیت بلندمدت نیست، زیرا در نهایت، نقش‌های Technical Lead و Engineering Manager متفاوت هستند. انجام دو نقش به طور همزمان (بدون کیفیت مناسب) بدون اینکه بتواند دامنه (فنی یا تیمی) کسی که به یکی از این نقش‌ها اختصاص داده شده را پیش ببرد. در نهایت، TLM باید یکی از این دو مسیر را انتخاب کند یا درجا بزند، زیرا نمی‌تواند دامنه کار خود را گسترش دهد.

چرا یک Engineering Manager نباید Code Review انجام دهد؟

در نهایت، با ترکیب این موارد، دو واقعیت را ثابت می‌کنیم:

۱. نقش Technical Lead و Engineering Manager دو نقش هستند که با همکاری هم تیم را به موفقیت می‌رسانند. بنابراین، باید نقش‌ها و مسئولیت‌های روشنی داشته باشند و در یک مشارکت متقابل همکاری کنند.

۲. تیم‌ها به یک نقطه عطف تعداد بیشتر از ۴ نفر می‌رسند که در آن کسی باید زمان خود را به ارتباطات اختصاص دهد تا تیم کار کند. در غیر این صورت، تیم به یک سیاه‌چاله از هرج‌ومرج فرو می‌رود.

در تیم بزرگتر از ۴ نفر، یک Engineering Manager باید روی نقش اصلی خود متمرکز شود:

• مدیریت ارتباطات درون و بیرون تیم،
• تمرکز بر رشد اعضا
• درک اولویت‌های تیم

در تیم بزرگتر از ۴ نفر، یک Technical Lead باید برروی موارد ذیل متمرکز شود:

• معماری
• انتخاب‌های فنی
• کار فنی
• تقسیم کار

نتیجه گیری

• نقش اصلی یک Engineering Manager، مدیریت ارتباطات درون و بیرون تیم است: از جمله رشد شغلی، عملکرد، برنامه‌ریزی و تنظیم فرآیندهای تیم. این کار ارتباطی، سرمایه‌گذاری قابل توجهی در زمان است.
• پس از رسیدن به اندازه کافی از تیم، مدیر باید بین مهارت فنی و سرمایه‌گذاری در هماهنگی و ارتباطات یکی را انتخاب کند، زیرا پیچیدگی ارتباطات بالا است.
• در اندازه کافی از تیم، سربار ارتباطات ممکن است آنقدر بالا باشد که مدیر مجبور به انتخاب شود یا تنها توسط این کار غرق شود.
• یک Engineering Manager که Code را بررسی می‌کند، نه تنها نقش اصلی خود را نادیده می‌گیرد، بلکه به Micromanaging Technical Lead می‌پردازد. این فعالیت باعث از بین رفتن اعتماد می شود.
• این به این معنا نیست که Engineering Manager نمی‌تواند در بحث‌های فنی (به ویژه بررسی‌های معماری) مشارکت کند، اما Technical Lead است که فناوری را هدایت می‌کند.
• و بنابراین، دلیل اینکه چرا یک Engineering Manager با تیمی به اندازه کافی بزرگ نباید کد را بررسی کند، این است که اعتماد، تفویض اختیار و ارتباطات هسته اصلی نقش Engineering Manager هستند، و این همان چیزی است که اهمیت دارد.