در اوایل بازگشتمون، سعادتِ این رو داشتم که دوری در اکوسیستم فناوری زدم و همچنین با دوستانی از شرکت‌های مختلف گپ و گفت داشتم و با کارها و مساله‌هاشون آشنا شدم. این یادداشت، به برخی‌شون که نسبتا شایع بودن می‌پردازه (مشاهده‌ها محدود و از ۱۵-۱۰ شرکت هست). این تکه‌ها پیش‌تر در توییتر/اینستاگرام منتشر شده و اینجا در این یادداشت جمع‌آوری می‌شه؛ یعنی دلیل عدم انسجام احتمالی، اینه. کپی با یا بدون ذکر منبع آزاده.
شفاف کنم که نگاه انتقادی به این مساله‌ها، برای کمک به بهتر شدنه و نه ایراد گرفتن یا کم شمردن کارهایی که انجام شده؛ از متعالی‌ترین سازمان‌ها و محصولات دنیا هم می‌تونم صفحه‌ها نقد بنویسم. مشخصا مایلم روشن کنم که کارهایی که در اکوسیستم فناوری ایران انجام می‌شه شگفت‌آوره: با وجود این همه موانع و معضل‌هایی که هر یک به تنهایی برای سد راه کافی هست، سنگ‌اندازی‌های داخلی، تحریم‌های خارجی، بحران نیروی انسانی، همچنان چیزهایی ساخته شده که (به دید منِ کاربر) فاصله‌ی چندانی با محصولات مشابه جهانی نداره یا در برخی موارد بهتره. قطعا همیشه هم نیاز به بهبود هست.
در یک سری کارگاه‌های توسعه‌ی نرم‌افزار که برگزار کردم، بچه‌ها می‌گفتن در درس «مهندسی نرم‌افزار»، از چرخه‌ی توسعه (مثلا trunk based و feature branchای یا تک‌مخزنی و چندمخزنی یا بازبینی/review کد و …) یا تست قناری و تکنیک‌های پایش و غیره، خیلی گفته نمی‌شه، ولی مقدار خوبی متدلوژی و «اسکرام» گفته می‌شه - و درباره اسکرامِ ما (در گوگل) می‌پرسیدن. از نکات مشترک بین دانشگاه‌ها بود.
پاسخ: نه ما و نه هیچ‌یک از ده‌ها تیمی که بنده در این ۱۰ سال در گوگل باهاشون کار مشترک کردم، «اسکرام» کار نمی‌کردن. احتمالا هستن تیم‌هایی که اسکرام کار کنن ولی مرسوم نیست - و کلا «پکیج» مدیریت پروژه اون‌قدر مهم نیست. شما هم ببینید چی براتون کار می‌کنه. گیرِ این چارچوب‌ها نباشید. ما گاهی standup روزانه گذاشتیم، تو دست و پا بود، جمعش کردیم. sprint رو یه مدل دیگه رفتیم و چند بار هم عوضش کردیم. retro نرفتیم. اون مفهوم کذایی product owner رو هرگز نداشتیم و اصلا سَم می‌دونستیم. برای ابزار هم، یکی Google sheet، یکی Kanban، یکی SmartSheet. اون‌قدر مهم نیست. غیرقابل‌بازگشت هم نیست.
مدل trunk based و ادغام پیوسته (CI) و تست قناری و غیره ولی مثل مباحث مدیریت پروژه نیست، مساله‌های عینی‌تره/objectiveتره. از الان می‌تونم بهتون بگم بدون قناری چه بلاهایی سرتون می‌آد ولی بدون اسکرام احتمالا بلایی سرتون نمی‌آد. جا داره در سیلابس این درس‌های مهندسی نرم‌افزار یک بازنگری بشه.
یک مدل ناکارآمد در مدیریت پروژه در برخی جاها، اینه که یک «نقش» تعریف شده که به توسعه‌دهنده‌ها تکه کار (مثلا روزانه یا هفتگی) بده و تحویل بگیره. این مدل خودش بده، و بدتر این که این نقش رو هم یک فرد غیر فنی مثلا مدیر محصول (PM) یا مدیر پروژه/مدیر برنامه به عهده می‌گیره. مثلا طرف به من می‌گه ما چه‌طوری اطمینان حاصل کنیم توسعه‌دهنده کارش رو درست جلو می‌بره؟ می‌گم چرا تو؟ می‌گه پس کی؟! نمی‌دونم این تفکر از کجا اومده. شاید از اون مفهوم کذایی product owner در اسکرام. گویی توسعه‌دهنده‌ها واحدهای تک‌سلولی هستن که فقط حل مساله‌ی فنی بلدن و برای پیشرفتِ کار باید ریزمدیریت بشن.
پس مدل کارآمد چیه؟ خود توسعه‌دهنده‌ها مسؤل پیشرفت کار هستن؛ ولی یه کم توضیح داره، چون می‌گن «آقا دلت خوشه و اون گوگله و توسعه‌دهنده‌هاش فرق دارن و فلان». نه، آدماش فرق ندارن. اونجا هم آدم تازه‌کار که می‌آد، در آغاز نیاز به تکه کارهای کوچک و ریزمدیریت متناوب داره. حتی اگر رهاش کنی ممکنه چند هفته روی یک compile error دور خودش بچرخه. ولی نکته اینه که موظفه به سرعت از این مدل کاری فاصله بگیره - و این خودش یک اولویت مدیریتیه (همون‌طور که پیشرفت پروژه یک اولویته).
فاصله بگیره یعنی چی؟ چرا باید چنین کنه؟ چه‌طور این اولویت اِعمال می‌شه؟ نردبان. نردبان و ارزیابی رو نمی‌خوام الان باز کنم. به طور خلاصه، افراد رو شکل می‌ده. اگر می‌خوایم آچار فرانسه بشن، خود-رهبر بشن، به محصول نهایی اهمیت بدن، … موارد متناسبش رو می‌آریم تو نردبان: می‌گیم برای رشد شغلی و افزایش دستمزد و آزادی عمل و غیره، مسیرت از این شکلی شدن می‌گذره.
حالا شما نردبان فنی گوگل (که کلا در دره‌ی سیلیکون هم محبوبه) رو که ببینید، تمرکز بیشتر از این که بر عمق فنی باشه بر اینه که فرد باید زودتر به جایی برسه اولویت‌های خودش رو مدیریت کنه و کارهای بزرگ رو سر تا سر (e2e) جلو ببره. نیروی صفرکیلومتر که تازه از دانشگاه می‌آد معمولا در کمتر از یک سال به اینجا می‌رسه که ریزمدیریت نخواد. قطعا در جلسه‌های ۱:۱ همیشه در جریان پیشرفت کار فرد هستیم ولی از این جنسه که «داری چه می‌کنی؟ ایول. اینم یه نگاهی بکن»، نه این که هر هفته بیاد بگه حالا این هفته چه کار کنم. همین کار رو هم رهبر فنی (TL) می‌کنه، نه PM یا مدیر پروژه.
نه تنها ساز و کار ارزیابی عملکرد، افراد رو هُل می‌ده به سمت خود-رهبری، انتظار از مدیر هم همینه: کمک کنه و تو دست و پا نباشه. ریزمدیریت مثل فُحشه. از پرسش‌هایی که از همه در ارزیابی مدیرشون پرسیده می‌شه اینه که آیا مدیرت بهت فضا و اختیار عمل کافی می‌ده؟ ریزمدیریتت که نمی‌کنه؟
پرسیدن پس مدیر پروژه چیه؟ جداسازی کارهای مدیریت پروژه‌ای از رهبری فنی هزینه‌هایی داره، و در عوض انجامشون توسط خود رهبری فنی هم هزینه‌هایی داره. باید سنجید. (در اون فضایی که ترسیم شد) مدیریت پروژه در سطح کار ۱۵-۱۰ نفره معمولا توسط خود رهبران فنی انجام می‌شه، نه یک شخص سوم.
ولی در پروژه‌های بزرگتر و به ویژه «بین تیمی»، کمک تخصصی مدیر پروژه / مدیر برنامه لازم و لازم‌تر می‌شه. از وظایف این نقش:
یک ناکارآمدی دیگه در مدیرت پروژه اینه که (عموما دوستان مهندسی صنایع) روش‌هایی که برای صنایع دیگه ساخته شده رو می‌زنن به پروژه‌های نرم‌افزاری. ولی اینجا فضا خیلی پویاتره. مثلا نمودار گانت (Gantt chart) کشیدن: من نمونه‌ای که این کار واقعا آورده داشته باشه ندیدم و فقط تو دست و پاست. تجربه‌ی بنده محدوده، شاید مثلا در پروژه‌های نرم‌افزاری کلاسیک (تحویل نرم‌افزار حساب‌داری به مشتری برای نصب) به کار بیاد. ولی در بیشتر کارهای نرم‌افزاری امروز، یک مولفه‌ی پررنگ غیرقطعیت و اکتشافی بودن هست و پویایی بالایی هست.
یک مساله‌ی فراگیر، حوزه‌های «باریک» است که برخی برای خودشون تعریف می‌کنن؛ مثلا «BI کار»؛ «php کار». این رویکرد به یک سرعت‌گیر برای شرکت‌ها تبدیل شده - و جلوی رشد خود آدم‌ها رو هم می‌گیره و اصلا مفهوم مهندس ارشد (senior) عوض شده. متوجه تخصصی شدن کارها و این که همه چیز در «مهندس نرم‌افزار» جا نمی‌شه و مثلا گاهی نقش جداگانه‌ی data scientist لازمه هستم، ولی بحث افراط در این امره. از یک مهندس نرم‌افزار انتظار می‌ره بتونه SQL query بنویسه و داده تحلیل کنه، گراف بکشه و داشبورد بسازه، release و production بفهمه. نه از پیش، بلکه یعنی هر وقت لازم شد بتونه یاد بگیره.
یک مثال بزنیم. فرض کنید یکی قرار شده یک داده رو در قالب xml تبادل کنه، ولی بگه «من json کارم و xml کارِ من نیست». حرف عجیبیه، نه؟ اگر یکی بگه «من php کارم و پایتون کارِ من نیست» هم همین‌طور عجیبه واقعا. بسیاری از این حوزه‌های باریکی که مد شده هم همین‌طور: «دیتا آنالیست»، «دیتا انجینییر»، ...
یادگرفتن مهارت‌ها/تکنولوژی‌هایی که برای پیش‌بردِ کار لازم می‌شه، از شاخصه‌های مهندس نرم‌افزار متوسط/intermediate هست و نه حتی ارشد - بر اساس نردبان تعاریف سطحِ گوگل که در دره‌ی سیلیکون هم زیاد استفاده می‌شه. حتی مهندس‌های تازه‌کار/junior هم هرچند در آغاز ازشون انتظار نمی‌ره، در عمل چنین هستن و هر مهارتی لازم بشه یاد می‌گیرن چون می‌خوان نشون بدن لایق ارتقا به سطح متوسط/intermediate هستن.
نفرمایید «اونجا گوگله فرق می‌کنه». اولا از نظر کیفیت افراد، گوگل مطلقا اون تصویری که فکر می‌کنید نیست. دوما اتفاقا باید گفت «حتی» گوگل هم که حوزه آدم‌ها درش بسیار محدوده (سال تا سال فقط یک پیچ مشخص سفت می‌کنی) آچار فرانسه می‌خواد؛ در شرکت کوچکتر که انتظار گستره/breadth بیشتر هم می‌ره که دیگه هیچ.
مساله‌ی «مرزها» متاسفانه گاهی زیادی پررنگه. مثلا «من مهندس‌ام، در کار محصولی دخالت نمی‌کنم» یا «من PMام، به فنی کاری ندارم». عزیزان، «حوزه مسؤلیت» عالیه، ولی «حوزه استحفاظی» نه. مهندس خوب اونیه که محصول بفهمه و یک PM خوب اونیه که فنی بفهمه و در کار هم نظر بدن. این هم در نردبانی که در بالا گفتم، هست. با این «سیلو»هایی که برای نقش‌ها می‌سازیم، کارها ناکارآمد جلو می‌رن.
فقط بحث فنی و محصولی نیست. مثلا بین «مهندس backend» و «مهندس data» و … هم هست. هم عدم علاقه از سوی شخص مثلا کدنویس هست که داشبورد ساختن یاد بگیره، هم در برخی جاهای دیدم مثلا اون تیمی که روی داده نشسته دسترسی نمی‌ده و برای خودش نقش دربانی/gatekeeper می‌بینه. این بسیار نابهینه‌ست - مواردی که حفاظت اطلاعات می‌طلبه به کنار.
درباره‌ی کدها هم همین‌طور. برخی جاها می‌بینم هنوز مفهوم منسوخ code ownership پررنگه و این که در کدهای همدیگه کد بنویسیم، قبح داره. این خوب نیست. عموما هم رهبران سازمان‌ها طرفدار جمع شدن این سیستم هستن ولی شاید اراده‌ش کم‌رنگه.
کمی هم از QA: در دو شرکتی که بنده قدیم‌ترها کار می‌کردم (خارج از ایران) تیم QA داشتیم و مدلش خیلی ناکارآمد بود. اون مدل رو امروز هم در برخی شرکت‌ها می‌بینم. در عوض در شرکت دیگرم (گوگل) در ۱۰ سال گذشته و میان ده‌ها تیم، هیچ‌جا تیم یا عنوان QA ندیدم، جز یک مورد که خواهم گفت. مسولیت QA («اطمینان از کیفیت») به عهده‌ی خود تیم توسعه‌ست.
اما ... اتفاقا تیم‌هایی هستن با تمرکز بر تست، ولی کارشون «تست کردن و bug زدن» (شکل سنتی QA) نیست بلکه توسعه ابزار و زیرساخت تست است - تست‌هایی برای اجرای خودکار در فرایندهای CI و انتشار. اگر هم گاهی تست‌هایی دستی انجام بشه، معمولا کی داره انجام می‌ده؟ خود تیم توسعه (برای مثلا debug). تعریف انواع testهای لازم روی اون زیرساخت‌ها رو کی انجام می‌ده؟ خود تیم توسعه. امیدوارم تفاوت دو رویکرد مشخص باشه.
این تیم‌ها عضو زیرسازمانی با نام بهره‌وری مهندسی/EngProd هستن. تفاوت رویکرد از نام‌گذاری‌ها هم مشخصه: تیم «اطمینان از کیفیت» (QA) یا تیم «بهره‌وری مهندسی» (توانمندسازی تیم توسعه برای اطمینان از کیفیت). تست و اطمینان از کیفیت، یک بخش ذاتی از فرایند توسعه‌ست، و برای «بعدا» و «تیم دیگه» نیست، ولی مدل سنتی QA به اون سمت سوق می‌ده.
اما اون مورد که QA داشت چی بود؟ تیم‌هایی که device می‌ساختن می‌دادن دست کاربر. تیم QA، کارهایی که هیچ‌رقمه نمی‌شد ساخت‌یافته تست کرد رو انجام می‌داد، مثلا واقعا باز کردن جعبه و امتحان تجربه‌ی کاربر در setup. اون تیم‌های QA هم در سطحی پایین‌تر از تیم‌های مهندسی بودن؛ استخدام غیررسمی با دستمزد کمتر چون اصلا جنس کارشون متفاوته. حتی خیلی دسترسی‌ها رو نداشتن و ما اذیت می‌شدیم یک image بهشون برسونیم تست کنن.
منظور قطعا این نیست که کلا دوستان QA این سطح‌ان! مدل متفاوته. منظور اینه که بهتره بریم به سمت توانمندسازی تیم توسعه، و تست از توسعه جدا نشه مگر مجبوریم.
یک مدل ناکارامد دیگه اینه که PM چون درگاه بین توسعه و کاربر دیده می‌شه، می‌شه مسؤل تست و QA. این درست نیست. اطمینان از رسیدن محصول متعالی به دست کاربر، وظیفه‌ی (همه و مخصوصا) تیم توسعه‌ست. PM درگیر اینه که محصول--که بی bug تحویل داده می‌شه--واقعا نیاز کاربر و بازار رو پاسخ بده.
اینجا مفهوم «مدیر تیم» و «رهبر پروژه» زیادی خلط می‌شه: گفته می‌شه کار مدیر یعنی جلو بردن پروژه‌ها! ولی یک مدل دیگه (که من ازش می‌آم) اینه که مدیر مهندسی (EM) و رهبری فنی (TL) دو نقش جداست. EM درگیر بُعد انسانی افراد (رشد دادن، تیم‌سازی، مدیریت عملکرد، …) و TL درگیر جهت‌دهی فنی به افراد و جلو بردن کار.
این دو نقش، همکاری نزدیک دارن. EM بوق نیست، قطعا درگیر بُعد فنی هست و جزییات پروژه رو می‌فهمه، ولی از جنس «دنبال کردن» و نه از جنس «جهت‌دهی». نردبان (ladder) این دو هم متفاوته: EM بیشتر حولِ همون تیم‌سازی و غیره سنجیده می‌شه و ترفیع می‌گیره و TL حول جهت‌دهی و اجرای فنی.
گاهی هم برخی تنشون می‌خاره (عموما به دلایل علاقه‌ی شخصی به جدا نشدن از بُعد فنی) و هر دو نقش رو به عهده می‌گیرن (TLM). من خودم این بودم و سخت بود. EM یا TL خالی، راحت‌تره. سیستم نردبان و ارزیابی جدید گوگل (از پارسال) هم به این سمت رفته که TLM کم و کمتر بشه.
در ایران من اصلا EM خالی ندیدم. همه TLM هستن. برخی هم فقط TL. متوجه‌ام که برخی شرکت‌ها EM تعریف کردن ولی در واقع همون TLM هست.
ضمنا TLMها مثل TLها و همکاران فردی (IC)، روی نردبان فنی‌ان. فقط در سطح‌های نردبان، یک بند کوچک هم هست که «اگر مدیر هم هستی، فلان انتظارات تیم‌سازی و غیره». وقتی اینجا همه TLMان، دو نردبان جداگانه‌ی IC و مدیر، خیلی معنی نداره.
منظور این نیست که حتما مثل مدلی که توضیح دادم EM داشته باشیم، اون هم در این قحطی نیرو. ولی TLM و TL چرا: به TL اصالت بدیم. اگر فکر می‌کنیم «مدیر = مسؤل پیشبرد پروژه»، ساختار سازمانی خار در گلو خواهد شد. فصل بعدی رو ببینید. درباره‌ی ساختار سازمانی، نقش‌ها و رابطه‌ها در گوگل، این یادداشت بهتر توضیح می‌ده.
یک مساله که برای برخی شرکت‌ها مساله بوده اینه که ساختار سازمانی و روابط مدیر-کارمند خیلی اصالت داره؛ نه به معنی رییس‌بازی بلکه به معنی محدود شدن امکان همکاری دل‌به‌خواهیِ کارمندان. لزوما بد نیست، ولی بهتره مدل متفاوت (که در زیر گفته می‌شه) هم دیده بشه و تصمیم آگاهانه گرفته بشه.
در ساختار سازمانی، تیم یعنی کسانی که زیر یک مدیر قرار می‌گیرن. یک مدل فکری هست که معتقده انجام پروژه‌ها باید همیشه یا حالا جز در موارد استثنایی، بر اساس این درخت باشه. یک مدل فکری هم هست که هر گروهی از افراد که خواستن (نامقید به درخت سازمانی) دور هم جمع بشن و کار انجام بدن.
خوبی مدل اول اینه که منظم‌تره، برای مدیران ارشد روشن‌تره از کی چی بخوان، و برای مدیران میانی هم راحت‌تره دنبال کنن هر کسی داره خوب کار می‌کنه یا نه - چون تحت شخص خودشون کار می‌کنه. مشکل این مدل اینه که توی دست و پاست. سازمان رو، به ویژه اگر کار استارتاپی و نوآوری هست، فلج می‌کنه.
در مدل دوم، یک ایده زده می‌شه (یا از بالا می‌آد)، و خیلی راحت‌تر از مدل اول انجام می‌شه. اصلا مهارت یک مهندس ارشد یا بالاتر اینه که بتونه دیگران رو برای این همکاری‌ها همراه کنه تا بتونن پروژه‌های بین تیمی انجام بدن. کارهای اثرگذارتر برای سازمان و با سرعت بیشتری انجام می‌شن. ولی در این مدل، نظم کمتره. یک یا چند نفر رهبر فنی (TL) پروژه می‌شن. ممکنه مدیر باشن یا نباشن. یک فرد می‌تونه تحت رهبری فنی کسی به جز مدیرش، کار کنه. بنابراین مدیر باید همیشه در جریان کارهای فرد با دیگران باشه تا بتونه اون رو مدیریت عملکرد کنه و در پایان فصل هم ارزیابی مستدل بنویسه: مثلا مرور کارها در جلسه‌های هفتگی ۱:۱ و هر از گاهی هم گپ با رهبر فنی مربوطه. ولی به هر حال اون مدیر، بخشی از اون پروژه نیست - و تمایلش هم همینه. کار اون مدیر از جنس در جریان بودن هست، نه جهت دادن. پاسخگوی پروژه نیست هرچند درش نیرو داره. در جلسات منظم هماهنگی پروژه شرکت نمی‌کنه.
من با مدل دوم کار کردم و طرفدارشم، ولی تکرار می‌کنم به جنس کار شرکت بستگی داره. برای من، مدیرانم همیشه به کار با بقیه تشویقم کردن و خودم هم افراد تیمم رو. در اوایل مدیر شدنم، به عنوان یک «ایراد» به من گفته شد که بچه‌هات زیادی فقط با خودت کار می‌کنن و با رهبران دیگه کار نمی‌کنن. یک ایراد!
خلاصه «ساختار سازمانی» و «ساختار تیم‌های برای پروژه‌ها»، دو درخت هستن که هم‌پوشانی زیادی دارن ولی خیلی جاها هم ندارن. به جای این که دومی (پروژه‌ای)، اولی (سازمانی) رو دنبال کنه، بهتره اولی، دومی رو دنبال کنه: یعنی اگر همکاری فرد با اون تیمِ دیگر، طولانی شد، رسما ببریمش اون تیم.
چرا؟ ساختاری که برای پیشبرد پروژه ها شکل می‌گیره خیلی پویاست - باید هم پویا باشه و اصلا هدف همینه. ولی ما نمی‌تونیم ساختار سازمانی رو با این نرخ سریع، عوض کنیم و هر شش ماه یا یک سال مدیر افراد رو با تغییر پروژه‌ها تغییر بدیم. کل رشد فرد به این بستگی داره که مدیرش، ازش تاریخچه داره: طرف تو چه مسیری اومده جلو، و رشد در چه فاکتورهایی مونده. با عوض شدن مدیر، reset می‌شه. همچنین اون رابطه انسانی خاص که به مرور زمان بین فرد و مدیر شکل گرفته و خیلی مهمه، هر بار reset می‌شه.
من گمان می‌کردم فقط گوگل/فیس‌بوک/پیروانشون، مدلِ شناورن («تیم سازمانی» کم‌رنگه) و مثلا در مایکروسافت تیم خیلی اصالت داره (بچه‌هاشون گفتن). ولی در همین توییتر از دوستان شنیدم که مثلا Azure (یک زیرسازمان جدیدشون) همون مدلِ شناوره. یعنی شاید قدیمی‌ترها هم دارن بازنگری‌هایی می‌کنن.
این که شرکت‌های FAANG و MAMAA و اینا چه‌طور کار می‌کنن، زیاد ازش صحبت می‌شه و نکات آموزنده‌ای هم برای الگوبرداری داره (اگر جنبه‌ی cargo cult و تقلید کور رو بذاریم کنار). ولی یک نکته‌ی مهم که گاهی دیده نمی‌شه اینه که هر شرکتی از کجا می‌آد؛ جنسش چیه؛ دنبال چیه. چند مثال آموزنده:
مثلا شرکت اَپل، قرارش بر مخفی‌کاریه. دسترسی به طبقاتشون برای خودشون هم کلی محدودیت داره (و این ما رو متعجب می‌کرد وقتی شرکت‌های همدیگه رو می‌گشتیم ولی به اَپل که می‌رسیدیم …). بنابراین این که ساختار سازمانی خیلی دست‌وپاگیرانه رعایت می‌شه (اگر تیم الف با تیم ب کار داره باید از زنجیره‌ی مدیریت بره بالا و بیاد پایین)، هرچند مدل سنتی و ناکارآمده، ولی برای این روحیه‌ی سازمانی (زیادی قاطی نشدن تیم‌ها) معنی پیدا می‌کنه. این شرکت اصالتا هم یک شرکت سخت‌افزاریه و برای همین برخی رویکردها درش متفاوته. این‌ها رو باید پیش از هر برداشتی در نظر داشت.
یا مثلا در مایکروسافت، مفهوم «تیم» و «مدیر» به معنی کلاسیک، پررنگه. حتی خیلی مدیرانش «دفتر» دارن و در فضای باز نمی‌شینن (چیزی که در گوگل و فیس‌بوک عجیبه). یا بیش‌کاری ارزشه، یا حداقل «عیب» نیست؛ مثلا دیده بودم بعضیا ایمیل کاری رو تنظیم می‌کردن ۸ و ۹ شب فرستاده بشه که بگن تا شب کار کردن. اینجا باید دقت کنیم که این شرکت سن‌اش چه قدره و فرهنگش در چه دوره‌ای و تحت چه رهبری شکل گرفته. حالا الان بیل گیتس مهربون شده می‌گه پشیمونه ولی در دهه‌ی ۸۰ شِمری بوده. الان ولی جناب ساتیا گویا داره می‌ترکونه. قطعا تیم به تیم فرق داره و مثلا Azure که یک زیرسازمان جدیده فرق داره، من فقط یک تصویر کلی (و شاید نادقیق) گفتم.
یا مثلا آمازون چرا اون آوازه‌ی بد رو درباره‌ی مسائل بین تیمی و تعاملات شرکت با کارمندانش داره؟ چون اصالتا از خرده‌فروشی/retail می‌آد و نه tech، و هنوز در حال پوست‌اندازیه. منظور، قضاوت شرکت‌ها نیست. واکاویِ اینه که چرا این شکلی‌ان - و هر برداشتی ازشون رو باید در کنار این پس‌زمینه‌ها دید.
گوگل هم با یک ساختارشکنی‌هایی اومد و پیشروِ یک فرهنگ‌هایی شد ولی خودش بعدا فاصله گرفت ولی آیندگانش ادامه دادن - نزدیکترینش فیس‌بوک که از خیلی جهات پیشروتر هم شد (مسطح‌تر بودن ساختار سازمانی، سریع‌تر پیش رفتن کارها، …). خیلی شرکت‌های دیگر دره‌ی سیلیکون هم همین کارو کردن. خود گوگل ولی فاصله گرفت و در چند سال اخیر یک گردش به راست زده به سمت یک شرکت سنتی کلاسیک. مثلا خیلی شفافیت‌های درون‌سازمانی کمرنگ شده، پروژه‌های نظامی برداشته، فضای فکری شده زدن از هزینه‌ها (دیگه مثال نمی‌زنم آبروریزی نشه). اصطکاک‌های زیادی هم درون خود سازمان ایجاد کرده. کارهای نوآورانه سخت شده. سلسله مراتب پررنگ شده. مهمه که اگر برداشتی از گوگل داریم، هم اصلا ببینیم گوگل دنبال چیاست و ما چی، هم ببینیم آیا اصلا گوگل قدیم یا گوگل جدید.
عقب بودن یک خوبی داره، این که جلویی‌ها رو می‌بینی و کلی سعی و خطا صرفه‌جویی می‌کنی. فقط کمی دقت و واکاوی لازمه. برداشت‌هایی که عرض شد بیشتر بر اساس اطلاعات دست دوم از دوستان و همکارانه و ممکنه اشتباه باشه. اگر موردی بود، اصلاح کنید یاد بگیریم.
