یادداشت‌ها رهبری فنی

مدیر ارشد فناوری چطور به پرسش‌های مدیرعامل درباره‌ی هوش مصنوعی پاسخ دهد؟

«به‌اندازه‌ی کافی روی هوش مصنوعی سرمایه‌گذاری می‌کنیم؟»

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

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

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

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

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

مدیران ارشد به مرور فشرده‌ی معماری نیاز ندارند. می‌خواهند بدانند سازمان در وضعیت نامطمئن، تعهدهای سنجیده‌ای می‌پذیرد یا نه.

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

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

در نظرسنجی مدیرعاملان جهانی PwC در سال ۲۰۲۶، با شرکت ۴٬۴۵۴ مدیرعامل از ۹۵ کشور و منطقه، فاصله‌ی میان فعالیت و نتیجه آشکار است: ۵۶ درصد گفته‌اند که طی سال پیش از نظرسنجی، هوش مصنوعی نه درآمدشان را بالا برده و نه هزینه‌شان را کاهش داده است. این آمار ثابت نمی‌کند سرمایه‌گذاری هوش مصنوعی بد است؛ نشان می‌دهد استفاده از ابزار، انجام فعالیت و گرفتن نتیجه‌ی کسب‌وکار سه چیز متفاوت‌اند.

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

پرسش اول: تعهد بعدی را کجا بگذاریم؟

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

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

برای هر پیشنهاد پنج پرسش را مطرح کنید:

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

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

این برنامه سرمایه‌گذاریِ قابل‌سنجش‌تری است از این‌که بگوییم «RAG سازمانی راه می‌اندازیم». دامنه‌ی واقعی کار را نشان می‌دهد و می‌توان با شواهد ردش کرد.

در نظرسنجی وضعیت مدیران ارشد فناوری ۲۰۲۶ CIO.com، بازگشت سرمایه‌ی تعریف‌نشده و راهبرد نامشخص هوش مصنوعی برای شرکت از موانع مهم گسترش معرفی شده‌اند. پاسخ عملی این نیست که عددی رؤیایی برای بازده بسازیم؛ باید مرحله‌به‌مرحله سرمایه‌گذاری کنیم، برای هر مرحله شاهد بخواهیم و ادامه دادن را به تصمیمی آگاهانه تبدیل کنیم.

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

پرسش دوم: واقعاً کجا از رقبا جلوتریم یا عقب‌تریم؟

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

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

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

این نگاه می‌تواند به سه نتیجه برسد که مقایسه‌ی قابلیت‌های هوش مصنوعی به‌تنهایی نشان نمی‌دهد:

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

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

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

پژوهش مدیرعاملان شرکت IBM در سال ۲۰۲۶ می‌گوید شرکت‌هایی که از هوش مصنوعی نتیجه‌های بهتری می‌گیرند، در حال بازطراحی کار میان‌بخشی و جا دادن هوش مصنوعی در گردش‌کار سرتاسری‌اند. این یافته را می‌توان نشانه‌ای جهت‌نما دانست، نه دستورالعملی که همه باید عیناً اجرا کنند. مقایسه‌ی قابل‌دفاع همچنان باید به شواهد گردش‌کار خودتان برگردد: عملکرد، پذیرش، هزینه، کیفیت، بازیابی و سرعت یادگیری سازمان. گزارش مدیرعاملان IBM را بخوانید.

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

این از گفتنِ «دو سال از رقبا در هوش مصنوعی عقبیم» بسیار سودمندتر است.

پرسش سوم: کدام ریسک را می‌پذیریم؟

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

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

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

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

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

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

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

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

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

این کارت گفت‌وگو را کوتاه و در عین حال جدی نگه می‌دارد. برای هر تعهد مهم فناوری یا هوش مصنوعی آن را تکمیل کنید. شواهد پشت صفحه باشند؛ خود کارت را به انبوه داده تبدیل نکنید.

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

سه خط دیگر پایین کارت اضافه کنید:

پیشنهاد: در یک جمله بگویید چه انتخابی را پیشنهاد می‌کنید و چرا اکنون بهتر است.

ابهام: مهم‌ترین واقعیتی که ممکن است این پیشنهاد را تغییر دهد چیست؟

نشانه‌ی بازبینی: چه تاریخی، هزینه‌ای، رخدادی، آستانه‌ای از نتیجه یا تغییر بازاری، موضوع را دوباره به مدیران می‌آورد؟

این کارت گزارش وضعیت پروژه نیست. گزارش وضعیت می‌گوید تحویل با برنامه هماهنگ است یا نه؛ کارت می‌سنجد که آیا هنوز باید به برنامه متعهد بمانیم.

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

شواهد ضعیف را پشت دقت مالی پنهان نکنید

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

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

این به معنی خیالی بودنِ افزایش بهره‌وری نیست. یعنی باید زنجیره‌ی علت و معلول را روشن بنویسیم:

رفتار سامانه ← تغییر در گردش‌کار ← رفتار کاربر ← نتیجه‌ی عملیاتی ← اثر مالی یا راهبردی

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

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

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

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

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

این تقسیم مسئولیت وقتی اهمیت بیشتری پیدا می‌کند که ایجنت‌ها به ابزار و اختیار دسترسی پیدا کنند. پژوهش مدیرعاملان IBM در سال ۲۰۲۶ از نزدیک‌تر شدن مسئولیت رهبران فناوری و استعداد می‌گوید، اما نزدیک شدن نقش‌ها نباید به ابهام بینجامد. هنوز مدیران انسانی تصمیم می‌گیرند چه کسی مجاز به تغییر فرایند است، کدام تصمیم خودکار می‌شود، چه استثنایی باید بازبینی شود و اگر نتیجه به مشتری آسیب زد چه کسی پاسخ‌گوست.

پیش از جلسه، از هر مالک بخواهید یکی از این جمله‌ها را تأیید کند:

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

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

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

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

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

گفتنِ «هنوز نه» باید پنج چیز را در بر بگیرد:

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

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

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

پاسخ نهایی باید پیشنهاد باشد، نه گشت‌وگذار در معماری

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

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

هدف ساده کردن حرف به هر قیمت نیست؛ کیفیت تصمیم است.

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

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

نسخه‌ی انگلیسی این یادداشت در DATATWEETS منتشر شده است.