پیش از اخراج کارمند فنی، علت افت عملکرد را پیدا کنید

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

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

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

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

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

چهار علت احتمالی را از هم جدا کنید

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

به‌جای برچسب، چهار احتمال را بررسی کنید:

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

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

پیش از نوشتن حکم، سابقه‌ی تصمیم درباره‌ی عملکرد را ثبت کنید

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

۱. نقش در آن زمان چه انتظاری داشت؟

نتیجه، کیفیت، زمان و حدود اختیار را با زبانی روشن بنویسید. «مسئولیت‌پذیرتر باش» معیار قابل‌مشاهده‌ای نیست. «وابستگیِ مسدودکننده را حداکثر تا یک روز کاری اعلام کن، گزینه‌ها را پیشنهاد بده و تصمیم توافق‌شده را ثبت کن» روشن‌تر است.

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

۲. بر اساس شواهد قابل‌مشاهده چه اتفاقی افتاد؟

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

«استقرار در شش هفته سه رخداد با اولویت بالا ایجاد کرد» واقعیتی است که می‌شود بررسی کرد. «برای قابلیت اطمینان اهمیتی قائل نیست» برداشت درباره‌ی نیت است. جمله‌ی اول می‌تواند گفت‌وگوی مفیدی شروع کند؛ جمله‌ی دوم احتمالاً بحث را به حدس زدن انگیزه می‌کشاند.

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

۳. آیا انتظار را فهمیده بود؟

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

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

۴. آیا راه معقولی برای موفق شدن داشت؟

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

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

۵. چه بازخورد و پشتیبانی‌ای گرفت؟

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

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

۶. با موارد مشابه یکسان برخورد شده است؟

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

کمیسیون فرصت‌های برابر شغلی آمریکا (EEOC) به کارفرمایان توصیه می‌کند سیاست‌های انضباطی را به‌طور یکسان اجرا، دلیل تصمیم را ثبت و برخوردهای متفاوت را توجیه کنند. راهنمای کلیِ خاتمه‌ی استخدام این کمیسیون هم هشدار می‌دهد تصمیم نباید بر ویژگی‌های حفاظت‌شده یا تلافی‌جویی مبتنی باشد. الزامات دقیق با محل کار فرق دارند، اما رعایت انصاف در برخورد با موارد مشابه آزمون مدیریتیِ مفیدی در هر جایی است.

۷. چه شواهدی می‌تواند تصمیم را عوض کند؟

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

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

عملکرد را در همان بخشی بررسی کنید که شکست خورده است

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

فرض کنید مهندسی چند بار کدِ کمک‌گرفته از هوش مصنوعی را ادغام می‌کند و بعداً همان کد مشکل می‌سازد. «دیگر از هوش مصنوعی استفاده نکن» و «دقت بیشتری کن» هر دو واکنش‌های ضعیفی‌اند. گردش‌کار را بررسی کنید:

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

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

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

برای تصویر وسیع‌تر، به سامانه‌ی کاری مدیران تیم هوش مصنوعی مراجعه کنید. درس اصلی آن این‌جا هم کاربرد دارد: مدیریت آدم‌ها و طراحی شیوه‌ی کار از هم جدا نیستند.

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

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

دوره‌ی بهبودِ معتبر این ویژگی‌ها را دارد:

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

برنامه را به نسخه‌ی مینیاتوریِ کاری ناممکن تبدیل نکنید. «همه‌ی پروژه‌های عقب‌افتاده را در ۳۰ روز و بدون هیچ خطایی تحویل بده» شاید شکست را ثبت کند، اما نشان نمی‌دهد بهبود شدنی است یا نه. مسئولیت‌های نماینده و شواهد واقع‌بینانه انتخاب کنید.

راهنمای نهاد مشاوره و سازش بریتانیا (Acas) درباره‌ی توانایی و رفتار اصلی کلی و مفیدی دارد، حتی برای خواننده‌ی بیرون از بریتانیا: در مسئله‌ی توانایی، کارفرما باید اول به فرد برای پیشرفت کمک کند، منابع کافی بدهد، تغییر مناسب در نقش را بررسی کند، شواهد را نگه دارد و اخراج را آخرین راه بداند. راهنمای جاری آن‌ها بر رعایت روند منصفانه هم تأکید دارد. قانون محلی و سیاست سازمان همچنان ملاک‌اند، اما منطق مدیریتی پابرجاست.

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

