بعد از Senior شدن چی میشه؟ وقتی مسیر رشد دیگر خطی نیست

چند سال اول مسیر مهندسی نرم‌افزار، حداقل روی کاغذ، نسبتاً مشخصه.

معمولاً از کارآموزی شروع می‌کنیم. کم‌کم یاد می‌گیریم کارهای کوچیک رو مستقل انجام بدیم و Junior می‌شیم. تجربه‌مون بیشتر می‌شه، دانش فنی‌مون عمیق‌تر می‌شه و می‌تونیم مسئولیت مسئله‌های بزرگ‌تری رو بگیریم؛ Mid-level می‌شیم.

بعد از چند سال، وقتی تصمیم‌هامون پخته‌تر شده، می‌تونیم مسئله‌های پیچیده رو مستقل جلو ببریم و تبدیل به یکی از آدم‌های قابل اتکای تیم بشیم، به Senior می‌رسیم.

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

ولی جهت کلی تقریباً مشخصه:

استقلال بیشتر، مسئله‌های سخت‌تر، مسئولیت بزرگ‌تر و تصمیم‌های تأثیرگذارتر.

تا اینکه بالاخره Senior می‌شیم.

و بعد یک سؤال عجیب ظاهر می‌شه:

خب... حالا چی؟

Senior شدن آخر مسیر نیست، ولی شاید آخر مسیر خطی باشه

خیلی از ما بخش بزرگی از سال‌های اول Careerمون رو با یک مقصد نسبتاً مشخص جلو می‌ریم:

می‌خوام Senior بشم.

ولی وقتی بهش می‌رسیم، مسیر بعدی دیگه به اون وضوح نیست.

یکی از پیشنهادهایی که معمولاً به آدم‌هایی که تازه Senior شدن می‌کنم اینه که برای رفتن به Level بعدی عجله نکنن.

اول Senior بودنت رو پُر کن.

گرفتن Title سینیور و تبدیل شدن به یک Senior پخته الزاماً در یک روز اتفاق نمی‌افتن.

کسی که داخل یک شرکت Senior شده قطعاً Evidence کافی از توانایی فنی، Ownership و تصمیم‌گیری داشته؛ ولی بخشی از این موفقیت معمولاً از شناخت خوب اون شرکت، محصول، آدم‌ها و Domain هم میاد.

برای همین به نظرم ارزش داره مدتی در این سطح بمونیم.

با Incidentهای واقعی روبه‌رو بشیم. تصمیم اشتباه بگیریم. نتیجه‌ی تصمیم‌های معماری‌مون رو شش ماه بعد ببینیم. پروژه‌ای که فکر می‌کردیم ساده‌ست پیچیده بشه. با آدم‌های مختلف کار کنیم. Trade-offهایی رو تجربه کنیم که جوابشون توی هیچ کتابی نوشته نشده.

این تجربه‌ها کم‌کم ما رو از کسی که Title سینیور داره به یک Senior پخته تبدیل می‌کنن.

بحث «Senior در یک شرکت» در برابر «Senior به شکل عمومی‌تر» خودش موضوع مفصلیه که دوست دارم جداگانه درباره‌ش بنویسم.

اما حتی اگر Senior بودنت رو هم پُر کنی، بالاخره دوباره همون سؤال برمی‌گرده:

بعدش چی؟

از اینجا به بعد، باید مسیرت رو بیشتر خودت بسازی

هفته‌ی گذشته کتاب Staff Engineer: Leadership Beyond the Management Track از Will Larson رو می‌خوندم و یکی از ایده‌هایی که خیلی با تجربه‌ی خودم هم‌راستا بود همین بود:

بعد از Senior، Career دیگه الزاماً یک مسیر خطی و از قبل تعریف‌شده نیست.

به شکل خیلی ساده‌شده، دو مسیر رایج جلوی ما قرار می‌گیره.

یک مسیر People Management که می‌تونه به نقش‌هایی مثل Engineering Manager و بعدتر نقش‌های مدیریتی بزرگ‌تر برسه.

