کوچینگ بنیان‌گذار فنی: چرا کوچینگ اجرایی استاندارد گلوگاه را نمی‌بیند

گفتن به یک بنیان‌گذار مهندس که «بیشتر تفویض کن»، یک توصیه است، نه یک سیستم.

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

چه چیزی ساختاری متفاوت است

بنیان‌گذار فنی معمولاً در مهارت اجرا محدود نیست؛ در معماری تصمیم محدود است — و آن دو کاملاً متفاوت‌اند.

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

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

سه گلوگاه مخصوص بنیان‌گذاران سازنده

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

دو. آستانهٔ کیفیت کالیبره‌نشده. در کد، کیفیت پایین بدهی تولید می‌کند و بعداً هزینه دارد. در بیشتر تصمیم‌های کسب‌وکار، نودرصد-درست و سریع، از صددرصد-درست و کند بهتر است. انتقال آستانهٔ مهندسی به تصمیم‌های تجاری، تأخیر تولید می‌کند.

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

چرا کوچینگ عمومی اینجا کم می‌آورد

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

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

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

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

هیچ‌کدام از این‌ها به انگیزه ربطی ندارند و همه‌شان قابل اندازه‌گیری‌اند — که برای این مخاطب اهمیت دارد.

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

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

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

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

راه عبور از این، ساختن بازخورد مصنوعی است. به همین دلیل سنجش تأخیر تصمیم و شمارش تصمیم‌های تکراری این‌قدر مؤثرند — نه به این خاطر که خودِ اعداد ارزش ذاتی دارند، بلکه چون به یک ساختار سازمانی همان جنس بازخوردی را می‌دهند که یک تست به کد می‌دهد.

یک نمونهٔ واقعی: بنیان‌گذاری که مشکل زمان نداشت

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

یک لاگ تصمیم یک‌هفته‌ای گرفتیم. نتیجه: ۴۷ تصمیم در پنج روز کاری. از این‌ها، ۳۱ مورد در سه دستهٔ تکراری بودند و همه‌شان پیش‌تر پاسخ مشابهی گرفته بودند.

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

سه مرز نوشته شد. در ماه بعد، تعداد تصمیم‌های ثبت‌شده به ۲۹ رسید. ساعت کاری تقریباً تغییری نکرد.

چیزی که تغییر کرد، طول بلندترین بلوک بدون وقفهٔ کاری بود: از حدود ۴۰ دقیقه به حدود دو ساعت. کار استراتژیک به همان بلوک‌ها نیاز داشت، نه به ساعت بیشتر.

اولین کاری که در یک تعامل انجام می‌شود

هیچ جلسه‌ای پیش از داشتن داده مفید نیست. پس اولین کار همیشه یکی است: یک هفته لاگ تصمیم، پیش از هر بحثی.

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

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

نشانه‌های تناسب — و نشانه‌های عدم تناسب

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

احتمالاً مناسب است اگر: بیشتر روزتان صرف تصمیم‌های کوچک می‌شود؛ تیم برای چیزهایی که باید خودش تصمیم بگیرد منتظر شماست؛ می‌توانید مسئله را دقیق توصیف کنید ولی نمی‌دانید ساختارش چیست؛ و به عدد بیشتر از احساس اعتماد دارید.

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

آیا این با مشاورهٔ فنی یکی است؟

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

چقدر طول می‌کشد تا اثر دیده شود؟

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

اگر تیم کوچک باشد چه؟

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

جمع‌بندی

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

اگر این توصیف آشناست، جلسهٔ شناخت کوچینگ جای بررسی‌اش است.