مهندسان در دو دهه گذشته کاملاً لوس و نازپرورده شده‌اند.
این حقیقتی تلخ – اما عینی – است. پیش از سال ۲۰۲۲، افراد بیست‌ساله اغلب با گذراندن تنها یک دوره بوت‌کمپ در رزومه خود، به راحتی مشاغلی با درآمد ۶ رقمی پیدا می‌کردند. کارفرمایان در شرکت‌های بزرگ فناوری مزایای نامحدودی مانند مرخصی نامحدود (PTO)، زمان ۲۰ درصدی و امکانات مجلل ارائه می‌دادند – به عنوان مثال، باشگاه‌های ورزشی خصوصی، کافه‌تریاهای لوکس، و مراقبت از کودکان در محل کار. امنیت شغلی تضمین‌شده بود؛ و استخدام‌کنندگان دائماً با پیشنهادهای بیشتر، مزایای بهتر، حقوق بالاتر و عناوین شغلی مهم‌تر، مهندسان را احاطه می‌کردند.
اگر آن‌قدر خوش‌شانس بودید که در دسته استعدادهای فناوری قرار بگیرید، تقریباً هیچ راهی برای شکست وجود نداشت. حتی اگر به دلیل ناکارآمدی خودتان اخراج می‌شدید، می‌توانستید در عرض چند هفته شغلی جدید با عنوان و حقوق بهتر پیدا کنید.
پشت این ماجرا یک انگیزه پنهان وجود داشت. مهندسان محرک اصلی رشد نرم‌افزار بودند. برای Google یک مزیت بود که ۶۰,۰۰۰ نیروی متخصص (ICs) را در اختیار داشته باشد. هدف این نبود که همه آن‌ها را به کار بگیرد، بلکه داشتن این نیروها به خودی خود ارزش داشت؛ این مسئله به شرکت گزینه‌های بیشتری می‌داد و منابع حیاتی را از دسترس رقبا دور نگه می‌داشت.
تأثیر این رویکرد به مرور زمان، نقش مهندسی را به‌طور کلی تغییر داد. اگر شما (مانند اکثر شرکت‌ها) نمی‌توانستید هزینه ۳۵۰ هزار دلاری یک توسعه‌دهنده ارشد را بپردازید، تنها یک راه برای جذب استعدادهای برتر باقی می‌ماند: ایجاد یک «فرهنگ عالی مهندسی»
به عبارت دیگر، فرهنگی که در آن مهندسان مجبور نباشند کاری را انجام دهند که تمایلی به آن ندارند.
مهندسان از سیاست خوششان نمی‌آید، بنابراین مدیریت محصول به یک سخنگوی تشریفاتی تبدیل شد که وظیفه‌اش رفع اختلافات و حل مشکلات با ذی‌نفعان ناراضی بود. زمان توسعه‌دهنده بسیار ارزشمند است، بنابراین بروکراسی به کار گرفته شد تا درخواست‌ها پیش از آنکه به دست مهندسان برسد، بررسی شوند. نظرسنجی‌های احساسات توسعه‌دهندگان به‌طور منظم توزیع می‌شود تا تیم فنی بداند که احساسات آن‌ها بسیار، بسیار مهم است.
هیچ بخش دیگری به این شکل مدیریت نمی‌شود، اما برای مهندسی، این وضعیت عادی بود. این کار دلایل خوبی داشت – حفظ نیروهای متخصص حیاتی بود؛ از دست دادن آن‌ها (که دائماً توسط استخدام‌کنندگان شرکت‌های بزرگ فناوری برای پیشنهادهای بهتر جذب می‌شدند) می‌توانست به معنای از کار افتادن کل شرکت باشد.
خلاصه‌ای از یکی از پربیننده‌ترین پست‌های R/ExperiencedDevs
دو دهه این رقابت تسلیحاتی، پدیده‌ای شگفت‌انگیز را به وجود آورده است: ما اکنون یک نسل کامل از رهبران مهندسی داریم که فکر می‌کنند استخدام و نگهداری نیروها هدف اصلی است. آن‌ها به‌جای مدیریت، نیروی کار را نوازش می‌کنند، از سیاست‌های شرکتی بیزارند و آن‌ها را دور می‌زنند، و در اولویت‌بندی اهداف تجاری شکست می‌خورند.
این مسئله در مورد همه رهبران مهندسی صدق نمی‌کند، اما این هنجارها به فرهنگ مهندسی نفوذ کرده‌اند. مهندسی مدت‌ها تحت شرایط منحصربهفردی فعالیت کرده است، به‌طوری‌که اکثر مدیران ارشد فناوری (CTOs) هرگز یک محیط کاری «عادی» را تجربه نکرده‌اند. آن‌ها فکر می‌کنند که می‌توان اولویت‌ها را بر اساس اعتماد و حسن نیت تعیین کرد. آن‌ها شاخص‌های تجربه توسعه‌دهندگان را با معیارهای «بهره‌وری» اشتباه می‌گیرند. آن‌ها فکر می‌کنند که ارائه یک نقشه راه از سوی تیم محصول باید برای توضیح آنچه مهندسی انجام می‌دهد کافی باشد.
اما این رهبران متوجه نیستند که دوران تمرکز بر نگهداری نیروها به پایان رسیده است.
نرم‌افزار دنیا را تسخیر کرد و دیگر دلیلی وجود ندارد که Google بخواهد ۶۰,۰۰۰ مهندس را برای خود نگه دارد. در سال ۲۰۲۳، شرکت‌های بزرگ فناوری بدون هیچ تشریفاتی بیش از ۲۵۰,۰۰۰ نیروی کار خود را اخراج کردند و مزایا را به طرز چشمگیری کاهش دادند. وعده هوش مصنوعی تیر خلاص را زد: مهمانی به پایان رسیده و دیگر برنمی‌گردد.
منبع https://layoffs.fyi
این تغییر برای مدیران ارشد فناوری (CTOs) و تیم‌هایشان قرار است تجربه‌ای دردناک باشد. همکاران آن‌ها در سطح مدیریت ارشد (C-Suite) به کاهش‌های گسترده‌ای که سازمان‌هایی مثل Google و Amazon با موفقیت انجام دادند نگاه می‌کنند و از خود می‌پرسند که آیا می‌توانند همین کار را انجام دهند.
این موضوع در هیچ بخش دیگری مشکل‌ساز نمی‌شود؛ شما وقتی می‌خوانید JetBlue بودجه بازاریابی خود را کاهش داده است، بلافاصله به این فکر نمی‌کنید که آیا شما هم باید هزینه تبلیغات خود را کاهش دهید. اما مهندسی مشکلی منحصربه‌فرد دارد، زیرا هیچ‌کس واقعاً نمی‌داند که مهندسان در طول روز چه کاری انجام می‌دهند.
من این را در یک نقل‌قول برجسته قرار می‌دهم تا دوباره بر عجیب بودن این موضوع تأکید کنم: اکثر رهبران تقریباً هیچ دیدی نسبت به یکی از گران‌ترین و مهم‌ترین عملکردهای اصلی کسب‌وکار خود ندارند.
چندین عامل هم‌افزا ما را به این نقطه رسانده است.
برای شروع، مهندسی به‌عنوان یک نقش به‌خوبی درک نشده است. در مدارس کسب‌وکار درباره موقعیت‌یابی محصول و عملیات یاد می‌گیرید، اما چیزی درباره نگهداری امنیت اطلاعات (InfoSec) به‌عنوان زیرساخت استراتژیک نمی‌شنوید. هیچ راهکار خوبی برای رهبران غیر‌فنی وجود ندارد که حتی یک مدل ذهنی ابتدایی از نحوه عملکرد مهندسی در سطح سازمانی ایجاد کنند.
این امر مکالمات بین رهبران فنی و غیر‌فنی را به‌طور منحصربهفردی دشوار می‌کند. تقریباً هر مکالمه‌ای نیازمند توضیح اصول بنیادی است. تصور کنید اگر مدیر بازاریابی (CMO)، قبل، در حین، و پس از ارائه پیشنهاد یک کمپین تبلیغاتی عادی، نیاز داشت مفهوم برند، اهمیت ایجاد تقاضا و دلایل تبلیغات را توضیح دهد.
وضعیت به‌قدری بد است که اکثر رهبران مهندسی به‌طور بی‌سروصدا وظایف معمول مهندسی را در پشت‌صحنه انجام می‌دهند. انجام یک به‌روزرسانی بزرگ برای تیم آن‌ها بسیار ساده‌تر از توضیح [یک مثال رایج از تعمیرات که احتمالاً یک فرد غیر‌فنی هرگز نامش را نشنیده است] است.
این وضعیت یک شکاف “ما در برابر آن‌ها” بین مهندسی و تقریباً هر بخش دیگر از کسب‌وکار ایجاد می‌کند. مهندسی احساس می‌کند (به‌درستی) که درک نشده و مورد قدردانی قرار نمی‌گیرد. باقی بخش‌ها (به‌درستی) احساس می‌کنند که با یک جعبه سیاه سر‌و‌کار دارند که اطلاعات را نگه‌داشته است. مکالمات میان این دو طرف به‌طور فزاینده‌ای خصمانه می‌شود، تا جایی که رهبران مهندسی – که اغلب در محیط‌هایی تربیت شده‌اند که اجتناب از مسائل ناخوشایند کاملاً قابل قبول بود – به‌طور کلی از تلاش برای توضیح خود دست می‌کشند.
در بسیاری از سازمان‌ها، این مدیریت محصول است که نهایتاً این خلأ را پر می‌کند. آن‌ها به‌عنوان یک عامل تسکین‌دهنده عمل می‌کنند – به‌جای مهندسی پل می‌سازند و کمک می‌کنند تا “چه”، “چرا” و “چگونه” تصمیمات مهندسی توضیح داده شود. تعجبی ندارد که وقتی کسی می‌پرسد مهندسی در حال انجام چه کاری است، پاسخ معمولاً نقشه راه محصول است.
این وضعیت در بسیاری از شرکت‌ها به هنجار تبدیل شده است. و این همان چیزی است که باعث می‌شود رهبران مهندسی در این دوران ساده‌سازی، درد زیادی را تجربه کنند:
کنترل روایت خود برای بازی در عرصه سیاست ضروری است. روایت‌های خوب باعث می‌شوند اهداف طبیعی و اجتناب‌ناپذیر به نظر برسند. آن‌ها به رهبران کمک می‌کنند تا همه – نه فقط کسانی که تحت مدیریت آن‌ها هستند – را برای رسیدن به اهداف هیجان‌زده کنند. آن‌ها در مواقع سخت پشتیبان هستند و در مواقع موفقیت اعتبار می‌آورند.
تیم‌های مهندسی این را ندارند. در بهترین حالت، آن‌ها یک نقشه راه دارند – یک لیست آرزوهایی که مدیریت محصول دوست دارد انجام شود.
به همین دلیل است که اکثر مدیران عامل هیچ درکی از فعالیت‌های نگهداری حیاتی که تیم‌های مهندسی آن‌ها هر روز انجام می‌دهند، ندارند. آن‌ها نمی‌دانند چه زمانی بازسازی‌ها انجام می‌شوند و چرا. آن‌ها نمی‌فهمند چه زمانی گلوگاه‌ها ایجاد می‌شوند، زیرا نمی‌دانند دانش نهادی حیاتی کجا نگهداری می‌شود.
به‌طور خلاصه، آن‌ها نمی‌توانند کاری که مهندسان انجام می‌دهند را ببینند. مهندسی شبیه یک جعبه سیاه پرهزینه و ازخودراضی به نظر می‌رسد که به‌طور جادویی ویژگی‌هایی را ارائه می‌دهد.
این وضعیت به‌خودی‌خود بد است، اما طبیعت از خلأ بیزار است. مهندسی پشت فرمان نیست، اما همچنان یک روایت دارد.
- مهندسان، افراد خجالتی و ناتوان از نظر اجتماعی هستند.
- کار آن‌ها سرد، خشک و دوگانه (باینری) است.
- آن‌ها از کسب‌وکار سر درنمی‌آورند و جایی در اتاق هیئت‌مدیره ندارند.
- نمی‌توانیم آن‌ها را به سرمایه‌گذاران و مشتریان معرفی کنیم.
- آن‌ها تمام روز فوتبال‌دستی بازی می‌کنند و آبجو می‌نوشند.
این تصوری است که مردم از مهندسان پیدا کرده‌اند. تصور کنید یک مدیر پشتیبانی (که پس از دو دهه مدیریت مراکز تماس سالانه ۱۲۰ هزار دلار درآمد دارد)، گروهی از جوانان بیست‌ساله را ببیند که ساعت ۴ عصر پینگ‌پنگ بازی می‌کنند. ممکن است مهندسان لازم باشند، اما فقط به‌زور تحمل می‌شوند.
به همین دلیل است که اخراج‌های گسترده در FAANG به چنین نیروی محرک قدرتمندی برای شرکت‌های کاملاً نامرتبط تبدیل شده است تا اخراج‌های خود را آغاز کنند. مردم نمی‌توانند صبر کنند تا باور کنند که مهندسان دیگر این‌قدر ارزشمند نیستند. اینجاست که بحث‌های داغی که اکنون درباره «بهره‌وری توسعه‌دهندگان» می‌بینیم شکل می‌گیرد؛ آن‌ها مشتاقانه منتظرند تا تیم‌های مهندسی خود را متناسب کنند.
این همان تهدید وجودی است که مدیران ارشد فناوری (CTOs) اکنون با آن روبه‌رو هستند. مسئله ترسناک این است که بسیاری از آن‌ها حتی متوجه این موضوع نیستند – آن‌ها هنوز فکر می‌کنند در سال ۲۰۱۵ هستند، زمانی که هدف، استخدام و نگهداری نیروها بود. آن‌ها با نظرسنجی‌های احساسات توسعه‌دهندگان وارد بحث با مدیران مالی (CFOs) درباره «بهره‌وری» می‌شوند.
تیم‌های آن‌ها هدف‌های آسانی هستند. دیدن این وضعیت دردناک است.
تناقض در اینجاست که اکثر سازمان‌های مهندسی خارج از شرکت‌های بزرگ فناوری، همین حالا هم چابک هستند. استعدادهای فناوری آن‌قدر گران بوده‌اند که اکثر رهبران خارج از FAANG یاد گرفته‌اند با حداقل‌ها کارهای زیادی انجام دهند. وقتی ذی‌نفعان تجاری بیش‌ازحد مشتاق، کاهش‌های نادرستی انجام می‌دهند، به‌طور ناخواسته تداوم کسب‌وکار را با کاهش زیرساخت‌های اصلی به خطر می‌اندازند.
این زیرساخت – و توسعه‌دهندگانی که آن را ساخته‌اند – رفاه ناشی از رونق نرم‌افزار را ممکن کرد. مهندسان نرم‌افزار ممکن است در این مسیر از امتیازات فوق‌العاده‌ای برخوردار شده باشند، اما این امتیازات به‌خاطر انجام درست کار بود. نگاهی به عملکرد سهام شرکت‌های بزرگ فناوری در دو دهه گذشته بیندازید؛ به‌راحتی می‌توانید استدلال کنید که این کارکنان حتی شایسته امتیازات بیشتری بودند.
بخش‌های دیگر هم می‌توانند با تمرکز بر بهره‌وری، شادی و استقلال کارکنان خود به همان اندازه موفق شوند. در واقع، مدیران ارشد فناوری که به مدیران عامل تبدیل شده‌اند، معمولاً از مهربان‌ترین، خلاق‌ترین و سخاوتمندترین رهبرانی هستند که من افتخار همکاری با آن‌ها را داشته‌ام. آن‌ها درک ذاتی از اهمیت فرهنگ و ارزشمند دانستن افراد دارند.
اما آن‌ها – و تیم‌هایشان – اگر همچنان چشم خود را بر واقعیت ببندند دوام نمی‌آورند . حتی در این مقاله، من احتمالاً احساسات مختلفی را درباره مهندسان در شما برانگیختم. من چیزی از تجربیات زندگی شما تغییر ندادم؛ فقط افکارم را سازمان‌دهی کردم، کلمات را با دقت انتخاب کردم، و زمینه‌های لازم را اضافه کردم. این قدرت روایت است. روایت‌های خوب مانند حقیقت طنین‌انداز می‌شوند، زیرا به توضیح و تقویت تجربیات ما کمک می‌کنند.
به همین دلیل است که رهبران مهندسی باید بپذیرند که زمانه تغییر کرده است. اگر این کار را نکنند، نه‌تنها تیم‌ها و مشاغلشان در خطر خواهد بود، بلکه حتی تداوم کسب‌وکارهایی که با سختی بسیار ساخته‌اند نیز به خطر می‌افتد.
آیا مهندسان گروهی از افراد لوس، بیش‌ازحد دستمزد گرفته و اهل فناوری هستند که مدت‌هاست نیاز به بازخواست داشته‌اند؟ یا آن‌ها زیرساخت اصلی درآمد و نوآوری هستند که همه ما می‌توانیم از آن‌ها درس بگیریم؟ این‌که مدیران ارشد فناوری تصمیم بگیرند پا پیش بگذارند یا نه، تفاوت بزرگی ایجاد خواهد کرد.
در نهایت، اگر شما داستان خود را ننویسید، کسی دیگر آن را خواهد نوشت.