Debugging Teams

توضیحات

با بیش از بیست سال سابقه در مهندسی نرم‌افزار و رهبری تیم‌های کوچک و بزرگ، Brian Fitzpatrick و Ben Collins-Sussman دانش و تجربه‌ای منحصر به فرد در راستای موفقیت کار گروهی به دست آورده‌اند. آن‌ها در عمل به این نتیجه رسیده‌اند که مهارت‌های انسانی افراد در همکاری با یکدیگر به اندازه توانایی‌های فنی در موفقیت یک محصول نقش دارند. آن دو، تجربه ارزشمند خود را در قالب یک کتاب سرگرم کننده ولی بسیار آموزنده تحت عنوان Debugging Teams با دیگران به اشتراک گذاشتند. این کتاب به سرعت جای خود را بین مهندسین پیدا کرد و رهبران و مدیران زیادی آموزه‌های این کتاب را به کار گرفته و به اعضای تیمشان پیشنهاد دادند.

نظر

کتابی مفید در رابطه با کار کردن در شرکت هم به عنوان مدیر و هم به عنوان یک توسعه دهنده. بررسی مشکلات موجود در تیم‌ها و ارائه راه حل درباره آنها. پیشنهاد مواردی که به عنوان مدیر باید انجام داد و همچنین مواردی که نباید انجام داد.

نظر

• امتیاز : 09/10
• به دیگران توصیه می‌کنم : بله
• دوباره می‌خوانم : بله
• ایده برجسته : توسعه‌ی نرم‌افزار یک ورزش تیمی است؛ برای موفقیت، باید رفتار خودت را حول سه اصل «تواضع، احترام، و اعتماد» بازتنظیم کنی.
• تاثیر در من : چگونگی بهتر مدیریت کردن روابط انسانی در تیم‌های نرم‌افزاری، و این‌که چطور این روابط می‌توانند بهره‌وری را به‌شکل چشمگیری بالا ببرند.
• نکات مثبت : واقعا کاربردی بودن کتاب؛ پر از مثال‌های واقعی و داستان‌های جذاب از تجربه‌ی نویسنده‌ها در Google و جاهای دیگر؛ و این‌که به‌جای شعارهای کلی، رفتارهای کاملاً عملی را آموزش می‌دهد.
• نکات منفی : -

مشخصات

• نویسنده : Brian Fitzpatrick, Ben Collins-Sussman
• انتشارات : O’Reilly Media
• صفحه مشخصات : goodreads

بخش‌هایی از کتاب

در این بلوک می‌رویم سراغ فصل ۱ تا جایی که سه ستون HRT و «HRT in Practice» شروع می‌شود.

۱. مسئله از «خودت» شروع می‌شود

فصل ۱ با این ایده شروع می‌کند که وقتی بحثِ ریسک‌های اجتماعی توسعه‌ی خلاق است، تنها متغیری که واقعاً رویش کنترل کامل داری «خودت» هستی.

• انسان‌ها ذاتاً پر از باگ‌اند؛ قبل از این‌که باگ‌های هم‌تیمی‌هایت را ببینی، باید باگ‌های خودت را ببینی.
• هدف فصل: کمک کند واکنش‌ها، رفتارها و نگرش‌های خودت را ببینی و اصلاح کنی تا انرژی کم‌تری صرف درگیری‌های انسانی و انرژی بیش‌تری صرف نوشتن کد خوب شود.

ایده‌ی کلیدی فصل: توسعه‌ی نرم‌افزار یک «Team Sport» است؛ برای موفقیت، باید رفتار خودت را حول سه اصل «تواضع، احترام، و اعتماد» بازتنظیم کنی.

۲. Help Me Hide My Code – ناامنیِ رایج برنامه‌نویس‌ها

نویسنده‌ها یک الگوی تکرارشونده از کارشان روی Google Project Hosting دیدند:

• «می‌شود شاخه‌های خاص Subversion را روی Google Code مخفی کنیم؟»
• «می‌شود پروژه‌ی متن‌باز اول private باشد بعد public شود؟»
• «من می‌خواهم همه‌ی history پاک شود که انگار کد از اول این‌شکلی بوده.»

تم مشترک: ناامنی.

• ترس از این‌که دیگران، کار در حال پیشرفت را ببینند و قضاوت کنند.
• کسی دوست ندارد روی چیزی که هنوز ناتمام است نقد شود.
• نتیجه: برنامه‌نویس می‌خواهد تا لحظه‌ی «شاهکارِ بی‌نقص» کد را پنهان کند.

نویسنده‌ها این را نه فقط یک واکنش انسانی طبیعی، بلکه «علامتِ یک مشکل عمیق‌تر» در فرهنگ توسعه می‌دانند.

۳. افسانه‌ی «برنامه‌نویس نابغه»

۳.۱. قهرمان‌سازی فردی

کتاب مثال مایکل جردن و Chicago Bulls را می‌زند: رسانه‌ها تیم را نادیده می‌گیرند و تمام فوکوس را روی «ستاره» می‌گذارند.

در دنیای نرم‌افزار هم همین است:

• Linus Torvalds، Richard Stallman، Bill Gates، Steve Jobs… به‌عنوان قهرمانان تک‌نفره دیده می‌شوند.
• روایت رایج: «لینوس به تنهایی Linux را نوشت.» درحالی‌که او فقط یک هسته‌ی اولیه نوشت و اصل کار، کار صدها نفر بود؛ هنر واقعی او «رهبری و هماهنگی» بود.
• Unix هم محصول یک تیم در Bell Labs بود نه فقط Thompson و Ritchie.
• Stallman Emacs اولیه را نوشت، اما بقیه‌ی ecosystem را صدها نفر دیگر ساخته‌اند.

در بسکتبال هم جردن بدون تیم و بدون مربی‌ای مثل Phil Jackson قهرمان نمی‌شد؛ Jackson عمداً یک «dream team» ساخت و سیستم را حول آن چید.

۳.۲. فانتزی Batcave

نویسنده‌ها فانتزی رایجِ توسعه‌دهنده را این‌طور توصیف می‌کنند:

• ایده‌ی ناب به‌سراغت می‌آید؛
• در Batcave خودت برای هفته‌ها/ماه‌ها disappear می‌کنی و implementation بی‌نقص را می‌نویسی؛
• بعد، محصول را «Release» می‌کنی و همه از نبوغت شگفت‌زده می‌شوند؛ شهرت و ثروت می‌آید.

این فانتزی، همان «Genius Programmer» myth است.

واقعیت:

• اولاً «نابغه» بسیار نادر است.
• ثانیاً حتی نوابغ هم باگ دارند؛ ایده و مهارت کافی نیست؛ outcome محصول به شدت به «چقدر خوب با دیگران کار می‌کنی» وابسته است.

۳.۳. ناامنی به‌عنوان ریشه‌ی افسانه

ترس از این‌که «اگر کار نیمه‌کاره‌ام را ببینند می‌فهمند نابغه نیستم» باعث می‌شود توسعه‌دهنده‌ها:

• از نمایشِ زودهنگام کد فرار کنند؛
• هر نقدی را تهدید به «افشا شدن احمق بودن» تلقی کنند.

نقل قول وبلاگی که می‌آورند دقیقاً همین را می‌گوید: «حس می‌کنم اگر قبل از تمام شدن کسی کد را ببیند فکر می‌کند احمقم.»

نویسنده‌ها صریح می‌گویند:
در این مورد «هر جور دوست داری کار کن» جواب نیست؛ پنهان‌کاریِ سیستماتیک، اشتباه استراتژیک است.

۴. «پنهان‌کاری مضر است» – چرا کار در غار خطرناک است؟

۴.۱. ریسک فنی و یادگیری

داستان دوچرخه و تغییر دنده:

• یک نفر در گاراژ، ماه‌ها روی مکانیزم جدید کار می‌کند، هیچ‌کس را در جریان نمی‌گذارد.
• همسایه‌اش، با کمک بچه‌های مغازه‌ی دوچرخه، در همان زمان یک مکانیزم مشابه اما بهتر می‌سازد و لانچ می‌کند.
• وقتی prototype مخفی خودش را نشان می‌دهد، معلوم می‌شود اشکال‌های ابتدایی‌ای دارد که اگر از هفته‌ی اول کسی دیده بود، به‌سرعت fix می‌شد.

نتیجه‌ها:

• تا وقتی ایده را در «حالت خام» با دیگران تست نکرده‌ای، نمی‌دانی:
  • ایده قبلاً حل شده یا نه؛
  • مسیرت غلط است یا درست؛
  • implementation اولیه‌ات کجاهای بنیادی ایراد دارد.
• هرچه زودتر بازخورد بگیری، ریسک ماشین‌زدن به دیوار پایین‌تر می‌آید (با این caveat که «Feedback زیادِ خیلی زود» هم می‌تواند مضر باشد که در فصل‌های بعدی به آن می‌پردازند).

۴.۲. Bus Factor

آن‌ها «Bus Factor» را این‌طور تعریف می‌کنند:

تعداد افرادی که باید زیر اتوبوس بروند تا پروژه کاملاً نابود شود.

اگر تنها کسی هستی که کد و طراحی را می‌فهمد:

• Bus Factor = ۱؛ پروژه با غیبت تو (ازدواج، مهاجرت، مریضی، شرکت عوض کردن) زمین می‌خورد.
• اگر دو نفر درک عمیق دارند، Bus Factor = ۲ و قوی‌تر است؛ یک تیم کوچک آن را بالا می‌برد.

پنهان‌کاری آگاهانه، Bus Factor را پایین نگه می‌دارد و پروژه را شکننده می‌کند.

۴.۳. سرعت و Feedback Loop

کار انفرادی معمولاً کندتر از چیزی است که دوست داری اعتراف کنی؛ وقتی گیر می‌کنی، ساعت‌ها/روزها در باتلاق می‌مانی؛ درحالی‌که یک هم‌تیمی باتجربه در ۳۰ ثانیه ممکن است بگوید: «ببین، این‌جا فلان چیز را جا انداختی.»

نویسنده‌ها analogy کامپایلر را می‌آورند:

• هیچ‌کس ۱۰هزار خط کد نمی‌نویسد و بعد برای اولین‌بار Compile بزند.
• ما در حلقه‌های خیلی کوتاه کار می‌کنیم: تابع جدید → Compile → Test → Refactor → Compile.

مغز ما برای feedback سریع تنظیم شده است. در سطح پروژه هم همین‌طور:

• Requirements عوض می‌شوند؛
• موانع سیاسی یا طراحی پیدا می‌شوند؛
• محیط تغییر می‌کند و چیزی که یک سال پیش relevant بود ممکن است امروز بی‌اهمیت باشد.

«چند جفت چشم بیش‌تر» نه فقط Bug را کم‌عمق می‌کند، بلکه کمک می‌کند پروژه روی ریل بماند و با محیط update شود؛ کسانی که در غار کار می‌کنند ممکن است بعد از مدت‌ها با محصولی بیرون بیایند که بازار و جهان مدت‌هاست از آن عبور کرده است.

۴.۴. بحث Office و Open Space

یک اینسرت جالب هم دارند درباره‌ی فضای فیزیکی تیم:

• افسانه‌ی قدیمی: برای بهره‌وری بالا، حتماً باید «دفتر دربسته‌ی شخصی» داشته باشی تا در سکوت کد بزنی.
• دیدگاه نویسنده‌ها: برای اکثر مهندس‌ها، این نه لازم است نه لزوماً مفید؛ چون نرم‌افزار را تیم می‌نویسد و «کانال پرظرفیت و کم‌اصطکاک به بقیه‌ی تیم» تقریباً به‌اندازه‌ی خود اینترنت مهم است. اگر ساعت‌ها بدون تعامل، روی چیز اشتباه کار کنی، آن سکوت به ضررت است.
• اما Open Space افراطی (۵۰–۱۰۰ نفر در یک سالن) هم مزخرف است؛ باعث می‌شود همه از ترسِ اذیت کردن بقیه، سکوت کنند. نتیجه: نه تمرکز داری، نه ارتباط درست.

پیشنهاد آن‌ها:

• تیم‌های ۶ تا ۱۲نفره در اتاق‌های کوچک/بزرگ مجزا، که مکالمه‌ی خودجوش ساده و غیرخجالت‌آور باشد.
• Protocolهای ساده برای «interrupt»: مثلاً call کردنِ «breakpoint Mary» و گرفتن ack/NACK؛ یا استفاده از هدفون، توکن روی مانیتور و … برای سیگنال‌دادن.

جمع‌بندی این بخش:
کار تنهایی ریسک فنی، ریسک محصولی، و ریسک انسانی را بالا می‌برد. بزرگ‌ترین ترس تو نباید این باشد که «دیگران ایده‌ام را می‌دزدند» یا «می‌فهمند بی‌نقص نیستم»، بلکه این باشد که «ماه‌ها روی چیزی کار کنم که یا اشتباه است یا بی‌ربط».

۵. همه‌چیز درباره‌ی تیم است

نویسنده‌ها نتیجه می‌گیرند:

• قهرمان‌های تک‌نفره‌ی واقعی خیلی نایاب‌اند؛ و همان‌ها هم دستاوردهایشان را «در خلأ» به‌دست نیاورده‌اند؛ همیشه یک جرقه بوده و بعد یک تلاش تیمی قهرمانانه.
• هدف اصلی، ساختنِ «تیم سوپراستار» است، نه تبدیل شدن به قهرمان تنها.

فرمول‌شان را این‌طور خلاصه می‌کنند:

توسعه‌ی نرم‌افزار یک ورزشِ تیمی است.

این جمله را عمداً تبدیل به مانترا می‌کنند، چون دقیقاً با فانتزی درونیِ «Genius Programmer» در تعارض است.

اگر در «لانه‌ی هکر»ت نابغه باشی ولی نتوانی با دیگران ویژن را توزیع و مهندسی را تقسیم کنی، نمی‌توانی دنیا را عوض کنی یا میلیون‌ها کاربر را خوشحال کنی.

۶. سه ستون (Three Pillars): HRT

برای این‌که از «درک تیمی بودن کار» برسیم به «ساختن تیم عالی»، نویسنده‌ها سه اصل را به‌عنوان زیرساخت تمام تعامل‌های سالم معرفی می‌کنند: Humility, Respect, Trust = HRT.

• Humility (تواضع):
  • مرکز عالم نیستی؛ نه همه‌چیز را می‌دانی، نه خطاناپذیری.
  • برای رشد و بهبود خودت باز هستی.
• Respect (احترام):
  • به همکارانت به‌عنوان «انسان» اهمیت می‌دهی، نه صرفاً «منبع تولید کد».
  • توانایی‌ها و دستاوردهایشان را جدی می‌گیری.
• Trust (اعتماد):
  • باور داری دیگران competent‌اند و معمولاً کار درست را می‌کنند.
  • می‌توانی در زمان مناسب «فرمان را بدهی دست آن‌ها» و واقعاً ول کنی.

تز قوی‌شان:

تقریباً هر تعارض اجتماعی را می‌توان در نهایت به نبود یک یا چند مورد از این سه تا برگرداند.

ساختار کتاب هم حول همین است:

• فصل ۱: کار کردن روی خودت و جا انداختن HRT در رفتار شخصی‌ات.
• فصل ۲: ساخت فرهنگ تیمی بر پایه‌ی HRT.
• فصل ۳ و بعد: کار با آدم‌های بیرون تیم، سازمان، و نهایتاً کاربران، باز هم با همین سه ستون.

---

در این بلوک می‌رویم سراغ بخش «HRT in Practice» از فصل ۱؛ یعنی جایی که نویسنده‌ها تواضع، احترام و اعتماد را به رفتارهای کاملاً عملی ترجمه می‌کنند.

۱. «Ego» را کم کن

هیچ‌کس دوست ندارد با کسی کار کند که دائماً مثل مهم‌ترین آدمِ اتاق رفتار می‌کند. حتی اگر واقعاً ارشدترین و باتجربه‌ترین نفر تیم باشی، اگر این را مدام به رخ بکشی، تیم را ضعیف می‌کنی.

چند نشانه‌ی Ego بالا:

• همیشه می‌خواهی «اولین» یا «آخرین» نفر باشی که در هر بحثی حرف می‌زند.
• روی هر جزئیات ریز باید کامنت بدهی و نظر داشته باشی.

نویسنده‌ها بین «اعتماد به نفس» و «خودبزرگ‌بینی» تمایز می‌گذارند:

• اعتماد به نفس لازم است؛ بدونش مسئولیت نمی‌گیری.
• اما راه درست، ساختن یک غرور جمعی تیمی است، نه غرور فردی؛ چیزی شبیه فرهنگ Apache که به‌شدت به «هویت جمعی پروژه» بها می‌دهد و آدم‌هایی را که صرفاً دنبال self‑promotion هستند پس می‌زند.

مثال Hamming: John Tukey فوق‌العاده بود، ولی عمداً خیلی راحت و ساده لباس می‌پوشید؛ این یعنی حاضر بود «قیمتِ کمی‌جدی‌گرفتن در نگاه اول» را بدهد، تا در عوض در بلندمدت راحت‌تر با سیستم کار کند و با Ego نجنگد.

۲. یاد بگیر انتقاد بدهی و انتقاد بگیری

۲.۱. انتقاد دادن

داستان Joe: توسعه‌دهنده‌ای که در تیم جدید، شروع می‌کند برای کد بقیه ایمیلی Code Review فرستادن؛ با لحن محترم، اما چون تیم فرهنگ HRT نداشت و ناامن بود، چند هفته بعد مدیر به او می‌گوید «خیلی خشن و انتقادی رفتار می‌کنی، همه ناراحت شده‌اند.»

نکته‌ی نویسنده‌ها:

• در یک فرهنگ سالمِ HRT، این رفتار Joe باید «هدیه» محسوب شود، نه تهدید.
• ولی وقتی اطرافیان ناامن‌اند، باید نسبت به context حساس باشی و در introduce کردن Code Review محتاط‌تر عمل کنی.

تفاوتِ انتقاد مخرب شخصیتی و انتقاد سازنده روی خروجی:

• انتقاد شخصیتی: «تو همیشه design رو خراب می‌کنی، چرا مثل بقیه نمی‌فهمی…»
• انتقاد سازنده: مشخص، action‑able، و روی Artifact (کد، طراحی، داک) متمرکز است، نه روی ارزش آدم.

مثالِ بدی که خودشان می‌زنند:

«من کاملاً flow این متد را اشتباه می‌دانم، باید الگوی xyzzy را مثل همه استفاده می‌کردی.»

ایرادها:

• دوتایی کردن دنیا به «درست/غلط».
• رفرنس دادن به «همه» برای شرمنده کردن طرف.
• دستور دادن، نه پیشنهاد دادن.

فرم بهتر همان حرف:

«من این‌جا کمی در فهم flow مشکل داشتم؛ شاید اگر الگوی xyzzy را استفاده کنیم، فهم و نگه‌داری‌اش در درازمدت ساده‌تر شود؟»

در این نسخه:

• از تواضع استفاده کرده: «من متوجه نمی‌شوم» نه «تو غلط نوشتی».
• تغییر را به‌عنوان پیشنهادی برای «واضح‌تر شدن برای من و آینده‌ی پروژه» مطرح می‌کند، نه به‌عنوان حکم.
• اختیار رد یا قبول پیشنهاد را به خودِ نویسنده می‌دهد.

۲.۲. انتقاد گرفتن

برای گرفتن انتقاد باید دو لایه را از هم جدا کنی:

• قیمت‌گذاری روی خودت
• قیمت‌گذاری روی خرو‌جی‌ات (کد، داک، دیزاین)

تز کلیدی‌شان:

«تو، کدت نیستی.»

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

به‌صورت عملی:

• انتقاد = «هدیه‌ای که می‌توانی بپذیری یا رد کنی».
• لازم نیست روی تک‌تک نکته‌هایی که می‌شنوی حتماً action بگذاری؛ مثل مثالی که می‌زنند: دوستت می‌گوید «اسفناج دندانت گیر کرده و من از این کت و شلوارت خوشم نمی‌آید»؛ لازم است فقط اسفناج را برداری، نه این‌که لزوماً لباس عوض کنی.

۳. Fail Fast and Iterate – شکستِ زود، یادگیریِ سریع

اینجا دو ایده را کنار هم می‌گذارند:

• افسانه‌ای که می‌گوید مدیرِ ارشدی ۱۰ میلیون دلار اشتباه می‌کند، استعفا می‌نویسد، و CEO جواب می‌دهد: «من تازه ۱۰ میلیون دلار خرج آموزش تو کرده‌ام، چرا باید اخراجت کنم؟»
• شعار Google: «Failure is an option»؛ اگر هیچ‌وقت fail نمی‌کنی، یعنی کافی‌قدر risk و innovation نداری.

نمونه‌ی Google X:

• در moonshotها (ماشین خودران، Glass و …) افراد تشویق می‌شوند ایده‌های دیوانه‌وار بدهند.
• هم‌تیمی‌ها تشویق می‌شوند این ایده‌ها را هرچه سریع‌تر بترکانند؛ reward می‌گیری اگر بتوانی یک ایده را با reasoning خوب kill کنی.
• تنها ایده‌هایی جلو می‌روند که نتوانی در whiteboard با کمک بقیه آن‌ها را جدی debunk کنی.

Postmortem به‌عنوان ابزار یادگیری از شکست:

• هدفش «لیست عذرخواهی و بهانه» نیست؛ باید دقیقاً بگوید چه یاد گرفتیم و چه تغییری اعمال می‌شود.
• اصولاً باید public و discoverable باشد تا نسل بعدی دوباره همان اشتباه را تکرار نکند.

المان‌های یک Postmortem خوب:

• خلاصه‌ی کوتاه
• Timeline از کشف تا resolution
• علت ریشه‌ای
• تخمین اثر و خسارت
• Action itemهای فوری برای حل مشکل
• Action itemهای پیشگیرانه برای آینده
• Lessons Learned

۴. برای یادگیری جا باز کن

داستان Cindy: مهندس سوپراستاری که در حوزه‌ی خودش به «کمال» رسیده و بعد:

• Technical Lead می‌شود، چند تیم را می‌گیرد، mentor بقیه می‌شود، کنفرانس می‌رود، expert می‌شود.
• کم‌کم می‌فهمد دیگر چیز تازه‌ای یاد نمی‌گیرد؛ مدام در نقش «معلم» است.
• یک روز می‌بیند حوزه‌ای که روی آن expert شده، اساساً دیگر مرکز توجه صنعت نیست.

نویسنده‌ها این را نوعی local maximum trap می‌بینند:

• خیلی خوب است که در یک نقطه از landscape مهارت به قله برسی، اما اگر فقط همان‌جا بمانی، یادگیری‌ات متوقف می‌شود و از بازار جا می‌مانی.
• Ego به‌راحتی تو را قفل می‌کند: addicted می‌شوی به این‌که «همیشه باسوادترین آدم اتاق» باشی.

راه‌حل مبتنی بر تواضع:

• بعضی وقت‌ها آگاهانه خودت را در موقعیتی قرار بده که از بقیه ضعیف‌تر باشی؛ تیمی که در آن «بزرگ‌ترها» از تو جلوترند.
• uncomfortable بودن و یاد گرفتن از آن‌ها، در بلندمدت خیلی بیش‌تر از «همیشه لیدر بودن» تو را رشد می‌دهد.

۵. یاد گرفتن صبر (وقتی سبک‌ها با هم نمی‌خوانند)

داستان Fitz و Karl روی converter CVS → Subversion/Git:

• Fitz «bottom‑up» کار می‌کرد: شیرجه در کد، patch سریع، آزمون و خطا.
• Karl «top‑down» بود: می‌خواست قبل از هر تغییری، call stack و معماری را کامل بفهمد.

وقتی pair programming کردند:

• برخورد سبک‌ها تبدیل شد به دعوای جدی؛
• فهمیدند به این شکل نمی‌توانند کنار هم پشت یک کیبورد بنشینند.

اما چون:

• تاریخ مشترک طولانی داشتند،
• به همدیگر اعتماد و احترام داشتند،

با صبر و انعطاف مدل جدیدی تعریف کردند:

• با هم bug را isolate می‌کردند؛
• بعد جدا می‌شدند، Fitz از پایین، Karl از بالا جلو می‌رفت و بعد وسط راه دوباره meet می‌کردند.

نتیجه: هم دوستی حفظ شد، هم کار پروژه جلو رفت.

پیام عملی: اگر HRT پشت صحنه باشد، اختلاف سبک را می‌شود با کمی صبر تبدیل به Complementarity کرد، نه میدان جنگ.

۶. Open to Influence بودن (و Vulnerability به‌عنوان قدرت)

دو پارادوکس ظاهری:

• «هرچه بیش‌تر بازِ تأثیر گرفتن باشی، تأثیرگذارتر می‌شوی.»
• «هرچه آسیب‌پذیرتر به‌نظر برسی، قوی‌تر دیده می‌شوی.»

۶.۱. آدم لجباز چه می‌شود؟

همه یک نفر را می‌شناسیم که:

• در هیچ بحثی کوتاه نمی‌آید؛
• هرچه بیش‌تر سعی کنی نظرش را عوض کنی، بیش‌تر در موضعش فرو می‌رود.

در بلندمدت:

• تیم کم‌کم او را route around می‌کند؛
• حرفش دیگر جدی گرفته نمی‌شود؛
• حتی اگر نکته‌ی خوبی هم بگوید، کسی حوصله‌ی دوباره درگیر شدن با او را ندارد.

پس اگر می‌خواهی حرفت جدی گرفته شود:

