به‌عنوان یک لیدر یا مدیر، ما در طول روز تصمیم‌های زیادی می‌گیریم. گاهی باید مسئولیت یک باگ بحرانی رو به عهده بگیریم، گاهی باید ریسک سپردن یک فیچر حساس به یک مهندس جوان‌تر رو مدیریت کنیم و گاهی باید بین بدهی فنی و سرعت محصول تعادل بسازیم.
اما یکی از حساس‌ترین موقعیت‌هایی که عیار واقعی رهبری رو مشخص می‌کنه، نه توی کدبیس اتفاق می‌افته و نه توی جلسات طراحی معماری؛ بلکه دقیقاً توی «جلسات سخت» خودش رو نشون می‌ده.
منظورم از جلسات سخت چیه؟
جلسه‌ی فیدبکی که قراره توش به یکی از اعضای تیم بگید از عملکرد چند ماه اخیرش راضی نیستید؛
جلسه‌ی رترویی (Retrospective) که قراره بعد از چند هفته ددلاینِ پرفشار و فرسایشی، خطاهای تیم رو کالبدشکافی کنید؛
جلسه‌ی اعلام رد شدنِ درخواست پروموشن (Promotion) یک نیرو که خودش فکر می‌کنه آماده‌ی سطح بعدیه؛
یا حتی سخت‌تر از همه‌ی این‌ها: جلسه‌ی خداحافظی با یکی از اعضای تیم.
و البته یک نکته‌ی مهم که خیلی وقت‌ها فراموش می‌شه: جلسه‌ی سخت یک خیابان یک‌طرفه نیست. همیشه این ما نیستیم که به‌عنوان لیدر جلسه‌ی سخت رو برگزار می‌کنیم؛ گاهی خودِ ما سوژه‌ی اصلی جلسه‌ایم و اعضای تیم قراره به تصمیم‌های فنی، نحوه‌ی مدیریت یا رفتار ما نقد وارد کنن.
سؤال اصلی اینه: چرا این جلسات انقدر انرژی‌بر و پرریسک هستن و چطور می‌تونیم از پسشون بربیایم بدون اینکه یا واقعیت رو قربانی کنیم، یا آدم‌ها رو؟
وقتی به رفتار خودمون یا مدیرهایی که دیدیم نگاه می‌کنیم، در مواجهه با یک مکالمه‌ی ناخوشایند معمولاً سه الگوی رفتاری تکرار می‌شه. هیچ‌کدوم از ما مطلقاً توی یکی از این دسته‌ها نیستیم و بسته به خستگی، فشار پروژه یا رابطه‌مون با طرف مقابل ممکنه بینشون نوسان کنیم؛ اما هر کدوم از این الگوها یک هزینه‌ی سیستمی جدی دارن:
این دسته سعی می‌کنن اصلاً کار به جلسه‌ی سخت نکشه. اگر از عملکرد نیرویی راضی نیستن یا رفتاری توی تیم آزاردهنده‌ست، با پشت گوش انداختن، جمله‌های کلی در جمع، یا خودشون دست‌به‌کد شدن و جمع کردن خرابکاری‌ها، از مواجهه‌ی مستقیم فرار می‌کنن.
هزینه‌ی سیستمی: ایجاد «بدهی پنهان». اعضای تیم نقاط ضعفشون رو درک نمی‌کنن، فکر می‌کنن همه‌چیز خوب پیش می‌ره و یک روز ناگهان با یک تصمیم سنگین (مثل رد شدن پروموشن یا قطع همکاری) غافلگیر می‌شن. نتیجه‌ش از بین رفتن تدریجی اما کاملِ اعتماده.
این گروه از جلسه فرار نمی‌کنن؛ جلسه رو می‌ذارن، اما حرف واقعی رو نمی‌زنن. آن‌قدر دورِ مسئله می‌چرخن و سعی می‌کنن شرایط رو «نایس» و مثبت نگه دارن که پیام اصلی گم می‌شه.
هزینه‌ی سیستمی: از بین رفتن نسبت سیگنال به نویز (Signal-to-Noise Ratio). طرف مقابل با حس خوب از جلسه بیرون میاد، اما واقعاً متوجه نمی‌شه که یک مشکل جدی وجود داره که اگر حل نشه، در آینده هزینه‌ی خیلی بزرگ‌تری برای خودش و تیم می‌سازه.
این دسته همه‌چیز رو بیش‌ازحد سفت و سخت می‌گیرن. با هر خطایی طوری برخورد می‌کنن که انگار آخر دنیاست و هیچ راه برگشتی وجود نداره. جلسه‌ی فیدبک برای این افراد بیشتر شبیه دادگاهه تا گفتگو.
هزینه‌ی سیستمی: نابود شدن امنیت روانی (Psychological Safety). کار کردن با این مدل لیدرها به‌شدت فرسایشیه، چون هر حرکتی ممکنه به یک جنگ واقعی تبدیل بشه. از فردای چنین جلسه‌ای، آدم‌ها به‌جای اینکه دنبال حل مشکلات باشن، یاد می‌گیرن باگ‌ها و خطاهاشون رو قایم کنن تا کار به جلسه‌ی سخت نکشه.
جلسه‌ی سخت در اصل یک مکانیزم اصلاح خطا (Error-Correction Mechanism) در سیستم‌های انسانیه. اگر درست انجام بشه، هم کیفیت کار بالا می‌ره و هم رابطه‌ی حرفه‌ای قوی‌تر می‌شه.
مدلی که به نظرم می‌تونه به ما کمک کنه تا بدون افتادن در تله‌ی فرار، تعارف یا تندخویی از پس این جلسات بربیایم، به سه فاز «قبل»، «حین» و «بعد از جلسه» تقسیم می‌شه:
برنده‌شدن یا باختن در یک جلسه‌ی سخت، معمولاً قبل از ارسال لینک جلسه اتفاق می‌افته.
یکی از اصلی‌ترین دلایلی که جلسات فیدبک رو به یک بحث فرسایشی و سلیقه‌ای تبدیل می‌کنه اینه که از اول مشخص نبوده «عملکرد خوب» یعنی چی. اگر به یک مهندس Senior نگفته باشید که انتظار دارید توی Design Reviewها فعال باشه یا Ownership یک ماژول رو کامل به دست بگیره، غافلگیر کردنش توی جلسه‌ی ارزیابی منصفانه نیست. وقتی انتظارات از قبل شفاف باشه، در لحظه‌ی دادن فیدبک هم شما و هم طرف مقابل دقیقاً می‌دونید چرا به این جلسه نیاز بوده.
بیاید با خودمون روراست باشیم: فیدبک منفی دادن یا شنیدن برای هیچ‌کس لذت‌بخش نیست. طبیعیِ که قبلش معذب بشیم. اما ما به‌عنوان لیدر اونجا نیستیم که در تک‌تک لحظات «محبوبِ همه» باشیم؛ ما اونجاییم که گره‌ها و نکات منفی رو باز کنیم تا تیم رشد کنه. باید با خودمون تمرین کنیم که ناراحتیِ کوتاه‌مدتِ یک مکالمه‌ی بی‌پرده رو به جون بخریم تا از فرسایشِ بلندمدتِ تیم جلوگیری کنیم.
وقتی توی کدبیس یک سرویس خطا می‌ده، ما کل معماری رو دور نمی‌ریزیم؛ مشکل رو ایزوله می‌کنیم. اما توی روابط انسانی، یکی از بزرگ‌ترین خطاهای مدیران (و اعضای تیم نسبت به مدیرشون) اینه که یک تصمیم غلط یا عملکرد ضعیف در یک پروژه رو تا بی‌نهایت گسترش می‌دن. اگر نیرویی در تحویل یک تسک بد عمل کرده، یا لیدری در یک اسپرینت تصمیم اشتباهی گرفته، نباید این ذهنیت منفی روی تمام قضاوت‌های بعدی ما سایه بندازه و راه برگشت رو ببنده. مسئله رو محدود به همون اتفاق نگه دارید.
وقتی وارد جلسه شدیم، هدف اینه که حقیقت روی میز گذاشته بشه، اما انسانیت و کرامت آدم‌ها حفظ بشه.
مهم‌ترین اصل در یک محیط حرفه‌ای، صداقته. سعی نکنید یک واقعیت تلخ رو با کلمات قشنگ مخفی کنید. یکی از تله‌هایی که خودِ من هم بارها درگیرش بودم، استفاده از همون تکنیک معروف «ساندویچ فیدبک» بود: اینکه ناخودآگاه برای اینکه جلسه سخت نشه و طرف مقابل ناراحت نشه، اولش کلی از خوبی‌هاش بگیم و وسطش یک نقد کوچیک بکنیم. قدردانی کردن عالیه، اما نه وقتی که باعث بشه خودِ نقد بی‌معنی و بی‌اثر بشه. شفاف، مستقیم و بر اساس فکت بگید چه چیزی کار نمی‌کنه و چه انتظاری دارید.
این نقطه‌ایه که مدیران سخت‌گیر معمولاً توش شکست می‌خورن. نقد کردن به معنی تند صحبت کردن نیست، و نقد شنیدن از نیرو هم به معنی «پررو شدن» اون نیرو نیست. فراموش نکنیم کسی که روبه‌روی ما نشسته و داره فیدبک منفی می‌گیره، یک انسانه؛ غرور داره، زحمت کشیده و ممکنه در لحظه بترسه یا موضوع رو شخصی برداشت کنه. هدف جلسه‌ی فیدبک این نیست که طرف رو بندازیم گوشه‌ی رینگ و پشت سر هم بهش مشت بزنیم به امید اینکه «بهتر بشه»! مرز بین «نقد کردنِ خروجی کار» و «حمله به شخصیت فرد» باید کاملاً واضح باشه. لحن ما باید این پیام رو بده: «من و تو روبه‌روی هم نیستیم؛ کنار هم نشستیم تا این مسئله‌ای که پیش اومده رو حل کنیم.»
خیلی وقت‌ها یک اتفاق از زاویه‌ی دید شما به‌عنوان لیدر، «کم‌کاری» یا «بی‌دقتی» دیده می‌شه؛ اما از سمت نیروتون یک داستان کاملاً متفاوت جریان داره. شاید نیازمندی‌های محصول وسط کار سه بار عوض شده، شاید یک وابستگی فنی (Blocker) وجود داشته که شما ندیدید، یا شاید فشار کاری روی اون فرد بیش از حد بوده. قبل از اینکه حکم نهایی رو صادر کنید، واقعاً بپرسید: «از زاویه‌ی دید تو چه اتفاقی افتاد؟» و آماده باشید که با شنیدن Context جدید، قضاوت اولیه‌تون رو اصلاح کنید.
همون‌طور که اول متن گفتم، گاهی این ماییم که باید فیدبک منفی بشنویم. وقتی یکی از اعضای تیم توی جلسه‌ی ۱:۱ یا رترو به نحوه‌ی مدیریت یا تصمیم فنی ما نقد می‌کنه، اولین واکنش طبیعیِ مغز، دفاع کردن و توجیه کردنه. اما یادمون باشه: اگر وقتی بهتون نقد می‌شه حس کنید مورد تهاجم قرار گرفتید و گارد بگیرید، احتمالاً اون آخرین باری خواهد بود که تیمتون واقعیت رو به شما می‌گه. فیدبک منفیِ تیم به لیدر، یک هدیه‌ی کمیابه که نقاط کور عملکرد ما رو روشن می‌کنه. به‌جای دفاع، سؤال بپرسید تا دقیق‌تر بفهمید کجای رفتارتون برای تیم گلوگاه ساخته.
یک جلسه‌ی سخت با بستن تبِ Google Meet یا بیرون اومدن از اتاق جلسات تموم نمی‌شه؛ اصلِ کار تازه از اونجا شروع می‌شه.
مسیر رشد مهندسی و یادگیری همیشه از دل اشتباه کردن می‌گذره. قرار نیست با اولین اشتباه، یک نیرو رو لت‌وپاره کنیم یا Ownership رو کامل ازش پس بگیریم. اگر به آدم‌ها اجازه‌ی خطا ندید، خلاقیت و جسارت تصمیم‌گیری رو در اون‌ها می‌کشید. هنر لیدر اینه که بعد از جلسه‌ی فیدبک، به فرد کمک کنه تا «اثرِ اشتباهش بر سیستم» رو درک کنه و به مرور به نقطه‌ای برسه که خودش قبل از هر کسی دنبال پیدا کردن و اصلاح خطاهاش باشه.
جلسات سختی که با جمله‌های مبهمی مثل «حالا سعی کن در آینده بیشتر دقت کنی» تموم می‌شن، معمولاً چند هفته بعد دوباره تکرار می‌شن. خروجی جلسه باید مشخص و قابل مشاهده باشه: چه چیزی قراره تغییر کنه؟ آیا نیاز به یک Guardrail جدید در فرآیند Code Review داریم؟ آیا قراره بار کاری تنظیم بشه؟ و از همه مهم‌تر: دو هفته‌ی دیگه بر چه اساسی به این نتیجه می‌رسیم که این مشکل حل شده؟
بعد از یک جلسه‌ی سنگین، خیلی طبیعیه که یک فاصله‌ی عاطفی یا سنگینیِ نامرئی بین شما و اون فرد شکل بگیره. اینجا وظیفه‌ی لیدره که در روزهای بعد نشون بده پرونده‌ی اون جلسه بسته شده و رابطه‌ی کاری سالمه. در تعاملات روزمره‌ی بعدی عادی رفتار کنید و به‌محض اینکه اولین نشانه‌های تغییر مثبت رو در عملکرد فرد دیدید، صریحاً بهش اشاره کنید و قدردانی کنید. آدم‌ها باید مطمئن بشن که توی ذهن شما توی «لیست سیاه» نرفتن و تلاششون برای تغییر دیده می‌شه.
رعایت کردن همه‌ی این اصول به این معنی نیست که هر چالشی با یکی دو جلسه گفتگوی محترمانه حل می‌شه. اینجا یک Trade-off و مرز خیلی ظریف وجود داره که هر لیدری باید حواسش بهش باشه:
گاهی تکرارِ بی‌پایانِ جلسات فیدبک، خودش تبدیل به شکلی از «فرار از تصمیم نهایی» می‌شه.
اگر انتظارات رو شفاف کردید، زوایای مختلف رو شنیدید، فضای امن برای خطا و یادگیری ساختید و توافق‌های عملی گذاشتید، اما بعد از چند چرخه هنوز هیچ تغییری در رفتار یا خروجی فرد (یا تناسبش با نیاز تیم) اتفاق نمی‌افته، برگزاری جلسه‌ی فیدبکِ چهارم و پنجم دیگه کمک کردن نیست؛ فرسوده کردن سیستم و بقیه‌ی اعضای تیمه. در اون نقطه، جلسه‌ی سخت بعدی باید درباره‌ی تغییر نقش، جابه‌جایی تیم، یا یک خداحافظی محترمانه و حرفه‌ای باشه.
دفعه بعد که قرار شد وارد یک جلسه‌ی چالشی بشید (چه به‌عنوان برگزارکننده، چه به‌عنوان شنونده)، این ۵ سؤال رو از خودتون بپرسید:
شفافیت: آیا پیام اصلی من در یک یا دو جمله کاملاً مشخصه، یا لای کلی تعارف پنهانش کردم؟
Scope: آیا دارم درباره‌ی «یک رفتار/خروجی مشخص» حرف می‌زنم یا کل شخصیت فرد رو بردم زیر سؤال؟
کنجکاوی: چه اطلاعات یا Contextی ممکنه دست طرف مقابل باشه که من الان ازش بی‌خبرم؟
انسانیت: چطور می‌تونم این حقیقت رو طوری بگم که طرف مقابل حس نکنه گوشه‌ی رینگ افتاده، بلکه حس کنه کنارش ایستادم تا مشکل حل بشه؟
آینده: در پایان این جلسه، چه توافق مشخصی می‌ذاریم که هر دو بدونیم قدم بعدی چیه؟
رهبری مهندسی فقط به معنای گرفتن تصمیم‌های فنی درست در روزهای آروم نیست؛ بخش بزرگی از اون در نحوه‌ی مواجهه‌ی ما با لحظات ناخوشایند ساخته می‌شه.
ما نمی‌تونیم از جلسات سخت فرار کنیم، چون فرار کردن از اون‌ها مشکل رو حذف نمی‌کنه؛ فقط هزینه‌ش رو با بهره‌ی مرکب به آینده منتقل می‌کنه. اما می‌تونیم یاد بگیریم که صادق باشیم بدون اینکه بی‌رحم باشیم، و محترمانه رفتار کنیم بدون اینکه حقیقت رو پنهان کنیم.
پلتفرم‌های نرم‌افزاری با مانیتورینگ و لاگ‌ها خطاهاشون رو پیدا و اصلاح می‌کنن؛ تیم‌های انسانی با جلسات صادقانه و محترمانه.
سؤال من از شما: سخت‌ترین جلسه‌ای که به‌عنوان لیدر یا عضوی از تیم تجربه کردید چی بوده و چه چیزی باعث شد اون جلسه به یک نقطه‌ی عطف مثبت (یا برعکس، یک تجربه‌ی تلخ) تبدیل بشه؟