و یک مسیر Technical Leadership که معمولاً با عنوان‌هایی مثل Staff Engineer، Principal Engineer و نقش‌های مشابه می‌شناسیمش.

هیچ‌کدوم نسخه‌ی بهتر اون یکی نیست.

مسئله اینه که جنس کارشون متفاوته و باید بفهمیم کدوم مسیر با چیزی که از Careerمون می‌خوایم سازگارتره.

من فعلاً می‌خوام فقط درباره‌ی مسیر دوم حرف بزنم؛ چون هم به فضای کاری خودم نزدیک‌تره و هم کتاب Larson کمک کرد بخش‌هایی از چیزی که تجربه می‌کردم برام شفاف‌تر بشه.

شاید یک روز بعد از تجربه و مطالعه‌ی بیشتر درباره‌ی مسیر Management هم بنویسم.

Staff Engineer یک Senior قوی‌تر نیست

شاید اولین تصور این باشه که مسیر این شکلیه:

Junior → Mid → Senior → Staff

و بنابراین Staff همون Seniorـیه که System Design بیشتری بلده، سریع‌تر کد می‌زنه و مسئله‌های سخت‌تری حل می‌کنه.

ولی به نظرم این دقیقاً جاییه که باید مدل ذهنی‌مون رو عوض کنیم.

تا Senior شدن، بخش بزرگی از رشد ما حول افزایش توانایی خودمون اتفاق می‌افته.

اول برای انجام یک Task کمک می‌خوایم.

بعد می‌تونیم Task رو مستقل انجام بدیم.

بعد Ownership یک Feature رو می‌گیریم.

بعد پروژه‌های پیچیده‌تر و تصمیم‌های مهم‌تر رو مدیریت می‌کنیم.

یاد می‌گیریم وقتی بقیه گیر کردن، وارد بشیم و مسئله رو حل کنیم.

در واقع سیستم هم معمولاً همین رفتار رو Reward می‌کنه.

Bug سختی بود؟ تو حلش کردی.

Incident داشتیم؟ تو جمعش کردی.

پروژه‌ی مهمی بود؟ تو Owner شدی.

تصمیم معماری سختی داشتیم؟ همه سراغ تو اومدن.

و همین رفتارها بخشی از چیزیه که ما رو به Senior تبدیل می‌کنه.

اما جالبه که همین رفتارها می‌تونن بعداً تبدیل به محدودیت رشد ما بشن.

از Hero بودن به ساختن Heroهای بیشتر

فرض کنید در هر مسئله‌ی سختی خودتون وارد می‌شید.

بهترین Design رو شما انجام می‌دید.

سخت‌ترین بخش Implementation رو شما برمی‌دارید.

وقتی Production خراب می‌شه شما نجاتش می‌دید.

هرجا تیم گیر می‌کنه، منتظر شماست.

احتمالاً Engineer خیلی خوبی هستید.

ولی یک مشکل وجود داره:

Impact شما به ظرفیت خودتون محدود شده.

شما بالاخره در روز تعداد محدودی ساعت دارید.

اینجاست که به نظرم یکی از مهم‌ترین تغییرهای ذهنی بعد از Seniority اتفاق می‌افته.

سؤال کم‌کم از این:

How can I solve this?

تبدیل می‌شه به:

How can I make sure this gets solved well without needing me to be the hero?

این به معنی بی‌تفاوت شدن یا فاصله گرفتن از مسائل فنی نیست.

اتفاقاً Staff Engineer احتمالاً یکی از باتجربه‌ترین افراد فنی مجموعه‌ست و وقتی Production واقعاً در وضعیت بحرانیه، ممکنه دقیقاً همون کسی باشه که باید وارد مسئله بشه.

اما هنر اصلی اینه که بفهمه:

کجا حضور مستقیم من بیشترین ارزش رو ایجاد می‌کنه و کجا بهتره اجازه بدم یکی دیگه مسئله رو حل کنه؟