• باید نشان بدهی قابلیت تغییر نظر داری؛
• باید قبل از این‌که public موضع قطعی بگیری، خوب گوش کنی؛ وگرنه اگر مدام عقب بنشینی، به‌عنوان «متزلزل» دیده می‌شوی. بنابراین تعادل: late commitment + real openness.

۶.۲. آسیب‌پذیری و اعتراف به ندانستن

سؤال: اگر بگویی «نمی‌دانم» یا «اشتباه کردم»، آیا اعتبارت از بین می‌رود؟

سیاسی‌ها معمولاً هرگز اشتباه را نمی‌پذیرند، حتی وقتی فکت‌ها فریاد می‌زنند؛ نتیجه: مردم کلاً اعتمادشان را به حرف‌هایشان از دست می‌دهند.

در تیم مهندسی سالم:

• اعتراف به اشتباه یا ندانستن = نمایشِ تواضع + مسئولیت‌پذیری + اعتماد به قضاوت بقیه.
• در عوض، دیگران برای صداقتت احترام بیش‌تری قائل می‌شوند و در درازمدت «بیش‌تر به تو گوش می‌دهند».

نکته‌ی کلیدی آن‌ها:

• در یک تیم نرم‌افزاری، طرف مقابل تو «رقیب سیاسی» نیست؛ هم‌تیمی است. نیازی نیست دائم در حالت دفاعی باشی.

---

در این بلوک، انتهای فصل ۱ را جمع‌بندی می‌کنیم؛ همان جایی که نویسنده‌ها HRT را از سطح «اصل» به سطح «Next Steps» می‌برند.

۱. چرا اصلاً باید وارد این دردسرها شد؟

نویسنده‌ها می‌پذیرند که «آدم‌ها messy و خسته‌کننده‌اند» و برای خیلی از مهندس‌ها جذاب‌تر است همیشه با کامپایلر سر و کله بزنند تا با انسان. اما نقل‌قولی از Richard Hamming می‌آورند:

• او تعریف می‌کند که با شوخ‌طبعی و رفاقت با منشی‌ها، سطح کمک‌هایی که از آن‌ها می‌گرفت فوق‌العاده بالا بود؛ تا حدی که یک‌بار برای گرفتن یک کار چاپی، شخصاً از Murray Hill به Holmdel رفتند و برگشتند.
• نکته: چون روی رابطه سرمایه‌گذاری کرده بود (جوک گفتن، حال‌پرسیدن، آدم حساب کردنشان)، بعداً در نقطه‌ی حساس، سیستم (سازمان) به نفع او خم شد.

جمع‌بندی: بازی اجتماعی «ترفند» نیست، بخشی از مهندسی است. هدف، دست‌کاری آدم‌ها نیست؛ ساختن رابطه‌هایی است که خروجی تو و تیم‌ات را چندبرابر می‌کند، و این روابط عمرشان از هر پروژه‌ای طولانی‌تر است.

۲. HRT در بافت کلی کتاب

نویسنده‌ها تأکید می‌کنند که HRT فقط یک شعار اخلاقی نیست، اسکلت‌بندی کل کتاب است:

• این فصل (۱): اول از همه باید خودت را زیر ذره‌بین بگذاری؛ رفتارهای شخصی را با HRT align کنی؛ Ego را کم کنی، یاد بگیری انتقاد بدهی و بگیری، سریع fail کنی و از آن درس دربیاوری، برای یادگیری وقت بگذاری، صبور باشی و تأثیرپذیر.
• فصل ۲: HRT را از سطح فرد تعمیم می‌دهند به سطح فرهنگ تیم؛ این‌که چطور «تیم رؤیایی» بسازی که در آن تواضع، احترام و اعتماد default است.
• فصل‌های بعد:
  • کار با آدم‌هایی که هر روز با تیم در تماس‌اند ولی جزو core culture نیستند (دیگر تیم‌ها، contributors بیرونی، آدم‌های سمی).
  • ناوبری سازمانی؛ جایی که سیاست، ساختار و بوروکراسی می‌تواند همان‌قدر خطرناک باشد که یک آدم سمی.
  • و نهایتاً رابطه با کاربران؛ کسانی که گاهی فراموش می‌کنیم وجود دارند، ولی بدون آن‌ها نرم‌افزار ما هیچ معنایی ندارد. HRT باید در تعامل با کاربران هم حاضر باشد.

نکته‌ی مهم: اگر فکر می‌کردی داری یک کتاب «مهندسی نرم‌افزار» می‌خوانی، این‌جا روشن می‌شود که در واقع داری یک کتاب درباره‌ی مهندسی روابط انسانی در بستر توسعه‌ی نرم‌افزار می‌خوانی.

۳. Next Steps – قدم بعدی از نگاه نویسنده‌ها

فصل با این پیام تمام می‌شود:

• اگر تا این‌جا آمده‌ای، در مسیر درست برای یاد گرفتن «خوب با بقیه بازی کردن» هستی.
• نقطه‌ی شروع، خودت هستی: باید روی الگوهای رفتاری خودت مکث کنی، آن‌ها را ببینی و عمداً عوضشان کنی.
• وقتی HRT را internalize کردی، همکاری برایت طبیعی‌تر می‌شود و بهره‌وری مهندسی‌ات به‌شکل محسوسی بالا می‌رود؛ نه با کدنویسی بیش‌تر، بلکه با هدررفت کمتر روی درگیری‌ها و سوءتفاهم‌ها.

ساختار رشد هم از «داخل به بیرون» است:

1. Self: تو و عاداتت.
2. Team: ساختن culture بر پایه‌ی HRT.
3. Organization & Others: برخورد با آدم‌های بیرون تیم، آدم‌های سمی، و ساختن خوشه‌های HRT در یک محیط بزرگ‌تر.
4. Users: تعمیم همین نگاه به کاربران، و طراحی محصول/تعامل‌ات با آن‌ها بر این اساس.

---

در این بلوک، ابتدای فصل ۲ را تا پایان دو بخش «What Is Culture?» و «Why Should You Care?» باز می‌کنیم.

۱. مقدمه‌ی فصل ۲: چرا درباره‌ی فرهنگ تیم حرف می‌زنیم؟

نویسنده‌ها از این‌جا به بعد تمرکز را از «فرد» به «تیم» می‌برند:

• فرهنگ تیم‌ها بسیار متنوع است و طیف وسیعی از ارزش‌ها و اولویت‌ها را منعکس می‌کند.
• بعضی فرهنگ‌ها تیم را به موفقیت می‌رسانند، بعضی هم به فاجعه.
• حتی بین فرهنگ‌های موفق، بعضی خیلی کارآمد هستند و تقریباً تمام انرژی تیم روی ساخت محصول می‌رود، بعضی دیگر پر از حواس‌پرتی و اصطکاک‌اند.

هدف فصل:

• توضیح این‌که «فرهنگ» چیست؛
• تمرکز ویژه روی الگوهای ارتباطی (communication) که به موفقیت کمک می‌کنند؛
• و این‌که چطور با همین الگوها می‌شود هر محصولی را با یک تیم انسانی، کم‌هزینه‌تر و مؤثرتر ساخت.

۲. «Culture» یعنی چه؟ – استعاره‌ی نان خمیرترش

وقتی کلمه‌ی Culture را می‌شنویم، یا یاد اپرا و هنر می‌افتیم، یا یاد پتری‌دیش بیولوژی؛ نویسنده‌ها عمداً از همانی دومی استفاده می‌کنند.

۲.۱. داستان نان خمیرترش (Sourdough)

اگر یک نان خمیرترش واقعاً عالی خورده باشی و دنبال نانوا بگردی، به این می‌رسی که:

• کلید طعم و کیفیت نان، یک Starter است: مخلوطی از خمیر و آب که داخلش مخمر (yeast) و باکتری Lactobacillus زندگی می‌کند.
• مخمر نان را پف می‌دهد، باکتری طعم ترش و خاص می‌سازد.
• همه‌ی لکتوباسیل‌ها یکسان نیستند؛ بعضی سوش‌ها طعم خیلی بهتری می‌دهند. اگر نانوا یک Starter با طعم عالی پیدا کند، با دقت از آن نگه‌داری و آن را تغذیه می‌کند، و هر بار مقدار کمی از آن را به خمیر جدید «تزریق» می‌کند.

این Starter یک کار دیگر هم می‌کند:

• آن‌قدر قوی است که وقتی وارد خمیر جدید می‌شود، «سوش‌های وحشی و ناخواسته» مخمر/باکتری محیط را عقب می‌زند و خودش غالب می‌شود؛ نتیجه: خروجیِ نهایی نان، همان طعم و هویت مشخص.

۲.۲. قیاس با فرهنگ تیم

فرهنگ یک تیم مهندسی دقیقاً شبیه همین استارتر خمیرترش است:

• Starter Culture = بنیان‌گذاران و اعضای اولیه‌ی تیم
• خمیر تازه = نیروهای جدیدی که به تیم اضافه می‌شوند
• مخمر و باکتری = خود اعضای تیم و رفتارهایشان

اگر Starter قوی باشد:

• می‌تواند «سوش‌های فرهنگی ناشناخته» که نیروهای جدید می‌آورند را مهار و هضم کند؛
• و newcomers را آرام‌آرام به همان هویت، ارزش‌ها و رفتارها آغشته می‌کند.

اگر Starter ضعیف باشد:

• هر newcomer عملاً می‌تواند بخش‌هایی از فرهنگ قبلی خودش را «تزریق» کند؛
• چون هیچ چیز قوی‌ای برای شکل دادن رفتار وجود ندارد، تیم به‌راحتی توسط ارزش‌ها و الگوهای تصادفی تازه‌واردها re‑shape می‌شود؛
• خروجی نهایی (نان / تیم) غیرقابل پیش‌بینی و غالباً ناامن می‌شود.

نکته‌ی مهم: فرهنگ فقط این نیست که «چطور کد می‌زنیم». فرهنگ ترکیبی است از:

• شیوه‌ی کار (code review، TDD، design doc و …)
• ارزش‌ها و اهداف مشترک
• و حتی Ritualهای اجتماعی و شوخی‌های داخلی تیم (ناهار پنج‌شنبه، نوشیدنی جمعه، یا جنگ Nerf Gun در دفتر Pittsburgh گوگل هر وقت قطار رد می‌شد).

بنیان‌گذاران و اعضای اولیه بیشترین اثر را روی شکل‌دهیِ اولیه دارند، اما فرهنگ یک چیز ایستا نیست؛ همراه رشد و تغییر تیم، خودِ فرهنگ هم evolve می‌کند.

۳. چرا باید برای فرهنگ وقت بگذاری؟

بخش بعدی می‌پرسد: «خب، چرا باید این‌قدر به فرهنگ اهمیت بدهم؟ چه می‌شود اگر ندم؟»

۳.۱. اگر فرهنگ را رها کنی، دیگران برایت می‌سازند

اگر خود تیم روی ساختن و نگه‌داشت culture سرمایه‌گذاری نکند:

• به‌مرور شخصیت‌های قوی (لزوماً نه سالم) وارد می‌شوند و شروع می‌کنند فرهنگ خودشان را تحمیل کردن.
• ممکن است خوش‌شانس باشی و اتفاقاً فرهنگِ آن‌ها خوب از آب دربیاید، ولی در اکثر موارد، نتیجه ترکیبی است از:
  • دعوا و کشمکش
  • حواس‌پرتی دائمی از کار اصلی
  • و هدر رفتن انرژی‌ای که باید صرف design و shipping می‌شد.

داشتن یک فرهنگ «قابل دفاع» مهم است:

• اگر خودِ اعضای تیم فرهنگ را ارزشمند ندانند، انگیزه‌ای هم برای دفاع از آن در مقابل newcomerها نخواهند داشت.
• آن وقت یک نفر جدید با style بد یا ارزش‌های ناسازگار می‌تواند به‌راحتی کل جو تیم را عوض کند.

۳.2. فرهنگ، مسئولیت همه است، نه فقط لید

اشتباه رایج:

• «Culture» را مسئولیت Lead یا Manager فرض می‌کنند؛ انگار فقط اوست که نگهبان فرهنگ است.

نویسنده‌ها صریح می‌گویند:

• بنیان‌گذاران و لیدها نقش پررنگی دارند، اما هر عضو تیم هم در تعریف، هم در نگه‌داری، و هم در دفاع از فرهنگ مسئول است.
• وقتی کسی تازه وارد تیم می‌شود، فرهنگ را فقط از Lead نمی‌گیرد؛ از تمام رفتارهایی که از نزدیکانش می‌بیند می‌آموزد:
  • چطور کار همدیگر را review می‌کنید؛
  • چطور conflict حل می‌کنید؛
  • چقدر روی کیفیت حساس هستید؛
  • چه چیزی در تیم تشویق یا تحمل می‌شود.

۳.۳. «فرهنگ قوی» یعنی چه؟

نویسنده‌ها یک تعریف عملی می‌دهند:

• فرهنگ قوی = باز است به تغییراتی که آن را بهتر می‌کند، اما در برابر تغییراتی که آن را بدتر می‌کند، مقاومت دارد.

در تیم‌های موفق:

• فکوس اصلی فرهنگ، «Ship کردنِ نرم‌افزار خوب» است.
• اگر تمرکز اصلی فرهنگ چیزهای دیگری مثل:
  • مهمانی دائم،
  • جلسه برای جلسه،
  • بازی قدرت و one‑upmanship،
    باشد، تیم شاید «با هم حال کند»، ولی خروجی خیلی کمی خواهد داشت.

برای کسی مثل تو که از ساختن و shipping لذت می‌برد:

• حیاتی است در تیمی باشی که محصول‌محور است؛ و بعد فعالانه کمک کنی همین فضا حفظ و تقویت شود.

۳.۴. فرهنگِ Self‑Selecting

یک Insight مهم: فرهنگ مثل یک فیلتر خودانتخاب‌گر عمل می‌کند.

• در پروژه‌های متن‌باز Apache، تیم‌هایی که روی HRT و کد تمیز و maintainable تأکید دارند، دقیقاً همین مدل آدم‌ها را جذب می‌کنند.
• اگر فضای mailing list آن‌ها پر از توهین و حمله‌ی شخصی باشد، همان جنس آدم را هم جمع می‌کند؛ آدم‌های introvert و سازنده به‌مرور کنار می‌روند.

در سازمان‌های شرکتی، این Self‑Selection به‌وضوح در فرآیند استخدام دیده می‌شود:

• مثلاً گوگل «Culture fit» را صریحاً به‌عنوان یکی از معیارهای interview دارد؛ اگر کسی از نظر تکنیکی عالی باشد اما نتواند در team‑based environment کار کند، یا محیط ساختار-پذیر افراطی بخواهد، رد می‌شود.
• اگر به culture‑fit در استخدام توجه نکنی، بعداً انرژی عظیمی باید صرف «جا انداختن» یا «بیرون کردن» آن فرد کنی؛ هر دو هزینه‌بر و فرساینده‌اند.

---

در این بلوک، بخش «Culture and People» از فصل ۲ را باز می‌کنیم؛ یعنی جایی که کتاب تفاوت کار خلاق (مثل توسعه‌ی نرم‌افزار) با کار خط تولید را توضیح می‌دهد و اثر فرهنگ را روی نوع آدم‌هایی که جذب می‌کنی نشان می‌دهد.

۱. چرا نرم‌افزار مثل خط تولید نیست؟

نویسنده‌ها تأکید می‌کنند که کار خلاق مثل نرم‌افزار را نباید با مونتاژکار خط تولید قاطی کرد:

• در بعضی کارها، چند روز آموزش و یک‌سری ابزار ساده کافی است و اگر یکی از کارگرها برود، نفر بعدی را راحت جایگزین می‌کنی؛ خروجی هم با تکرار یک سری حرکت روتین تولید می‌شود.
• در مهندسی نرم‌افزار (و هر کار خلاق مشابه)، خروجی به تفکر، حل مسئله و تصمیم‌گیری وابسته است؛ اگر نیروی خوب از دست بدهی، با یک ramp‑up چندروزه جبران نمی‌شود.

اگر می‌خواهی محصول خوب بسازی، به مهندسان خوب نیاز داری، و برای این‌که مهندسان خوب بتوانند best workشان را انجام بدهند و بمانند، باید فرهنگی داشته باشی که:

• برای ایده‌ها و نظرهایشان safe باشد؛
• بتوانند واقعاً روی محصول اثر بگذارند؛
• و در تصمیم‌گیری مشارکت کنند.

۲. چه کسانی را جذب می‌کنی؟

خیلی از مهندسان قوی دو چیز را می‌خواهند:

• هم‌تیمی‌های قوی‌تر یا هم‌سطح، تا از آن‌ها یاد بگیرند؛
• و نقشی واقعی در تصمیم‌گیری محصول؛ نه صرفاً «پیاده‌ساز دستورات بالا».

نویسنده‌ها دو مدل مدیریت/فرهنگ را مقابل هم می‌گذارند:

1. Top‑down / alpha‑engineer
   • یک «alpha engineer» لید است و بقیه باید فقط دستورات او را اجرا کنند.
   • معمولاً آدم‌هایی را می‌آورد که ارزان‌تر و مطیع‌ترند؛ outcome: تیمی پُر از «follower» که خودش باید برای همه تصمیم بگیرد، و مهندسانی که می‌توانستند در جای دیگر driver باشند، اصلاً جذب این تیم نمی‌شوند.
2. Consensus‑driven / مشارکتی
   • همه حس «مالکیت و مسئولیت» نسبت به محصول دارند.
   • لید واقعاً گوش می‌دهد، و احترام (R از HRT) در مرکز است.
   • گاهی، برای سرعت، تیم خودخواسته بخشی از تصمیم‌ها را به TL/Tech Committee تفویض می‌کند، اما این delegation نتیجه‌ی همان consensus است، نه دیکتاتوری.

بسیاری وقتی کلمه‌ی «Consensus» را می‌شنوند یاد جلسات بی‌پایان هیپی‌ها و «Kumbaya» می‌افتند، اما نویسنده‌ها می‌گویند اگر چنین شود، مشکل از team dysfunction است، نه از خودِ consensus.

۳. رفتارِ آدم‌ها با هم: از «قلدری» تا HRT

اگر فرهنگ تیم این باشد که:

• «سینه‌کوبی»، داد و بیداد، تحقیر و حمله‌ی شخصی normal است،

در عمل:

• فقط آدم‌های تهاجمی و ego‑driven جذب می‌شوند یا دوام می‌آورند؛
• مخصوصاً بسیاری از زنان (به تجربه‌ی نویسنده‌ها) این فضا را به‌شدت repel‑کننده می‌یابند؛
• تیم شاید از بیرون «پر سروصدا و بااعتمادبه‌نفس» به‌نظر برسد، اما درونش انرژی عظیمی صرف جنگ قدرت می‌شود.

اگر فرهنگ را روی HRT بنا کنی:

• مهندسانی را جذب می‌کنی که هم به کیفیت و هم به احترام اهمیت می‌دهند؛
• و به‌جای جنگ، وقتشان را صرف نوشتن کد تمیز و طراحی خوب می‌کنند.

نویسنده‌ها بین Ego تیمی و Ego فردی فرق می‌گذارند:

• غرور تیمی (Team Pride) خوب است؛ این‌که تیم به محصولش افتخار کند.
• اما وقتی افراد با Egoهای شخصی‌شان تیم را زیر سایه می‌برند، فرمول شکست است؛ در فصل ۴ مفصل‌تر به این می‌پردازند.

۴. نقش انتقاد سازنده در فرهنگ

انتقاد سازنده برای رشد فرد و تیم حیاتی است، ولی خیلی‌ها از آن فرار می‌کنند. دلایل:

• ناامنی؛ می‌ترسند اگر Feedback بگیرند، مجبورند حتماً مطابق‌اش عمل کنند.
• درکی که دارند این است: «اگر به من انتقاد شد، یعنی باید همه‌چیز را عوض کنم؛ پس بهتر است اصلاً نپرسم.»

درحالی‌که:

• انتقاد «هدیه» است؛ بخشی را که مفید و align با ارزش‌هاست برمی‌داری، بقیه را می‌گذاری کنار.
• بدون انتقاد، احتمال این‌که سال‌ها همان اشتباهات را تکرار کنی، بالاست؛ چون self‑awareness و introspection به‌تنهایی معمولاً کافی نیستند که همه‌ی blind spotهایت را ببینی.

نویسنده‌ها می‌گویند همین کتاب را حداقل دوازده نفر به‌طور جدی review کردند و انتقادهای خیلی دقیق دادند؛ بدون آن، کیفیت نهایی کتاب به‌مراتب پایین‌تر بود.

البته دادن feedback خوب کار راحتی نیست؛ ساده‌ترین کار «خراب کردن» و مسخره کردن است؛ ساختن feedback سازنده انرژی و مهارت می‌خواهد.

اگر colleagues و دوستانی داری که وقتی ازشان feedback می‌خواهی واقعاً نقد سازنده می‌دهند (نه فقط تعریف)، این‌ها را «مثل unobtainium» نگه‌دار؛ بسیار کمیاب‌اند.

۵. فرهنگ HRT و طیف شخصیت‌ها

نکته‌ی مهم برای طراحی culture:

• آدم‌های تهاجمی معمولاً می‌توانند در محیط‌های آرام هم به‌صورت productive کار کنند.
• اما آدم‌های آرام، introvert و متفکر تقریباً هرگز در محیط‌های aggressive شکوفا نمی‌شوند؛ صدایشان گم می‌شود و کم‌کم کنار می‌کشند.

اگر به‌دنبال فرهنگی هستی که بیشترین طیف آدم‌ها بتوانند در آن خوب کار کنند، آن فرهنگ باید روی تواضع، احترام و اعتماد ساخته شود.

هشدار: فرهنگ‌های آرام و محترم نسبت به disruption توسط آدم‌های تهاجمی آسیب‌پذیرترند؛ به‌همین خاطر:

• باید آگاهانه اجازه ندهی newcomer تهاجمی، tone تیم را تصاحب کند؛
• معمولاً با engage نکردن در لحن aggressive شروع می‌شود؛
• و گاهی لازم است یکی از اعضای ارشد، مستقیم و قاطع با آن شخص صحبت کند تا از فرهنگ محافظت کند (فصل ۴، «Poisonous People»، این را باز می‌کند).

---

در این بلوک، از ابتدای بخش «Communication Patterns of Successful Cultures» تا انتهای سه زیر‌بخش اولش می‌رویم: High‑Level Synchronization، Mission Statement، Efficient Meetings، و بعد هم بخش «Working in a Geographically Challenged Team».

۱. الگوهای ارتباطی در فرهنگ‌های موفق

مشکل کلاسیک مهندسان: ترجیح می‌دهند با کامپایلرِ منطقی و قابل پیش‌بینی سر و کله بزنند تا با انسانِ احساسی و غیرخطی، و ارتباط را مانعِ راه نوشتن کد می‌بینند.

اما اگر:

• تیم روی جهت و اولویت‌ها sync نباشد،
• و اطلاعات شفاف در دسترس نباشد،

اصلاً نمی‌فهمی «در حال نوشتن کد روی مسأله‌ی درست» هستی یا نه.

در هر فرهنگ موفق و کارآمد، روی کانال‌های ارتباطی مختلف سرمایه‌گذاری می‌شود:

• mailing list
• design doc
• chat room
• mission statement
• کامنت‌های کد
• how‑toهای عملیاتی و …

برقراری هم‌فهمی روی جهت تیم، effort می‌خواهد، اما این effort مثل سرمایه‌گذاری است که بازدهش را در بهره‌وری و رضایت تیم می‌بینی.

یک قاعده‌ی کلی:

• ارتباط هم‌زمان (synchronous) (جلسه، تماس تلفنی) را تا حد ممکن با «کم‌ترین تعداد آدم لازم» انجام بده.
• ارتباط ناهم‌زمان (asynchronous) (ایمیل، issue tracker، کامنت روی doc) را تا حد امکان برای «گروه بزرگ‌تر» بفرست تا همه بتوانند در زمان مناسب خودش ببینند.

هر بار کسی را وسط کارش قطع می‌کنی، باید هزینه‌ی context switching را در نظر بگیری.

۲. هم‌ترازی سطح بالا (High‑Level Synchronization)

در سطح بالا، دو چیز حیاتی است:

• توافق روی اهداف مشترک
• و توافق روی روش‌های کار (best practices)

ابزارهایی که در ادامه مطرح می‌شود، همه به همین خدمت می‌کنند: mission statement، design doc، typeهای خاص جلسه و …

۳. Mission Statement – نه از جنس شعارهای بازاری

اول ماموریت را از نوعی که اکثر شرکت‌ها دارند، مسخره می‌کند؛ مثال دو mission statement مبهم که می‌توانستند برای هر چیزی از کارواش تا فروشگاه پوشاک به کار بروند.

این missionها هیچ جهت عملیاتی واقعی به تیم نمی‌دهند: تو نمی‌فهمی امروز باید «ماشین بشویی»، «نشتی لوله را درست کنی» یا «پیتزا تحویل بدهی».

۳.۱. Mission خوب برای تیم مهندسی چیست؟

برای یک تیم تولید نرم‌افزار، mission statement ابزاری است برای:

• تعریف جهت (Direction)
• محدود کردن حوزه (Scope)

یک مثال خوب: mission تیم Google Web Toolkit (GWT). وقتی GWT متن‌باز شد، Fitz و Ben به تیم گفتند باید یک mission statement شفاف بنویسند. تیم اول مقاومت داشت («وقت تلف کردن است»)، اما وقتی نشستند، بحث‌های جدی در گرفت، چون مشخص شد خودِ لیدهای ارشد روی جهت محصول اتفاق‌نظر ندارند.

در نهایت، Mission این شد:

GWT’s mission is to radically improve the web experience for users by enabling developers to use existing Java tools to build no‑compromise AJAX for any modern browser.

