لا تخلط بين انشغال الفريق وتقدمه؛ قد يعمل الجميع لساعات طويلة بينما تظل العقبة الأساسية دون صاحب أو حل.
السرعة ليست فضيلة عندما ترفع تكلفة الأخطاء؛ أحيانًا يوفر اختبار إضافي يومًا كاملًا من إصلاح ما كان يمكن منعه.
قبل إطلاق خدمة جديدة اختبرها مع شخص لم يشارك في تصميمها؛ ما يبدو بديهيًا للفريق قد يكون مربكًا لأول مستخدم.
إذا لم يعرف الفريق من صاحب القرار، فحتى الأشخاص الأكفاء سيضيعون وقتهم في انتظار الموافقات وتبادل المسؤولية.
التقرير الجيد لا يكدس الأرقام؛ يوضح ماذا تغير ولماذا يهم وما القرار الذي ينبغي التفكير فيه بعد قراءة النتائج.
عندما تختلف الفرق حول سبب المشكلة، ارجع إلى رحلة المستخدم الفعلية؛ التجربة الملموسة قد تكشف ما لا تظهره تقارير الأقسام.
لا تضع مؤشرًا للسرعة وحدها إذا كانت الجودة مهمة؛ ما ينجز بسرعة ويعاد إصلاحه مرتين ليس بالضرورة إنجازًا أسرع.
إذا كان النظام يعتمد على شخص واحد يعرف أسراره، فهذه مخاطرة تشغيلية؛ وثّق المعرفة قبل أن تتحول إجازته إلى أزمة.
قبل توسيع خدمة ناجحة، تأكد أن أسباب نجاحها قابلة للتكرار في المكان الجديد؛ التشابه الظاهري لا يعني تشابه الاحتياجات.
الفريق الجيد لا يخفي الخلافات المهمة وراء المجاملة؛ يناقشها مبكرًا وباحترام قبل أن تصبح قرارات مكلفة.
إذا كان الموظفون يخافون من إخبار الإدارة بالأخبار السيئة فلن تختفي المشكلات؛ ستصل فقط متأخرة بعد أن تصبح أكثر تكلفة وأصعب في الحل.
لا تبدأ باختيار التقنية ثم تبحث لها عن مشكلة؛ ابدأ بحاجة العميل أو العملية وبعدها اسأل إن كانت التقنية أبسط طريقة لحلها.
القياس الجيد لا يكتفي بعدد من استخدم الخدمة؛ اسأل كم شخصًا أكمل هدفه وكم استغرق وأين احتاج إلى مساعدة أو انسحب.
حين يتكرر الاستثناء كثيرًا راجع القاعدة نفسها؛ ربما لم يعد الواقع استثناءً بل تغيرت الظروف بينما بقي الإجراء في مكانه.
الاجتماع الناجح لا يقاس بكمية النقاش بل بما أصبح واضحًا بعده: من سيفعل ماذا ومتى وكيف سنعرف أن المهمة اكتملت.
حين تتخذ قرارًا طويل الأثر بناءً على توقع، اكتب الافتراض الذي بنيت عليه القرار؛ سيكون من الأسهل مراجعته عندما تتغير الحقيقة.
رضا العميل لا يظهر فقط في الاستبيانات؛ راقب أين يتوقف وما الذي يعيده للاتصال وكم خطوة يحتاج حتى يكمل حاجته دون مساعدة.
قبل أتمتة أي عملية تأكد أنها جيدة أصلًا؛ الأتمتة قد تجعل الخطأ القديم أسرع وأكثر انتشارًا بدل أن تجعله صحيحًا.
عندما ينجح المشروع وثّق لماذا نجح كما توثق أسباب الفشل؛ النجاح الذي لا تفهم أسبابه يصعب تكراره عندما تتغير الظروف.
إذا كانت كل مشكلة تحتاج موافقة المدير الأعلى فأنت لا تملك فريقًا مفوضًا بل عنق زجاجة؛ وضوح الصلاحيات جزء من سرعة المؤسسة.
المعلومة القديمة قد تكون أخطر من غياب المعلومة، لأنها تمنحك ثقة في قرار مبني على واقع لم يعد موجودًا.
قبل إضافة ميزة جديدة إلى منتج، اسأل كم شخصًا يستخدم الميزات الموجودة فعلًا؛ التعقيد المتراكم قد يقلل القيمة بدل أن يزيدها.
إذا كان العميل يحتاج إلى شرح طويل حتى يستخدم خدمة يفترض أنها بسيطة، فقد تكون المشكلة في التصميم لا في قدرة العميل على الفهم.
عندما يتحسن المؤشر الذي تقيسه، تأكد أن الواقع نفسه تحسن؛ الناس والأنظمة يتعلمون أحيانًا تحسين الرقم دون تحسين النتيجة التي صُمم الرقم لقياسها.
الموظف الذي يبلغك بالمشكلة مبكرًا أكثر قيمة من بيئة تخفي فيها الأخطاء حتى تصبح أزمات؛ الأمان في الكلام جزء من إدارة المخاطر.
قبل أن تبدأ مشروعًا جديدًا حدد كيف ستعرف أنه نجح؛ فالعمل الكثير لا يعني بالضرورة أن النتيجة المطلوبة تحققت.
ليس كل شيء عاجل مهمًا وليس كل شيء مهمًا عاجلًا؛ معرفة الفرق بينهما تحمي وقتك من أن تستهلكه طلبات اللحظة.
حين يحتاج الإجراء إلى شخص محدد يشرحه كل مرة، فربما المعرفة لم تتحول بعد إلى نظام يستطيع الجميع استخدامه.
إذا كانت المشكلة نفسها تعود بعد كل حل مؤقت، فتوقف عن علاج النتيجة وابحث عن السبب الذي يسمح لها بالظهور من جديد.
القرار الجيد لا يعتمد فقط على المعلومات التي تؤيد رأيك؛ قوته تظهر عندما تبحث بجدية عن الأدلة التي قد تثبت أنك مخطئ.
إذا كنت تذكر الناس بالإجراء كل مرة فربما لم يصبح جزءًا من النظام بعد.
القرار الذي لا تعرف كيف ستقيس نجاحه يحتاج تعريف النتيجة أولًا.
كلما زادت الافتراضات في الخطة زادت أهمية اختبارها مبكرًا.
لا تحل المشكلة الأكثر ضجيجًا قبل أن تتأكد أنها الأكثر ضررًا.
الاختيار بين خيارين جيدين يصبح أسهل عندما تعرف أي معيار أهم.
إذا تغيرت الحقائق فالتمسك بالقرار القديم ليس ثباتًا.
ليس كل ما يمكن فعله يستحق أن يُفعل؛ الأولوية جزء من جودة القرار.
قبل أن تسأل من المسؤول عن الخطأ اسأل كيف نمنع حدوثه مرة أخرى.
إذا لم تستطع قياس النتيجة فسيصعب معرفة هل التحسين نجح أم بدا جيدًا فقط.
الحل الذي يحتاج شرحًا جديدًا كل مرة قد يحتاج تبسيطًا أكثر من التدريب.