درباره‌ی ساختار سازمانی، نقش‌ها و رابطه‌ها در گوگل

ساختار سازمانی در گوگل، همان درخت استاندارد است، ولی تفسیرش یعنی نقش‌ها و رابطه‌ها، نه. همچنین دو کارراهه (career) مدیریت و مهندسی از هم جدا هستند، مانند بیشتر شرکت‌های بزرگ فناوری. ولی نه مدیر شدن، شرط رشد شغلی است و نه بودن در کارراهه/نردبان مدیریت، شرط مدیر شدن؛ خواهیم دید. به علاوه، رهبری فنی و مدیریت تیم معمولا مجزا هستند؛ نیز مدیر پروژه اگر نیاز به حضورش باشد.چرا سیستم هیأتی‌ست؟ فرق این نقش‌ها چیست و خوبی و بدی‌های این جداسازی‌های شناور چه‌اند؟ اصلا نردبان نَمَنه؟ مدیریت پروژه چه؟ ببینیم.بسیاری از این رویه‌های منعطف، امروزه در شرکت‌های مختلفی جاافتاده و گوگل در برابر بسیاری‌شان سنتی حساب می‌شود - اگر در شرکت شما چنین است این پایین بنویسید تا یاد بگیریم و استفاده کنیم. ولی در بسیاری شرکت‌ها هم نه، از جمله شرکت‌های گذشته‌ی خودم. (یعنی مقایسه‌های احتمالی در متن که «در گوگل فلان است و سنتی نیست» بر اساس این زمینه‌ست و منظور مقایسه‌ی عام و حلوا حلوا گوگل نیست.) همچنین مسلما رویه‌های گفته شده لزوما برای سازمان شما هم بهینه نیستند، بلکه هدف صرفا تبادل ایده برای ساختاربندی و مدیریت بهینه است.۱. ساختار سازمانی و آن‌چه معنی می‌دهد و نمی‌دهدساختار سازمانی را در نظر بگیرید: چند همکار فردی (ه.ف.) به یک مدیر گزارش می‌دهند، چند مدیر و ه.ف. به یک مدیر لایه بالاتر، و همین‌طور تا مدیر کل شرکت؛ ارتباط‌های خط‌چین (مدیر دوم برای فرد) هم داریم ولی نه شایع است و نه مهم. این درخت استاندارد را در ذهن نگه دارید و سراغ چند نکته برویم.۱. نه این ساختار، زنجیره‌ی فرمان است، و نه ارتباط نیرو با بقیه‌ی شرکت منوط به گذر از کانال مدیرش. خوشبختانه این نگاه امروزه در شرکت‌های فناوری بیشتر از گذشته جا افتاده.منظور از زنجیره‌ی فرمان نبودن یعنی وظایف و ایده‌ها و چالش‌ها لزوما از بالا به پایین جریان ندارد بلکه از پایین به بالا و در عرض و قطر و غیره هم جریان دارد؛ محدود کردن جریان ایده‌ها به یک قالب شابلونی خاص، رویکرد سنتی و ناکارایی‌ست. توجه کنید که این الگو کاملا به جنس کار تیم که چه میزان نوآورانگی دارد یا ندارد بستگی دارد.منظور از منوط به کانال مدیر نبودن یعنی اگر کسی ایده‌ای یا نظری یا اعتراضی برای مطرح کردن با مدیران لایه‌های بالاتر یا با تیم دیگر داشت، قرار نیست حتما از کانال مدیرش رد شود؛ اصلا لازم نیست قبلش به او بگوید مگر به کمکش نیاز باشد. این نکته باید بدیهی باشد ولی خوب خلافش را زیاد دیده‌ام.۲. در یک رسم رایج در بسیاری تیم‌ها، نیروها علاوه بر این که با مدیر مستقیم‌شان جلسه‌ی ۱:۱ هفتگی دارند، با مدیرِ مدیرشان هم جلسه‌ی ۱:۱ ماهیانه یا فصلی دارند (مثلا بنده اخیرا از مدیرم شنیدم فلان نیروی تیمم دغدغه‌ی فلان در کارش دارد که در جلسه ۱:۱شان به اون گفته بود و نشان از کم‌کاری بنده بود و باید حواسم بیشتر باشد)، یا اصلا با تیم‌های دیگر جلسه‌ها و تبادل‌ها دارند بدون دخالت مدیر.نکته‌ی فرعی: یکی از دلایل این ارتباط‌ها، به قول منابع انسانی‌ها «گرده‌افشانی» است. مثلا بنده با چندین نفر از تیم‌هایی که اصلا پروژه‌ی مشترک نداریم جلسه‌های دیر به دیر ولی منظم دارم. گپ می‌زنیم تا در جریان کار هم باشیم و ایده بزاییم.۳. ساختار کار کردن افراد با هم، لزوما محدود به ساختار سازمانی نیست. مثلا بنده در تیم پیشین با مدیر یک تیم دیگر بیشتر کار می‌کردم تا مدیر خودم، یا نیروهایی از تیم دیگر بیشتر با بنده کار می‌کردند. نمونه‌ها فراوانند. البته اگر قرار باشد در درازمدت (مثلا یک سال) چنین باشد، ساختار سازمانی بازبینی می‌شود تا نابهینگی‌ها کم شود، یعنی به نوعی ساختار سازمانی با ساختار کاری تطبیق داده می‌شود - مسلما منوط به ملاحظات سرشمار/headcount و غیره. خلاصه ساختار کاری، محدود سفت و سخت به ساختار سازمانی نیست؛ این رویکرد، سنتی و ناکاراست.نکته‌ی فرعی: این انعطاف، جدا از مقوله‌ی پروژه‌های ۲۰٪ای است. در آنجا نیرو می‌تواند ۲۰٪ از زمانش را صرف پروژه‌ی کاملا دلخواه و بی‌ربط کند و اصلا معمولا از زیرسازمانِ دیگر است.۴. بخش دیگری از اشتباه نگرفتن ساختار سازمانی با زنجیره‌ی فرمان، این است که (از شعارهای گوگل) هر کس می‌تواند هر کس در هر رده‌ای را (محترمانه) به چالش بکشد: درستی و نادرستیِ خودِ حرف مهم است و نه رده‌ی فرد گوینده و گیرنده. البته این شعار در عمل ملاحظاتی دارد و رده‌ها پشمِ پشم نیست، یعنی میزان بحث شما با هم‌تیمی‌تان با بحثتان با مدیر چند لایه بالاتر فرق دارد. ولی مثلا یک ناظر بیرونی در یک جلسه‌ی بحث احتمالا نتواندتشخیص دهد کدام‌یک زیردست و کدام بالادست است - این هم از سنّت‌شکنی‌هایی‌ست که شرکت‌های فناوری درش پیشرو بوده‌اند.مثال: بنده اخیرا با مدیر زیرسازمان‌مان (چند رده بالاتر از بنده) اختلاف نظر پیدا کردم و مشخصا توضیح دادم چرا اشتباه می‌کند، دو سه سری رفت و برگشت. این امکان، بخش پسندیده‌ای از فرهنگ سازمان است. ولی حالا در یک مورد حرف خودش را تکرار می‌کرد و بنده -- در تلاشی بین ایده‌آل‌گرایی و سیاست‌ورزی -- به جای افتادن در دور باطل بحث با این مدیر رده بالا که جالب نمی‌بود یا بی‌خیال شدن که برای سازمان بهینه نمی‌بود، از کارگردان (director) بالادستم که مدیر خودم هم هست خواستم تا به بحث ورود کند و حالا انشالله که طرف می‌پذیرد. البته چنین مواردی، معمول نیست و برای مثال عرض شد. حالا شاید هم نپذیرد. بخش دیگری از فرهنگ سازمانی، «مخالفم ولی متعهدم» (disagree but commit) است چون به هر حال گاهی پس از همه‌ی گفتگوها هم باز همه هم‌نظر نمی‌شوند و بالاخره باید یک تصمیم نهایی گرفته شود. ولی عرض کردم، در کمترِ موارد به اینجا می‌رسد.مثال: دوستی داشتم که (با خنده) تعریف می‌کرد در همان اوایل و به عنوان یک تازه‌کار، رفته بود در یک جلسه با رهبران ارشد آن حوزه، و کُل جلسه با آن‌ها کل‌کل می‌کرد که اشتباه می‌کنند. بعدتر چند بار این رفتار را تکرار کرده بود و از مدیرش بازخورد گرفته بود که نکن.مثال: نیروی تازه‌کاری داشتیم که خیلی شاخ بود و سر جزییات با بنده کل‌کل‌ها می‌کرد و حتی صدایش بالا می‌رفت. تمرین خوبی برای ساز و کار حل اختلاف (conflict resolution) بود و اگر فرصت بود و عُمری بود بعدا می‌نویسم.این رویه‌های فرهنگی برای خیلی شرکت‌ها بدیهی نیست و امیدوارم جرقه‌ای برای بازبینی باشد.۲. مدیر، همکار فردی (ه.ف.) و نردبان‌هابه کسی که مدیر کسان دیگری نیست، همکار فردی (individual contributor) گفته می‌شود یا به اختصار ه.ف.برای مدیر شدن باید از یک سطحی بالاتر بود ولی برعکسش نه، یعنی به ترجیح شخصی می‌شود تا سطح‌های بسیار بالا رفت ولی ه.ف. ماند و مدیر نشد - بالاترینش در گوگل جناب Sanjay Ghemawat است که شاید بشناسید. مدیر شدن، نه شرط لازم برای پیشرفت شغلی و ترفیع در نردبان است (امثال Sanjay در انواع رده‌ها فراوانند) و نه شرط کافی - گاهی حتی به ضرر پیشرفت است.نردبان چیست؟ جدولی‌ست که برای نیروهای هر سطح (مثلا «مهندس ارشد»)، رفتارها و انتظارها را تبیین می‌کند. نیروها بر اساس شایستگیِ قابل اثبات (نه بر اساس تعداد سال سابقه) ترفیع گرفته و از این نردبان بالا می‌روند. کلیدی‌ترین و محوری‌ترین معیار برای ارزیابی افراد، تعریف‌ها در نردبان است. جزییات بیشتر از نردبان: این یادداشت؛ از ارزیابی: این یادداشت. مفهوم نردبان را در ذهن نگه دارید.کارراهه مهندسی و مدیریت، دو نردبان جدا دارند. البته انتظارهای تعریف شده از سطح X در نردبان مهندسی با سطح X در نردبان مدیریت، هم‌پوشانی‌هایی دارند، مثل هدایت راهبردیِ تیم/زیرسازمان/سازمان، ولی متفاوت‌اند. مثلا از مدیرها مشخصا انتظارهایی برای هدایت و مربی‌گری نیروها برای رشد شغلی یا مدیریت پویایی تیمی (بالا و پایین‌های ارتباطات افراد و تیم‌ها) می‌رود، ولی از مهندسان، انتظارهایی در تعریف و رهبری پروژه‌ها.مهاجرت از نقش/نردبان مهندسی به نقش/نربان مدیریت، لازمه‌ی مدیر شدن «نیست». برخی مدیران (از جمله بنده)‌ ترجیح می‌دهند در نردبان مهندسی بمانند و با معیارهای این نردبان ارزیابی شوند و بالا روند. حتی هزینه‌ی اضافه دارد و شاید پیشرفت را کُنْد کند. پس چرا؟ برای دور نشدن از دنیای فنی. به قول تُرک‌ها «قان چَکیر».در درخت سازمانی، تا لایه‌های بالا هم ه.ف.ها (نامدیرها) هستند، یعنی در همه‌ی لایه‌های درخت، nodeهای برگ هست. آن‌ها عموما ه.ف.های ارشد به بالا هستند که (احتمالا علی‌رغم درخواست رهبری زیرسازمانشان) ترجیحشان ه.ف. ماندن است، و طبیعتا با توجه به سطح‌شان بیشتر درگیر مساله‌های راهبردی (هدف‌گذاری) هستند تا مساله‌های تاکتیکی (اجرای اهداف؛ طراحی و کُد). مثل Sanjay. خلاصه برخی افراد، قابلیت سرآمد شدن دارند ولی حوصله‌ی مسئولیت مدیریت ندارند و باید بتوان از ظرفیت‌های رشدشان استفاده کرد.۳. مدیریت و رهبری فنی از دیگر جداسازی‌های سودمند در گوگل، جدایی نقش رهبری فنی (TL) از نقش مدیریت است. گاهی این دو نقش دو شخص متفاوت‌اند و گاهی یک شخص (بنده این هستم و می‌توانم بعدا از خوبی‌ها و بدی‌های این انتخاب بنویسم)، که به او مدیر-رهبر فنی (TLM) گفته می‌شود. هر دو مدل شایع‌اند.خوبی این جداسازی چیست؟ مدیریت و رهبری فنی، هرچند هم‌پوشانی دارند، دو تمرکز متفاوت می‌طلبند. رهبری فنی یعنی نیاز به عمق و سرآمدیِ فنی و حل مساله و (در رده‌های بالاتر) بینش راهبردی و جهت‌دهی به تیم‌ها. اما مدیریت یعنی «تمرکز بر افراد»، مسائل پویایی تیم و چانه‌زنی برای کسب منابع (نیرو) - همچنین دلداری دادن‌هایی که در این یادداشت اشاره شد! بسیاری کارها هم مشترک انجام می‌شوند (مثل اولویت‌بندی و تخصیص نیرو)‌ و در بسیاری مواقع هم اصلا مرزها خاکستری‌اند، ولی امیدوارم تفاوت در تمرکز، روشن باشد.بدی این جداسازی چیست؟ هم‌پوشانی این دو نقش، کم نیست و نیازمند هم‌گامی نزدیک بین مدیر و رهبر فنی‌ست، که گاهی آسان نیست. همچنین جدایی مدیر از جزییات فنی، هرچند گاهی ناگزیر، ولی به هر حال ایده‌آل نیست و همه یک مدیرِ درگیر در جزییات فنی را ترجیح می‌دهند.در لایه‌های بالاتر، خوبی‌های این جداسازی روشن‌تر است. مثلا کارگردان (director) ما، در فضای مدیریت و روی نردبان مدیریت است و با ۱۰۰ نیروی زیر دست، تنها امکان درگیری حدودیِ فنی دارد و نه عمیق. ولی شخص دیگری هم‌سطح او در زیرسازمان ما هست که در فضای فنی‌ست و اصلا ه.ف. است (مدیر نیست) - و شخصی‌ست کاردرست که همه‌ی گوشه‌های مهم سیستم‌های پیچیده‌ی ما را می‌شناسد.در لایه‌های پایین‌تر و تیم‌های کوچک‌تر، خوبی‌های این جداسازی کم‌رنگ‌تر است. مثلا پیش‌تر، تیم ما یک مدیر داشت و دو رهبر فنی، و خوب نقش مدیر خیلی پررنگ نبود. اولا این جداسازی برای تیم آورده‌ی چندانی نداشت و کمی نابهینگی داشت؛ می‌توانید تصور کنید جلسه‌های هفتگی ۱:۱ نیروهای متوسط به پایین (که سرشان به یک کار خاص است) با مدیری که در عمق فنی نیست چگونه می‌گذرد: چیز خاصی ندارند جز «همه چی خوبه؟ آره خوبه. روی چی کار می‌کنی؟ روی فلان. کمی توضیح. خوب ایوَل. خداحافظ تا هفته‌ی بعد.». دوما برای خود مدیر هم ایده‌آل نیست: مدیرِ خالی برای تیمِ نه چندان بزرگ، به اندازه‌ی یک آدم تمام‌وقت کار نمی‌برد و حوصله‌اش سر می‌رود ولی در چه سطحی وارد کار فنی شود؟ پایین‌تر از رهبری فنی؟ موازی او؟ روشن نیست. (آن مدیر خاص هم خیلی تلاش کرد وارد کار فنی شود ولی چون از بیرون آمده بود و زیست‌بومِ زیرسازمان ما منحنیِ یادگیریِ تیز و طولانی دارد، نتوانست سری در سرها شود و افسرده شد و سر سال رفت به یک تیم دیگر.)در سازمان بزرگ ما، برای خود نقش رهبری فنی هم گونه‌هایی تعریف شده، مثلا رهبر فنیِ یک زمینه/محصول بزرگ و بالادستِ چند رهبر فنی دیگر، uber TL خوانده می‌شود و رهبر فنی یک حوزه‌ی بزرگ، area TL که بیشتر برای نقشش در تصمیم‌گیری‌ها مجزا شده. اگر سازمان کوچکی دارید به این قرتی بازی‌ها نیاز نخواهید داشت.مدیرانِ برآمده از خود تیم‌های مهندسی، عموما در موقعیت بهتری برای موفقیت و برای مقبولیت قرار دارند تا مدیرانِ از بیرون آمده - به تجربه‌ی خودم از هم مدیر داشتن و هم مدیر بودن عرض می‌کنم. حتی مثلا یک بار در یکی از جلسه‌های فراگیر دفتر ما این پرسش را مطرح شد که اصلا چرا از بیرون مدیر می‌آورید وقتی این همه نیرو با ظرفیت مدیر شدن در داخل هست. ولی پاسخ روشن است: سیستم بسته، سیستم محتوم به میرایی‌ست.۴. مدیر پروژه/برنامهاین فصل چندان ربطی به سه فصل پیش ندارد جز این که یک ر دارد ولی چون پرسش‌های مدیریت پروژه‌ای زیاد از دوستان گرفته‌ام، این ضمیمه‌ی کوچک را به تَنگ این مطلب زدم. scrum کار می‌کنیم؟ مدیر پروژه‌ی جداگانه داریم؟ چه کار می‌کند؟مدیریت پروژه نه تنها در گوگل بلکه در هر شرکت بزرگی که دیده یا شنیده‌ام، کاملا خودمختارانه است. منطقی هم هست. چرا اجبار به یک‌دست شدن؟! در گوگل هر تیمی به شکل دلخواه‌اش: یکی با kanban و یکی نمودار گانت (نامعمول) و یکی اصلا با دفتر کاغذی؛ یک تیم برای بیشتر کارها issue/ticket می‌زند (نامعمول) و یکی نه؛ یک تیم scrum کار می‌کند (نامعمول) و یکی نه. این رویکر بسیار کارآمدتر از اجبارِ سربارهای بوروکراتیک (حتما issue زدن و ...) یا دخیل کردن اشخاص/تیم‌ها/دُکان‌دارهای غیرفنی برای پی‌گیری پیشرفت است در حالی که ضروری نیست، رویه‌ای ناکارا که در برخی جاها دیده‌ام. مدیریت پروژه در سطح یکی دو تیم و ۱۰ ۲۰ نفر، توسط خود رهبران فنی انجام می‌شود.ولی در رده‌ی پروژه‌های بزرگ‌تر و به ویژه «بین تیمی»، نیاز به مسولیت تخصصی‌ست و نام این نقش در گوگل «مدیر [فنی] برنامه» (PgM/TPgM) است. مسولیت‌های این نقش --به جز پی‌گیری و پی‌گیری و پی‌گیری-- شامل:مدیریت ارتباطات درونی و بیرونی درباره‌ی پیشرفت،نوشتنِ نوشتنی‌ها (مثلا مستند‌ها و دستور/صورت جلسه‌های برنامه‌ریزی) و کشیدنِ کشیدنی‌ها (مثلا جدول و نمودارهای مربوط به برنامه‌ریزی)،تشخیص موانعِ پیشرفت و پیدا کردن مسول/صاحب و پی‌گیری،(مهم) اطمینان از گم نشدن کارها در فاصله‌ی بین تیم‌ها،(مهم) کشف deadlockها (مثلا این منتظر آن است و آن منتظر این) و حل آن‌ها،کمک به مهندسان و رهبران فنی برای رهبری پروژه در مقیاس تیم خودشان (مثلا نوشتن برنامه‌ی عمل از روی OKRها)،و این دست است. برای همین کار هم هر گوشه یک شکل است؛ یکی با smartsheet و یکی صرفا با spreadsheet سنتی.توضیح: وقتی گفتم این کارها توسط خود رهبران فنی انجام می‌شود، اشتباه برداشت نشود که مدیر پروژه‌ها (به قول ما: مدیر برنامه‌ها) تخصص خاصی ندارند و هر کس به طور پیش‌فرض توانا به عهده‌داریِ این مسولیت‌هاست. این مهارت‌ها مهم‌اند و یکی از عامل‌های تعریف‌کننده‌ی مدیریت خوب. منظور این بود که جداسازی این وظایف از رهبری فنی، هزینه و فایده دارد --از یک سو مدیریت کارهای بالا توسط کسی که فنی نیست و از یک سو محدودیت وقت و بینش مهندسان فنی-- و صرفا مرز ما برای پرداخت هزینه‌اش کمی بالاتر از جاهای دیگری‌ست که دیدم.تکرار پایانی: مسلما منظور این نیست که این رویه‌ها لزوما خوبند یا برای سازمان شما هم بهینه‌اند. صرفا چند نقطه‌داده برای تبادل ایده است و قضاوت‌ها هم از دید محدود بنده‌اند.