این جمله کوتاه، دو چیز را دقیق مشخص می‌کند:

• جهت: بهبود رادیکال تجربه‌ی وب برای کاربر، از طریق توانمندسازی توسعه‌دهنده.
• محدودیت دامنه: تمرکز روی ابزارهای Java.

تیم علاوه بر جمله‌ی Mission، یک سند مفصل «Making GWT Better» هم نوشت که تک‌تک عبارت‌های mission و non‑goals پروژه را توضیح می‌داد.

نتیجه‌های عملی:

• لید تیم بعدها اعتراف کرد: فکر می‌کرد این تمرین وقت‌تلف‌کردن است، اما همین پروسه باعث شد لیدها تفاوت دیدگاهشان را کشف و resolve کنند؛ چیزی که می‌توانست بعداً سرعت محصول را بکشد.
• وقتی mission روی وب منتشر شد، newcomers را به آن ارجاع می‌دادند و بخش بزرگی از بحث‌های تکراری «جهت محصول چیست؟» حذف شد.
• هر وقت محیط یا بیزنس pivot می‌کرد، باید صادقانه می‌دیدند آیا mission هنوز معنا دارد یا باید به‌سختی آن را update کنند؛ مثل اصلاح قانون اساسی، سخت ولی ممکن.

۴. جلسات کارآمد (Efficient Meetings)

نویسنده‌ها صریحاً می‌گویند بیشتر آدم‌ها از جلسه متنفرند؛ اگر بد اداره شود، waste محض است.

۴.۱. جلسات دوره‌ای (standing meetings)

جلسات هفتگی تیم باید:

• فقط برای اعلان‌های مهم، معرفی‌ها و هماهنگی خیلی سطح بالا باشد.
• دور زدن اتاق و شنیدن status از هر نفر، حتی وقتی چیزی ندارند، فرمولی است برای اتلاف وقت و self‑harm.

راه بهتر:

• هر موضوعی که نیاز به بحث عمیق دارد، در لیست «sidebar» نوشته شود؛ بعد از اتمام بخش اصلی، فقط کسانی که به آن topic ربط دارند می‌مانند و بقیه با خیال راحت می‌روند.
• وقتی این عادت جا بیفتد، هر کس هر جا دید بحث دارد منحرف می‌شود، می‌تواند بگوید «sidebar؟» و بحث را ذخیره کند بدون این‌که کسی احساس کند خاموش شده است.
• اگر در آن هفته agenda مهمی ندارید، بدون عذاب وجدان جلسه را لغو کنید.
• اگر فرهنگ سازمان جوری است که «پر بودن کلندر» نشانه‌ی status است، این را صریحاً «دیوانگی» می‌نامند.

Daily Standup (Agile):

• اگر واقعاً «۱۵ دقیقه‌ای، ایستاده و on‑point» بماند، قابل دفاع است.
• اما بدون مراقبت دائمی، به‌سرعت تبدیل می‌شود به جلسات ۳۰ دقیقه‌ای با بحث‌های عمیق و therapy group.
• کسی باید با authority آن را time‑box و track نگه دارد.

۴.۲. جلسات طراحی / تصمیم‌گیری

اگر می‌خواهی چیز جدیدی design کنی یا تصمیم سخت بگیری:

• به‌صورت تجربی، بیش از ۵ نفر در اتاق، تصمیم‌گیری واقعی را فلج می‌کند؛ مگر این‌که یک نفر decision‑maker از پیش تعیین‌شده وجود داشته باشد.
• مثال‌شان: اگر ۶ نفر را در یک تور شهری بدون لیدر بگذاری و بخواهی با consensus تصمیم بگیرند که کجا بروند، بیشتر روز در گوشه‌ی خیابان مشغول بحث خواهند بود.

۴.۳. Maker’s Schedule و زمان «Make»

جلسات با «Make Time» سازگار نیستند.

• اشاره به مقاله‌ی Paul Graham: مهندس نیاز به blocks ۳–۴ ساعته‌ی بدون interruption دارد.
• توصیه: این blocks را در کلندر خودت explicit رزرو کن (Busy / Make Time).

بهتر است جلسات را:

• تا حد امکان نزدیک breakهای طبیعی بگذاری (ناهار، آخر روز).
• در گوگل، سنت «No Meeting Thursday» وجود داشت تا حداقل یک روز را تا جای ممکن خالی بگذارند؛ کار می‌کرد، اما نیاز به policing مداوم داشت.

پنج قانون ساده‌ی آن‌ها برای جلسه‌ی خوب:

1. فقط کسانی را دعوت کن که واقعاً لازم‌اند.
2. حتماً agenda داشته باش و قبل از جلسه بفرست.
3. وقتی اهداف جلسه محقق شد، جلسه را تمام کن (حتی اگر زودتر از زمان رزرو شده باشد).
4. بحث را روی agenda نگه‌دار و اجازه‌ی drift بی‌پایان نده.
5. زمان جلسه را تا حد امکان با دیگر نقاط وقفه در روز align کن.

۵. کار در تیم‌های «Geographically Challenged»

وقتی تیم distributed است یا خودت remote کار می‌کنی، دومسئله داری:

• هم نیاز به ابزارهای دیگر برای ارتباط داری؛
• هم به‌طور کلی باید بیش‌تر روی ارتباط سرمایه‌گذاری کنی، نه کم‌تر.

۵.۱. مستندسازی تصمیم‌ها

وقتی اعضای تیم در یک مکان نیستند:

• تصمیم‌های مهم را باید کتبی و share کنی (معمولاً ایمیل).
• chat، پیام فوری و صحبتِ راهرو مفید است، اما نتیجه‌های مهمشان باید در کانالی که همه می‌بینند (مثلاً mailing list) ثبت شود.
• مزیت جانبی: archive برای بعداً، و شفافیت برای newcomers.

در پروژه‌ی Subversion، شعارشان این بود:

«اگر بحثی در لیست ایمیل رخ نداده، انگار هرگز رخ نداده است.»

یعنی:

• می‌توانی در chat brainstorm کنی، ولی وقتی به تصمیم رسیدید، باید آن را روی لیست ایمیل replay کنید، تا یک:
  • log قابل جست‌وجو از reasoning داشته باشید؛
  • و امکان مشارکت برای کسانی که حاضر نبودند فراهم شود.

این برای فرهنگ consensus حیاتی است.

۵.۲. Over‑Communication از راه دور

اگر remote کار می‌کنی:

• باید بیش از حد نرمال با تیم communicate کنی؛
• از تمام مدیاها استفاده کن: chat، ایمیل، video call، تلفن؛
• مطمئن شو همه هم می‌دانند که «هستی» و هم می‌دانند روی چه کار می‌کنی.

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

• قدرت و نقش «face‑to‑face» را دست‌کم نگیر؛ هیچ چیز از نظر bandwidth و اعتمادسازی به آن نزدیک نمی‌شود.

۵.۳. مثال‌های سفر حضوری

دو مثال واقعی:

1. مهندسی که با تیمی در کلرادو کار می‌کرد و نمی‌توانست momentum بگیرد. Fitz به او گفت یک هفته برو آن‌جا مستقر شو. بعد از یک روز، ایمیل زد که:
   • اوضاع حرکت کرده،
   • و با هم ناهار و بعد از کار بیرون رفتن، رابطه‌ای ساخته که روی ریتم کار اثر گذاشته است.
2. Corey که با تیمی در یک دفتر دیگر پروژه جدیدی را شروع کرده بود. traction نمی‌گرفت، Ben گفت برو دو روز همان‌جا کنارشان بشین. Corey نگران هزینه‌ی سفر بود، اما وقتی رفت دید:
   • فقط همان دو روز bandwidth گفتگو و context مشترک ایجاد کرد که بعداً تمام تعامل‌های remote را نرم و مؤثر کرد.

نکته‌ی زیرخط:

• سفر کاری ممکن است گران به‌نظر برسد، ولی هزینه‌ی نرفتن، از نظر friction، سوءتفاهم و کند شدن کار، معمولاً بیش‌تر است.
• اگر بودجه داری و پروژه مهم است، برای جلسات شروع پروژه یا تصمیم‌های کلیدی، حضور فیزیکی تقریباً همیشه ارزشش را دارد.

---

در این بلوک، بقیه‌ی فصل ۲ را تا انتهای «It Really Is About Your Product, After All» پوشش می‌دهم.

۱. Design Doc؛ چرا قبل از کد باید بنویسی؟

نویسنده‌ها می‌گویند مقاومت مهندس در برابر «اول طراحی، بعد کد» طبیعی است، ولی اکثر وقت‌ها اگر مستقیم بپری توی کدنویسی، به‌خصوص برای چیزی فراتر از یک prototype خیلی سریع، آخرش بد تمام می‌شود.

ویژگی‌های یک Design Doc سالم:

• معمولاً یک owner دارد، ۲–۳ نفر مشارکت‌کننده‌ی اصلی، و تعداد بیش‌تری reviewer.
• نقش‌اش:
  • blueprint سطح‌بالای پروژه‌ی آینده؛
  • کانال ارزان برای sync کردن تیم روی این‌که «چه می‌خواهیم بسازیم و چطور».
• چون هنوز ماه‌ها کد نزده‌ای، پذیرش Feedback و تغییر مسیر، ارزان‌تر و راحت‌تر است؛ هم کیفیت design و هم implementation بالاتر می‌رود.
• بعداً راهنمای برنامه‌ریزی و تقسیم کار می‌شود.

اما نباید «دین طراحی» بگیری:

• اگر پروژه‌ای را می‌توانی چندبار از صفر در همان زمانی که برای نوشتن یک Design Doc طولانی لازم است بازنویسی کنی، Doc احتمالاً overkill است.
• judgement لازم است: برای سیستم توزیع‌شده با stateful service و SLA بالا، Design Doc ضروری است؛ برای اسکریپت ۱۰۰ خطی، نه.

Doc باید سند زنده باشد، نه سنگ قبر:

• باید همراه با تکامل پروژه update شود، نه این‌که فقط در لحظه‌ی «before coding» نوشته و بعد رها شود؛ البته اغلب تیم‌ها دقیقاً همین اشتباه را می‌کنند.

۲. روزمره‌ی ارتباط: Mailing List، Chat، Issue Tracker

وقتی هدف و mission مشخص شد، می‌رسی به ابزارهایی که ارتباط روزمره را حمل می‌کنند. این کانال‌ها bandwidth و context محدودی دارند و خطر سوء‌تفاهم و آسیب به HRT بالاست، ولی اگر درست استفاده شوند، بهره‌وری را بالا می‌برند.

۲.۱. Mailing List

تقریباً هیچ تیمی نیست که لااقل یک لیست ایمیل نداشته باشد؛ مسئله این است چطور از آن استفاده کنی.

• پروژه‌های بزرگ معمولاً چند لیست دارند: dev، code‑review، users، announce، و …
• اما پروژه‌ی کوچک با ۳ مهندس و ۲ کاربر اگر ۶ لیست بسازد، مثل این است که برای ۵ نفر ۶ اتاق جلسه درست کرده باشی: پراکندگی، echo، و اتاق‌های خالی.
  • توصیه: با یک لیست شروع کن، فقط وقتی واقعاً traffic بالا شد و آدم‌ها رحم خواستند، آن را بشکن.
  • استثنا: ایمیل‌های خودکار و botها بهتر است در لیست جدا یا حداقل با prefix قابل فیلتر شدن باشند.

نکته‌های عملی:

• etiquette مشخص برای بحث ایمیلی تعریف کن:
  • لحن مؤدب،
  • جلوگیری از «noisy minority» که روی هر thread سوار می‌شوند و فضا را انحصار می‌دهند.
• برای هر چیز مهمی (agenda جلسات، minutes، تصمیم‌ها، design docها) یک copy روی لیست بفرست تا:
  • یک «system of record» قابل جست‌وجو داشته باشی،
  • newcomers وقتی می‌پرسند «چرا این تصمیم را گرفتید؟»، بتوانی آن‌ها را به آرشیو ارجاع دهی، نه این‌که دوباره از صفر دفاع کنی.

اگر این آرشیو را نسازی، محکوم به تکرار همه‌ی بحث‌ها برای هر نسل جدیدی از نیروها هستی.

۲.۲. Online Chat

Chat یک ابزار عالی برای پرسش‌های سریع و تعامل سبک‌وزن است، مشروط به این‌که kill‑switch مزاحمت را در دست خود مهندس بگذاری.

نویسنده‌ها تأکید می‌کنند: group chat عمداً بهتر از ۱:۱ است:

• قبلاً تیم‌ها غالباً در IRC کانال مشترک داشتند؛ امروز معادل‌اش Slack است.
• افراد می‌توانند:
  • در بحث‌ها شرکت کنند،
  • صرفاً از دور دنبال کنند (lurk)،
  • یا بعداً log را بخوانند.
• این باعث می‌شود lore پروژه collect شود، نه این‌که در DMها گم بشود.

مشکل مدرن: با IM، default تبدیل شد به ۱:۱ private chat، که insecurities را تغذیه می‌کند:

• کسی که از «پرسیدن سؤال احمقانه» جلوی بقیه می‌ترسد، همه‌چیز را private می‌پرسد؛ نتیجه:
  • بار تکرار پاسخ روی seniorها می‌افتد،
  • دانش shared نمی‌شود.

با تولد Slack موج جدید group chat برگشت:

• Slack integrationهای زیادی دارد؛ owner گزارش هفتگی از نسبت DM به پیام‌های کانال می‌گیرد و می‌تواند تیم را gently هل بدهد به‌سمت بحث‌های public.

قانون مفید:

• سوال/بحثی که «ارزش یک بار جواب درست» دارد، باید در کانال گروهی مطرح شود؛ DM برای چیزهایی که ذاتاً شخصی‌اند.

۲.۳. Issue Tracker

اگر issue tracker داری (و باید داشته باشی)، فقط داشتن ابزار کافی نیست؛ باید فرآیندی برای triage و رسیدگی داشته باشی.

اگر:

• tracker neglected باشد،
• اولویت‌گذاری نداشته باشی،

رخ می‌دهد که:

• مردم filing را رها می‌کنند و یا مستقیماً غر می‌زنند،
• و وقتی تیم برمی‌گردد سراغ tracker، کلی وقت را روی باگ‌های بی‌اهمیت می‌گذارد، درحالی‌که مهم‌ها پشت backlog گم شده‌اند.

Issue tracker عملاً یک فروم تخصصی است، با همان قواعد mailing list:

• بحث‌های راهرو و شفاهی درباره‌ی یک باگ را حتماً به‌صورت کامنت در issue ثبت کن؛ این تصمیم‌ها فقط وقتی «واقعی» هستند که جایی ثبت شده باشند.
• لحن باید مؤدبانه بماند؛ رفتارهای troll‑like را تحمل نکن.
• اگر thread در issue طولانی و پیچیده شد، بحث conceptual را موقتاً روی لیست ایمیل ببرید؛ email client ابزار بهتری برای managing threadهای عمیق است.

۳. ارتباط به‌عنوان بخشی از مهندسی

در این قسمت، چند نقطه‌ی حساس در خود فرآیند توسعه را از زاویه‌ی ارتباط بررسی می‌کند.

۳.۱. Code Comments – نه زیاد، نه کم، و روی «چرا»

استایل کامنت‌گذاری بحث‌برانگیز است، اما چند اصل عملی:

• کامنت‌های خیلی verbose ممکن است intent و reasoning را خوب بیان کنند، اما اگر update نشوند تبدیل به noise خطرناک می‌شوند.
• کامنت‌های صفر یا خیلی کم هم باعث می‌شود آینده‌ای‌ها وقت‌شان را صرف reverse‑engineering intent تو کنند.

اشتباه رایج:

• کامنتی که فقط ساختار بد و نام‌گذاری بد را پنهان می‌کند؛ در اصل دارد همان‌چیزی را تکرار می‌کند که کد already می‌گوید.

نویسنده‌ها می‌گویند:

• تمرکز کامنت باید روی چرا باشد، نه «چه کار می‌کند»؛
• مفیدترین سطح برای کامنت، سطح method / function و API است.

قانون‌شان: اصل یونانی «μηδέν άγαν» – «هیچ چیز بیش از حد لازم».

نکته مهم‌تر از خود سبک: یک style guide مشترک و ثبات.

دلیل Style Guide را هم باید شفاف بگویی (مثل intro راهنمای C++ گوگل):

• هدف، manage complexity، enforce consistency، و جلوگیری از feature‑bloat است؛
• نه necessarily «بهترین» یا «سریع‌ترین» possible C++؛ مهم این است که هر مهندس بتواند سریع کد بقیه را pattern‑match کند.

۳.۲. اسم گذاشتن روی فایل‌ها – چرا «امضای نویسنده» بد است؟

سنت قدیمی این است که بالای فایل بنویسی:

# Created: October 1998 by Brian W. Fitzpatrick <...>

مشکل این رویکرد برای codebaseهای امروزی:

• نرم‌افزار امروز را «افراد متعدد»، در بازه‌های زمانی طولانی، مدام تغییر می‌دهند.
• سوال حل‌نشدنی: از چه نقطه‌ای نام نفر دوم، سوم، چهارم را باید اضافه کرد؟ چند خط تغییر؟ یک تابع؟ چند باگ‌فیکس؟
• اگر تابعی را کسی نوشته، بعداً دیگری refactor کرده، و سومی rewrite، چه اسمی باید بماند / حذف شود؟

نتیجه‌ی واقعی:

• انرژی عظیمی صرف بحث‌های بی‌حاصل روی attribution می‌شود؛
• Ownership ذهنی روی فایل ایجاد می‌کند و Bus Factor را پایین می‌آورد؛
• دیگران برای تغییر فایل «با اسم دیگری روی آن»، تردید می‌کنند.

راه‌حل پیشنهادی:

• attribution را از سطح فایل بردار؛
• در عوض:
  • یک فایل top‑level AUTHORS یا CONTRIBUTORS داشته باش؛
  • از history سیستم Version Control برای جزئیات دقیق‌تر استفاده کن.

۳.۳. Code Review برای هر Commit

اگر استاندارد کدنویسی داری، بدون review این استاندارد روی کد enforce نمی‌شود.

اصل‌شان:

• هر خطی که وارد repo می‌شود، باید حداقل یک جفت چشم دوم رویش را دیده باشد؛ قبل یا بعد از commit، ولی حتماً دیده شده باشد.
• Changeset باید کوچک و reviewable باشد؛ patch هزاران خطی عملاً فقط برای پیدا کردن indentation‑nit مرور می‌شود، نه برای کیفیت واقعی.

اثرات:

• کیفیت کد بالا می‌رود؛
• sense of group‑ownership و غرور جمعی روی codebase تقویت می‌شود؛
• حلقه‌ی Feedback سریع‌تر می‌شود (همان چیزی که در «Hiding Is Considered Harmful» گفتند).

۳.۴. فرآیند تست و Release واقعی

مهم نیست TDD کار می‌کنی یا فقط regression test ساده داری؛ اصل:

• هرچه تست‌های خودکار بیش‌تر، اطمینان‌ات در زمان refactor و feature‑addition بالاتر.
• نقش تست باید بخشی رسمی از «چرخه‌ی کدنویسی و review» باشد، نه یک چیز optional.

Release:

• فرآیند باید آن‌قدر سبک باشد که release مکرر (مثلاً هفتگی) ممکن شود.
• ولی آن‌قدر هم شُل نباشد که buildهای شکسته و regressionها سر از دست کاربر دربیاورند.

بدون فرآیند Release سالم، یا در تله‌ی «لانچِ هر ۶ ماه یک بار با ریسک بالا» می‌افتی، یا در تله‌ی «لانچِ سریعِ پر از خطا»؛ هر دو برای اعتماد کاربر و morale تیم سمی‌اند.

۴. چرا همه‌ی این‌ها باز هم به «محصول» برمی‌گردد؟

فصل ۲ با این نکته تمام می‌شود:

• شاید بخشی از این توصیه‌ها بازتاب سلیقه‌ی نویسنده‌ها در شیوه‌ی کار باشد، اما observation تجربی آن‌ها در پروژه‌ها و شرکت‌های متعدد این است که:
  • تیم‌هایی که روی فرهنگ قوی و ارتباط خوب کار کرده‌اند، واقعاً وقت بیش‌تری را صرف نوشتن و Ship کردن محصول می‌کنند و کم‌تر درگیر این می‌شوند که «اصلاً چه چیزی را باید بسازیم».
• تیم قوی «تصادفی» ساخته نمی‌شود؛ حاصل seed و cultivation آگاهانه‌ی لیدها و بنیان‌گذاران است که هزینه‌ی بالای کار کردن با تیم dysfunctional را می‌فهمند.

اگر این کار را در ابتدا بکنی:

• فرهنگ self‑selecting به‌وجود می‌آوری که:
  • آدم‌های هم‌خوان با ارزش‌ها را جذب می‌کند،
  • و به newcomers کمک می‌کند سریع onboard شوند.
• بدون این‌ها، تازه‌وارد یا:
  • مدت‌ها وقتش در فهم «چگونه کار این تیم پیش می‌رود» می‌سوزد،
  • یا سعی می‌کند تیم را وادار کند مثل تیم قبلی خودش کار کند (که می‌تواند خوب یا فاجعه‌بار باشد).

نقطه‌ی پایانی‌شان تیز است:

• بیش‌ترِ «هزینه‌ی فرهنگ» در عمل هزینه‌ی ارتباط است: mission statement، جلسات، mailing list، chat، کامنت کد، داکیومنت‌ها و فرآیندهای تصمیم‌گیری.
• خیلی‌ها تعجب می‌کنند که چرا برای تیمی که فقط قرار است «محصول بسازد»، این‌همه ارتباط (و انرژی عاطفی) لازم است؛ اما واقعیت همین است: محصول تو نهایتاً درباره‌ی «ارتباط با انسان‌ها» است، نه فقط با ماشین.

در فصل بعد (۳)، این مبنا را روی «نقش لید» می‌گذارند: این‌که leader واقعاً چه‌کار می‌کند و چرا تقریباً هر تیم مؤثر، یک «کاپیتان» نیاز دارد.

---

حالا وارد فصل ۳ می‌شویم: «Every Boat Needs a Captain» – هر قایقی به کاپیتان نیاز دارد. این فصل مستقیماً درباره‌ی leadership است و برای هر کسی (نه فقط مدیرها) مفید است، چون درک بهتر رهبریت را به تو می‌دهد یا درک بهتری از رفتار لید خودت.

مقدمه فصل: کدام الگوی لیدری؟ Servant Leadership

نویسنده‌ها با یک نقل‌قول آغاز می‌کنند:

“Managers serve the team, while the team builds the product. Managers don’t serve the product unless they also happen to be on the team.”
— Brian Fitzpatrick, in a Google internal mailing list

این جمله خلاصه‌ی فلسفه‌شان است: manager واقعاً در خدمت تیم است، نه برعکس.

۱. Servant Leadership چیست؟

اصطلاح Servant Leadership را Robert Greenleaf در دهه‌ی ۱۹۷۰ مطرح کرد:

• Leader یک «خدمتگزار» است؛
• هدفش remove کردن موانع، حمایت از تیم، و ایجاد فضایی است که تیم بتواند مؤثرترین کارش را انجام دهد.
• برعکس الگوی traditional top‑down که لید فرمان می‌دهد و تیم اجرا می‌کند، Servant Leader فیلسوفه‌اش «خدمت به تیم تا تیم محصول را بسازد» است.

اما در واقعیت، خیلی از مهندسان با این مفهوم آشنا نیستند، چون:

• دانشگاه‌ها اصلاً درس «همکاری» نمی‌دهند؛
• بیشتر دانشجویان یک‌بار تجربه‌ی گروهی را از روی اجبار داشته‌اند و نتیجه‌اش بد بوده، نه آموزش واقعی مهارت تیم‌سازی. همین‌طور، خیلی از مهندسان فکر می‌کنند «manager = مزاحم» و کارش را «دخالت و چک کردن» می‌دانند. اما leadership خوب آن‌قدر نامرئی است که تیم حس می‌کند «خودمان همه چیز را درست کردیم».

  ۲. Manager، Tech Lead و Engineering Manager

در این فصل، تمرکز اصلی روی دو نقش است:

• Engineering Manager (people manager): کسی که مسئولیت عملکرد، رشد و حقوق اعضای تیم را دارد؛ اغلب خودش کد نمی‌نویسد یا خیلی کم می‌نویسد.
• Tech Lead (TL): کسی که همچنان یک مهندس contributing است (کد می‌نویسد)، اما مسئولیت فنی پروژه را هم به عهده دارد: design، architecture، تقسیم کار، اولویت‌بندی فنی و …

در بسیاری شرکت‌ها این دو نقش overlap هستند یا یک نفر هر دو را برعهده می‌گیرد (Manager/TL)، اما می‌توانند جدا باشند. چرا بعضی شرکت‌ها این تقسیم را دارند؟

• ممکن است یک Senior Engineer قدرت فنی بالایی داشته باشد اما اصلاً توانایی (یا علاقه‌ای) به people management نداشته باشد؛
• در عوض، ممکن است یک Engineering Manager از نظر فنی متوسط باشد، اما توانایی بالایی در گوش دادن، حل تعارض، career development و … دارد.

نویسنده‌ها تأکید می‌کنند:

• اجبار کردن یک مهندس فوق‌العاده برای این‌که مدیر شود، می‌تواند یک مهندس عالی را از دست بدهد و یک مدیر افتضاح به‌دست آورد (اشاره به «Peter Principle»).
• بهتر است مسیر شغلی تخصصی و مسیر مدیریتی را جدا نگه داشت، اگر فرد علاقه‌ای به people‑management نداشته باشد.