بعضی پرونده‌های عملکرد در اصل مشکل طراحی نقش‌اند

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

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

سه پرسش بپرسید:

• این فرد همین حالا در چه کاری نتیجه‌ی قابل‌اتکا می‌دهد؟
• کدام مسئولیت ضروری هنوز به‌طور پیوسته انجام نمی‌شود؟
• آیا نیاز واقعی‌ای در سازمان هست که با پاسخ پرسش اول جور باشد و پرسش دوم را پنهان نکند؟

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

رفتار، توانایی و حذف موقعیت شغلی را قاطی نکنید

عملکرد ضعیف با تخلف رفتاری فرق دارد؛ هر دو هم با حذف شدن یک نقش بر اثر تغییر راهبرد، بودجه یا ساختار سازمان متفاوت‌اند. قاطی کردنشان شاید از نظر اداری آسان به نظر برسد، اما توضیح را کم‌صداقت و مقایسه را ناعادلانه می‌کند.

اگر شرکت یک خط محصول را حذف کرده، بگویید تصمیم سازمانی بر نقش اثر گذاشته است. داستان ناگهانیِ ضعف عملکرد نسازید تا تصمیم را شخصی جلوه دهید. اگر احتمال تخلف امنیتی هست، واقعیت‌ها را بررسی و روند مناسب را اجرا کنید، نه این‌که موضوع را به گفت‌وگوی مربی‌گری تغییر نام دهید. اگر مسئله توانایی است، انتظار و پشتیبانی را در مرکز بگذارید.

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

تصمیم پرخطر را به بازبین مستقل بسپارید

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

بازبینی مستقل به‌ویژه زمانی مهم است که:

• کارمند به‌تازگی نگرانی امنیتی، تبعیض، آزار، دستمزد، اخلاق یا رعایت مقررات را مطرح کرده باشد؛
• مرخصی، معلولیت، سازگارسازی شغلی، بارداری، فعالیت اتحادیه‌ای یا موضوع حفاظت‌شده‌ی قانونیِ دیگری مطرح باشد؛
• ارزیابی‌های قبلی خوب بوده‌اند، اما نظر فعلی ناگهان تغییر کرده باشد؛
• با کارکنان مشابه برخورد متفاوتی شده باشد؛
• مدیر خودش در اختلاف اصلی درگیر باشد؛
• شواهد به‌شدت به داوری‌های شخصی وابسته باشند.

راهنمای EEOC درباره‌ی تلافی‌جویی مشخصاً توصیه می‌کند پس از فعالیت حفاظت‌شده، اقدام منفیِ پیشنهادی به‌طور مستقل ارزیابی شود و پایه‌ی واقعی سنجش عملکرد هم بررسی شود. این کار تشریفات کاغذی نیست؛ مانع می‌شود تعارض مدیر به تصمیم کل سازمان تبدیل شود.

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

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

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

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

برنامه‌ای را که با منابع انسانی و مشاور حقوقی تنظیم کرده‌اید دنبال کنید. تصمیم را روشن و محترمانه بگویید، دلیلِ تأییدشده را در سطح مناسب توضیح دهید، گام‌های عملی بعدی را مرور کنید و حریم خصوصی را حفظ کنید. برای نقش فنیِ دارای دسترسی ممتاز، قطع دسترسی‌ها را با دقت هماهنگ کنید؛ اما نگذارید سامانه‌ی خودکار پیش از یک انسان خبر را اعلام کند. امنیت و شأن انسانی هر دو باید در طراحی فرایند لحاظ شوند.

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

سپس جدا از پرونده‌ی کارمند، مدیریت را هم مرور کنید:

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

این بازبینی برای پس گرفتن مسئولیت نیست؛ برای پیشگیری از پرونده‌ی بعدی است.

تصمیم منصفانه از پیش از افت عملکرد شروع می‌شود

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

هیچ چارچوبی سختیِ پایان دادن به همکاری را حذف نمی‌کند و نباید هم بکند. این تصمیم بر درآمد، هویت، همکاران، مشتریان و اعتبار رهبری اثر دارد. اما دشوار بودن تصمیم توجیهی برای مبهم ماندنش نیست.

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

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