Staff Engineer باید بدونه توجهش رو کجا خرج کنه

فرض کنید Production مشکل داره و سفارش‌های کاربران با خطا مواجه می‌شن.

Risk بالاست، زمان مهمه و تجربه‌ی شما می‌تونه مستقیماً روی Business Impact اثر بذاره.

احتمالاً وقتشه خودتون وارد بشید.

حالا یک پروژه‌ی جانبی داریم که Deadline سختی هم نداره. یک Senior داخل تیم می‌تونه انجامش بده، ولی احتمالاً بیشتر از شما زمان می‌بره و در طول مسیر هم به Guidance نیاز خواهد داشت.

اینجا شاید بهترین تصمیم این باشه که خودتون انجامش ندید.

حتی اگر شما سه روزه انجامش می‌دید و اون Engineer یک هفته زمان می‌خواد.

چون Outcome فقط تمام شدن پروژه نیست.

در حالت دوم:

پروژه تمام شده + یک Engineer باتجربه‌تر داریم.

به نظرم یکی از مهارت‌های مهم Staff Engineer همین Allocation of Attentionـه.

اینکه فقط بلد نباشه مسئله‌های سخت رو حل کنه؛ بلکه بفهمه کدوم مسئله ارزش این رو داره که خودش حلش کنه.

Delegation یعنی رها کردن کار نیست

البته «بذار بقیه انجامش بدن» خیلی راحت می‌تونه تبدیل به Management از راه دور و در بدترین حالت Abandonment بشه.

اگر پروژه رو به Engineer دیگه‌ای سپردیم و سه ماه بعد برگشتیم ببینیم چی شده، Delegation نکردیم؛ صرفاً مسئله رو رها کردیم.

به نظرم مقدار آزادی و Guardrail باید متناسب با دو چیز باشه:

ریسک مسئله و تجربه‌ی فرد.

هرچه مسئله Criticalتر باشه، طبیعتاً فضای Failure کوچیک‌تره.

می‌تونیم Acceptance Criteria واضح‌تری تعریف کنیم، قبل از Implementation روی Design توافق کنیم، برای تصمیم‌های مهم ADR داشته باشیم، Milestone تعریف کنیم و در نقاط مشخص Review انجام بدیم.

در عین حال قرار نیست هر پنج دقیقه بالای سر Engineer بایستیم.

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

Staff Engineer خوب فقط کار رو Delegate نمی‌کنه.

ظرفیت تصمیم‌گیری سازمان رو بزرگ‌تر می‌کنه.

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

این قسمت برای من کمی Paradoxicalـه.

در مسیر Junior تا Senior دائماً تلاش می‌کنیم آدم قابل اتکاتری بشیم.

Junior:

«برای انجام این کار به کمک نیاز دارم.»

Senior:

«این مسئله رو می‌تونید کامل به من بسپرید.»

ولی بعد از یک نقطه، شاید شکل رشد دوباره تغییر کنه.

Staff:

«کاری می‌کنم برای حل این مسئله لازم نباشه همیشه سراغ من بیاید.»

در تجربه‌ی خودم هم کم‌کم بیشتر با این موضوع مواجه شدم.

مثلاً برای بعضی پروژه‌ها Owner مشخص برای Freeze و Release تعریف کردیم.

بخشی از مسئولیت‌هایی که قبلاً مستقیم خودم انجام می‌دادم رو با Engineerهای قوی‌تر تیم Share کردم.

یا تصمیم گرفتم در بعضی Dailyها شرکت نکنم، چون اگر یک تیم برای پیش رفتن هر روز نیاز به حضور Lead داشته باشه، احتمالاً مسئله‌ی عمیق‌تری داریم.

هدف این نیست که کمتر کار کنیم.

هدف اینه که کمتر Bottleneck باشیم.

وقتی بقیه دیده می‌شن، شاید شما دارید کارتون رو درست انجام می‌دید

این تغییر یک قسمت روانی سخت هم داره.

تا Senior شدن، موفقیت خیلی Visibleـه.

