تک‌لید کیست؟ مرز با مدیر پروژه و مدیر افراد

«Tech Lead» در یک شرکت یعنی ارشدترین برنامه‌نویس، در شرکتی دیگر یعنی کسی که عملاً مدیر تیم است، و در سومی نقشی موقت برای یک پروژه. این ابهام واقعی است و مقالات زیادی با تعریف قطعی آن را پنهان می‌کنند. این مقاله چند تعریف رسمی منتشرشده از سه سازمان را کنار هم می‌گذارد (GitLab، GOV.UK و Redgate؛ خوانده‌شده ۱۹ اکتبر ۲۰۲۶) و نتیجه می‌گیرد که بهتر است نقش را با «مسئولیت‌ها و مرزها» تعریف کنیم نه با عنوان. تفسیر و جدول مقایسه از نویسنده است و تعریف جهانی نیست. برای زمینهٔ نقش‌های پروژه نقش‌های پروژه نرم‌افزاری را ببینید.

سه تعریف منتشرشده

• GitLab: Tech Lead هم archetype و هم نقش است. به هر مهندس صرف‌نظر از ارشدیت قابل واگذاری است، موقت و وابسته به یک موضوع یا پروژه است، مدیر نیست و سطح ارشدیت اضافی هم نیست. مسئولیت‌ها شامل چشم‌انداز و معماری فنی، راهنمایی و منتورینگ، برنامه‌ریزی و اولویت‌بندی، پیگیری پیشرفت، مدیریت ریسک فنی و هماهنگی و رفع مانع است.
• GOV.UK: نقشی در تیم که هر توسعه‌دهنده می‌تواند بگیرد و با product manager و delivery manager همکاری می‌کند. وظایف: شناسایی و برنامه‌ریزی کار، نوشتن کارت‌ها، onboarding اعضای جدید، توجه به سلامت تیم، رفع موانع فنی، ترویج رویه‌های خوب (تست، بازبینی) و شرکت در بازبینی حوادث.
• Redgate: Tech Lead مسئول رهبری تیم است و هم برای خروجی تیم و هم برای بهزیستی افراد پاسخگوست. چارچوب آن حوزه‌هایی مثل رهبری تیم، مدیریت افراد، مشارکت فنی، ارتباط با ذی‌نفعان، هوش هیجانی و تحویل را شامل می‌شود.

تفاوت آشکار است: در GitLab «مدیر نیست»، اما در Redgate مدیریت افراد بخشی از نقش است. پس هر جا شنیدید «تک‌لید»، اولین سؤال باید این باشد که در آن سازمان تعریفش چیست.

وجه مشترک

در هر سه، چند چیز تکرار می‌شود: ارتباط با حوزهٔ فنی تیم (معماری، بازبینی طراحی)، برنامه‌ریزی و شکستن کار، مدیریت ریسک و موانع، و ارتباط با ذی‌نفعان. همچنین در هر سه، این نقش تماماً «نوشتن کد بیشتر از دیگران» نیست. مستند GOV.UK صریحاً می‌گوید لازم نیست tech lead همه چیز دربارهٔ پلتفرم را بداند و نقش به همان اندازه رهبری و مهارت‌های نرم است که توانایی فنی. چارچوب Redgate هم از «ماندن در تماس فنی بدون تبدیل‌شدن به گلوگاه تحویل» حرف می‌زند.

تفاوت با مدیر پروژه و مدیر افراد

این جدول یک الگوی رایج است ولی GitLab می‌گوید تقسیم میان tech lead و EM را خود آن دو تعیین می‌کنند، و Redgate بخش‌هایی از مدیریت افراد را در نقش tech lead می‌گذارد. بنابراین جدول را قطعی نگیرید و در سازمان خودتان با نوشتن قرارداد نقش‌ها روشنش کنید.

وابستگی به اندازهٔ تیم و مرحلهٔ شرکت

در تیم بسیار کوچک ممکن است همهٔ این مسئولیت‌ها در یک نفر جمع شود، و در تیم بزرگ‌تر بین چند نفر تقسیم شود. GOV.UK هم می‌گوید لازم نیست tech lead بر همه چیز نظارت کند و هر مسئولیت گاهی توسط دیگران انجام می‌شود. پیشنهاد نویسنده: به‌جای «یک تک‌لید همه‌کاره»، مسئولیت‌ها را فهرست کنید و مشخص کنید هر کدام در تیم شما صاحب دارد یا نه. اگر مسئولیتی بی‌صاحب است، آن مشکل واقعی است، نه عنوان.