۳. The Engineering Lead

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

۳.۱. تصور اشتباه: «تیم خودران» بدون لید

بعضی باور دارند «اگر مهندسان واقعاً قوی باشند، لید لازم نیست؛ تیم خودش خودش را مدیریت می‌کند». اما نویسنده‌ها می‌گویند:

• در عمل دیده‌اند که اگر تیمی لید (یا مدیر) نداشته باشد، یکی از چند اتفاق می‌افتد:
  1. افراد سرشان را پایین می‌گذارند و روی کار تکنیکال می‌روند، اما هماهنگی بلندمدت ضعیف می‌شود و ممکن است در جهت‌های متفاوت حرکت کنند.
  2. یا یکی از اعضای تیم (معمولاً senior) به‌طور طبیعی رهبری را می‌گیرد؛ اما چون رسماً لیدر نیست، ممکن است انرژی زیادی صرف این شود که «چطور دیگران را به این کار متقاعد کنم؟»

چرا؟ چون تیم نیاز به تصمیم‌گیری دارد و شخصی باید آخرین کلمه را بزند؛ مخصوصاً در تصمیم‌های مهم. اگر این نقش واضح نباشد، یا سردرگمی پیش می‌آید یا نوعی «shadow leadership» پدید می‌آید که ناکارآمد است.

۳.۲. تعریف نقش

لید مهندسی واقعاً چه می‌کند؟ نه دیکتاتور که همه را زیر فرمان می‌برد، نه صرفاً یک ستاره‌ی تکنیکال که بقیه باید دنبالش کنند. در paradigm Servant Leadership:

• Remove کردن موانع: اگر تیم نیاز به resource، اطلاعات، یا تصمیم سازمانی دارد، لید باید آن را تأمین کند.
• Facilitation: اطمینان از این‌که تیم روی اهداف sync است و ارتباط شفاف دارد.
• تصمیم‌گیری نهایی: در مواقعی که consensus نمی‌شود یا زمان محدود است، لید قاطعانه تصمیم می‌گیرد (ولی بر اساس مشورت با تیم).
• Accountability: لید در برابر سازمان، نتایج و عملکرد تیم را به عهده می‌گیرد.

چیزهایی که لید نباید باشد:

• شخصیت alpha که همه را تحت فرمان دارد: این تیم را به dependence می‌کشاند.
• خودش کل کد را بنویسد: اگر لید همه‌ی کار را بکند، bus factor پایین می‌شود و رشد تیم متوقف می‌شود.

  ۴. تمایز Leadership از Management

یک نکته‌ی ظریف در فصل:

• Manager: به معنای دقیق، کسی که اختیارات اداری روی افراد دارد (hiring، firing، performance review، حقوق و …).
• Leader: کسی که تیم را هدایت می‌کند، اما لزوماً اختیارات اداری ندارد (مثل یک Tech Lead که مدیر نیست، اما lead می‌کند).

در فصل ۳، نویسنده‌ها اغلب از «lead» صحبت می‌کنند تا شامل هر دو گروه شود (Manager و TL)، اما وقتی لازم است، تمایز را مشخص می‌کنند.

۵. چرا لیدری برای تو مهم است؟

حتی اگر هرگز قصد نداری مدیر یا TL شوی، فهمیدن این مفاهیم:

• کمک می‌کند رفتار لید خودت را بهتر بفهمی؛
• اگر روزی به اجبار به سمت lead سوق داده شدی (یا خودت خواستی)، این ابزارها را داری؛
• و می‌توانی روی رفتار رهبر تیم خودت تأثیر بگذاری یا feedback بدهی، چون می‌فهمی کدام رفتار productive و کدام antipattern است.

نکته‌ی پایانی این بخش

فصل ۳ به دو قسمت تقسیم می‌شود:

1. Antipatterns – رفتارهایی که لیدها معمولاً (حتی بدون قصد بد) مرتکب می‌شوند و تیم را فلج می‌کنند.
2. Patterns – رفتارهای مثبتی که لید خوب را می‌سازند و تیم را قدرت می‌بخشند.

در بلوک بعدی، وارد بخش Antipatterns می‌شویم: Hire Lowering Standards، Ignore Low Performers، Treat Team Like Children، Be Everyone’s Friend، Compromise Hiring Bar، و چند مورد دیگر.

---

حالا وارد Antipatterns فصل ۳ می‌شویم؛ یعنی رفتارهای اشتباهی که لیدها معمولاً (حتی با نیت خوب) مرتکب می‌شوند و تیم را فلج می‌کنند.

Antipattern #1: نادیده گرفتن Low Performers

یکی از سخت‌ترین چالش‌های لیدری، مدیریت کسی است که performance پایین دارد.

مثال واقعی

Fitz اوایل مدیریت‌اش وقتی می‌خواست پاداش‌ها را توزیع کند، به مدیرش گفت: «عاشق مدیر بودن هستم!» مدیر بلافاصله پاسخ داد:

«گاهی تو پری دندونی (Tooth Fairy) هستی، گاهی باید دندان‌پزشک باشی.»

یعنی گاهی باید کار ناخوشایند «کشیدن دندان» را انجام دهی.

چرا نادیده گرفتن مشکل دارد؟

اکثر لیدها امیدوارند low performer به‌طور جادویی یا خودش بهتر شود یا برود، اما:

• این تقریباً هرگز اتفاق نمی‌افتد.
• «Hope is not a strategy.» (یکی از شعارهای تیم SRE گوگل)

در این بین:

• High performers وقت و انرژیشان را صرف کشاندن low performer می‌کنند؛
• Morale تیم آب می‌رود؛
• بقیه خیلی خوب می‌دانند کی low performer است، چون آن‌ها دارند بارش را بر دوش می‌کشند.

نتیجه‌ی نادیده گرفتن

• جذب high performers جدید سخت می‌شود (کسی نمی‌خواهد عضو تیمی شود که low performer دارد).
• High performers فعلی تیم را ترک می‌کنند.
• در نهایت، فقط low performers باقی می‌مانند، چون فقط آن‌ها نمی‌توانند جای دیگری شغل پیدا کنند.

همچنین، تو حتی به low performer هم لطف نمی‌کنی؛ چون ممکن است در تیمی دیگر واقعاً موفق باشد.

چگونه مدیریت کنی؟

نویسنده‌ها طی تجربه‌ی دردناک، این متد را یاد گرفته‌اند (تشبیهشان: کمک به کسی که لنگ می‌زند تا دوباره راه برود، بعد دوید):

1. بازه‌ی زمانی مشخص: مثلاً ۲–۳ ماه برای بهبود.
2. اهداف بسیار خاص و کوچک: incremental milestones تا موفقیت‌های کوچک احتمالی زیاد باشد.
3. جلسه‌ی هفتگی: چک کردن progress، انتظارات explicit را برای هر هفته مشخص کن.
4. نتیجه‌ی شفاف: اگر نتواند follow کند، خیلی زود واضح می‌شود (هم برای تو، هم برای او).

معمولاً یکی از دو چیز اتفاق می‌افتد:

• خودش متوجه می‌شود که نمی‌تواند و استعفا می‌دهد (راه‌حل بدون درگیری).
• یا عزم خودش را جمع می‌کند و واقعاً بهتر می‌شود.

در هر حال، تو سریع حرکت کردی و یا او را کمک کردی «up» شود یا «out».

اگر خیلی دیر عمل کنی، رابطه‌ی او با تیم و تو آن‌قدر خراب می‌شود که دیگر نمی‌توانی کمک‌اش کنی.

Antipattern #2: نادیده گرفتن Human Issues

لیدری به دو بخش اصلی نیاز دارد: تکنیکال و social. خیلی از لیدها (که از نقش فنی ترفیع گرفته‌اند) فقط روی تکنیکال تمرکز می‌کنند و مشکلات انسانی را ignore می‌کنند.

مثال واقعی: Jake و Pablo

دوست نزدیک Fitz (Jake) تازه بچه‌دار شده بود و چند هفته از خانه کار می‌کرد؛ برای Fitz (که قبلاً هم remote با Jake کار کرده بود) مشکلی نبود و Jake هم مثل همیشه productive بود.

مدیرشان، Pablo، از دفتر دیگری می‌آمد و فهمید Jake بیش‌تر هفته را از خانه کار می‌کند. Pablo عصبانی شد و گفت باید سر کار بیاید، Jake توضیح داد که productivity اش ثابت است و فقط برای چند هفته راحت‌تر است. پاسخ Pablo:

«Dude, people have kids all the time. You need to go into the office.»

Jake که فردی خونسرد بود، وحشی شد و احترامش به Pablo به‌طور جدی آسیب دید.

تحلیل

Pablo می‌توانست:

• کمی empathy نشان بدهد؛
• بگوید «چند هفته remote مشکلی ندارد»؛
• یا شرایطی Negotiate کند (مثلاً ۱–۲ روز هفته بیا دفتر).

هرکدام از این‌ها بهتر از آن لحن سرد و بی‌احساس بود.

نکته‌ی کلیدی: اگر فقط روی تکنیکال متمرکز باشی و مسائل انسانی را نادیده بگیری، رضایت و اعتماد تیم را از دست می‌دهی.

Antipattern #3: دوست همه بودن (Be Everyone’s Friend)

اولین تجربه‌ی لیدری بیش‌تر افراد: ترفیع در همان تیمی که عضو بودند. خیلی از لیدها نمی‌خواهند دوستی‌هایشان را از دست بدهند، پس بیش از حد تلاش می‌کنند که دوستی حفظ شود.

مشکل

وقتی تو قدرت career کسی را داری، او ممکن است فشار احساس کند که باید به‌صورت مصنوعی به اشاره‌های دوستانه‌ی تو پاسخ دهد؛ یعنی چیزی که به‌نظر «دوستی» است، واقعاً معصومانه نیست.

نکته‌ی مهم:

• «دوست بودن» و «soft touch leadership» یکی نیست؛ می‌توانی consensus بسازی و تیم را lead کنی، بدون این‌که peer بقیه باشی.
• همین‌طور می‌توانی لید سختگیر باشی، بدون این‌که دوستی‌های قبلی را به باد بدهی.

توصیه:

• یک راه: Lunch با تیم – فضای غیررسمی برای ارتباط اجتماعی، بدون این‌که احساس ناراحتی به وجود بیاید.
• اگر کسی که باید مدیرش باشی دوست خیلی خوب (و هم‌سطح) تو بوده و خودش self‑managing نباشد و سخت‌کوش نباشد، موقعیت برای هر دو استرس‌زا خواهد بود. نویسنده‌ها توصیه می‌کنند تا حد امکان از این وضعیت دوری کنی.

Antipattern #4: پایین آوردن استانداردهای استخدام (Compromise Hiring Bar)

استیو جابز گفته:

«A people hire other A people; B people hire C people.»

وقتی تیم نیاز به استخدام سریع دارد، ممکن است از میان ۴۰–۵۰ نفر مصاحبه شده «۵ نفر بهترین» را انتخاب کنی، حتی اگر هیچ‌کدام‌شان واقعاً hiring bar را pass نکرده باشند. این سریع‌ترین راه ساختن تیم متوسط است.

هزینه‌ی استخدام اشتباه

هزینه‌ی پیدا کردن فرد درست (کار recruiter، تبلیغات، رفرنس و …) بسیار کم‌تر از هزینه‌ی نگه‌داشتن کسی است که هرگز نباید استخدام می‌شد:

• افت productivity تیم،
• stress تیم،
• زمان صرف‌شده برای managing او تا جایی که بالاخره اخراجش کنی،
• اگر هم نگهش داری، هزینه‌اش از همه بیش‌تر است (تیم کاملاً فلج می‌شود).

اگر تو مدیر تیمی هستی که سازمان مدام نیروی بی‌کیفیت برایت می‌فرستد، تا آخر جنگ کن برای hiring quality؛ اگر هنوز بی‌فایده است، شاید وقت آن رسیده که دنبال شغل جدید بگردی. بدون مواد اولیه‌ی خوب، محکوم به شکست هستی.

Antipattern #5: رفتار مثل بچه با تیم (Treat Team Like Children)

بهترین راه برای نشان دادن «بی‌اعتمادی» به تیم، رفتار کردن مثل بچه یا زندانی با آن‌هاست. آدم‌ها معمولاً همان‌طور رفتار می‌کنند که با آن‌ها رفتار می‌شود.

مثال‌ها:

• Micromanagement مداوم،
• بی‌احترامی به توانایی‌هایشان،
• هیچ فرصتی برای مسئولیت‌پذیری ندادن.

اگر تو باید دائماً micromanage کنی چون بهشان اعتماد نداری، پس اشتباه استخدامی داری. اگر افرادی استخدام کردی که لیاقت اعتماد دارند و اعتمادت را نشان بدهی، معمولاً خودشان را به ارتفاع آن بالا می‌کشند.

مثال کنفرانس Fitz

Fitz یک کنفرانس در شیکاگو برگزار می‌کرد و سالن را از یک موسسه‌ی محلی اجاره کرده بود. مدیر تأسیسات بعد از تور کوتاهی، فقط کلید را داد به Fitz و گفت «هفته‌ی دیگه ازت پس می‌گیرم».

• هیچ لیستی از دستورات و ممنوعیت‌ها نداد.
• نظارت زیادی هم نکرد.
• نتیجه: Fitz و تیمش احساس مسئولیت کردند و از سالن مثل مال خودشان مراقبت کردند؛ حتی بالاتر از انتظار، جا را تمیز و مرتب نگه داشتند.

مثال Google

گوگل برای کارمندان:

• کابینت‌های پر از لوازم‌التحریر دارد (مفت)،
• Tech Stops: شبیه فروشگاه الکترونیک self‑service برای کابل، ماوس، USB و … بدون کنترل خاص.

خیلی از شرکت‌های معمولی با وحشت می‌گویند «مطمئناً دارند پول هدر می‌دهند، همه چیز را می‌دزدند!» اما:

• هزینه‌ی داشتن workforce که مثل بچه رفتار می‌کنند بسیار بالاتر از هزینه‌ی چند خودکار و کابل USB است.

وقتی به مهندسان اعتماد کنی، خودشان احساس مسئولیت می‌کنند و «Do The Right Thing» را انجام می‌دهند.

---

حالا وارد Positive Patterns (الگوهای مثبت لیدری) می‌شویم.

Pattern #1: Lose the Ego (نه به Ego فردی، بله به Ego جمعی)

این ساده‌ترین راه گفتن این است که «تواضع را جایگزین غرور کن». هیچ‌کس نمی‌خواهد با کسی کار کند که مرتب طوری رفتار می‌کند انگار مهم‌ترین آدم اتاق است.

نشانه‌های Ego زیاد

• همیشه باید اولین یا آخرین حرف را در هر موضوع بزنی؟
• احساس می‌کنی باید روی هر جزئیات proposal یا بحثی نظر بدهی؟

تفاوت بین تواضع و ضعف

تواضع به معنای «پادری بودن» نیست. اعتماد‌به‌نفس هیچ مشکلی ندارد، فقط مثل Know-it-all رفتار نکن.

Collective Ego (ایگوی جمعی)

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

مثلاً Apache Software Foundation جوامعی با هویت قوی ساخته که افراد self-promotion را رد می‌کنند؛ اگر کسی بیاید که بیش‌تر به خودنمایی اهمیت می‌دهد تا محصول، تیم او را نمی‌پذیرد.

داستان واقعی: John Tukey

John Tukey (ریاضی‌دان بزرگ) تقریباً همیشه لباس casual می‌پوشید و وارد دفترهای مهم می‌شد؛ گاهی مدت‌ها طول می‌کشید تا طرف مقابل بفهمد این یک first-class man است.

Richard Hamming می‌گوید:

«ظاهر conforming بودن، تو را راه می‌برد. اگر بخواهی مدام ego خودت را در جاهای مختلف جا بزنی و بگویی “من به روش خودم انجامش می‌دهم”، قیمت جزئی ولی ثابتی در طول کل career خودت می‌پردازی، و در طول یک عمر، این تبدیل به یک مشکل عظیم می‌شود.»

Pattern #2: Be a Zen Master (مثل استاد ذن آرام باش)

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

• زبان بدن تو،
• واکنش‌های تو به چت‌های کوچک،
• سیگنال‌هایت سر ناهار.

همه دارند می‌خوانند: آیا تو اعتماد‌به‌نفس داری یا ترس؟

مثال واقعی: Bill (مدیر Fitz)

Bill هر موقع یک مشکل بزرگ پیش می‌آمد، هرگز panic نمی‌کرد.

• یک بازویش را روی سینه‌اش می‌گذاشت،
• چانه‌اش را روی دستش می‌گذاشت،
• شروع به پرسیدن سوال درباره‌ی مشکل می‌کرد (معمولاً از کسی که دارد کاملاً panic می‌کند).

این کار، آن شخص را آرام می‌کرد و کمک می‌کرد روی حل مشکل تمرکز کند بجای این‌که مثل مرغ سر بریده دور خودش بچرخد.

Fitz می‌گوید اگر کسی می‌آمد و می‌گفت ۱۹ دفتر شرکت توسط Alien حمله شده، Bill جواب می‌داد:

«ایده‌ای داری چرا نشدن ۲۰ دفتر؟»

Zen Trick: پرسیدن سوال

وقتی یکی از تیم از تو advice می‌خواهد، خیلی هیجان‌انگیز است چون بالاخره می‌توانی چیزی را Fix کنی! اما آخرین جایی که باید بروی solution mode است.

آن شخص معمولاً نمی‌خواهد تو مشکلش را حل کنی، بلکه می‌خواهد کمکش کنی که خودش حلش کند.

راه آسان: پرسیدن سوال.

این به معنای جایگزینی خودت با Magic 8 Ball نیست (که دیوانه‌کننده و بی‌فایده است)؛ بلکه کمک کنی مشکلش را refine و explore کند. معمولاً این کار، کارمند را به جواب هدایت می‌کند و جواب او خواهد بود، که به ownership و مسئولیت می‌انجامد.

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

Pattern #3: Be a Catalyst (کاتالیزگر باش)

در شیمی catalyst چیزی است که واکنش شیمیایی را تسریع می‌کند، اما خودش مصرف نمی‌شود. یکی از کارهای کاتالیزگرها این است که مواد واکنش‌دهنده را به هم نزدیک می‌کنند.

این نقشی است که اغلب به‌عنوان لید باید بازی کنی.

Build Consensus (ایجاد اجماع)

یکی از رایج‌ترین کارهای team leader این است که consensus بسازد.

• ممکن است کل فرآیند را از ابتدا تا انتها lead کنی،
• یا فقط به آن یک هل ملایم بدهی تا سریع‌تر پیش برود.

ساختن consensus یک مهارت لیدری است که حتی توسط unofficial leaders استفاده می‌شود، چون می‌توانی بدون هیچ authority واقعی، lead کنی.

Remove Roadblocks (برطرف کردن موانع)

گاهی تیم روی چیزی consensus دارد اما به roadblock می‌خورد.

خیلی از موانع برای تیم غیرممکن هستند، اما برای تو به‌عنوان لید آسان است که حلشان کنی:

مثال ۱: تیم Fitz چند هفته سعی کرد مشکلی را با Legal Department حل کنند؛ وقتی به Fitz آمدند، او در کم‌تر از ۲ ساعت حلش کرد چون می‌دانست باید با چه کسی صحبت کند.

مثال ۲: تیم Ben نیاز به server resources داشت و نمی‌توانستند allocated شود؛ Ben چون با تیم‌های دیگر در ارتباط بود، همان بعدازظهر منابع را برایشان فراهم کرد.

داستان “Know Where to Put the Chalk Mark”

یک استاد مکانیک بازنشسته شده؛ شرکت قدیمی‌اش مشکلی دارد که هیچ‌کس نمی‌تواند حل کند. استاد را صدا می‌کنند، او ماشین را بررسی می‌کند، گوش می‌دهد، و بالاخره یک X کوچک با گچ روی ماشین می‌زند و می‌گوید:

«دقیقاً اینجا یک سیم شل شده، تعمیرش کن.»

تعمیرکار باز می‌کند، سیم را محکم می‌کند، مشکل حل می‌شود. صورت‌حساب می‌رسد: ۱۰,۰۰۰ دلار. CEO عصبانی می‌شود و breakdown خرج را می‌خواهد.

استاد صورت‌حساب جدید می‌فرستد:

• خودِ علامت گچ = ۱ دلار
• دانستن اینکه کجا باید علامت بزنی = ۹,۹۹۹ دلار

این داستان درباره‌ی wisdom است: یک تنظیم کوچک ولی دقیق می‌تواند اثر عظیم داشته باشد.

Ben تیمش را مثل یک blimp تصور می‌کند که آرام در یک جهت حرکت می‌کند. بجای micromanage و اصلاحات مداوم، او یک هفته را فقط می‌بیند و گوش می‌دهد؛ آخر هفته یک علامت گچ کوچک در مکان دقیق روی blimp می‌زند و یک “tap” کوچک اما حیاتی می‌زند تا مسیر تنظیم شود.

Pattern #4: Remove Roadblocks (موانع را بردار)

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

بعضی از موانع تقریباً برای اعضای تیم غیرممکن هستند، اما برای تو آسان. کمک کردن در این موارد بسیار ارزشمند است.

توضیح بیش‌تر در بخش Catalyst همین فصل بود؛ این یکی از انواع catalyst بودن است.

Pattern #5: Be a Teacher and Mentor (معلم و مربی باش)

کمک به رشد مهارت‌های تیم، یکی از بهترین سرمایه‌گذاری‌های بلندمدت است.

وقتی وقت می‌گذاری به افراد یاد بدهی، نه‌تنها مهارتشان بالا می‌رود، بلکه اعتماد و احترامشان به تو افزایش می‌یابد. این باز به HRT بازمی‌گردد.

---

حالا وارد الگوهای بعدی لیدری می‌شویم.

Pattern #6: Set Clear Goals (اهداف واضح تعیین کن)

یکی از بزرگ‌ترین چیزهایی که می‌توانی برای تیمت انجام دهی این است که اهداف را واضح کنی.

چرا مهم است؟

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

مثال: Mission Statement

گاهی شنیدن واژه‌ی Mission Statement باعث می‌شود فکر کنیم به چیزی مانند این برسیم:

«ما آرزو می‌کنیم محبوب‌ترین و باارزش‌ترین شرکت در جهان باشیم…»

این نوع بیانیه‌ها، marketing doublespeak هستند و هیچ معنای عملی ندارند.

Mission Statement واقعی

یک mission statement خوب، جهت را مشخص می‌کند و scope را محدود می‌کند. مثال واقعی از Google Web Toolkit (GWT):

«ماموریت GWT این است که تجربه‌ی وب را برای کاربران به‌شدت بهبود ببخشد، با این که توسعه‌دهندگان بتوانند با ابزارهای Java موجود، AJAX بدون سازش برای هر مرورگر مدرن بسازند.»

بعد از این، تیم GWT یک سند کامل با عنوان “Making GWT Better” نوشتند که جمله‌جمله‌ی mission statement را توضیح می‌داد و حتی یک بخش Nongoals (چیزهایی که پروژه نباید روی آن‌ها کار کند) هم داشت.

فایده

با داشتن mission statement واضح:

• همه می‌دانند چه کاری باید انجام دهند؛
• می‌توانی feature request های خارج از scope را به‌راحتی رد کنی؛
• سال‌ها کار روی چیزهای نامرتبط را ذخیره می‌کنی.

Pattern #7: Be Honest (صادق باش)

صداقت در لیدری بسیار حیاتی است، چه در feedback دادن، چه در اعلام مشکلات واقعی.

مثال: Constructive Criticism

بسیاری از مردم از گرفتن criticism می‌ترسند چون فکر می‌کنند مجبورند روی تمام نقدهایی که دریافت می‌کنند action بگیرند، حتی اگر با آن موافق نباشند.

اما واقعیت این است: criticism یک هدیه است که می‌توانی قبول یا رد کنی.

مثلاً قبل از مصاحبه‌ی مهم، کت و شلوار مورد علاقه‌ات را پوشیدی و از دوستت پرسیدی: «چطور به‌نظر می‌رسم؟» او گفت:

«اسفناج بین دندان‌هات مانده، و راستش از کتت بدم می‌آد.»

تو می‌توانی اسفناج را پاک کنی، ولی لزومی ندارد لباسـت را عوض کنی.

چگونه نقد سازنده بدهیم؟

اشتباه: «دوست عزیز، کاملاً control flow اون متد رو اشتباه نوشتی. باید از pattern استاندارد xyzzy استفاده کنی مثل بقیه.»

این feedback پر از antipattern است:

• به او می‌گویی «اشتباه است» (انگار دنیا سیاه و سفید است!).
• demand می‌کنی چیزی را تغییر دهد.
• به او می‌گویی کاری خلاف بقیه کرده (احساس احمق بودن).

درست: «هی، من کمی confused شدم از control flow اینجا. فکر می‌کنم pattern xyzzy ممکن است واضح‌تر و maintainable تر باشد؟»

توجه کن:

• از humility استفاده کردی تا سوال را درباره‌ی خودت کنی، نه او.
• او اشتباه نکرده؛ تو فقط مشکل در درک کد داری.
• پیشنهاد را فقط offer می‌کنی، نه demand.
• بحث در حوزه‌ی کد باقی می‌ماند، نه مهارت یا ارزش فردی.

Pattern #8: Track Happiness (شادی تیم را رصد کن)

به‌عنوان لید، یکی از راه‌های افزایش بهره‌وری بلندمدت (و جلوگیری از ترک شغل) این است که گاهی از شادی تیم خبر بگیری.

چگونه؟

