CTO کیست و چه کاری می‌کند؟ چه زمانی لازم است؟

«CTO» یکی از مبهم‌ترین عنوان‌های دنیای نرم‌افزار است. در یک استارتاپ دونفره یعنی بنیان‌گذار فنی که کد می‌نویسد؛ در شرکت بزرگ یعنی مدیر ارشدی که چند لایه با کد فاصله دارد. این مقاله می‌کوشد بدون وعدهٔ قطعی بگوید CTO چه می‌کند، چه زمانی لازم است، و چطور با نقش‌های هم‌جوار (هم‌بنیان‌گذار فنی، tech lead، مدیر مهندسی/VP Engineering) تفاوت دارد. منابع ما دو نوشتهٔ تجربی از فعالان حوزه (David Mytton و Karl Hughes؛ هر دو دیدگاه شخصی‌اند، نه استاندارد) و سندهای عمومی tech lead در سازمان‌هایی مثل GitLab و Redgate است (خوانده‌شده ۱۹ اکتبر ۲۰۲۶). هیچ آمار، درصد یا هزینه‌ای نقل نمی‌شود. جمع‌بندی و تصمیم‌ها از نویسنده است. برای نقش‌های پروژه نقش‌های پروژه نرم‌افزاری را ببینید.

چرا تعریف واحد وجود ندارد

Karl Hughes می‌نویسد کار CTO در استارتاپ «خیلی متفاوت» از شرکت‌های بزرگ است و او کمی از همه‌چیز را انجام می‌دهد. می‌گوید CTOهای شرکت‌های بزرگ معمولاً دو یا سه لایهٔ مدیریتی با مهندسی روزمره فاصله دارند و به همین دلیل ممکن است برای ساخت MVP مناسب نباشند. این گزارش تجربهٔ یک نفر است. نتیجهٔ محتاطانه: وقتی می‌گویید «CTO می‌خواهم»، اول بنویسید برای چه مرحله‌ای از شرکت و برای چه مسئولیت‌هایی.

CTO در مرحلهٔ اولیه

David Mytton «تنها کار» CTO مرحلهٔ اولیه را رساندن کسب‌وکار به نقاط عطف با استفاده از فناوری می‌داند و می‌نویسد درک کسب‌وکار چیزی است که CTO را از مهندس نرم‌افزار جدا می‌کند. به نظر او CTO باید بپذیرد معماری کامل و «به‌اندازهٔ کافی خوب» در تعارض‌اند، بخش بزرگی از کد اولیه بازنویسی خواهد شد، و باید روی یکی دو چیز متمایزکنندهٔ شرکت متمرکز بماند و بقیه را به سرویس‌های آماده بسپارد. این دیدگاه یک نویسنده است و برای هر شرکتی صدق نمی‌کند، اما نشان می‌دهد در مرحلهٔ اولیه «تصمیم فنی در خدمت نتیجهٔ کسب‌وکار» اصل است نه کمال فنی.

مسئولیت‌های رایج

فهرست Karl Hughes شامل ساخت MVP، استخدام و آموزش مهندسان، مسئولیت امنیت شرکت، مدیریت محصول و جریان کار، معماری، triage باگ، QA، DevOps، داده و ML، ارتباط با فروشنده و مشتری، تصمیم دربارهٔ بازنویسی نسخهٔ دوم، مدیریت رشد تیم و نگه‌داشت نیرو است. همهٔ این‌ها در یک شرکت کوچک ممکن است در یک نفر جمع شود. همین فهرست نشان می‌دهد چرا «CTO» بیش از یک مهارت می‌خواهد. بخشی از این مسئولیت‌ها را می‌توان با رشد شرکت به افراد دیگر سپرد.

تفاوت با هم‌بنیان‌گذار فنی، tech lead و مدیر مهندسی

Mytton می‌نویسد با رشد شرکت نقش VP Engineering برای تمرکز بر افراد جدا می‌شود. این جداسازی یک الگوی رایج است نه قانون؛ بسیاری از شرکت‌های کوچک ساختار دیگری دارند. نکتهٔ سهامداری و قرارداد (تقسیم سهام، مسئولیت حقوقی، حقوق) موضوعی حقوقی و مالی است و در این مقاله بررسی نشده؛ برای آن مشورت حقوقی لازم است.

چه زمانی CTO لازم است؟

به‌جای عدد و مرحلهٔ ثابت، چند پرسش بپرسید (پیشنهاد نویسنده):

1. آیا تصمیم‌های فنی گران‌برگشت‌پذیر (انتخاب پلتفرم، معماری، امنیت) بدون صاحب مانده‌اند؟
2. آیا کسی هست که بتواند به سؤال سرمایه‌گذار یا مشتری دربارهٔ امنیت و مقیاس‌پذیری پاسخ بدهد؟
3. آیا استخدام مهندسان بدون ارزیابی فنی قابل‌اعتماد انجام می‌شود؟
4. آیا تیم فنی بزرگ‌تر از آن است که یک tech lead بتواند هماهنگش کند؟
5. آیا بدهی فنی یا ریسک امنیتی تصمیم‌گیری کسب‌وکار را به خطر انداخته است؟

اگر پاسخ چند مورد «بله» است، نیاز به رهبری فنی با اختیار تصمیم وجود دارد. این لزوماً یعنی استخدام تمام‌وقت CTO نیست؛ ممکن است مشاور فنی پاره‌وقت یا ارتقای یک مهندس ارشد کافی باشد. هزینه و شرایط استخدام را در این مقاله بررسی نکرده‌ایم.