شما Feature رو ساختید.

شما Bug رو حل کردید.

شما Design رو انجام دادید.

اسم شما روی PRـه.

ولی در Staff-level work ممکنه بهترین کاری که انجام دادید، کاری باشه که در نهایت اسم یک نفر دیگه بیشتر بابتش دیده می‌شه.

فرض کنید یک Senior داخل تیم پروژه‌ای رو Owner شده.

شما شاید Direction اولیه رو باهاش مشخص کرده باشید، Designش رو Challenge کرده باشید، در چند نقطه Unblockش کرده باشید و کمک کرده باشید Riskها رو ببینه.

ولی در نهایت اون Engineer پروژه رو تحویل داده.

به نظرم بخش اصلی Credit باید برای اون باشه.

حتی بیشتر از Mentorship، Staff Engineer می‌تونه Sponsor آدم‌های قوی اطرافش باشه.

فرصت واقعی بهشون بده.

اجازه بده Ownership داشته باشن.

و وقتی موفق شدن، کمک کنه دیده بشن.

چون رشد آدم‌های اطراف شما خودش یکی از نشانه‌های Impact شماست.

از Solution به Outcome

شاید اگر بخوام کل این تغییر رو در یک مفهوم خلاصه کنم، برای من اینه:

نگاه از Solution به Outcome حرکت می‌کنه.

یک Engineer قوی می‌پرسه:

«بهترین راه‌حل این مسئله چیه؟»

ولی در Scope بزرگ‌تر باید قبلش سؤال دیگه‌ای بپرسیم:

«اصلاً حل این مسئله چه دستاوردی برای تیم یا سازمان داره؟»

ممکنه جواب آخرش یک Architecture جدید باشه.

ممکنه یک Library بسازیم.

ممکنه Process رو تغییر بدیم.

ممکنه Ownership یک قسمت از سیستم رو جابه‌جا کنیم.

و حتی ممکنه بهترین تصمیم این باشه که اصلاً چیزی نسازیم.

این تغییر باعث می‌شه افق زمانی هم بزرگ‌تر بشه.

فقط این Sprint رو نمی‌بینیم.

می‌پرسیم این تصمیم شش ماه دیگه چه Maintenance Costی داره؟

آیا داریم Dependency جدیدی ایجاد می‌کنیم؟

آیا Autonomy یک تیم رو بیشتر می‌کنیم یا کمتر؟

آیا داریم مشکل رو حل می‌کنیم یا فقط علامتش رو؟

و مهم‌تر:

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

Staff Engineer دقیقاً چه شکلیه؟

اینجا یکی از قسمت‌های کتاب Will Larson برای من خیلی جالب بود.

وقتی می‌گیم Staff Engineer، ممکنه تصویری که من توی ذهنم دارم با چیزی که شما تصور می‌کنید کاملاً متفاوت باشه.

چون برخلاف Levelهای قبلی، Staff Engineer یک شکل واحد نداره.

Larson برای توضیح این تفاوت چهار Archetype معرفی می‌کنه:

Tech Lead، Architect، Solver و Right Hand.

این Archetypeها Job Description نیستن و مرز کاملاً مشخصی هم بینشون وجود نداره. بیشتر یک Lens هستن برای اینکه بفهمیم Staff-level Impact در یک سازمان چه شکل‌های متفاوتی می‌تونه داشته باشه.

بیاید هرکدوم رو کمی واقعی‌تر ببینیم.

۱. Tech Lead — کسی که یک تیم یا مجموعه‌ای از تیم‌ها رو در یک جهت حرکت می‌ده

احتمالاً آشناترین Archetype همینه.

Tech Lead معمولاً نزدیک به Product و تیم‌های Delivery کار می‌کنه، ولی مسئولیتش فقط این نیست که سخت‌ترین Taskهای Backlog رو برداره.

فرض کنید سه تیم روی قسمت‌های مختلف یک محصول بزرگ کار می‌کنن.