بهترین لیدهایی که با آن‌ها کار کرده‌ایم، روانشناسان آماتور بودند: گاهی از وضعیت رفاهی اعضا خبر می‌گرفتند، مطمئن می‌شدند که برای کارشان recognition دریافت کنند، و سعی می‌کردند خوشحال باشند.

یکی از لیدها: یک spreadsheet از تمام کارهای کثیف و ناخوشایند ساخت و مطمئن می‌شد این کارها به‌صورت مساوی بین تیم تقسیم شوند.

لید دیگر: ساعات کاری تیمش را زیر نظر داشت و از comp time و تفریحات تیمی استفاده می‌کرد تا از burnout جلوگیری کند.

لید سوم: در جلسات one-on-one ابتدا مشکلات فنی مهندس را حل می‌کرد (برای یخ شکنی)، سپس مطمئن می‌شد که همه چیز برای کار کردن دارد. بعد گرم که می‌شدند، کمی درباره‌ی این‌که چقدر از کارش لذت می‌برد و منتظر چه چیزی است صحبت می‌کردند.

سوال طلایی

یکی از ارزشمندترین ابزارها در پایان هر one-on-one این سوال است:

«به چه چیزی نیاز داری؟»

این سوال ساده، یک راه عالی برای wrap up است و مطمئن می‌شوی هر نفر آن‌چه را برای productive و خوشحال بودن نیاز دارد، دریافت کند. اگر این را هر بار بپرسی، بالاخره تیمت یادش می‌ماند و گاهی با یک لیست از چیزهایی که نیاز دارند پیش تو می‌آیند.

Career Tracking

بخش بزرگی از tracking happiness، tracking career است. اگر بپرسی «۵ سال دیگر خودت را کجا می‌بینی؟» بیش‌تر اوقات یک shrug و نگاه خالی می‌گیری. ولی معمولاً چند چیز وجود دارد که همه می‌خواهند:

• Promote شوند،
• چیز جدیدی یاد بگیرند،
• چیزی مهم launch کنند،
• با آدم‌های باهوش کار کنند.

اگر می‌خواهی لید موثری باشی، باید فکر کنی چطور می‌توانی همه‌ی این‌ها را محقق کنی و به تیمت بگویی که به این فکر می‌کنی. مهم‌تر از همه: این اهداف ضمنی را صریح کن تا وقتی career advice می‌دهی، یک مجموعه واقعی از معیارها برای ارزیابی موقعیت‌ها و فرصت‌ها داشته باشی.

Pattern #9: Intrinsic Versus Extrinsic Motivation (انگیزه‌ی درونی در برابر بیرونی)

در TED Talk معروف Dan Pink درباره‌ی motivation، او توضیح می‌دهد که برای کارهای خلاقانه (مانند نوشتن نرم‌افزار)، Intrinsic Motivation بسیار مهم‌تر از Extrinsic Motivation است.

Extrinsic Motivation

پاداش‌های بیرونی مثل:

• پول بیش‌تر،
• عنوان (Title) بهتر،
• امتیازات (Perks) بیش‌تر.

این‌ها برای کارهای مکانیکی کار می‌کنند، اما برای کار خلاقانه، اثر می‌توانند معکوس باشد.

Intrinsic Motivation

پاداش‌های درونی که واقعاً کارآیی را بالا می‌برند:

1. Autonomy (استقلال): آزادی در تصمیم‌گیری درباره‌ی نحوه‌ی کار.
2. Mastery (تسلط): فرصت برای یادگیری و بهتر شدن.
3. Purpose (هدف): احساس کردن که کارت اهمیت دارد.

اگر این سه را برای تیمت فراهم کنی، حتی اگر حقوق خیلی بالا نباشد، مهندسانت بسیار productive و خوشحال خواهند بود.

Other Tips and Tricks (نکات و ترفندهای دیگر)

Delegate, But Get Your Hands Dirty (واگذار کن، اما دست‌هایت را کثیف کن)

وقتی از نقش individual contributor به leadership می‌روی، سخت‌ترین کار یافتن balance است:

• در ابتدا، تمایل داری همه‌ی کارها را خودت انجام دهی.
• بعد از مدتی، ممکن است هیچ‌کدام را خودت انجام ندهی.

راه درست:

• اگر تازه وارد لیدری شدی، باید سخت کار کنی تا کارها را به مهندسان دیگر delegate کنی، حتی اگر برایشان خیلی طول بکشد. این یکی از راه‌های حفظ sanity تو و رشد تیم است.
• اگر مدت‌هاست لیدی یا تیم جدیدی گرفتی، یکی از آسان‌ترین راه‌های کسب احترام تیم این است که دست‌هایت را کثیف کنی — معمولاً با برداشتن یک کار کثیف که هیچ‌کس نمی‌خواهد انجامش دهد.

رزومه و لیست دستاوردهایت می‌تواند یک مایل طول داشته باشد، ولی هیچ‌چیز مانند پریدن و انجام کار سخت، مهارت و تعهد (و فروتنی) تو را به تیم نشان نمی‌دهد.

Seek to Replace Yourself (به دنبال جایگزین خودت باش)

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

این از فرآیند hiring شروع می‌شود: اگر می‌خواهی یکی از اعضای تیم جایت را بگیرد، باید افرادی استخدام کنی که قادر باشند جایت را بگیرند — به‌عبارت دیگر: «افرادی باهوش‌تر از خودت استخدام کن.»

وقتی اعضای تیم داری که می‌توانند کارت را انجام دهند، باید به آن‌ها فرصت بدهی مسئولیت‌های بیش‌تری بگیرند یا گاهی تیم را lead کنند. اگر این کار را بکنی، سریع می‌بینی که چه کسی بیش‌ترین استعداد برای لیدری دارد و چه کسی می‌خواهد لید کند.

نکته: به یاد داشته باش بعضی افراد ترجیح می‌دهند فقط high-performing individual contributor باشند، و این هم OK است. ما همیشه از شرکت‌هایی تعجب کرده‌ایم که بهترین مهندسانشان را — بر خلاف میلشان — به نقش‌های مدیریتی می‌کشند. این معمولاً یک مهندس عالی از تیمت کم می‌کند و یک مدیر بد اضافه می‌کند.

Know When to Make Waves (بدان کی باید موج بزنی)

گاهی موقعیت‌های سخت پیش می‌آید که تمام سلول‌های بدنت به تو می‌گویند: «هیچ کاری نکن».

ممکن است مهندسی باشد که مهارت فنی‌اش کافی نیست، یا شخصی که جلوی هر قطاری می‌پرد، یا کارمند بی‌انگیزه‌ای که ۳۰ ساعت هفته کار می‌کند. تو به خودت می‌گویی:

«کمی صبر کن، خودش درست می‌شود.»

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

با صبر کردن، فقط اجتناب‌ناپذیر را به تاخیر می‌اندازی و در این مسیر آسیب غیرقابل توصیفی وارد می‌کنی. پس عمل کن، و سریع عمل کن.

---

حالا وارد فصل ۴: Dealing with Poisonous People (برخورد با افراد سمی) می‌شویم. این فصل به‌شدت کاربردی و مهم است.

فصل ۴: برخورد با افراد سمی

همان‌طور که در ابتدای کتاب گفته شد: «مهندسی کار آسانی است، آدم‌ها سخت‌اند.»

تاکنون، تمرکز ما روی خود تو و تیمت بوده است. حالا می‌خواهیم به بیرون نگاه کنیم: چطور از فرهنگ تیمت در برابر افراد مخرب محافظت کنی؟

تعریف “Poisonous” (سمی)

وقتی برای اولین بار درباره‌ی این موضوع سخنرانی کردیم، اسمش را “How Projects Survive Poisonous People” گذاشتیم. عنوان جنجالی بود و همیشه سالن پر می‌شد — اما خطر دارد.

خطر برچسب‌زدن

اصطلاح “Poisonous Person” یک لیبل منفی است که خط تقسیم ایجاد می‌کند: ما (آدم‌های خوب) در برابر آن‌ها (آدم‌های بد). اما راه بهتر این است: بجای رد کردن افراد، باید رفتارهای غیرقابل تحمل را رد کنی.

افراد صرفاً خوب یا بد نیستند؛ رفتارها هستند که باید شناسایی و اصلاح شوند.

پس در این فصل، “Poisonous Person” فقط یک کوتاه‌نویسی برای «شخصی که رفتار خوبی ندارد» است، نه یک حکم اعدام!

Fortifying Your Team (تقویت دفاع‌های تیم)

به یاد داستان خمیرمایه (Yeast Starter) در فصل ۲ هستی؟

• اگر starter culture تیمت قوی باشد، می‌تواند تأثیر منفی افراد جدید را خنثی کند.
• اگر ضعیف باشد، فرهنگ جدید (معمولاً مخرب) تیم را تسخیر می‌کند.

نمونه‌های واقعی:

• Subversion از همان اول با تیمی بسیار مؤدب و محترم شروع شد. ۱۵ سال گذشته، ولی فرهنگ همچنان همان است: افراد جدید یا با فرهنگ سازگار می‌شوند یا می‌روند.
• برعکس، بعضی پروژه‌ها (مثل کامیونیتی Linux Kernel) از ابتدا پر از اشخاص aggressive بودند، و همچنان همان فرهنگ ادامه دارد.

بدترین دفاع: امیدواری که مشکلات خودشان حل شوند.
بهترین دفاع: تقویت فرهنگ تیم با best practice‌های محکم (Mission Statement، مستندسازی، Code Review، …).

Identifying the Threat (شناسایی تهدید)

بزرگ‌ترین خطر: از دست دادن Attention و Focus تیم.

این‌ها کمیاب‌ترین منابع تو هستند. افراد سمی می‌توانند تمام انرژی تیم را روی بحث‌های بی‌فایده، دفاع از خود، یا درگیری‌های احساسی بگذارند.

چطور رفتار سمی را تشخیص بدهی؟

نویسنده‌ها می‌گویند وقتی این نشانه‌ها را دیدند، ذهناً “Bozo Bit” فرد را می‌زنند — یعنی یک علامت ذهنی می‌گذارند که این شخص مدام رفتارهای مخرب دارد و باید خیلی مراقب باشند.

Signal #1: بی‌احترامی به وقت دیگران

کسانی که بجای خواندن documentation، پرسیدن سوالاتی که خودشان می‌توانند جوابش را پیدا کنند، یا دائماً با چیزهای غیرضروری وقت تیم را می‌گیرند.

مثال: Charlie در پروژه‌ی Subversion هر ۲–۳ ساعت یک ایمیل ارسال می‌کرد با ایده‌های تازه‌اش (بدون هیچ کد نوشتنی). سپس جواب سوالات کاربران را هم غلط می‌داد و تیم مجبور بود دوباره اصلاح کنند. مدت‌ها طول کشید تا بفهمیم او در واقع poisonous است.

Signal #2: Ego (غرور افراطی)

کسی که هرگز نمی‌تواند consensus را بپذیرد، نظر دیگران را گوش کند، یا به مصالحه برسد.

مثال: یک برنامه‌نویس باهوش آمد و اعلام کرد «طراحی کل Subversion اشتباه است و باید از صفر شروع شود!» یک هفته کامل صرف بحث با او شد. او حاضر به compromise نبود و پروژه‌ای که در beta بود قرار نبود از صفر شروع شود. بالاخره مجبور شدیم بحث را ول کنیم. جالب این‌که بعداً فهمیدیم بعضی از حرف‌هایش درست بود، اما Subversion با همان design موفق شد!

نکته: نه کسی ۱۰۰٪ حق داشت نه غلط؛ بلکه وقت تلف کردن در بحث‌هایی که هیچ وقت تمام نمی‌شوند مشکل بود.

Signal #3: Perfectionism (کمال‌گرایی افراطی)

ظاهرش خوب است: فردی فروتن، مؤدب، محترم، شنونده. اما تهدید فلج شدن را به همراه دارد.

مثال: Patrick یک مهندس عالی بود، اما هیچ وقت طراحیش کامل نمی‌شد. تیم منتظر ماند و ماند؛ هرگز شروع به کد نوشتن نکردند چون او هر بار می‌گفت «ممکن است مشکلی در آینده پیش بیاید». فلج شده بودیم.

Repelling the Poison (دفع کردن سم)

هدف ما Boot کردن Behavior است، نه شخص.

اول باید به شخص واضح گفت «این رفتار قابل قبول نیست». اگر بعد از چندین هشدار، تغییر نکرد، آن وقت بیرونش کردن معنا دارد.

Strategy #1: Redirect Energy of Perfectionists (انرژی کمال‌گراها را هدایت کن)

وقتی یک راه‌حل “کافی” پیدا شد، کمال‌گرا را سمت یک مشکل دیگر هدایت کن.

مثال Patrick: بهش گفتیم «باشه، الان روی همین طراحی شروع می‌کنیم، امیدواریم تو کمکمون کنی اگر مشکلی پیش اومد.» او موافقت کرد و شروع به obsess شدن روی موضوع دیگری کرد!

این ترفند برای کسانی که مرتب شکایت می‌کنند هم کار می‌کند: بهشان بگو testing انجام دهند و regressionها را report کنند — همچنان complaint دارند ولی مفید است!

Strategy #2: Don’t Feed the Energy Creature (به تریبون دادن وقتت را تلف نکن)

شعار قدیمی Usenet: «Don’t feed the trolls».

• اگر کسی عمداً trolling می‌کند (می‌خواهد تو را عصبانی کند)، سکوت کن.
• هر چقدر جواب بدهی، بیشتر از انرژی تو تغذیه می‌کند.
• معمولاً وقتی هیچ‌کس توجه نکند، خودش خسته می‌شود و می‌رود.

سخت است که جواب ندهی، ولی قوی باش!

Strategy #3: Don’t Get Overly Emotional (احساساتی نشو)

حتی اگر شخص عمداً troll نیست، آسان است که دفاعی شوی.

• اگر کسی تو را متهم کند که طراحی بدی داشتی، یا تئوری توطئه ارائه دهد، یا وقتت را با سوالات بی‌فایده بگیرد، عصبانی می‌شوی.
• اما کارت ساختن محصول عالی است، نه توجیه کردن دائمی.
• هرچه احساساتت قوی‌تر باشد، احتمال بیشتری دارد ساعت‌ها یا روزها صرف نوشتن پاسخ‌های احساسی کنی.

قانون: نبردهایت را با دقت انتخاب کن و آرام بمان.

Strategy #4: Look for Facts in the Bile (در بین تلخی، فکت را پیدا کن)

همیشه با دادن benefit of the doubt شروع کن.

• اگر کسی شکایت می‌کند، با دقت گوش کن.
• آیا نکته‌ی واقعی دارد؟ آیا چیزی برای یادگیری هست؟

مثال: یک روز یک ایمیل عصبانی از یک leader معروف‌ی در جامعه open source دریافت کردیم. پر از توهین و اغراق بود. اما یکی از تیم ما فقط چند سوال فنی درباره‌ی bug پرسید و تمام توهین‌ها را نادیده گرفت. فرستنده بازهم جواب داد (با سم بیشتر)، ولی تیم ما همچنان فقط روی bug تمرکز کرد و گفت:

«ممنون از bug report، می‌دونم چطور حلش کنم — به‌زودی patch منتشر می‌کنیم.»

تا پایان بحث، فرستنده‌ی اصلی تمام اعتبارش را از دست داد و دیگر اطرافش نماند.

---

ادامه فصل ۴ را ارسال می‌کنم.

بخش دوم: استراتژی‌های دفاعی (ادامه)

حالا که الگوهای تهدید را شناختیم، باید بدانیم چطور به رفتار سمی پاسخ دهیم (نه خود شخص).

Strategy #5: Redirect Energy of Perfectionists (هدایت انرژی کمال‌گراها)

وقتی یک راه‌حل “خوب به اندازه کافی” (good-enough) پیدا کردی، کمال‌گرا را به سمت یک مشکل دیگری که هنوز نیاز به توجه دارد هدایت کن.

مثال Patrick: در پروژه‌ی Subversion، ما در یک نقطه Patrick را کنار کشیدیم و گفتیم:

«خب، ما همین الان با همین طراحی شروع به کار می‌کنیم و می‌بینیم چه اتفاقی می‌افتد. امیدواریم بتونی بهمون کمک کنی وقتی مشکلی پیش اومد.»

تعجب‌آور این بود که Patrick قبول کرد! بعد از آن، او به سمت یک موضوع دیگر رفت و روی آن obsessed شد. هیچ احساسی هم جریحه‌دار نشد و Patrick همچنان به تلاش کلی کمک می‌کرد.

یک ضرب‌المثل قدیمی هست: «اجازه نده perfect دشمن good باشد.»

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

ترفند جانبی: Complainers (افراد شکایتگر)

این ترفند “هدایت انرژی” برای افرادی که بیشتر شکایت می‌کنند تا کمک هم کار می‌کند.

• وسوسه‌انگیز است که بهشان بگویی: “Patches welcome” (کد بنویس یا ساکت شو!).
• بهتر است سعی کنی علاقه‌شان را به testing رسمی نرم‌افزار جلب کنی و regression ها را report کنند.
• این کار به آن‌ها اجازه می‌دهد همچنان شکایت کنند، اما به شکل مفید!

Strategy #6: Don’t Feed the Energy Creature (انرژی به هیولا نده)

این یک قانون قدیمی Usenet است.

به‌خصوص برای Troll های عمدی کارآمد است — افرادی که هدفشان عصبانی کردن تو یا تیمت است.

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

نکته: اغلب نیاز به قدرت اراده بسیار زیادی دارد تا جواب ندهی. قوی بمان!

Strategy #7: Don’t Get Overly Emotional (بیش از حد احساساتی نشو)

حتی اگر شخص عمداً troll نباشد، خیلی آسان است که دفاعی شوی.

وقتی کسی تو را متهم می‌کند که:

• تصمیم طراحی بدی گرفته‌ای،
• یا تئوری توطئه دارد،
• یا وقتت را با سوالات بی‌فایده می‌گیرد،

خیلی آسان است که عصبانی شوی.

یادت باشه: کار تو ساختن چیزهای عالی است، نه راضی کردن هر بازدیدکننده یا دفاع مکرر از وجود خودت.

• هرچه احساساتت قوی‌تر باشد، احتمال بیشتری دارد ساعت‌ها یا روزها را صرف نوشتن پاسخ‌های پرشور به کسی کنی که ارزشش را ندارد.
• نبردهایت را با دقت انتخاب کن و آرام بمان.
• با دقت تصمیم بگیر چه کسی ارزش پاسخ دارد و چه کسی را نادیده می‌گیری.

Strategy #8: Look for Facts in the Bile (در بین سم، به دنبال فکت باش)

ادامه‌ی تم “آرام ماندن” این است که فعالانه به دنبال fact ها باش.

• اگر کسی شکایت می‌کند، با دقت گوش کن.
• همیشه با دادن benefit of the doubt شروع کن، با وجود زبان عصبانی یا بی‌ادبانه.
• آیا شخص یک نکته‌ی واقعی دارد؟
• آیا چیزی برای یادگیری از تجربه‌ی او وجود دارد، یا ایده‌ای هست که ارزش پاسخ دارد؟

معمولاً جواب “بله” است — با وجود نثر زهرآلود یک شخص سمی، حکمتی واقعاً درون آن دفن شده است. همیشه بحث را به یک discussion فنی بازگردان.

مثال کلاسیک: Bug Report از یک رهبر مشهور

یک روز یک ایمیل خشمگین از یک رهبر مشهور open source دریافت کردیم.

• ظاهراً یک bug report بود، اما در واقع شبیه یک rant درباره‌ی هوش کلی تیم بود.
• پست پر از توهین و اغراق بود، انگار هدف عصبانی کردن تیم بود نه fix کردن bug.

پاسخ یکی از اعضای تیم:
او فقط چند سوال خاص پرسید و فقط روی bug تمرکز کرد.

Bug reporter با بیشتر توضیح داد، اما باز هم پر از سم بود. عضو تیم ما همچنان کاملاً توهین‌ها را نادیده گرفت، مشکل را بررسی کرد، و پاسخ داد:

«ممنون از bug report، فهمیدم چطور مشکل رو حل کنم — به‌زودی patch منتشر می‌کنیم.»

نتیجه: ما به‌شدت به نحوه‌ی برخورد عضو تیممان افتخار می‌کردیم. کاملاً آرام و fact-driven ماندن فقط باعث شد که فرستنده اصلی بیشتر شبیه یک دیوانه به نظر بیاید.

تا پایان بحث، bug reporter تمام اعتبارش را با مخاطبانش از دست داد و دیگر علاقه‌ای به ماندن نداشت.

Strategy #9: Pissing Contests (مسابقه‌ی ادرار!)

بعضی افراد دوست دارند در مسابقه‌های alpha-male شرکت کنند تا ببینند کدام‌شان قوی‌تر، باهوش‌تر، یا با تجربه‌تر است.

تنها راه برای برنده شدن در این مسابقه، شرکت نکردن است.

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

قانون: همیشه در ذهنت نگه دار که اگر کسی می‌خواهد تو را به یک pissing contest بکشد، شرکت نکن!

Strategy #10: Derailers (خارج‌کننده‌ها از مسیر)

Derailers افرادی هستند که عمداً یا ناخودآگاه باعث می‌شوند تیم از هدف اصلی منحرف شود.

مثال‌ها:

• کسی که هر بحثی را به موضوع دیگری می‌کشد؛
• کسی که مدام email طولانی با موضوعات بی‌ربط می‌فرستد؛
• کسی که در جلسات، مدام سوالات غیرمرتبط می‌پرسد.

راه حل:

• Mission Statement خودت را یادآوری کن.
• مؤدبانه بگو: «این موضوع خارج از scope ماست، لطفاً بعداً درباره‌اش بحث کنیم.»
• اگر ادامه داد، جلسه را به پایان برسان یا او را از thread بیرون کن.

Handling the Threat (برخورد با تهدید)

اگر بعد از تمام این استراتژی‌ها، شخص همچنان رفتار سمی دارد، چه باید کرد؟

گام ۱: هشدار خصوصی

در یک محیط خصوصی (یک‌به‌یک) با فرد صحبت کن و بگو:

«شاید متوجه نیستی، اما رفتارت (مشخص کن کدام رفتار) باعث ناراحتی تیم شده. می‌تونی کمکمون کنی که این رو اصلاح کنیم؟»

معمولاً افراد متوجه نمی‌شوند که چطور روی دیگران تأثیر می‌گذارند. این فرصتی است که یاد بگیرند.

گام ۲: هشدار عمومی

اگر رفتار ادامه یافت، یک هشدار عمومی (در email list یا meeting) بده:

«این نوع رفتار (مثلاً: لحن توهین‌آمیز یا تلف کردن وقت تیم) در تیم ما قابل قبول نیست.»

گام ۳: اخراج موقت یا دائم

اگر بعد از چند هشدار، رفتار تغییر نکرد، باید او را از تیم بیرون کنی.

• در پروژه‌های open source: ban کردن از mailing list یا revoke کردن دسترسی commit.
• در محیط کار: گزارش به مدیر یا HR و تصمیم به اخراج.

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

Conclusion (نتیجه‌گیری)

یادت باشد: هدف تو محافظت از فرهنگ تیم و focus روی ساخت محصول عالی است.

• افراد سمی attention و focus تیم را می‌دزدند.
• با شناسایی سریع و واکنش مناسب، می‌توانی از تیمت محافظت کنی.
• بهترین دفاع: فرهنگ قوی مبتنی بر HRT (Humility, Respect, Trust) و best practice های محکم.

---

حالا وارد فصل ۵: The Art of Organizational Manipulation (هنر دستکاری سازمانی) می‌شویم.

فصل ۵: هنر دستکاری سازمانی

این فصل درباره‌ی Navigate کردن در سازمان است — چگونه در ساختارهای بزرگ و پیچیده کار کنی و کارها را انجام دهی.

مقدمه: چرا این مهم است؟

شرکت‌های بزرگ مانند پیچ‌درپیچ‌های پیچیده هستند. حتی بهترین‌شان نیاز به GPS، چراغ‌قوه، و یک کامیون پر از نان‌های خرده‌خرده برای navigate کردن از یک انتها به انتهای دیگر دارند!

در این فصل:

• ابتدا نگاه می‌کنیم که یک تیم چطور در یک شرکت ایده‌آل کار می‌کند.
• سپس بررسی می‌کنیم چطور یک شرکت dysfunctional می‌تواند مانع موفقیت تیمت شود.
• استراتژی‌هایی برای انجام کارها در هر دو نوع شرکت بررسی می‌کنیم.
• و در نهایت، اگر همه چیز شکست خورد، Plan B را می‌گوییم.

How Things Ought to Be (چگونه باید باشند)

دو سطح در یک شرکت درست‌کار وجود دارد:

1. مدیرت که بیشتر اوقات با او سر و کار داری.
2. شرکت فراتر از مدیرت شامل کارکنان دانش، مدیران میانی، مدیران اجرایی، فروشندگان، وکلا، و غیره.

تجربه‌ی کارمند ایده‌آل

اگر مدیرت یک servant leader است که HRT را به‌کار می‌برد و واقعاً علاقه‌مند به موفقیت تو است (فصل ۳ را ببین)، چند کار ساده وجود دارد که می‌توانی انجام دهی تا کار او را آسان‌تر کنی، و در نتیجه خودت productive تر و ارزشمندتر باشی.

Pattern #1: Pursue Extra Responsibility (به دنبال مسئولیت بیشتر باش)

یکی از بهترین استعاره‌ها برای این موضوع forest ranger است:

