چند روز پیش، یکی از دوستان گله‌ای را با من در میان گذاشت که عمیقاً با تجربه‌های خودم در تیم‌های مختلف همخوانی داشت: «جلسات بازنگری (retro) تیم ما بی‌فایده شده. جالب اینکه همه قبول دارند مشکلاتی وجود دارد، اما همیشه انگشت اتهام را به بیرون نشانه می‌روند. همیشه پای ‘وابستگی‌ها’، ‘قوانین شرکت’، یا ‘گروه یا دپارتمان دیگر’ وسط است و انتهای همه بحث‌ها به این نتیحه میرسیم که فقط مشکلات را به اطلاع مدیران برسانیم، اما هیچ تغییری از طرف خودمان اعمال نمی‌شود.»

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

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

اما چرا این اتفاق می‌افتد؟

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

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

این دقیقاً همان جایی بود که دوست من در آن گیر کرده بود و تلاش می‌کرد تیمش را به سمت رویکردی فعال‌تر سوق دهد. خوشبختانه، اولین غریزه‌ی او درست بود: استفاده از حوزه‌های نفوذ یا Circles of Influence.

حوزه‌های نفوذ یا Circles of Influence را به شکل سه دایره‌ی تو در تو تصور کنید. در مرکز، حوزه‌ی کنترل مستقیم یا Circle of Control شما قرار دارد. این‌ها چیزهایی هستند که شما مستقیماً بر آن‌ها قدرت دارید: اقدامات فردی‌تان، فرایندهای تیمتان، کدی که می‌نویسید، برای این اقدامات نیاز به هیچ نوع تایید یا اختیارات اضافی ندارید. با حرکت به دایره بیرونی، به حوزه‌ی نفوذ یا Circle of Influence می‌رسید. اینجا چیزهایی قرار دارند که می‌توانید بر آن‌ها تأثیر بگذارید، اگرچه مستقیماً کنترلشان نمی‌کنید: نظرات همکاران، اولویت‌های بخش شما، تفسیر مقررات. و در نهایت، بیرونی‌ترین دایره، حوزه‌ی نگرانی یا Circle of Concern است. این شامل همه‌ی چیزهایی است که به آن‌ها اهمیت می‌دهید اما تأثیر مستقیمی روی آن‌ها ندارید: اقتصاد جهانی، چشم‌انداز استراتژیک مدیرعامل، آب و هوا.

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

اما نکته‌ی کلیدی اینجاست: پیشرفت به معنای به‌دست آوردن جادویی کنترل بر چیزهای غیرقابل کنترل نیست. بلکه به معنای گسترش استراتژیک حوزه‌ی نفوذ با تمرکز بی‌وقفه بر حوزه‌ی کنترل مستقیم است.

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

خب، چگونه می‌توانیم به تیم‌هایی مثل تیم این دوست من کمک کنیم تا تمرکزشان را تغییر دهند و اختیار عمل خود را دوباره به‌دست آورند؟

• زوم کنید، نه فقط به بیرون: تیم‌ها را تشویق کنید تا مشکل «خارجی» را تشریح کنند. سؤالات عمیق بپرسید: «خب، وابستگی به API تیم X باعث تأخیر شد. اما چه فرایندهای داخلی‌ای می‌توانست این تأثیر را کاهش دهد؟ آیا می‌توانستیم نیازهایمان را زودتر اطلاع دهیم؟ آیا می‌توانستیم مدیریت خطای قوی‌تری ایجاد کنیم؟» مثال: یک تیم توسعه‌دهنده‌ی اپلیکیشن موبایل ممکن است دائماً تأخیرها را به کندی API سمت سرور نسبت دهد. اما با زوم کردن، شاید متوجه شوند که می‌توانند از مکانیزم‌های کش (cache) کارآمدتری در اپلیکیشن استفاده کنند یا منطق نمایش اطلاعات را به گونه‌ای تغییر دهند که نیاز کمتری به داده‌های لحظه‌ای داشته باشند.
• روایت را تغییر دهید: به‌جای پرسیدن «چه چیزی اشتباه پیش رفت؟»، بپرسید «چه چیزی را ما می‌توانیم بهبود دهیم، صرف‌نظر از عوامل خارجی؟» زبان را از سرزنش به مالکیت تغییر دهید. مثال: یک تیم فرانت‌اند ممکن است دائماً باگ‌ها را به ساختار داده‌های نامناسب API تیم بک‌اند نسبت دهد. به جای سرزنش، می‌توانند تمرکز کنند روی پیاده‌سازی اعتبارسنجی‌های قوی‌تر در سمت کلاینت یا ایجاد لایه‌ای میانی برای تبدیل داده‌ها به فرمت مورد نیازشان.
• اقدامات کوچک و دست‌یافتنی: از وسوسه‌ی حل یکباره‌ی همه‌ی مشکلات خودداری کنید. روی شناسایی اقدامات کوچک و مشخص در حوزه‌ی کنترل تیم تمرکز کنید. مثال: یک تیم DevOps که از قطعی‌های مکرر زیرساخت خسته شده، ممکن است تقصیر را به گردن تیم شبکه بیاندازد. اما در حوزه‌ی کنترل خود، می‌توانند فرآیندهای مانیتورینگ و هشداردهی خود را بهبود بخشند،
• قدرت «هنوز»: وقتی تیمی می‌گوید «ما نمی‌توانیم کاری در مورد این مقررات انجام دهیم»، آن‌ها را تشویق کنید که «…هنوز» به جمله خود اضافه کنند. این واقعیت فعلی را تصدیق می‌کند و در عین حال در را برای تأثیرگذاری در آینده باز می‌گذارد. این یک تغییر ظریف اما قدرتمند در طرز فکر است، حرکت از یک دیدگاه ثابت به یک دیدگاه رشد. 
• همانند موج عمل کنید: تیم‌ها را تشویق کنید تا تغییرات کوچکی را در حوزه‌ی کنترل خود امتحان کنند و سپس تأثیر آن را مستند کنند. نشان دهید چگونه تمرکز به درون می‌تواند اثرات بیرونی ایجاد کند. مثال: تیمی که برای انجام یک وظیفه به شدت به خروجی تیم دیگری وابسته است و همواره با تأخیر مواجه می‌شود، به جای گله‌گذاری مداوم، می‌تواند با تیم مقابل جلسات هماهنگی منظم برگزار کند، انتظارات را به طور شفاف مشخص کند و حتی با کمک هم، فرآیند انجام کار را بهینه‌سازی کنند.

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

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

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