هر تیم Requirement خودش رو داره، Deadline خودش رو داره و طبیعتاً دوست داره مسئله‌ی خودش رو سریع‌تر حل کنه.

اما تصمیم‌های این سه تیم روی یکدیگر اثر می‌ذارن.

یک تیم می‌خواد State Management رو تغییر بده.

یک تیم می‌خواد بخشی از Architecture رو جدا کنه.

تیم دیگه برای حل Requirement خودش API Contract جدیدی می‌خواد.

هر تصمیم به‌تنهایی ممکنه منطقی باشه، ولی مجموع این تصمیم‌ها می‌تونه شش ماه بعد یک سیستم غیرقابل نگهداری بسازه.

اینجا Tech Lead فقط نمی‌پرسه:

«راه‌حل این Feature چیه؟»

باید بپرسه:

«چطور این تیم‌ها رو طوری جلو ببریم که هم Product حرکت کنه و هم Technical Direction سیستم از هم نپاشه؟»

ممکنه خودش RFC بنویسه.

ممکنه Design یک Senior Engineer رو Review کنه.

ممکنه دو تیم رو برای رسیدن به یک Contract مشترک Align کنه.

ممکنه تصمیم بگیره یک Technical Debt الان ارزش پرداخت کردن داره یا باید سه ماه دیگه سراغش بریم.

و در خیلی از مواقع خودش حتی Implementer اصلی هیچ‌کدوم از این پروژه‌ها نیست.

Impact اون از Orchestration و Direction میاد.

این Archetype به چیزی که خودم در نقش Lead تجربه می‌کنم خیلی نزدیکه.

۲. Architect — کسی که چند قدم عقب‌تر می‌ایسته تا تصویر بزرگ‌تر رو ببینه

Architect بیشتر روی Technical Direction در Scope بزرگ‌تر تمرکز داره.

فرض کنید یک شرکت چندین تیم داره و طی چند سال هر تیم برای حل مسئله‌ی خودش تصمیم‌های منطقی گرفته.

یکی Library خودش رو ساخته.

یکی Authentication رو یک شکل پیاده کرده.

یکی Observability متفاوتی داره.

یکی Data Fetching رو با Pattern خودش انجام می‌ده.

هیچ‌کدوم الزاماً تصمیم بدی نگرفتن.

ولی وقتی از بالا نگاه می‌کنیم، نتیجه ممکنه یک Ecosystem باشه که تغییر دادن هرچیزی در اون خیلی گرونه.

Architect اینجا قرار نیست بره همه‌چیز رو Rewrite کنه.

باید بفهمه:

کجا Standardization واقعاً ارزش داره؟

کجا تفاوت بین تیم‌ها مشکلی ایجاد نمی‌کنه؟

چه چیزی باید Shared باشه و چه چیزی نباید؟

Migration چطور باید اتفاق بیفته که Delivery تیم‌ها متوقف نشه؟

و مهم‌تر از همه:

کدوم تصمیم معماری الان بیشترین Leverage رو برای آینده ایجاد می‌کنه؟

مثلاً شاید نتیجه‌ی کارش تعریف یک Design System مشترک باشه.

شاید Strategy مهاجرت از یک Legacy Architecture باشه.

شاید استاندارد کردن Observability بین چند تیم باشه.

یا حتی ممکنه بعد از بررسی به این نتیجه برسه که نباید سیستم فعلی رو تغییر بدیم، چون هزینه‌ی Migration بیشتر از Benefitشه.

Architect خوب کسی نیست که پیچیده‌ترین Diagram رو بکشه.

کسیه که بتونه Technical Direction بلندمدت رو با محدودیت‌های واقعی Business متعادل کنه.

۳. Solver — کسی که سراغ مسئله‌هایی می‌ره که بقیه نمی‌تونن راحت حلشون کنن

Solver شاید نزدیک‌ترین Archetype به تصویر کلاسیک «Engineer خیلی قوی» باشه.

ولی تفاوت مهمی وجود داره.