• مدیرت (یک ranger ارشد) تو را به جنگل می‌فرستد تا یک درخت بیمار را قطع کنی.
• اگر فقط روی کار فعلی متمرکز باشی، می‌روی، درخت را قطع می‌کنی، و برمی‌گردی.
• اما اگر به تصویر بزرگ‌تر فکر کنی، می‌روی، درخت را قطع می‌کنی، و با یک نقشه از تمام درختان بیمار دیگری که در مسیرت دیدی برمی‌گردی، همراه با یک طرح کارآمد برای قطع آن‌ها.

نتیجه:
دفعه‌ی بعد که مدیرت کاری با سطح مسئولیت بالاتر دارد، احتمالاً اول به تو می‌دهد — چون می‌داند تو می‌توانی انجامش دهی و این کم‌ترین مقاومت است (برای او کار کمتری است).

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

Pattern #2: Take Risks and Don’t Fear Failure (ریسک کن و از شکست نترس)

در فصل‌های ۳ و ۴ زیاد درباره‌ی اهمیت taking risks و failing fast صحبت کردیم.

• در حضور یک مدیر روشن‌فکر، شکست راهی عالی برای یادگیری سریع است.
• کشف محدودیت‌های خودت و رشد آن‌ها.

استیو هایمن (دوست نویسنده‌ها) که زیاد سفر می‌کند گفته:

«اگر سالی حداقل یک بار پروازت را از دست ندهی، یعنی خیلی زود به فرودگاه می‌رسی!»

این استعاره‌ای عالی برای ساخت هر محصولی است: اگر سالی حداقل یک بار شکست نخوری، ریسک کافی نمی‌کنی.

• اگر ریسک نکنی، شکست‌های کمتری داری، اما موفقیت‌های بزرگ کمتری هم داری.
• یک مدیر خوب می‌خواهد تیمی داشته باشد که حاضر است مرزها را جلو بزند و ببینند چه می‌توانند و چه نمی‌توانند انجام دهند (و در این مسیر زیاد یاد بگیرند).
• او یک فرود نرم برای شکست فراهم می‌کند.

وقتی شکست خوردی:

• مسئولیتش را بپذیر،
• به دنبال سرزنش دیگران نباش،
• مستند کن چه اتفاقی افتاد و چطور می‌توانی از تکرار همان شکست جلوگیری کنی.

Lather, rinse, repeat. (تکرار کن!)

Pattern #3: Act Like an Adult (مثل یک بزرگسال رفتار کن)

یکی دیگر از پیشنهادهای واضح: تو مسئول آموزش مردم هستی که چطور رفتار کنند و چطور با تو برخورد کنند.

• مدیران بد اغلب تیم‌شان را مثل بچه‌ها تربیت می‌کنند: هر ابتکار، مسئولیت یا قانون‌شکنی را له می‌کنند.
• اگر چنین مدیری داشته‌ای، معمولاً از همه‌ی مدیران همین نوع برخورد را انتظار داری.

راه حل: اگر با تصمیم مدیرت موافق نیستی، نترس که با او بحث کنی یا پیش‌فرض‌هایش را زیر سوال ببری. این license برای مانع‌تراشی نیست، اما «yes-man» بودن هم به کسی که در موقعیت لیدری است کمکی نمی‌کند اگر تو اطلاعات یا تجربه‌ای داری که او ندارد.

Pattern #4: Overcommunicate (بیش‌ازحد ارتباط برقرار کن)

مدیرت غیب‌گو نیست!

به‌ندرت شخصی پیدا می‌شود که overcommunicate کند، پس دریغ نکن که قبل از اینکه مدیرت بپرسد چه‌کار می‌کنی، خودت او را از وضعیتت مطلع کنی.

• وقتی به مانعی برخوردی، یک یادداشت سریع بفرست.
• وقتی پیروزی به‌دست آوردی، خبر بده.
• وقتی به چیزی نیاز داری یا انتظار چیزی داری، بگو.

این نه‌تنها راهی عالی برای مطلع نگه‌داشتن مدیرت است، بلکه یک تکنیک برای مقابله با micromanagement هم هست:
اگر مدیرت مدام check می‌کند، proactive یک ایمیل با همان frequency به او بفرست — راهی تضمین‌شده برای اینکه او عقب بکشد!

وقتی سازمانت ایده‌آل نیست…

این تکنیک‌ها در سازمان ایده‌آل خوب کار می‌کنند، اما وقتی سازمانت اصلاً ایده‌آل نیست چه؟

Bad Managers and Bad Organizations (مدیران بد و سازمان‌های بد)

The Bad Manager (مدیر بد)

در تضاد کامل با servant leader که در فصل ۳ بحث کردیم، مدیر بد می‌خواهد بداند اخیراً چه‌کار برای او کرده‌ای.

• آن low performer های تیمت؟ تا وقتی تیم را کاملاً متوقف نکنند، جایی نمی‌روند — چون برای مدیر بد، deal کردن با آن‌ها خیلی کار دارد.

خلاصه: آیا مدیرت در خدمت تو است؟ یا تو در خدمت مدیرت؟
باید همیشه اولی باشد.

The Office Politician (سیاست‌باز اداری)

اگرچه ما طرفدار trust کردن به مردم هستیم، اما trust کردن به سیاست‌باز اداری می‌تواند حرکتی جدی برای محدودسازی career باشد.

چطور او را تشخیص دهیم؟

• در ابتدا سخت است چون او معمولاً در مدیریت روابط خیلی خوب است و ممکن است بسیار دوستانه باشد.
• کار عالی در managing up (مدیریت رئیسش) انجام می‌دهد، و حتی بهتر از آن: از همکارانش و زیردستانش برای خودنمایی استفاده می‌کند.
• سریع دیگران را سرزنش می‌کند، اما سریع‌تر credit را می‌دزدد.
• معمولاً مستقیم confrontational نیست، بلکه چیزی می‌گوید که تو می‌خواهی بشنوی تا نظر خوبی درباره‌اش داشته باشی.
• اگر نتواند از تو استفاده کند یا دستکاریت کند، یا نادیده‌ات می‌گیرد یا اگر تو را تهدید ببیند، سعی می‌کند تو را تضعیف کند.

وقتی مدتی با او کار کرده‌ای، راحت می‌توانی او را ببینی: او وقت بیشتری صرف به‌نظر رسیدن impactful می‌کند تا واقعاً impactful بودن.

توصیه:

• تا جایی که می‌توانی از او دور شو (route around him).
• اما بی‌احتیاط درباره‌اش پشت سرش بد نگو به کسانی بالاتر از او، چون نمی‌دانی چه کسی را فریب داده و چه کسی به او شک دارد.

اگر از نوع افرادی هستی که دوست داری سرت را پایین بگیری و روی فناوری جالب تمرکز کنی، ممکن است بخواهی این استراتژی را وقتی office politician در اطراف است بازنگری کنی.
اگر انرژی نگذاری برای ارتقا گرفتن چون نمی‌خواهی «بازی را انجام دهی»، ممکن است office politician از تو ارتقا بگیرد — و حالا یک مدیر بد و یک office politician داری!

The Bad Organization (سازمان بد)

وقتی شرکت‌ها رشد می‌کنند، بوروکراسی و فرآیندها ایجاد می‌کنند تا سود را مدیریت کنند، ریسک را کاهش دهند، قابلیت پیش‌بینی را افزایش دهند، و وزن عظیم سازمان را پشتیبانی کنند.

با گذشت زمان، این بوروکراسی می‌تواند به نقطه‌ای برسد که مانع موفقیت شرکت شود.

چند مثال از مشکلات سازمانی:

1. شرکت‌ها معمولاً engineering-focused نیستند: مهندسان ابزاری برای رسیدن به اهداف business هستند که معمولاً فنی نیستند. پس افرادی که شرکت را اداره می‌کنند احتمالاً زیرساخت‌های فنی سیستم را نمی‌فهمند، فقط خواسته‌های business را می‌دانند.
   • نتیجه: deadline های غیرواقعی و فقدان افراد فنی واجد شرایط برای تکمیل پروژه‌ها به‌موقع.

2. ساختارهای command and control سفت‌وسخت که شبیه fiefdom (حکومت‌های کوچک) هستند. مثال: دوست نویسنده‌ها، Terrence، در شرکتی کار می‌کرد که قوانین سختی برای pass کردن bug بین تیم‌ها داشت. یک تیم دیگر bugی ساخت که باعث شد محصول Terrence out of memory شود. به‌جای ایمیل زدن به اعضای تیم مسئول، او تمام شب بیدار ماند، bug را reproduce کرد، داده جمع کرد، و case خودش را ساخت. سپس ایمیلش را به مدیرش فرستاد، مدیرش به director خودش فرستاد، آن director به director تیم دیگر فرستاد، و… بیش از ۱۰ روز بعد، Terrence در جلسه‌ای با ۲ مدیر، ۲ director، و ۳ مهندس دیگر نشست تا درباره‌ی bug بحث کنند!

   در مقابل: در هفته‌ی اول Fitz در Google، او یک typo در Gmail پیدا کرد. سورس کد را باز کرد، typo را درست کرد، و patch را به تیم Gmail فرستاد — آن‌ها از او تشکر کردند!

3. Obsession با سلسله‌مراتب سازمانی: منجر به power struggle های بی‌پایان می‌شود. مدیران اغلب مانع transfer مهندسان به تیم دیگر می‌شوند تا تیم خودشان را از دست ندهند — حتی وقتی کار درست برای شرکت و مهندس این است که transfer اتفاق بیفتد.

4. رفتار کردن با تو مثل یک بچه‌ی شیطون: firewall سخت‌گیرانه، timecard دقیق برای هر لحظه از روزت، یا حتی اندازه‌گیری productivity با متریک‌های بی‌معنی مثل تعداد خطوط کد نوشته‌شده در هفته!

5. فقدان focus، vision، یا direction: معمولاً نتیجه‌ی «design by committee» است که منجر به دستورات متناقض می‌شود. پس در دایره‌های بسته حرکت می‌کنی به‌جای جهت منسجم.

---

دستکاری سازمانت

شرکت‌ها، درست مانند سیستم‌های نرم‌افزاری، از قوانین ساخته شده‌اند: برخی از قوانین را می‌توان خم کرد، برخی دیگر را می‌توان شکست.

اگر فقط روی چگونه باید باشد تمرکز کنی، معمولاً چیزی جز ناامیدی و سرخوردگی نمی‌یابی. به‌جای آن، وضعیت فعلی را بپذیر و بر مسیریابی در ساختار سازمانی متمرکز شو تا راه‌هایی پیدا کنی که می‌توانند کارها را انجام دهند و جایگاه خوشحال‌کننده‌ای برای خودت بسازند.

استراتژی شماره ۱: «بخشش گرفتن آسان‌تر از اجازه گرفتن است»

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

• اگرچه پرسیدن اجازه فرصتی می‌دهد که مسئولیت را به دیگری منتقل کنی، اما فرصتی هم برای کسی ایجاد می‌کند که به تو «نه» بگوید.
• مهم است بدانی چه چیزهایی را می‌توانی بدون تایید صریح مدیرانت انجام دهی.
• هرجا ممکن است، آن‌چه فکر می‌کنی برای شرکت درست است، انجام بده.

انتخاب نبردها

حتی اگر آماده‌ای تا بخشش بطلبی، نبردهایت را عاقلانه انتخاب کن.

• هر بار که مجبوری یک موضوعی را دفاع کنی یا در برابر کسی در شرکت بایستی، سرمایه‌ی سیاسی‌ات را خرج می‌کنی.
• اگر تمام سرمایه‌ات را صرف برنده شدن در نبردهایی کنی که اهمیتی ندارند، وقتی به موضوعات مهم برسی، چیزی در حسابت باقی نمانده.
• هوشمندانه عمل کن و برای چیزهایی بجنگ که یا مهم هستند یا می‌دانی شانس برد داری.
• خرج کردن تمام سرمایه روی نبردی که می‌دانی نمی‌توانی ببری، بی‌فایده و مانع پیشرفت شغلی‌ات است.

مشاور

اگر تصمیم گرفتی مسیر «بخشش بطلب» را انتخاب کنی، داشتن همکاران و دوستانی که می‌توانی ایده‌هایت را با آن‌ها مطرح کنی مفید است — به‌خصوص ایده‌های پرریسک‌تر.

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

مثال: یک بار در بخش بازاریابی از فیتز خواستند که آگاهی درباره‌ی تیم آزادسازی داده را بین مدیران ارشد گوگل افزایش دهد. فیتز ایده‌ای به دوستانش گفت: انبرهای برش‌زن با نام تیم و جعبه‌های قفل‌شده‌ی پر از هدیه (که کلیدها داخل آن‌ها قفل شده بود!) به مدیران ارشد هدیه دهد. بعد از مشورت با مشاورانش، تصمیم گرفت جلو برود — و موفق شد!

چند سال بعد، فیتز داشت فکر می‌کرد تبلیغات چاپی که کمی «نامناسب» بودند بسازد. همان مشاوران نگرانی ابراز کردند که طرح خیلی پرریسک است — فیتز آن را لغو کرد.

استراتژی شماره ۲: اگر نمی‌توانی از مسیر عبور کنی، مسیر را خودت بساز

یک راهکار دیگر برای ایجاد تغییر در شرکت این است که راهی پیدا کنی تا ایده‌هایت را در سطح پایه (از پایین به بالا) قبول شوند.

• اگر بتوانی افراد کافی را متقاعد کنی که ایده یا محصول خاصی را بخرند یا استفاده کنند، اغلب دیر می‌شود که بوروکراسی بتواند جلویت را بگیرد.
• مدیریت مجبور خواهد شد آن را متوجه شود و یا بپذیرد یا علیه آن عمل کند (که برای آن‌ها هزینه‌ی سرمایه‌ی سیاسی دارد!).

مثال: این همان راهکاری است که مهندسان سال‌ها برای وارد کردن ابزارهای منبع آزاد به روال کاری روزانه‌شان استفاده کردند تا زندگی‌شان راحت‌تر شود.

ترغیب از طریق واسطه

اگر می‌خواهی کسی را متقاعد کنی، راه عالی برای افزایش شانس موفقیت این است که چند نفر پیدا کنی که با تو موافقند و بگیری ایده‌ات را در گفتگو با آن شخص مطرح کنند.

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

به اشتراک گذاشتن ایده‌ها

ایده‌ها چیزهای جالبی هستند: می‌توانند مسافت زیادی بروند اگر برایت مهم نباشد چه کسی اعتبار می‌گیرد!

• گاهی افراد یک ایده را فقط اگر بتوانند اعتبار را برای خودشان بگیرند پخش می‌کنند.
• باید تصمیم بگیری چه چیز مهم‌تر است: این‌که تو اعتبار بگیری، یا این‌که ایده پخش شود.

علی‌رغم این‌که شنیدن حرف‌های خودت از دهان شخص دیگری (شاید نفرت‌انگیز) دردناک است، اغلب بی‌دردسرترین راه برای سفر کردن یک ایده است.

ما این را بارها دیده‌ایم: مفاهیم و ایده‌های بلندپروازانه‌ای که از دهان یک مدیر ارشد می‌آید، از کسی در سازمانش منشا گرفته است.

جایگزین کردن عادت‌های بد

درست مانند افراد، حذف عادت‌های بد در یک شرکت سخت است.

یکی از معلمان اولیه‌ی بن می‌گفت:

«غیرممکن است که به سادگی یک عادت بد را متوقف کنی؛ باید آن را با یک عادت خوب جایگزین کنی.»

شرکت‌ها نیز همین‌طور هستند.

مثال:

• آیا از یک جلسه‌ی هفتگی خاص بدت می‌آید؟ آن را با نوع دیگری از جلسه‌ی موثرتر جایگزین کن.
• آیا از یک فرآیند گزارش‌دهی بی‌فایده بدت می‌آید؟ شکایت نکن؛ یک فرآیند مفید بنویس که خیلی جذاب باشد که نتوان نادیده‌اش گرفت.

ترفند: برای غلبه بر مقاومت در برابر تغییر، پیشنهاد بده رویه‌ی جدیدت را برای چند هفته «آزمایش» کنید. این باعث می‌شود چیز جدید کمتر دائمی و ترسناک به‌نظر برسد، و اگر همه از آن خوششان آمد، تا پایان دوره‌ی آزمایشی فراموش می‌کنند که اصلاً آزمایشی بوده!

استراتژی شماره ۳: یاد بگیر به‌سمت بالا مدیریت کنی

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

این به معنای این است که:

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

بعضی افراد این «فروختن خودت» را ناخوشایند می‌بینند، اما مزایای انجام این کار عظیم است.

کمتر از توانت قول بده، بیشتر از قولت تحویل بده

همان‌طور که در فصل ۶ خواهیم گفت، باید هرجا ممکن است، کمتر از توانت قول بدهی و بیشتر تحویل بدهی.

• منظورمان این نیست که تمام برآوردهایت را بزرگ‌تر از واقع نشان دهی یا به ضرب‌الاجل‌ها زمان اضافه بدهی.
• اما هرجا که می‌توانی، از قول دادن چیزهایی که نمی‌توانی تحویل دهی، پرهیز کن — حتی اگر به معنای گفتن «نه» بیشتر از آن‌چه دوست داری باشد.

اگر مدام ضرب‌الاجل‌ها را از دست بدهی یا ویژگی‌ها را حذف کنی، افراد دیگر دلیلی برای اعتماد کردن به تو نخواهند داشت و احتمالاً وقتی دنبال کسی برای انجام کاری هستند، تو را رد می‌کنند.

روی عرضه‌ی محصولات متمرکز شو

توصیه می‌کنیم که انرژی‌ات را روی عرضه کردن محصولات متمرکز کنی بیشتر از هر چیز دیگری.

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

• عرضه‌ی محصولت یک رویداد بسیار قابل دیدن است که نشان می‌دهد داری چیزی به سرانجام می‌رسانی.
• اگرچه وسوسه‌انگیز است که زمان زیادی صرف تمیز کردن کد و بازنویسی کنی، ما از تجربه یاد گرفته‌ایم که اگر بیش از نیمی از وقتت را صرف این نوع کار دفاعی کنی، به‌ندرت توسط هر کسی خارج از تیمت ارزش‌گذاری می‌شود — از جمله مدیرانت.
• نتیجه: تو در موقعیت شرم‌آوری قرار می‌گیری که تقریباً هیچ چیز مهم سیاسی برای نشان دادن وقتت نداری.

این نه‌تنها راهی بد برای نگرفتن هیچ شناختی است، بلکه راهی بد برای لغو شدن محصولت هم هست!

کار تهاجمی در برابر کار دفاعی

وقتی بن اولین بار مدیر شد، به‌نظر می‌رسید بهره‌وری تیمش زیر کوهی از بدهی فنی خرد می‌شود. تصمیم گرفت اولویت اول تیم این باشد که وقت زیادی صرف پس دادن این بدهی کنند. مدیرانش سری تکان دادند و کار شروع شد.

اما اوضاع خوب پیش نرفت. علی‌رغم تایید قبلی، مدیر بن بعد از چند ماه عصبانی و بی‌حوصله شد — چرا تیم «هیچ‌کاری انجام نمی‌دهد»؟

تیم بن در واقع بسیار پرکار بود و او سعی کرد حجم عظیمی از بدهی که پس داده شده را نشان دهد. اما معلوم شد این نوع کار نمی‌تواند کسی را تحت تأثیر قرار دهد؛ در سطح احساسی اساساً خسته‌کننده است.

بعد از این تجربه‌ی بد، بن شروع کرد تمام کارها را به دو دسته تقسیم کند: «تهاجمی» یا «دفاعی».

کار تهاجمی

معمولاً تلاشی است برای ویژگی‌های جدید قابل دیدن برای کاربر — چیزهای جذابی که آسان است به افراد بیرونی نشان دهی و آن‌ها را هیجان‌زده کنی، یا چیزهایی که به‌طور قابل توجهی جذابیت محصول را افزایش می‌دهند (مثلاً رابط کاربری بهتر، زمان پاسخ سریع‌تر).

کار دفاعی

تلاشی است برای سلامت بلندمدت محصول (مثلاً بازنویسی کد، ساختاردهی مجدد ویژگی‌ها، تغییر ساختار پایگاه‌داده، انتقال داده، یا پایش بهتر برای مشکلات).

فعالیت‌های دفاعی محصول را قابل نگهداری، پایدار، و قابل اعتماد می‌کنند. و با این حال، علی‌رغم این‌که کاملاً حیاتی هستند، هیچ اعتبار سیاسی برای انجامشان نمی‌گیری. اگر تمام وقتت را صرف آن‌ها کنی، مردم محصولت را در حال توقف می‌بینند.

قانون طلایی:

یک تیم هرگز نباید بیش از یک‌سوم تا نیمی از زمان و انرژی‌اش را صرف کار دفاعی کند، صرف‌نظر از میزان بدهی فنی.

هر وقت بیشتری که صرف شود، یک نسخه برای خودکشی سیاسی است.

---

استراتژی شماره ۴: اگر نمی‌توانی از مسیر عبور کنی، مسیر را خودت بساز (ادامه)

یکی دیگر از راهکارهای ایجاد تغییر در شرکت این است که راهی پیدا کنی تا ایده‌هایت را در سطح پایه (از پایین به بالا) قبول شوند.

به اشتراک گذاشتن ایده‌ها

ایده‌ها چیزهای جالبی هستند: می‌توانند مسافت زیادی بروند اگر برایت مهم نباشد چه کسی اعتبار می‌گیرد!

گاهی متوجه می‌شوی افراد یک ایده را فقط در صورتی پخش می‌کنند که بتوانند اعتبار آن را برای خودشان بگیرند. پس باید تصمیم بگیری چه چیز مهم‌تر است: این‌که تو اعتبار بگیری، یا این‌که ایده پخش شود.

علی‌رغم این‌که شنیدن حرف‌های خودت از دهان شخص دیگری (حتی شخصی که دوستش نداری) دردناک است، اغلب این بی‌دردسرترین راه برای سفر کردن یک ایده است.

ما این را بارها دیده‌ایم: مفاهیم و ایده‌های بلندپروازانه‌ای که از دهان یک مدیر ارشد بیرون می‌آیند، از کسی در سازمانش منشا گرفته‌اند. فکر کن که ایده‌ی تو — که در غیر این صورت شنیده نمی‌شد — از این طریق چقدر می‌تواند به مخاطبان گسترده‌ای برسد!

جایگزین کردن عادت‌های بد

درست مانند افراد، از بین بردن عادت‌های بد در یک شرکت سخت است.

یکی از معلمان اولیه‌ی بن می‌گفت: «غیرممکن است که به سادگی یک عادت بد را متوقف کنی؛ باید آن را با یک عادت خوب جایگزین کنی.»

هر کسی که تلاش کرده است سیگار را ترک کند، با این پدیده آشناست. شرکت‌ها نیز همین‌طور هستند — اگر می‌خواهی یک عادت بد را با موفقیت از بین ببری، یک عادت بهتر پیدا کن که آن را جایگزین کنی.

نمونه‌ها:

• از یک جلسه‌ی هفتگی خاص بدت می‌آید؟ آن را با نوع دیگری از جلسه یا رسم موثرتر جایگزین کن.
• از یک فرآیند گزارش‌دهی بی‌فایده بدت می‌آید؟ شکایت نکن؛ یک فرآیند مفید بنویس که خیلی جذاب باشد که نتوان نادیده‌اش گرفت.

وقتی یک عادت جایگزین خوب پیدا کردی، باید بر اینرسی مقاومت در برابر تغییر غلبه کنی. ما توصیه می‌کنیم که پیشنهاد دهی رسم جدیدت را برای چند هفته «امتحان» کنید.

این باعث می‌شود چیز جدید کمتر دائمی و ترسناک به‌نظر برسد، و اگر همه از رسم جدید خوششان آمد، تا پایان دوره‌ی آزمایشی فراموش می‌کنند که اصلاً آزمایشی بوده است!

برنامه B: خارج شو

در تمام سال‌هایی که ما درباره‌ی انجام کارها در درون سازمان‌های بد و کار کردن با افراد بد سخنرانی کرده‌ایم، همیشه افرادی بعد از سخنرانی‌هایمان به سراغمان می‌آیند که با ناامیدی می‌گویند همه چیز را امتحان کرده‌اند و نمی‌توانند هیچ پیشرفتی ایجاد کنند یا کاری انجام دهند. پس چه کار باید بکنند؟

پاسخ ناخوشایند این است: احتمالاً کار دیگری نمی‌توانید بکنید. قربانی نباش. از آنجا خارج شو.

اگر نمی‌توانی سیستم را تغییر دهی، وقت گذاشتن برای تغییرش معنایی ندارد. به‌جای آن، انرژی‌ات را صرف ترک کردنش کن: رزومه‌ات را به‌روز کن، و از دوستان نزدیکت بپرس که آیا از فرصت‌های شغلی برای تو در شرکت‌های دیگر خبر دارند. خودت را در زمینه‌های جدید آموزش بده.

یکی از چیزهای عالی درباره‌ی کارگر دانشی بودن در این روزگار این است که افراد خوب در این حوزه تقاضای بالایی دارند، و این به تو قدرت کنترل آینده‌ی خودت را می‌دهد. وقتی متوجه شوی که این کنترل را داری، فوق‌العاده آزادکننده است.

اگر کمی بگردی و متوجه شوی که گزینه‌های شغلی دیگری برایت موجود است، ممکن است کشف کنی که ناگهان کارهای بیشتری در محل کارت انجام می‌دهی (با استرس بسیار کمتر) چون دیگر پایان دنیا نیست اگر کارفرمای فعلی‌ات تو را اخراج کند!

پست وبلاگ الهام‌بخش