قرارداد نقش (پیشنهاد نویسنده)

1. مسئولیت‌های tech lead را در چند جمله بنویسید.
2. مشخص کنید چه تصمیم‌هایی با اوست و چه تصمیم‌هایی نیاز به مشورت یا تأیید دارد.
3. مرز با مدیر افراد را بنویسید: ارزیابی عملکرد؟ استخدام؟ مرخصی؟
4. مدت نقش را مشخص کنید (دائمی یا مربوط به یک پروژه، مثل GitLab).
5. مشخص کنید چقدر از زمان او برای کدنویسی است.

مثال ساختگی

تیم فرضی پنج‌نفره یک «تک‌لید» دارد که همزمان به همه سؤال‌ها پاسخ می‌دهد، کد زیادی می‌نویسد و گلوگاه بازبینی است. تیم با نوشتن قرارداد نقش، تصمیم می‌گیرد بازبینی کد بین سه نفر تقسیم شود، تک‌لید روی معماری و ریسک متمرکز شود و ارزیابی عملکرد با مدیر افراد بماند. مثال ساختگی است.

اشتباهات رایج

• یکی‌گرفتن عنوان با سطح ارشدیت یا حقوق.
• یکی‌گرفتن tech lead با مدیر افراد بدون تصریح.
• تبدیل tech lead به گلوگاه بازبینی و تصمیم.
• انتظار اینکه همه چیز را بداند.
• بی‌صاحب‌ماندن مسئولیت‌ها چون «تک‌لید دارد».
• نبود قرارداد روشن نقش.

نگاه پژوهشی: رفتارهای مدیران مؤثر

برای بخش «مدیریت افراد» که در تعریف‌ها متفاوت است، پژوهش منتشرشدهٔ Google (Project Oxygen، مقالهٔ re:Work) مرجع مفیدی است. این پژوهش ده رفتار مدیران مؤثر را فهرست می‌کند: مربی‌گری، توانمندسازی بدون micromanagement، ایجاد محیط ارزشمند برای همه، تمرکز بر بهره‌وری و نتیجه، ارتباط مؤثر، حمایت از رشد شغلی و بحث عملکرد، چشم‌انداز و راهبرد روشن، مهارت‌های فنی کلیدی، همکاری بین‌سازمانی و تصمیم‌گیری قوی. نکتهٔ مرتبط با بحث ما این است که «مهارت‌های فنی کلیدی» فقط یکی از ده مورد است و بقیه به تعامل و رهبری مربوط‌اند. این پژوهش دربارهٔ مدیران Google است و به‌طور مستقیم دربارهٔ tech lead در شرکت‌های دیگر یا ایرانی ادعایی نمی‌کند؛ ما فقط از آن به‌عنوان نمونه‌ای از اینکه رهبری فنی جدا از مهارت فنی صرف است استفاده می‌کنیم.

همچنین چارچوب Manager Responsibilities که از این پژوهش نشأت گرفته سه انتظار اصلی را فهرست می‌کند: Deliver Results (نتیجهٔ ملموس، اولویت‌ها و اهداف)، Develop People (انتظارات روشن، بازخورد و گفتگوی شغلی) و Build Community (همکاری و ارتباط باز). اگر tech lead در سازمان شما بخشی از این وظایف را برعهده دارد، این سه محور می‌تواند مبنای گفتگو با مدیر افراد باشد که چه بخشی به چه کسی تعلق دارد. باز هم تأکید می‌کنیم این چارچوب به Google تعلق دارد و برای تیم شما باید تطبیق داده شود.

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

چک‌لیست

1. مسئولیت‌های نقش tech lead در سازمان نوشته شده است.
2. مرز با مدیر افراد و مدیر پروژه روشن است.
3. تصمیم‌های فنی و صاحبشان مشخص‌اند.
4. سهم کدنویسی و مدت نقش تعیین شده است.
5. مسئولیت‌های بی‌صاحب شناسایی شده‌اند.
6. tech lead گلوگاه تصمیم و بازبینی نیست.

منابع و مراجع

• Tech Lead at GitLab — The GitLab Handbook، 2026-10-19.
• Responsibilities of a Tech Lead — GOV.UK Developer Documentation، 2026-10-19.
• Tech Lead — Redgate Progression Framework — Redgate، 2026-10-19.
• Following the data: The research behind great managers — Google re:Work، 2026-10-19.