قرار نیست هر Bug سختی به Solver داده بشه.

Solver معمولاً سراغ مسئله‌هایی می‌ره که هم مهمن، هم مبهمن و هم تخصص بالایی برای حلشون لازمه.

فرض کنید Performance محصول طی چند ماه به شکل محسوسی افت کرده.

اما کسی دقیقاً نمی‌دونه چرا.

یک Metric مشخص نداریم که بگه مشکل اینجاست.

ممکنه Frontend باشه.

ممکنه Backend باشه.

ممکنه Network باشه.

ممکنه Architecture چند سال گذشته باعثش شده باشه.

تیم‌ها هم Featureهای خودشون رو دارن و کسی فرصت نداره چند هفته کل مسئله رو Investigate کنه.

Solver وارد این فضا می‌شه.

اول حتی ممکنه ندونه Solution چیه.

مسئله رو Decompose می‌کنه.

Measurement درست می‌سازه.

Hypothesis تعریف می‌کنه.

با چند تیم صحبت می‌کنه.

قسمت‌های مختلف سیستم رو بررسی می‌کنه.

و کم‌کم یک مسئله‌ی مبهم رو تبدیل به چیزی می‌کنه که قابل حل شدنه.

نکته‌ی مهم اینجاست:

بعد از اینکه مسیر مشخص شد، Solver الزاماً قرار نیست خودش تا آخر همه‌چیز رو Implement کنه.

ممکنه Execution رو به تیم‌های مربوطه منتقل کنه و خودش بره سراغ مسئله‌ی پیچیده‌ی بعدی.

ارزش اصلی Solver فقط در «حل کردن» نیست.

در تبدیل مسئله‌های مبهم و پیچیده به مسئله‌های قابل حل هم هست.

۴. Right Hand — کسی که Context و Trust بالایی داره و مسئله‌های مهم رو از دوش Leadership برمی‌داره

این Archetype شاید از بقیه کمتر شناخته‌شده باشه.

فرض کنید یک VP Engineering یا Head of Engineering مسئول چندین تیمه.

ده‌ها مسئله‌ی Technical و Organizational وجود داره که همه‌شون مهمن، ولی اون Leader طبیعتاً نمی‌تونه شخصاً وارد جزئیات همه‌شون بشه.

اینجا یک Staff Engineer باتجربه ممکنه تبدیل به Right Hand اون Leader بشه.

مثلاً Leadership متوجه شده Delivery چند تیم طی چند ماه کند شده.

ولی دلیلش مشخص نیست.

مشکل Product Planningـه؟

Architecture تیم‌هاست؟

Dependency بین تیم‌هاست؟

Technical Debt زیاده؟

Ownership مشخص نیست؟

Right Hand ممکنه مأمور بشه این فضای مبهم رو بررسی کنه.

با تیم‌ها صحبت کنه.

Data جمع کنه.

مشکل‌های مشترک رو پیدا کنه.

پیشنهاد بده کجا باید Process تغییر کنه، کجا Technical Investment لازمه و کجا اصلاً مسئله Technical نیست.

یا ممکنه یک Initiative مهم در سطح Engineering Organization وجود داشته باشه؛ مثلاً تغییر Release Process، تعریف Engineering Standards یا کاهش Dependency بین چند تیم.

Leadership جهت کلی رو مشخص کرده، ولی یک نفر باید اون Direction رو تبدیل به Execution واقعی کنه.

اینجاست که Right Hand وارد می‌شه.

این نقش نیاز به Technical Skill داره، ولی شاید بیشتر از Archetypeهای دیگه به Context، Judgment و Trust وابسته باشه.

چون مسئله‌هایی که به این فرد سپرده می‌شن معمولاً جواب مشخصی ندارن و حتی ممکنه مرز Technical و Organizational در اون‌ها کاملاً محو شده باشه.

پس من کدوم Archetype هستم؟

به نظرم لازم نیست حتماً یکی رو انتخاب کنیم و تا آخر Career همون بمونیم.

