‏از سینیور تا استاف: سه بُعدی که کسی بهت نمی‌گه

این مطلب یه مطالعهٔ موردی از کتابِ در حالِ نگارشِ Gregor Ojstersek دربارهٔ تبدیل شدن از سینیور به رهبرِ فنی در عصر AI‌ه، و راوی‌اش Jordan Cutler، استاف‌اینجینیرِ تیمِ Web Platform در پینترسته. نویسنده می‌گه مهندس‌هایی که سرِ سینیور گیر می‌کنن، اونایی‌ان که فقط هل می‌دن سمتِ مهارتِ فنیِ عمیق‌تر، اجرای سریع‌تر و سیستم‌های پیچیده‌تر؛ همه چیزای خوبی‌ان ولی استاف‌اینجینیرینگ روی بُعدهایی کار می‌کنه که خیلیا اصلاً بهشون فکر نمی‌کنن. سه بُعدی که معرفی می‌کنه اینان: گسترشِ سطحِ تأثیر، نفوذ بین تیم‌ها، و ساختنِ سیستم‌های مقیاس‌پذیر.

بُعد اول، گسترشِ سطحِ تأثیره. نویسنده می‌گه هیشکی ازش نخواست «آدمِ AI» بشه، ولی چون دید AI داره یه تغییرِ صنعتی می‌شه و با کارش روی بهره‌وریِ توسعه هم‌پوشانی داره، کلی آزمایش کرد. بعد یه کانالِ اسلکِ #how-i-ai راه انداخت تا همه یادگیری‌هاشون از AI رو به اشتراک بذارن؛ ظرف یه روز ۲۰۰ نفر و چند ماه بعد ۱۲۰۰+ نفر عضوش شدن و حتی توی ابزارِ شرکتی ادغام شد. همین دیده‌شدن باعث شد برای یه دموی مدیریتی و بعد گروهِ «AI Coding Pathfinders» دعوت بشه.

جمع‌بندیِ نویسنده برای این بخش اینه که منتظرِ تخصیصِ کار از بالا نمون؛ یه فضا بساز، با ارزش بذرافشانی‌اش کن و بذار خودش رشد کنه و انباشته بشه.

بُعد دوم، نفوذ بین تیم‌هاست. نویسنده روی صفحهٔ Search پینترست ممیزیِ پرفورمنس کرد و کندی‌ها رو پیدا کرد، ولی می‌گه درسِ سختی گرفت: اولش اصطکاک رو به‌قدرِ کافی کم نکرد و تیم‌ها کارو اولویت ندادن. فرقش اینه که به‌جای «این payload بزرگه» بگی «این پاسخ ۵۰۰ کیلوبایته، خیلی بزرگ‌تر از نیازه، فیکسش کاربر رو ۱۰۰ میلی‌ثانیه زودتر به نتیجه می‌رسونه و این‌جوری حلش می‌شه». یعنی بگی چی کنده، چرا، و چطور درست می‌شه، و کمک هم بکنی.

بعد همین رویکرد رو به Home Feed و Pin Page (که حدودِ ۸۰٪ ترافیک رو دارن) گسترش داد و با یه پیشنهادِ ساده مشاورِ چند تیم شد. یه نمونهٔ جالبش این بود که موقعِ کلیک روی Closeup، همون تصویرِ رزولوشن‌متوسطی که کاربر داشت می‌دید نشون داده بشه تا نسخهٔ رزولوشن‌بالا لود بشه. نتیجه‌اش بهبودِ ۳۰٪+ پرفورمنس روی اون صفحات بود، اون هم وقتی هنوز سینیور بود.

بُعد سوم، ساختنِ سیستم‌های مقیاس‌پذیره. نویسنده و مدیرش نمی‌تونستن به این سؤال جواب بدن که «تجربهٔ توسعه‌ٔ ما چطوره؟»؛ متریک همه‌جا بود (Buildkite، GitHub، JIRA، Honeycomb) ولی یه دیدِ کلی نبود و اولویت‌بندی بیشتر روی حسّ‌وحال می‌چرخید. اون یه چارچوب ساخت که سه چیزو وصل می‌کرد: متریک‌هایی که تیم کنترلشون می‌کنه، چیزی که توسعه‌دهنده روزمره حس می‌کنه، و عددهایی که رهبری نگاه می‌کنه. برای هر متریک هم آستانهٔ قرمز/زرد/سبز تعریف کرد؛ مثلاً CI زیرِ ۱۲ دقیقه سبز، ۱۲ تا ۱۸ زرد، بالای ۱۸ قرمز.

بعد یه سیستمِ گزارش‌دهیِ خودگردان روش سوار کرد: هر تیم یه آبجکتِ کانفیگِ ساده تعریف می‌کنه و یه پایپ‌لاین هفتگی داده رو می‌کشه و دوشنبه‌ها یه گزارشِ مرتب توی اسلک می‌ذاره. چون فرمتش اعلانی و ساده بود، تیم‌های دیگه (مثل API Platform) ظرف یه روز بهش وصل شدن. نتیجهٔ جمعی این تجربه‌ها به گفتهٔ نویسنده اینه که استاف‌اینجینیرینگ یعنی چیزی بسازی که بقیه به‌خاطرش بیشتر کار کنن؛ کاری که حتی وقتی تو تعطیلاتی هم کار می‌کنه و انباشته می‌شه.

نکات کلیدی:

• گیر کردن سرِ سینیور معمولاً به‌خاطرِ تمرکزِ صرف روی مهارتِ فنی و سرعتِ اجراست
• سه بُعدِ کلیدی: گسترشِ سطحِ تأثیر، نفوذ بین تیم‌ها، ساختنِ سیستم‌های مقیاس‌پذیر
• موقعِ مطرح‌کردنِ مشکل، داده + اثر + راه‌حل بده و کمک به فیکس رو هم پیشنهاد بده
• آستانه‌های قرمز/زرد/سبز، مشکلاتِ مبهم رو به اولویت‌های مشخص تبدیل می‌کنن
• هدف اینه چیزی بسازی که بقیه به‌خاطرش بیشتر کار کنن، نه اینکه خودت بیشتر کد بزنی