ما این پست وبلاگ از چید-منگ تان (Chade-Meng Tan)، «دوست خوش‌مشرب» گوگل، را بسیار الهام‌بخش یافتیم و تاثیر زیادی بر نحوه‌ی کار ما گذاشته است:

کار درست را انجام بده، و منتظر باش تا اخراجت کنند

کارمندان جدید گوگل (ما آن‌ها را «نوگلرها» می‌نامیم) اغلب از من می‌پرسند چه چیزی باعث می‌شود من در کارم موثر باشم. من تنها نیمه‌شوخی به آن‌ها می‌گویم که خیلی ساده است: من کار درست را برای گوگل و جهان انجام می‌دهم، و سپس عقب می‌نشینم و منتظر می‌مانم تا اخراج شوم. اگر اخراج نشوم، یعنی کار درست را برای همه انجام داده‌ام. اگر اخراج شوم، یعنی این کارفرمای اشتباهی است که در ابتدا برای او کار می‌کردم. پس به هر حال، من برنده هستم. این است استراتژی شغلی من.

اگر آماده باشی و گزینه‌هایت را بدانی، تو آزادترین آدم در جهان هستی.

از خارج شدن نترس. ما این مشاوره را بیش از پنج سال است که بعد از سخنرانی‌هایمان می‌دهیم، و خوشحالیم که گزارش دهیم چندین نفر برایمان ایمیل زده‌اند و اطلاع داده‌اند که به توصیه‌ی ما عمل کرده‌اند و اکنون کارهایی را که دوست دارند انجام می‌دهند. و این ایمیل‌ها برخی از بهترین ایمیل‌هایی هستند که دریافت کرده‌ایم — این یکی از مورد علاقه‌های ماست:

تاریخ: پنج‌شنبه، ۱ دسامبر ۲۰۱۱
موضوع: یادداشت تشکر
از: الکس مروالیویچ
به: برایان فیتزپاتریک

سلام برایان!
احتمالاً مرا به یاد نمی‌آوری، اما تو بهترین دو مشاوره‌ی شغلی را که تا به حال دریافت کرده‌ام به من دادی و زندگی‌ام را تغییر دادی.

من در سخنرانی فنی شما در گوگل I/O 2010 شرکت کردم و بعد از سخنرانی به سراغت آمدم تا درباره‌ی وضعیت کاری فعلی‌ام مشاوره بگیرم. به زبان ساده تو به من گفتی «از اونجا برو بیرون» پس رزومه‌ام را به عنوان مدیر پروژه برایت فرستادم. بعد از آن تو به من گفتی که گوگل به ندرت مدیران پروژه‌ی غیرفنی استخدام می‌کند.

به خاطر این حرف مجبور شدم درباره‌ی شغل‌ام عمیقاً فکر کنم: هر چه سیاست گوگل باشد، اکثر شرکت‌ها از آن پیروی می‌کنند. تغییر مسیر شغلی تنها گزینه‌ی من بود. نزدیک‌ترین شرط، مدیریت محصول بود. خیلی مطالعه کردم و «از اونجا رفتم بیرون» نه تنها از شرکتی که در آن بودم، بلکه از کشورم (در ونزوئلا مشاغل زیادی در زمینه‌ی مدیریت محصول وجود ندارد). این بهترین حرکت زندگی‌ام شد…

حالا به خاطر آن حرکت، تازه یک شغل شگفت‌انگیز به عنوان رهبر محصول در ژاپن گرفته‌ام و در فوریه به کوبه نقل مکان می‌کنم.

به خودم قول داده بودم اگر همه چیز به خاطر آن مشاوره درست شد، برایت یک یادداشت تشکر بفرستم، پس این است:
ممنونم.
الکس

همه چیز از دست نرفته است

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

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

---

بخش بعدی که شروع فصل ۶ است را با فارسی روان و گرامر درست ارسال می‌کنم.

فصل ۶: رهبری تیم

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

بیشتر افرادی که رهبر تیم می‌شوند، به این سمت درخواست نداده‌اند. معمولاً فردی به خاطر مهارت‌های فنی‌اش ارتقا می‌یابد، و بعد یک روز به او گفته می‌شود: «تبریک می‌گویم، حالا مسئول یک تیم هستی!» این اغلب شوکی بزرگ برای سیستم است.

بسیاری از مهندسان باهوش و ماهر وقتی رهبری تیم را تجربه می‌کنند، تا می‌توانند سریع از آن فرار می‌کنند و به نوشتن کد برمی‌گردند. چرا؟ زیرا کسی به آن‌ها یاد نداده که چگونه رهبر خوبی باشند.

در این فصل می‌خواهیم درباره‌ی این صحبت کنیم که چگونه یک رهبر خادم (Servant Leader) باشی — کسی که تیمش را توانمند می‌کند، نه این‌که آن‌ها را میکرومدیریت کند.

همه چیز درباره‌ی مأموریت است

قبل از هر چیز، باید بدانی که مأموریت تیمت چیست. اگر نمی‌دانی تیمت کجا می‌رود، چگونه می‌توانی آن‌ها را رهبری کنی؟

بسیاری از تیم‌ها بدون یک بیانیه‌ی مأموریت (Mission Statement) واضح کار می‌کنند. این یکی از بزرگ‌ترین اشتباهاتی است که می‌توانی مرتکب شوی.

بیانیه‌ی مأموریت — نه، واقعاً جدی هستیم

وقتی کسی «بیانیه‌ی مأموریت» می‌گوید، احتمالاً اولین چیزی که به ذهنت می‌آید، آن جملات تبلیغاتی و بی‌معنی است که شرکت‌های بزرگ استفاده می‌کنند.

مثال از یک شرکت مخابراتی بزرگ:

«ما آرزو داریم که محترم‌ترین و با ارزش‌ترین شرکت در جهان باشیم. هدف ما غنی کردن زندگی شخصی مشتریانمان و موفق‌تر کردن کسب‌وکارهایشان است…»

چه معنایی دارد؟ هیچ‌کس از این شرکت خوشش نمی‌آید!

یا این مثال از شرکت دیگر:

«ارائه‌ی راه‌حل‌ها در زمان واقعی برای رفع نیازهای مشتریانمان.»

این جمله می‌تواند به معنای هر چیزی باشد — شستن ماشین، تعمیر لوله، یا تحویل پیتزا!

این نوع حرف‌های شرکتی است که به بیانیه‌های مأموریت نام بد می‌دهد.

بیانیه‌ی مأموریت خوب چیست؟

برای یک تیم کارآمد و مؤثر، نوشتن یک بیانیه‌ی مأموریت راهی است تا جهت محصول را به طور خلاصه مشخص کنی و دامنه‌ی آن را محدود کنی.

نوشتن یک بیانیه‌ی مأموریت خوب زمان و تلاش می‌برد، اما می‌تواند سال‌ها وقت تو را ذخیره کند با روشن کردن این‌که تیمت باید روی چه چیزهایی کار کند و روی چه چیزهایی نباید کار کند.

مثال واقعی: گوگل و پروژه‌ی GWT

وقتی گوگل تصمیم گرفت توسعه‌ی Google Web Toolkit (GWT) را به یک پروژه‌ی منبع آزاد تبدیل کند، ما به عنوان مربی تیم عمل کردیم. به تیم گفتیم که نیاز دارند یک بیانیه‌ی مأموریت بنویسند.

برخی از اعضای تیم مخالفت کردند، اما بعد از بحث‌های زیاد، تیم نه تنها یک بیانیه‌ی مأموریت عالی و مختصر نوشت، بلکه یک سند کامل به نام «بهتر کردن GWT» تهیه کرد که هر عبارت را جمله به جمله توضیح می‌داد. حتی بخشی هم درباره‌ی غیرهدف‌های پروژه داشتند.

بیانیه‌ی مأموریت GWT:

«مأموریت GWT این است که به طور بنیادی تجربه‌ی وب را برای کاربران بهبود بخشد، با این که توسعه‌دهندگان را قادر سازد تا از ابزارهای موجود جاوا برای ساخت AJAX بدون سازش برای هر مرورگر مدرن استفاده کنند.»

این بیانیه مختصر، واضح، و دقیق است. هر کسی که آن را می‌خواند می‌فهمد که این پروژه چه می‌کند و برای چه کسی است.

چرا به بیانیه‌ی مأموریت نیاز داری؟

یک بیانیه‌ی مأموریت خوب مانند یک قطب‌نما عمل می‌کند. وقتی تیمت سردرگم است یا درباره‌ی چیزی اختلاف نظر دارد، می‌توانند به بیانیه‌ی مأموریت برگردند و بپرسند: «آیا این کار ما را به هدفمان نزدیک‌تر می‌کند؟»

همچنین به تیمت کمک می‌کند تا «نه» بگویند به درخواست‌هایی که خارج از دامنه‌ی کارشان است. اگر کسی بیاید و بگوید: «چرا این ویژگی را اضافه نمی‌کنید؟» تیمت می‌تواند به بیانیه‌ی مأموریت اشاره کند و بگوید: «این با مأموریت ما همسو نیست.»

---

ادامه‌ی فصل ۶ را با فارسی روان و گرامر درست ارسال می‌کنم.

رهبری خادم

بهترین رهبران کسانی هستند که تیمشان را توانمند می‌سازند، نه این‌که آن‌ها را میکرومدیریت کنند. به این نوع رهبری، رهبری خادم می‌گویند.

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

ضدالگوهای رهبری

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

ضدالگو: نادیده گرفتن افراد ضعیف

اوایل دوران مدیریت فیتز در گوگل، زمانی که قرار بود پاداش‌ها را به تیمش بدهد، با لبخند به مدیرش گفت: «عاشق مدیر بودن هستم!» مدیرش که یک فرد باتجربه بود، بدون مکث پاسخ داد: «گاهی باید پری دندان باشی، گاهی هم باید دندانپزشک باشی.»

کشیدن دندان هرگز کار خوشایندی نیست. ما دیده‌ایم که رهبران تیم تمام کارهای درست را انجام می‌دهند تا تیم‌های قوی بسازند، اما این تیم‌ها به خاطر فقط یکی یا دو نفر ضعیف‌العمل، شکست می‌خورند (و در نهایت از هم می‌پاشند).

ما می‌دانیم که جنبه‌ی انسانی سخت‌ترین بخش نوشتن نرم‌افزار است، اما سخت‌ترین بخش کار با انسان‌ها، برخورد با کسی است که انتظارات را برآورده نمی‌کند.

مشکل نادیده گرفتن افراد ضعیف:

• وقتی رهبر دارد امیدوار است و فرد ضعیف بهتر نمی‌شود (یا نمی‌رود)، افراد قوی تیم وقت ارزشمندشان را صرف کشیدن فرد ضعیف می‌کنند و روحیه‌ی تیم کاهش می‌یابد.
• مطمئن باش که تیم می‌داند فرد ضعیف آنجاست حتی اگر تو نادیده‌اش بگیری — بقیه‌ی تیم کاملاً آگاهند که افراد ضعیف چه کسانی هستند، چون باید آن‌ها را با خود حمل کنند.

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

چگونه با فرد ضعیف برخورد کنیم؟

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

یک بازه‌ی زمانی مشخص تعیین کن (مثلاً دو یا سه ماه)، و چند هدف بسیار خاص که انتظار داری او در آن دوره به آن‌ها برسد. اهداف را کوچک و تدریجی قرار بده، تا فرصت برای موفقیت‌های کوچک زیاد باشد. هر هفته با او ملاقات کن تا پیشرفت را بررسی کنی.

اگر فرد ضعیف نتواند همگام بماند، برای هر دوی شما خیلی زود آشکار می‌شود. در این مرحله، فرد اغلب تصدیق می‌کند که اوضاع خوب نیست و تصمیم می‌گیرد استعفا دهد؛ در موارد دیگر، عزم‌اش فعال می‌شود و «بازی‌اش را بهتر می‌کند» تا انتظارات را برآورده کند.

ضدالگو: نادیده گرفتن مسائل انسانی

یک رهبر تیم دو حوزه‌ی اصلی تمرکز برای تیمش دارد: اجتماعی و فنی. معمولاً رهبران در جنبه‌ی فنی قوی‌ترند، و چون اکثر رهبران از یک شغل فنی ارتقا می‌یابند، تمایل دارند مسائل انسانی را نادیده بگیرند.

مثال واقعی:
سال‌ها پیش، یک دوست نزدیک فیتز — بیایید او را جیک بنامیم — اولین فرزندش را به دنیا آورد. جیک و فیتز سال‌ها با هم کار کرده بودند، پس در هفته‌های بعد از تولد نوزاد، جیک از خانه کار می‌کرد. این برای جیک و همسرش عالی بود، و فیتز هم کاملاً راضی بود چون قبلاً هم به کار از راه دور با جیک عادت داشت. آن‌ها مانند همیشه پرکار بودند تا این‌که مدیرشان، پابلو (که در دفتر دیگری کار می‌کرد)، فهمید که جیک بیشتر هفته از خانه کار می‌کند.

پابلو ناراحت شد که جیک برای کار با فیتز به دفتر نمی‌آید، با این‌که جیک همان‌قدر پرکار بود و فیتز هم مشکلی نداشت. جیک سعی کرد به پابلو توضیح دهد که او همان‌قدر که در دفتر می‌بود پرکار است، و برای چند هفته کار کردن از خانه برای او و همسرش آسان‌تر است. پاسخ پابلو این بود: «رفیق، همه دارن بچه می‌آرن. تو باید بیای دفتر.»

طبیعتاً جیک (که معمولاً مهندس آرامی بود) عصبانی شد و احترام زیادی به پابلو از دست داد.

راه‌های بسیاری وجود داشت که پابلو می‌توانست متفاوت عمل کند: می‌توانست کمی درک نشان دهد که جیک می‌خواهد بیشتر برای همسرش خانه باشد، و اگر بهره‌وری و تیمش تحت تأثیر قرار نگرفته بود، به او اجازه دهد مدتی این کار را ادامه دهد. یا می‌توانست مذاکره کند که جیک یکی دو روز هفته به دفتر بیاید تا اوضاع آرام شود. صرف‌نظر از نتیجه، کمی همدلی راه زیادی می‌رفت برای شاد نگه داشتن جیک در این شرایط.

ضدالگو: دوست همه بودن

اولین تجربه‌ای که اکثر افراد در رهبری دارند، زمانی است که رهبر تیمی می‌شوند که قبلاً عضوش بودند. بسیاری از رهبران نمی‌خواهند دوستی‌هایی را که با تیمشان پرورش داده‌اند از دست بدهند، پس گاهی بیش از حد تلاش می‌کنند تا این دوستی‌ها را حفظ کنند. این می‌تواند دستور‌العمل فاجعه و دوستی‌های شکسته باشد.

هشدار: دوستی را با رهبری با لمس نرم اشتباه نگیر. وقتی قدرتی بر شغل کسی داری، او ممکن است فشار حس کند که به طور مصنوعی حرکات دوستانه را متقابل کند.

به یاد داشته باش که می‌توانی یک تیم را رهبری کنی و اجماع بسازی بدون این‌که همتای تیمت باشی (یا یک آدم بی‌رحم سخت‌گیر). همچنین می‌توانی یک رهبر سخت‌گیر باشی بدون این‌که دوستی‌های موجودت را به باد بدهی.

ما دریافته‌ایم که ناهار خوردن با تیمت می‌تواند راهی مؤثر برای ارتباط اجتماعی با آن‌ها باشد بدون این‌که احساس ناراحتی کنند — این به تو فرصت می‌دهد گفتگوهای غیررسمی خارج از محیط کار معمول داشته باشی.

ضدالگو: سازش در استاندارد استخدام

استیو جابز یک بار گفت: «افراد درجه یک، افراد درجه یک دیگر استخدام می‌کنند؛ افراد درجه دو، افراد درجه سه استخدام می‌کنند.»

افتادن در دام این ضرب‌المثل فوق‌العاده آسان است، به‌خصوص وقتی سعی می‌کنی سریع استخدام کنی. هزینه‌ی یافتن فرد مناسب — چه از طریق پرداخت به استخدام‌کنندگان، تبلیغات، یا پیدا کردن ارجاعات — در مقایسه با هزینه‌ی برخورد با کارمندی که هرگز نباید استخدام می‌کردی، بسیار ناچیز است.

این «هزینه» خودش را در کاهش بهره‌وری تیم، استرس تیم، زمان صرف‌شده برای مدیریت کارمند برای بهبود یا اخراج، و کاغذبازی و استرس مربوط به اخراج کارمند نشان می‌دهد.

ضدالگو: رفتار با تیم مانند بچه‌ها

بهترین راه برای نشان دادن این‌که به تیمت اعتماد نداری این است که با آن‌ها مانند بچه رفتار کنی — مردم تمایل دارند همان‌طور رفتار کنند که با آن‌ها رفتار می‌شود، پس اگر با آن‌ها مانند بچه یا زندانی رفتار کنی، تعجب نکن اگر همان‌طور رفتار کنند.

می‌توانی این رفتار را با میکرومدیریت آن‌ها یا ساده‌تر با بی‌احترامی به توانایی‌هایشان و ندادن فرصتی به آن‌ها برای مسئول بودن کارشان نشان دهی. اگر برای همیشه لازم است مردم را میکرومدیریت کنی چون به آن‌ها اعتماد نداری، یک شکست استخدامی داری.

اگر افرادی را استخدام کنی که شایسته‌ی اعتماد هستند و به آن‌ها نشان دهی که بهشان اعتماد داری، معمولاً به سطح انتظار می‌رسند.

---

ادامه‌ی فصل ۶ را درباره‌ی الگوهای مثبت رهبری با فارسی روان و گرامر درست ارسال می‌کنم.

الگوهای مثبت رهبری

حالا که ضدالگوها را دیدیم، بیایید درباره‌ی الگوهای رفتاری مثبت برای رهبری موفق صحبت کنیم. این الگوها چیزهایی هستند که ما از تجربه، از تماشای رهبران موفق دیگر، و بیش از همه از مربیان رهبری خودمان آموخته‌ایم.

الگو: کنار گذاشتن غرور

در فصل ۱ درباره‌ی «کنار گذاشتن غرور» در رابطه با HRT صحبت کردیم، اما این موضوع وقتی در نقش رهبر خادم هستی، فوق‌العاده مهم است.

این الگو اغلب به اشتباه تفسیر می‌شود که رهبران باید «پادری زیر پا» باشند و بگذارند تیمشان بالای سرشان راه بروند، اما اصلاً این‌طور نیست. یک خط باریک بین فروتن بودن و اجازه دادن به دیگران که از تو سوءاستفاده کنند، وجود دارد — اما فروتنی با فقدان اعتمادبه‌نفس یکی نیست. تو همچنان می‌توانی اعتمادبه‌نفس و نظرات خودت را داشته باشی بدون این‌که خودشیفته باشی.

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

بخشی از «کنار گذاشتن غرور» چیزی است که قبلاً پوشش دادیم: باید به تیمت اعتماد کنی. این یعنی به توانایی‌ها و دستاوردهای قبلی اعضای تیم احترام بگذاری، حتی اگر تازه به تیمت پیوسته باشند.

اگر تیمت را میکرومدیریت نمی‌کنی، می‌توانی تقریباً مطمئن باشی که افرادی که در خط مقدم کار می‌کنند، جزئیات کارشان را بهتر از تو می‌دانند. این بدان معناست که در حالی که ممکن است تو کسی باشی که تیم را به سمت اجماع هدایت می‌کنی و کمک می‌کنی جهت را تعیین کنی، جزئیات اجرایی برای رسیدن به اهدافتان بهتر است توسط افرادی که محصول را می‌سازند، تصمیم گرفته شود. این نه‌تنها حس مالکیت بیشتری به آن‌ها می‌دهد، بلکه حس مسئولیت‌پذیری و پاسخگویی بیشتری برای موفقیت (یا شکست!) محصولشان ایجاد می‌کند.

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

نکته مهم: عذرخواهی کردن هنگام اشتباه

آخرین بخش کنار گذاشتن غرور، یک کار ساده است، اما بسیاری از مهندسان ترجیح می‌دهند در روغن جوشان انداخته شوند تا این کار را انجام دهند: وقتی اشتباه می‌کنی، عذرخواهی کن. و منظورمان این نیست که فقط «متأسفم» را مانند نمک روی ذرت بو‌داده در سراسر گفتگوت پاشیدن کنی — باید واقعاً منظورت جدی باشد.

قطعاً اشتباه خواهی کرد، و چه قبولش کنی چه نکنی، تیمت می‌داند که اشتباه کرده‌ای. آن‌ها می‌دانند، صرف‌نظر از این‌که با تو صحبت کنند یا نه (و یک چیز تضمینی است: با یکدیگر درباره‌اش صحبت خواهند کرد). عذرخواهی پول خرج ندارد. مردم احترام فوق‌العاده‌ای برای رهبرانی دارند که وقتی اشتباه می‌کنند، عذرخواهی می‌کنند، و برخلاف باور عمومی، این تو را آسیب‌پذیر نمی‌کند. در واقع، معمولاً احترام مردم را وقتی عذرخواهی می‌کنی، به دست می‌آوری، چون عذرخواهی به مردم می‌گوید که تو متعادل هستی، در ارزیابی موقعیت‌ها خوب عمل می‌کنی، و — بازگشت به HRT — فروتن هستی.

الگو: استاد ذن باش

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

کنترل واکنش‌های خود و حفظ آرامش وقتی افراد بیشتری را رهبری می‌کنی، مهم‌تر می‌شود، چون تیمت (هم ناخودآگاه و هم آگاهانه) به دنبال نشانه‌هایی از تو خواهند بود که چگونه باید نسبت به هر اتفاقی که اطرافشان می‌افتد، عمل و واکنش نشان دهند.

تصویرسازی: چرخ‌دنده‌های سازمانی

یک راه ساده برای تصویرسازی این اثر، دیدن نمودار سازمانی شرکتت به عنوان یک زنجیره از چرخ‌دنده‌هاست. کارمند عادی یک چرخ‌دنده کوچک با تعداد کمی دندانه در یک سر است، و هر مدیر بعدی بالاتر از او، یک چرخ‌دنده دیگر است، و در نهایت مدیرعامل بزرگ‌ترین چرخ‌دنده با صدها دندانه است. این یعنی هر بار که چرخ‌دنده «مدیر» (با شاید چند ده دندانه) یک دور کامل می‌زند، چرخ‌دنده «کارمند» دو یا سه دور می‌زند. و مدیرعامل می‌تواند یک حرکت کوچک انجام دهد و کارمند بیچاره را، در انتهای زنجیره‌ای از شش یا هفت چرخ‌دنده، به طور وحشتناکی بچرخاند! هر چه بالاتر بروی، سریع‌تر می‌توانی چرخ‌دنده‌های زیرین را بچرخانی، چه قصدش را داشته باشی چه نداشته باشی.

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

اگر در یک موقعیت رهبری آشکار هستی، همیشه تحت نظر هستی: نه فقط وقتی جلسه برگزار می‌کنی یا سخنرانی می‌کنی، بلکه حتی وقتی فقط پشت میزت نشسته‌ای و به ایمیل‌ها پاسخ می‌دهی. همکارانت تو را برای نشانه‌های ظریف در زبان بدنت، واکنش‌هایت به صحبت‌های کوچک، و سیگنال‌هایت موقع ناهار خوردن، تماشا می‌کنند. آیا آن‌ها اعتماد یا ترس می‌خوانند؟ به عنوان یک رهبر، کارت الهام بخشیدن است، اما الهام‌بخشی یک کار ۲۴/۷ است. نگرش قابل مشاهده‌ی تو درباره‌ی هر چیزی — هر چقدر هم بی‌اهمیت — به طور ناخودآگاه متوجه می‌شود و به صورت مسری به تیمت منتقل می‌شود.

مثال واقعی: مدیری که همیشه آرام بود

فیتز مدیری به نام بیل داشت که واقعاً توانایی حفظ آرامش در همه مواقع را تسلط یافته بود. مهم نیست چه چیزی منفجر می‌شد، مهم نیست چه اتفاق دیوانه‌واری می‌افتاد، مهم نیست طوفان چقدر بزرگ بود، بیل هرگز پانیک نمی‌کرد. بیشتر اوقات یک دستش را روی سینه‌اش می‌گذاشت، چانه‌اش را روی دستش می‌گذاشت، و درباره‌ی مشکل سؤال می‌پرسید، معمولاً از یک کارمند کاملاً پانیک‌زده. این باعث می‌شد او آرام شود و به او کمک می‌کرد تا روی حل مشکل تمرکز کند به جای این‌که مثل مرغ بی‌سر حرکت کند.

ترفند مدیریت ذن: پرسیدن سؤال

وقتی یک عضو تیم از تو مشاوره می‌خواهد، معمولاً خیلی هیجان‌انگیز است چون بالاخره فرصت رفع کردن چیزی را پیدا کرده‌ای! این دقیقاً همان کاری است که سال‌ها قبل از ورود به موقعیت رهبری انجام می‌دادی، پس معمولاً می‌پری توی حالت حل مشکل، اما این آخرین جایی است که باید باشی. فردی که می‌خواهد مشاوره بگیرد، معمولاً نمی‌خواهد تو مشکلش را حل کنی، بلکه می‌خواهد به او کمک کنی تا خودش حلش کند، و ساده‌ترین راه برای این کار پرسیدن سؤال از اوست.

به جای این‌که جواب بدهی، سؤال بپرس تا به او کمک کنی مشکلش را بهتر تعریف کند. این معمولاً کارمند را به سمت پاسخ هدایت می‌کند، و پاسخ او خواهد بود، که بازمی‌گردد به مالکیت و مسئولیتی که قبلاً درباره‌اش صحبت کردیم. چه پاسخ را داشته باشی چه نداشته باشی، استفاده از این تکنیک تقریباً همیشه این تأثیر را روی کارمند خواهد گذاشت که تو پاسخ را داشتی. حیله‌گرانه است، نه؟ سقراط به تو افتخار می‌کرد.