ممکنه امروز بیشتر Tech Lead باشیم.

شش ماه درگیر یک Migration بزرگ بشیم و بیشتر نقش Architect بگیریم.

یک مشکل Performance عجیب پیدا بشه و مدتی Solver باشیم.

یا با افزایش Scope و Contextمون کم‌کم بخشی از نقش Right Hand رو بگیریم.

حتی ممکنه در یک زمان ترکیبی از چندتا باشیم.

ارزش این Framework برای من بیشتر در اینه که یک سؤال جدید ایجاد می‌کنه:

به جای اینکه فقط بپرسم:

«چطور Staff Engineer بشم؟»

می‌تونم بپرسم:

«سازمان من الان به چه نوع Staff Engineerای نیاز داره و من در کدوم مدل می‌تونم بیشترین Impact رو ایجاد کنم؟»

این سؤال خیلی واقعی‌تره.

چون Staff Engineer در یک Startup صدنفره ممکنه کار کاملاً متفاوتی با Staff Engineer در یک شرکت ده‌هزارنفره انجام بده.

حتی ممکنه Title شما Staff Engineer نباشه، ولی بخش زیادی از کاری که انجام می‌دید Staff-level work باشه.

در نهایت چیزی که مهم‌تر از Title می‌شه، Scope و Impact واقعی کاره.

چطور به سمت Staff Engineering حرکت کنیم؟

به نظرم این مسیر رو نمی‌شه با یک Checklist مثل:

System Design یاد بگیر -> Distributed Systems بخون -> بیشتر کد بزن -> Staff شو

توضیح داد.

Technical Depth همچنان خیلی مهمه، ولی Staff شدن بیشتر از اینکه مجموعه‌ای از تکنولوژی‌های جدید باشه، تغییر در Scope و Impactـه.

اگر بخوام برای خودم یک Roadmap بسازم، چیزی شبیه این می‌شه:

۱. اول Senior بودنت رو پُر کن

برای Title بعدی عجله نکن.

در معرض مسئله‌های واقعی قرار بگیر و اجازه بده تصمیم‌ها، شکست‌ها و تجربه‌ها کم‌کم Judgmentت رو بسازن.

۲. منتظر پروژه‌ی بزرگ‌تر نباش؛ مسئله‌ی مهم‌تر پیدا کن

اگر به من بگن:

«می‌خوام Staff بشم، یه پروژه‌ی خیلی بزرگ بهم بده.»

احتمالاً اولین پیشنهادم این نیست که بزرگ‌ترین Feature موجود رو بهش بسپرم.

می‌گم اطرافمون رو نگاه کن.

کدوم Process خرابه؟

کدوم مشکل دائماً تکرار می‌شه؟

کجا تیم‌ها کندن؟

کجا Ownership نداریم؟

کجا Engineerها دائماً یک مشکل مشابه رو حل می‌کنن؟

Staff-level work خیلی وقت‌ها با پیدا کردن مسئله‌ای که کسی به شما Assign نکرده شروع می‌شه.

۳. Scope رو از Feature به Problem Space گسترش بده

به جای Ownership یک Implementation، Ownership یک Outcome رو بگیر.

مأمور ساختن فلان Feature نباش.

مأمور بهتر کردن یک وضعیت باش.

۴. یاد بگیر توجهت رو کجا خرج کنی

هر مسئله‌ای که می‌تونی حل کنی، مسئله‌ای نیست که باید خودت حل کنی.

Criticality، Leverage و Opportunity Cost رو ببین.

۵. آدم‌های اطرافت رو قوی‌تر کن

کارهای سخت رو فقط برای خودت نگه ندار.

با Guardrail مناسب به بقیه فرصت بده تصمیم بگیرن، اشتباه کنن، Feedback بگیرن و رشد کنن.

۶. Influence بدون Authority رو یاد بگیر

در Staff-level work خیلی وقت‌ها قرار نیست Manager آدم‌هایی باشی که باید باهاشون کار کنی.