گزینه‌های جایگزین

• مهندس ارشد یا tech lead: برای تصمیم‌های فنی یک تیم، وقتی راهبرد کسب‌وکار روشن است.
• مشاور فنی پاره‌وقت: برای بازبینی معماری و امنیت و کمک به استخدام.
• شریک فنی (هم‌بنیان‌گذار): وقتی تعهد بلندمدت و تقسیم ریسک دو طرفه می‌خواهید؛ جنبهٔ حقوقی دارد.
• برون‌سپاری با مسئول فنی داخلی: وقتی توسعه را شرکتی دیگر انجام می‌دهد، ولی باید کسی در سمت شما کیفیت را سنجش کند.

مثال ساختگی

استارتاپ فرضی نسخهٔ اول محصول را با یک شرکت برون‌سپار ساخته و حالا مشتریان سازمانی سؤال‌های امنیتی می‌پرسند. هیچ‌کس در تیم نمی‌تواند پاسخ دقیق بدهد. تصمیم: یک مشاور فنی پاره‌وقت برای بازبینی امنیت و معماری و تعریف یک مسئول فنی داخلی به‌عنوان نقطهٔ تماس. چند ماه بعد، با رشد تیم، نقش تمام‌وقت بازنگری می‌شود. مثال ساختگی است و توصیهٔ استخدامی نیست.

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

• انتظار اینکه CTO هم بنیان‌گذار، هم کدنویس، هم مدیر استخدام و هم مدیر محصول باشد، بدون روشن‌کردن اولویت.
• استخدام CTO بر اساس عنوان، بدون تعریف مسئولیت‌ها.
• یکی‌گرفتن CTO با tech lead یا مدیر مهندسی.
• نادیده‌گرفتن جنبهٔ حقوقی و سهامداری.
• تصمیم فنی بدون ارتباط با هدف کسب‌وکار.
• پیش‌فرض گرفتن اینکه تجربهٔ شرکت بزرگ برای استارتاپ مناسب است.

نقش در گذر مراحل شرکت

دو منبع ما در یک نکته هم‌نظرند: نقش با رشد شرکت عوض می‌شود. Hughes می‌نویسد در مرحلهٔ بازنویسی نسخهٔ دوم، نقش CTO احتمالاً مدیریتی‌تر و کم‌دست‌به‌کدتر از روزهای MVP است و مدیریت رشد تیم (جذب افراد تخصصی‌تر با ساختار شغلی روشن‌تر) سخت‌تر می‌شود. Mytton می‌نویسد فقط با بزرگ‌شدن شرکت از نظر نیرو و درآمد، CTO به بخش «Technology» عنوانش فکر می‌کند: کمک به تصمیم‌های معماری و ساخت ساختار مدیریتی مهندسی، و در نهایت جداشدن نقش VP Engineering. هیچ‌کدام عدد یا مرز دقیقی نمی‌دهند و ما هم نمی‌دهیم؛ مرزها به شرکت و بنیان‌گذاران بستگی دارد.

از این دو نتیجه می‌گیریم که اگر برای نقش CTO استخدام می‌کنید، باید بدانید کدام «CTO» را می‌خواهید: کسی که امروز محصول را می‌سازد، یا کسی که سازمان فنی را اداره می‌کند. این دو مهارت متفاوت‌اند و کمتر فردی هر دو را در همان سطح دارد. بهتر است صریح بنویسید در شش تا دوازده ماه آینده چه چیزی باید رخ دهد (مثلاً نسخهٔ اول عرضه شود، یا تیم از سه به ده نفر برسد) و نقش را بر اساس آن تعریف کنید. این پیشنهاد نویسنده است و جایگزین مشاورهٔ حرفه‌ای نیست.

همچنین انتظارات را با حوزهٔ امنیت و ریسک هماهنگ کنید: Hughes اشاره می‌کند CTO استارتاپ اغلب اولین مسئول امنیت شرکت می‌شود و باید سیاست‌ها را مستند کند. برای شروع معقول است مسئول فنی مشخص کند چه کسی به کد و ابزارها دسترسی دارد، و سیاست‌های امنیتی ساده‌ای بنویسد؛ مقالهٔ بعدی دربارهٔ نقشهٔ راه CTO به چارچوب‌های رسمی مثل NIST SSDF هم می‌پردازد.

چک‌لیست

1. مرحلهٔ شرکت و مسئولیت‌های مورد انتظار نوشته شده است.
2. تفاوت CTO، مدیر مهندسی و tech lead در سازمان روشن است.
3. تصمیم‌های فنی بی‌صاحب شناسایی شده‌اند.
4. گزینه‌های جایگزین (مشاور، ارتقای داخلی) بررسی شده است.
5. جنبهٔ سهامداری و قرارداد با مشاورهٔ حقوقی بررسی می‌شود.
6. مسئولیت‌ها با رشد شرکت بازنگری می‌شود.

منابع و مراجع

• The one job of the early stage startup CTO — David Mytton (practitioner blog)، 2026-10-19.
• The Many Roles of a Startup CTO — Karl Hughes (practitioner blog, 2018)، 2026-10-19.
• Tech Lead at GitLab — The GitLab Handbook، 2026-10-19.