---

ادامه‌ی الگوهای مثبت رهبری را با فارسی روان و گرامر درست ارسال می‌کنم.

الگو: کاتالیزور باش

یکی از بهترین کارهایی که یک رهبر تیم می‌تواند انجام دهد، این است که موانع را از سر راه تیم بردارد تا آن‌ها بتوانند بهتر کار کنند. هنگامی که بر عملکرد افراد تیمت تمرکز می‌کنی، می‌توانی به‌عنوان یک کاتالیزور عمل کنی و به آن‌ها کمک کنی تا به اهداف خود برسند.

تشبیه مادر در قانون فیتز درباره‌ی کاتالیزور:

مادر شوهر فیتز یک روز گفت: «مردم مثل گیاه هستند. اگر یک گیاه رشد نکند، می‌توانی آفتاب و آب بیشتری بهش بدهی، اما اگر هنوز رشد نکرد، احتمالاً آن گیاه باید در خاکی دیگر باشد.»

این یک تشبیه فوق‌العاده برای مدیریت انسان‌هاست. به عنوان یک رهبر تیم، می‌توانی به افرادی که در کار خودشان مشکل دارند، کمک کنی، اما نه با میکرومدیریت کردنشان. بلکه با فراهم کردن ابزار، مشاوره، و دانشی که نیاز دارند، می‌توانی آن‌ها را برای موفقیت آماده کنی.

نمونه‌هایی از نقش کاتالیزوری:

• داشتن یک جلسه‌ی هفتگی برای بررسی موانع: پرسیدن از تیم که «چه چیزی شما را کند کرده؟» یا «چه کمکی می‌توانم به شما بکنم؟»
• برداشتن موانع اداری: اگر تیمت به دست‌رسی به ابزاری نیاز دارد، تو می‌توانی با بخش‌های دیگر شرکت هماهنگ کنی تا این کار انجام شود
• ایجاد ارتباطات: اگر دو عضو تیم نیاز دارند با هم همکاری کنند اما این اتفاق نمی‌افتد، تو می‌توانی آن‌ها را به هم معرفی کنی یا جلساتی ترتیب بدهی

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

محافظت از تیمت در برابر هرج‌ومرج

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

این بدان معنا نیست که بقیه‌ی سازمان “بد” است، بلکه به این معنی است که آن‌ها اولویت‌ها و مسائل خودشان را دارند که ممکن است همیشه با اولویت‌های تیم تو همسو نباشد. وظیفه‌ی تو این است که اطمینان حاصل کنی تیمت می‌تواند روی کارش تمرکز کند بدون این‌که دائماً وقفه ایجاد شود.

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

الگو: معلم و مربی باش

یکی از سخت‌ترین کارها برای یک رهبر تیم، تماشا کردن یک عضو جونیور تیم است که سه ساعت روی چیزی کار می‌کند که تو می‌دانی می‌توانی در ۲۰ دقیقه انجامش دهی. تعلیم دادن به افراد و دادن فرصت به آن‌ها برای یادگیری در ابتدا می‌تواند فوق‌العاده سخت باشد، اما یک جزء حیاتی رهبری موثر است.

این به‌ویژه برای استخدام‌های جدید مهم است که علاوه بر یادگیری تکنولوژی و کدبیس تیم، فرهنگ تیمت و سطح مناسب مسئولیتی که باید بپذیرند را هم یاد می‌گیرند.

چگونه یک مربی خوب باشیم:

مشابه نقش مدیر، اکثر افراد برای نقش مربی درخواست نمی‌دهند — معمولاً وقتی یک رهبر تیم به دنبال کسی است که یک عضو جدید تیم را راهنمایی کند، مربی می‌شوند. نیازی به آموزش رسمی زیاد برای مربی بودن نیست؛ در واقع، به طور اولیه به سه چیز نیاز داری:

1. تجربه با فرآیندها و سیستم‌های تیمت
2. توانایی توضیح دادن چیزها به شخص دیگری
3. توانایی سنجش این‌که فرد تحت راهنمایی‌ات به چه میزان کمک نیاز دارد

آخرین مورد احتمالاً مهم‌ترین است — دادن اطلاعات کافی به فرد تحت راهنمایی‌ات همان کاری است که قرار است انجام دهی، اما اگر بیش از حد توضیح بدهی یا بی‌پایان حرف بزنی، او احتمالاً حواسش را پرت خواهد کرد به جای این‌که مؤدبانه به تو بگوید که متوجه شده.

الگو: هدف‌های واضح تعیین کن

این یکی از آن الگوهایی است که هرچند به نظر بدیهی می‌رسد، توسط تعداد زیادی از رهبران کاملاً نادیده گرفته می‌شود. اگر می‌خواهی تیمت به سرعت در یک جهت حرکت کند، باید مطمئن شوی همه‌ی آن‌ها جهت را درک می‌کنند و با آن موافق هستند.

تشبیه کامیون:

تصور کن محصولت یک کامیون بزرگ است. هر عضو تیم یک طناب در دستش دارد که به جلوی کامیون بسته شده، و همان‌طور که روی محصول کار می‌کند، کامیون را به سمت خودش می‌کشد. اگر قصدت این است که کامیون را تا حد امکان سریع به سمت شمال بکشی، نمی‌توانی بگذاری اعضای تیم به هر جهتی بکشند — می‌خواهی همه‌ی آن‌ها کامیون را به سمت شمال بکشند.

راه حل:

ساده‌ترین راه برای تعیین یک هدف واضح و وادار کردن تیمت به کشیدن محصول در یک جهت، ایجاد یک بیانیه‌ی مأموریت مختصر برای تیم است.

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

تیم‌ها می‌توانند (و می‌توانند) بدون اهداف واضح موفق شوند، اما معمولاً مقدار زیادی انرژی را هدر می‌دهند چون هر عضو تیم محصول را کمی در جهت متفاوتی می‌کشد. این تو را ناامید می‌کند، پیشرفت تیم را کند می‌کند، و مجبورت می‌کند انرژی بیشتر و بیشتری برای اصلاح مسیر صرف کنی.

---

ادامه‌ی الگوهای مثبت رهبری را با فارسی روان و گرامر درست ارسال می‌کنم.

الگو: صادق باش

به عنوان رهبر، یکی از مهم‌ترین چیزها این است که با تیمت صادق باشی. این شامل موارد زیر می‌شود:

1. صداقت درباره‌ی محدودیت‌ها و چالش‌ها

اگر تیمت روی پروژه‌ای کار می‌کند که احتمال لغو شدنش بالا است، یا اگر بودجه‌ی شما در خطر است، یا هر نوع مشکل دیگری در راه است، باید با تیمت در این باره صادق باشی. پنهان کردن اطلاعات مهم از تیمت نه‌تنها اعتماد را از بین می‌برد، بلکه وقتی حقیقت فاش شود (و معمولاً فاش می‌شود)، شوک بسیار بزرگتری خواهد بود.

2. صداقت درباره‌ی عملکرد

وقتی یک عضو تیم عملکرد ضعیفی دارد، باید در اسرع وقت با او درباره‌اش صحبت کنی. معمولاً مردم می‌دانند وقتی عملکرد ضعیفی دارند، پس پنهان کردن آن فقط باعث می‌شود که وضعیت بدتر شود. با صداقت و احترام با آن‌ها صحبت کن و به آن‌ها کمک کن تا بهبود یابند.

3. صداقت درباره‌ی تصمیمات

اگر تصمیمی گرفته شده که ممکن است تیمت دوست نداشته باشد، صادقانه درباره‌ی دلایل آن صحبت کن. حتی اگر نمی‌توانی تصمیم را تغییر دهی، توضیح دادن منطق پشت آن می‌تواند به تیمت کمک کند تا آن را بهتر بپذیرد.

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

الگو: پیگیری شادی تیم

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

بهترین رهبرانی که با آن‌ها کار کرده‌ایم، همه روان‌شناسان آماتور بودند — گاهی اوقات به رفاه اعضای تیمشان نگاه می‌کنند، مطمئن می‌شوند که برای کاری که انجام می‌دهند تقدیر می‌شوند، و سعی می‌کنند مطمئن شوند که از کارشان راضی هستند.

چگونه شادی تیم را پیگیری کنیم:

1. توزیع عادلانه کارهای ناخوشایند

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

2. مراقبت از ساعات کاری

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

3. جلسات یک‌به‌یک منظم

یکی دیگر از رهبران، جلسات یک‌به‌یک خود با اعضای تیم را با پرداختن به مسائل فنی آن‌ها شروع می‌کند تا یخ را بشکند، سپس کمی وقت می‌گذارد تا مطمئن شود هر مهندس هر چیزی که برای انجام کارش نیاز دارد را دارد. بعد از گرم شدن، کمی با مهندس درباره‌ی این‌که چگونه از کاری که انجام می‌دهد لذت می‌برد و به چه چیزی مشتاق است، صحبت می‌کند.

4. سؤال جادویی: “به چه چیزی نیاز داری؟”

یکی از ارزشمندترین ابزارها در پیگیری شادی تیمت این است که در پایان هر جلسه‌ی یک‌به‌یک، از عضو تیم بپرسی: “به چه چیزی نیاز داری؟” این سؤال ساده، راه عالی برای جمع‌بندی و اطمینان از این که هر عضو تیم آنچه را که برای بهره‌ور و شاد بودن نیاز دارد، دارد.

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

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

همچنین می‌تواند ارزشمند باشد که به شادی تیمت خارج از محیط کار توجه کنی. مراقب باش که فرض نکنی مردم هیچ زندگی‌ای خارج از کار ندارند — داشتن انتظارات غیرواقعی درباره‌ی مقدار زمانی که مردم می‌توانند به کارشان اختصاص دهند، باعث می‌شود احترامت را از دست بدهی، یا بدتر، باعث فرسودگی آن‌ها می‌شود.

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

6. پیگیری مسیر شغلی

بخش بزرگی از پیگیری شادی اعضای تیمت، پیگیری مسیر شغلی آن‌هاست. اگر از یک عضو تیم بپرسی که پنج سال بعد حرفه‌اش را کجا می‌بیند، بیشتر اوقات با شانه بالا انداختن و نگاه خالی مواجه می‌شوی. اما معمولاً چند چیز وجود دارد که همه دوست دارند در پنج سال آینده انجام دهند: ارتقا بگیرند، چیز جدیدی یاد بگیرند، چیز مهمی را راه‌اندازی کنند، و با افراد باهوش کار کنند.

صرف‌نظر از این‌که آن‌ها این را بیان کنند یا نه، اکثر مردم درباره‌اش فکر می‌کنند. اگر می‌خواهی رهبر مؤثری باشی، باید درباره‌ی این‌که چگونه می‌توانی به تحقق همه‌ی این چیزها کمک کنی، فکر کنی و به تیمت بگویی که داری به این فکر می‌کنی.

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

پیگیری شادی در نهایت به این برمی‌گردد که نه‌تنها مسیرهای شغلی را مانیتور کنی، بلکه به اعضای تیمت فرصت‌هایی برای بهبود خودشان، تقدیر شدن برای کاری که انجام می‌دهند، و کمی تفریح در این مسیر بدهی.

---

ادامه‌ی الگوهای مثبت رهبری را با فارسی روان و گرامر درست ارسال می‌کنم.

انگیزه‌ی درونی در مقابل انگیزه‌ی بیرونی

دو نوع انگیزه وجود دارد: انگیزه‌ی بیرونی (Extrinsic) که از نیروهای خارجی (مانند جبران خسارت مالی) نشأت می‌گیرد، و انگیزه‌ی درونی (Intrinsic) که از درون می‌آید.

دن پینک در کتاب Drive خود توضیح می‌دهد که راه ایجاد شادترین و بهره‌ورترین افراد این نیست که آن‌ها را بیرونی انگیزه دهیم (مثلاً پول زیادی به آن‌ها بدهیم)، بلکه باید برای افزایش انگیزه‌ی درونی‌شان تلاش کنیم. دن ادعا می‌کند که می‌توانید انگیزه‌ی درونی را با دادن سه چیز به افراد افزایش دهید: استقلال (Autonomy)، تسلط (Mastery)، و هدف (Purpose).

استقلال (Autonomy)

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

این به انگیزه کمک می‌کند، نه‌تنها به این دلیل که آن‌ها رابطه‌ی نزدیک‌تری با محصول دارند (و احتمالاً بهتر از شما می‌دانند چگونه آن را بسازند)، بلکه به این دلیل که احساس مالکیت بسیار بیشتری نسبت به محصول به آن‌ها می‌دهد. هرچه سهم آن‌ها در موفقیت محصول بزرگتر باشد، علاقه‌ی آن‌ها به موفقیت محصول بیشتر است.

تسلط (Mastery)

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

مهارت‌های یک کارمند مانند تیغه‌ی یک چاقو است: ممکن است ده‌ها هزار دلار خرج کنید تا افرادی با تیزترین مهارت‌ها را برای تیمتان پیدا کنید، اما اگر سال‌ها از آن چاقو استفاده کنید بدون این‌که آن را تیز کنید، در نهایت با یک چاقوی کند مواجه خواهید شد که ناکارآمد و در برخی موارد بی‌فایده است. فرصت‌های کافی برای اعضای تیم جهت یادگیری چیزهای جدید و تسلط بر حرفه‌شان، آن‌ها را تیز، کارآمد و مؤثر نگه می‌دارد.

هدف (Purpose)

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

بسیاری از افراد روی محصولاتی کار می‌کنند که اهمیت زیادی دارند، اما آن‌ها از تأثیرات مثبتی که محصولاتشان ممکن است بر شرکتشان، مشتریانشان یا حتی جهان داشته باشند، دور نگه داشته می‌شوند. حتی در مواردی که محصول ممکن است تأثیر کوچک‌تری داشته باشد، می‌توانید تیمتان را با جستجوی دلیل تلاش‌هایشان و روشن کردن این دلیل برایشان، انگیزه دهید.

اگر بتوانید به آن‌ها کمک کنید این هدف را در کارشان ببینند، شاهد افزایش چشمگیری در انگیزه و بهره‌وری آن‌ها خواهید بود.

مثال عملی:

یکی از مدیرانی که می‌شناسیم، چشم‌اندازی دقیق به بازخورد ایمیل‌هایی که شرکت برای محصولش دریافت می‌کند، دارد (یکی از محصولات با تأثیر کوچک‌تر). هروقت پیامی از مشتری می‌بیند که درباره‌ی این صحبت می‌کند که چگونه محصول شرکت به او شخصاً یا به کسب‌وکارش کمک کرده، بلافاصله آن را برای تیم مهندسی فوروارد می‌کند. این نه‌تنها تیم را انگیزه می‌دهد، بلکه اغلب آن‌ها را الهام می‌بخشد که درباره‌ی راه‌هایی فکر کنند که می‌توانند محصولشان را حتی بهتر کنند.

الگو: مردم مانند گیاه هستند

مادر شوهر فیتز کوچک‌ترین فرزند از شش فرزند است، و مادرش با وظیفه‌ی دشوار بزرگ کردن شش فرزند بسیار متفاوت مواجه بود که هرکدام به چیزهای متفاوتی نیاز داشتند. فیتز از مادرشوهرش پرسید که چگونه این کار را مدیریت کرد، و او پاسخ داد:

“بچه‌ها مانند گیاه هستند: برخی مانند کاکتوس هستند و به آب کم اما آفتاب زیاد نیاز دارند، برخی دیگر مانند بنفشه‌های آفریقایی هستند و به نور پراکنده و خاک مرطوب نیاز دارند، و برخی دیگر مانند گوجه‌فرنگی هستند و واقعاً عالی عمل می‌کنند اگر کمی کود به آن‌ها بدهید.”

اگر شش بچه دارید و به هرکدام مقدار یکسانی از آب، نور و کود بدهید، همگی رفتار برابر دریافت می‌کنند، اما احتمال زیاد است که هیچ‌کدام آنچه را که واقعاً نیاز دارند، دریافت نکنند.

بنابراین اعضای تیم شما نیز مانند گیاه هستند: برخی به نور بیشتر نیاز دارند و برخی به آب بیشتر (و برخی به کود بیشتر نیاز دارند). شغل شما به عنوان رهبرشان این است که بفهمید چه کسی به چه چیزی نیاز دارد و سپس آن را به او بدهید.

به این ماتریس نگاه کنید:

• بالا چپ (انگیزه‌ی بالا + جهت کم): “ببین! سنجاب!” — افرادی که انگیزه دارند اما جهت ندارند
• بالا راست (انگیزه‌ی بالا + جهت بالا): “نقطه‌ی شیرین” — افرادی که هم انگیزه دارند و هم جهت
• پایین چپ (انگیزه‌ی کم + جهت کم): “سرگردان” — افرادی که نه انگیزه دارند و نه جهت
• پایین راست (انگیزه‌ی کم + جهت بالا): “گیر کرده” — افرادی که جهت دارند اما انگیزه ندارند

برای قرار دادن همه‌ی اعضای تیم در نقطه‌ی شیرین، باید:

• کسانی که در بخش “گیر کرده” هستند را انگیزه دهید
• به کسانی که در بخش “ببین! سنجاب!” هستند، جهت قوی‌تری بدهید
• به کسانی که “سرگردان” هستند، هم انگیزه و هم جهت بدهید

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

دادن جهت نسبتاً ساده است — نیاز به درک اولیه‌ای از آنچه باید انجام شود، مهارت‌های سازمانی ساده و هماهنگی کافی برای تقسیم آن به وظایف قابل‌مدیریت دارد.

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

---

ادامه‌ی ضدالگوهای رهبری را با فارسی روان و گرامر درست ارسال می‌کنم.

ضدالگو: مصالحه‌ی برای همدلی (Compromise the Quest for Consensus)

اجماع (Consensus) یک چیز عالی است، اما هر کسی که تابه‌حال در یک تیم کار کرده، می‌داند که رسیدن به اجماع دشوار است و گاهی اوقات غیرممکن. اگر مصالحه برای رسیدن به اجماع را بیش‌ازحد پیش ببرید، ممکن است خودتان را در موقعیتی پیدا کنید که همه چیز برای خوشحال کردن همه، دستکاری شده باشد و هیچ‌کس از نتیجه راضی نباشد.

همچنین احتمال زیادی وجود دارد که اگر تلاش کنید هر فرد در تیمتان را در تمام تصمیمات درگیر کنید، فرآیند تصمیم‌گیری به آهستگی گاری می‌خزد و بهره‌وری تیم به شدت کاهش می‌یابد.

راه‌حل:

در صورت امکان به دنبال اجماع باشید، اما از فرآیند بازگشت (Fallback) برای حل اختلافات زمانی که نمی‌توان به اجماع دست یافت، استفاده کنید. یک استراتژی خوب این است که تیمتان را به گروه‌های کوچک‌تری تقسیم کنید که مسئولیت‌های مشخصی دارند، و به آن‌ها اختیار تصمیم‌گیری در حوزه‌ی خودشان را بدهید.

بسته به پروژه و تیم، ممکن است تصمیم بگیرید که یک نفر (مثلاً رهبر تیم) تصمیم نهایی را می‌گیرد، یا اینکه یک گروه کوچک از افراد (مثلاً یک کمیته‌ی فنی) تصمیم را می‌گیرند. مهم این است که قبل از این‌که اختلاف بزرگی پیش بیاید، این فرآیند را مشخص و مستند کنید.

مثال:

بنیاد Apache Software Foundation یک مدل اجماع دارد، اما اگر اجماع دست‌نیافتنی باشد، آن‌ها به رأی‌گیری رسمی متوسل می‌شوند. در Google، بسیاری از تیم‌های مهندسی به رهبر تیم اختیار می‌دهند که تصمیم نهایی را بگیرد، اما تنها پس از شنیدن نظرات همه‌ی اعضای تیم.

ضدالگو: به اندازه‌ی کافی در ارتباط نبودن (Being a Roadblock)

اگر به عنوان رهبر، همیشه گلوگاه (Bottleneck) تیمت هستی — به این معنا که همه چیز باید از طریق تو عبور کند — تیمت بسیار کند خواهد بود و اعضای تیم احساس می‌کنند که به آن‌ها اعتماد نمی‌شود.

یک رهبر خوب باید به اندازه‌ی کافی در ارتباط باشد تا بداند چه اتفاقی می‌افتد، اما نه آنقدر زیاد که گلوگاه شود. اگر خودت را در موقعیتی می‌بینی که تمام تصمیمات باید از تو عبور کنند، باید یاد بگیری که تفویض اختیار (Delegate) کنی و به تیمت اعتماد کنی.

تفویض اختیار درست:

تفویض اختیار به این معنا نیست که فقط کارها را به اعضای تیم بدهی و بعد فراموششان کنی. تفویض اختیار به این معناست که مسئولیت (Responsibility) را به اعضای تیم بدهی، اما همچنان مسئولیت‌پذیری (Accountability) را نگه دارید. به عبارت دیگر، تو هنوز مسئول نتیجه نهایی هستی، اما دیگر خودت همه چیز را انجام نمی‌دهی.

وقتی تفویض اختیار می‌کنی، باید روشن باشی درباره‌ی این‌که چه چیزی را می‌خواهی انجام شود، اما نیازی نیست که دقیقاً مشخص کنی چگونه باید انجام شود. به عضو تیم اجازه بده که راه حل خودش را پیدا کند — این نه‌تنها باعث می‌شود او احساس مالکیت بیشتری کند، بلکه احتمالاً راه حلی بهتر از آنچه تو فکر می‌کردی پیدا خواهد کرد.

و همیشه به یاد داشته باش: اگر فردی را به اندازه‌ی کافی برای کار کردن در تیمت شایسته می‌دانی، باید او را برای تصمیم‌گیری‌های خود نیز شایسته بدانی.

ضدالگو: محافظت نکردن تیم از سیاست (Not Shielding Your Team from Chaos)

همان‌طور که قبلاً اشاره شد، یکی از مهم‌ترین کارهای یک رهبر، محافظت از تیم در برابر هرج‌ومرج و سیاست سازمانی است. اگر این کار را نکنی، تیمت دائماً حواسش پرت می‌شود و انرژی زیادی را برای چیزهایی که کنترل‌پذیر نیستند، صرف می‌کند.

مثال:

تصور کنید مدیر ارشد شما به تو می‌گوید که ممکن است بودجه‌ی پروژه کاهش یابد، اما هنوز مشخص نیست. آیا باید فوراً این اطلاعات را با تیمت به اشتراک بگذاری و همه را نگران کنی؟ یا باید صبر کنی تا جزئیات بیشتری داشته باشی؟

پاسخ این است: به اطلاع‌رسانی به تیمت ادامه بده، اما آن‌ها را از عدم قطعیت‌هایی که بعید است واقعاً به آن‌ها آسیب برساند، محافظت کن. اگر هر بار که شایعه‌ای شنیدی آن را با تیمت به اشتراک بگذاری، فقط باعث نگرانی و اختلال در تمرکز می‌شوی.

با این حال، اگر اطلاعات مهمی وجود داشته باشد که واقعاً بر تیمت تأثیر می‌گذارد (مثلاً تغییر اولویت‌ها، تغییر ضرب‌الاجل، یا تغییر منابع)، باید صادقانه و به سرعت با تیمت درباره‌اش صحبت کنی.

ضدالگو: دوست همه بودن (Being Everyone’s Friend)

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

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

راه‌حل:

با همه‌ی اعضای تیمت دوستانه و محترمانه رفتار کن، اما همیشه مرزهای حرفه‌ای را حفظ کن. باید بتوانی در صورت نیاز، تصمیمات سخت بگیری، حتی اگر این باعث ناراحتی کسی شود. رهبری به معنای محبوب بودن نیست؛ رهبری به معنای احترام شدن است.

خلاصه‌ی فصل

رهبری یک تیم به معنای یافتن تعادل بین رهبری فنی و رهبری اجتماعی است. بهترین رهبران تیم کسانی هستند که:

• به اعضای تیمشان خدمت می‌کنند، نه اینکه از آن‌ها انتظار خدمت داشته باشند
• به جای پاسخ دادن، سؤال می‌پرسند و تیمشان را به یافتن راه‌حل تشویق می‌کنند
• کاتالیزور هستند و موانع را از سر راه تیم برمی‌دارند
• معلم و مربی هستند و به اعضای تیم کمک می‌کنند تا رشد کنند
• اهداف واضحی تعیین می‌کنند تا همه بدانند در چه جهتی حرکت می‌کنند
• با تیمشان صادق هستند، حتی وقتی خبرها بد است
• شادی تیمشان را پیگیری می‌کنند و مطمئن می‌شوند که همه چیزهایی که نیاز دارند را دارند

و از سوی دیگر، از ضدالگوهای زیر اجتناب می‌کنند:

• استخدام افراد ضعیف‌تر از خودشان
• نادیده گرفتن افراد با عملکرد ضعیف
• نادیده گرفتن مسائل انسانی
• رفتار با تیم مانند کودکان
• مصالحه‌ی بیش‌ازحد برای رسیدن به اجماع
• گلوگاه بودن
• محافظت نکردن تیم از هرج‌ومرج سازمانی
• دوست صمیمی همه بودن

رهبری یک مهارت است که می‌توان آن را یاد گرفت و تمرین کرد. هیچ‌کس از ابتدا رهبر کامل نیست — همه‌ی ما اشتباه می‌کنیم و یاد می‌گیریم. کلید موفقیت این است که همیشه به دنبال بهبود باشید و از بازخورد تیمتان استفاده کنید.

---