باید بتونی با Context، Data، Design Document، RFC، Communication و Trust روی تصمیم‌ها اثر بذاری.

۷. موفقیت رو با Outcome اندازه بگیر

در پایان نپرس:

«من چقدر کار انجام دادم؟»

بپرس:

«به خاطر کاری که انجام دادم، چه چیزی در تیم یا سازمان بهتر کار می‌کنه؟»

ولی آیا اصلاً باید Staff بشیم؟

نه.

و به نظرم این سؤال باید قبل از Roadmap پرسیده بشه.

Senior Engineer بودن یک ایستگاه موقت نیست که حتماً باید هرچه سریع‌تر ازش عبور کنیم.

ممکنه کسی عاشق Coding عمیق، Ownership مستقیم و حل مسئله‌های Technical باشه و سال‌ها یک Senior Engineer فوق‌العاده باقی بمونه.

Staff Engineering هم الزاماً «نسخه‌ی بهتر» این زندگی نیست.

جنس کار تغییر می‌کنه.

ممکنه Coding مستقیم کمتر بشه.

جلسه، Alignment، Design و Communication بیشتر بشه.

مسئله‌ها مبهم‌تر می‌شن.

موفقیت کمتر فردی و بیشتر تیمی می‌شه.

گاهی ساعت‌ها روی مسئله‌ای کار می‌کنید که خروجیش حتی یک خط کد نیست.

و گاهی بهترین نتیجه‌ی کارتون اینه که یک نفر دیگه کار مهمی انجام بده و بابتش دیده بشه.

قبل از اینکه بپرسیم:

«چطور Staff Engineer بشم؟»

شاید بهتره بپرسیم:

«آیا از Staff Engineer بودن لذت می‌برم؟»

آیا از مسئله‌هایی که جواب مشخص ندارن لذت می‌برم؟

آیا دوست دارم روی چیزی بزرگ‌تر از Scope تیم خودم اثر بذارم؟

آیا حاضرم بخشی از لذت مستقیم حل مسئله رو به دیگران واگذار کنم؟

آیا می‌تونم بدون Authority مستقیم Influence ایجاد کنم؟

و آیا موفقیت بقیه می‌تونه به اندازه‌ی موفقیت مستقیم خودم برام رضایت‌بخش باشه؟

اگر جواب این سؤال‌ها مثبته، شاید وقتشه مسیر Staff Engineering رو جدی‌تر بررسی کنیم.

بعد از Senior شدن چی؟

شاید جواب واحدی وجود نداشته باشه.

می‌تونیم وارد Management بشیم.

می‌تونیم Staff Engineering رو دنبال کنیم.

می‌تونیم Senior باقی بمونیم و عمیق‌تر بشیم.

حتی ممکنه در دوره‌های مختلف Career بین این مسیرها حرکت کنیم.

ولی چیزی که برای من بعد از خوندن Staff Engineer و فکر کردن به تجربه‌ی خودم پررنگ‌تر شد اینه که:

بعد از Senior شدن، قرار نیست فقط مسئله‌های سخت‌تری حل کنیم. باید یاد بگیریم اثر بزرگ‌تری ایجاد کنیم.

گاهی با حل کردن یک مسئله‌ی Critical.

گاهی با پیدا کردن مشکلی که بقیه هنوز بهش توجه نکردن.

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

گاهی با اصلاح یک Process خراب.

و گاهی فقط با عقب ایستادن و دادن فرصت به یک Engineer دیگه.

شاید تا Senior شدن، بخش بزرگی از مسیر درباره‌ی این باشه که تبدیل بشیم به کسی که می‌شه مسائل مهم رو بهش سپرد.

اما بعد از اون، شکل جدیدی از رشد شروع می‌شه:

Senior بودن یعنی بتوانی مسئولیت یک مسئله‌ی مهم را به دوش بکشی.

Staff بودن یعنی کمک کنی سیستمی ساخته شود که مسائل مهم، حتی بدون حضور مستقیم تو، بهتر حل شوند.