Hiệu ứng Dunning-Kruger trong Product Team. Khi sự cẩn trọng bị trừng phạt
Tổ chức của bạn có đang vô tình thưởng cho sự tự tin rỗng toé không? Tại sao một bạn bạn chém gió to trong cuộc họp lại được promote nhanh hơn một Senior cẩn trọng phân tích rủi ro?
Câu chuyện bé A đợt này năng nổ, present trong họp management team rất tự tin, chốt roadmap đâu ra đấy. Anh định đợt review này cho bạn ấy lên Senior. Còn cậu B (Senior hiện tại), anh thấy dạo này làm việc hơi chậm, lúc nào giao dự án cũng vạch ra một đống rủi ro rồi đòi test thêm, ko được xông xáo cho lắm.
Bạn đã từng nghe nhận xét như vậy trong kỳ Performance Review Chưa? Hay bạn tự nghĩ như thế bao giờ chưa ?
Nếu có có thể đã dính một cái bẫy tâm lý kinh điển mà hầu hết các team Product/Tech ở Việt Nam đang mắc phải: Dunning-Kruger Effect.
Hiểu đơn giản, hiệu ứng Dunning-Kruger là khi một người biết rất ít về một vấn đề, nhưng lại cực kỳ tự tin vào khả năng của mình. Ngược lại, những người có kinh nghiệm sâu sắc lại thường đánh giá thấp bản thân và cực kỳ thận trọng vì họ biết rõ những điểm mù của hệ thống.
Vấn đề ko nằm ở tâm lý cá nhân, vấn đề nằm ở việc hệ thống đánh giá của chúng ta đang vô tình tưởng thưởng cho sự tự tin rỗng, và trừng phạt sự cẩn trọng.
Bức tranh thực tế có thể như này: Trong cuộc họp Review Roadmap.
Hãy lấy một ví dụ thực tế cực kỳ phổ biến. Công ty định launch một tính năng thanh toán mới tích hợp với bên thứ ba.
Bạn Junior PM Người đang ở đỉnh sự tự tin: Bật slide lên, dõng dạc tuyên bố “Tính năng này làm cực dễ, Dev bảo 2 tuần là xong. Em cam kết ra mắt vào ngày 15, đem về tăng trưởng 20% conversion rate.” Dù thống kê của Y Combinator cho thấy chưa tới 5% các A/B test thực sự mang lại tăng trưởng trên 10%. Ban Giám đốc vỗ tay rào rào. “Đấy, tuổi trẻ phải thế, can đảm, dám nghĩ dám làm!” Không chỉ Junior PM mà có thể cả 1 Senior PM mới từ tổ chức khác vào khi chưa hiểu hết vấn đề cũng có thể nói ý chang vậy.
Bạn Senior PM. Người đang ở “Thung lũng của sự tuyệt vọng” : Cau mày suy nghĩ rồi phát biểu: “Chưa được đâu anh. Tích hợp bên thứ ba thường hay bị miss webhook khi rớt mạng, rồi cả tỉ thứ ko chắc chắn. Mình phải thiết kế thêm cơ chế xyz, rồi phải test rollback tiền nếu fail giữa chừng. Nhanh nhất cũng phải 4 tuần mới an toàn.” Ban Giám đốc thở dài: “Sao em lúc nào cũng làm phức tạp vấn đề lên thế? Mình phải Agile lên chứ!”
Kết quả? Đến ngày 15, tính năng của bạn Junior ra mắt. Nó crash tanh bành. Tiền user bị trừ nhưng đơn hàng không ghi nhận. Nhưng trớ trêu thay, ai là người phải thức đêm fix bug và dọn dẹp đống rác đó? Chính là bạn Senior. Và đến cuối năm, ai là người được khen vì “đã có tinh thần xông pha dấn thân”? Bạn Junior.
Hệ quả tàn phá P&L âm thầm.
Khi một tổ chức liên tục ưu ái những người “nói to, cam kết bừa” và gạt đi những lời cảnh báo của người có chuyên môn sâu, hệ quả không chỉ dừng lại ở cảm xúc bất mãn. Nó đánh thẳng vào P&L.
Tech Debt phình to: Những tính năng được push nhanh gọn lẹ thường là những tính năng xây trên một cái móng rỗng. Công ty tốn 2 tuần để launch, nhưng mất 6 tháng để fix bug và maintain. Chi phí bảo trì đội lên gấp bội.
Chảy máu chất xám: Những nhân sự Senior những người thực sự hiểu hệ thống và bảo vệ nó khỏi sụp đổ sẽ nản chí và rời đi. Bạn sẽ chỉ còn lại một đội ngũ toàn những người “chém gió” rất hay nhưng đụng tay vào là gãy.
Mất niềm tin từ Khách hàng: User không quan tâm bạn Agile thế nào hay team bạn xông xáo ra sao. Họ chỉ biết là app bị lỗi lúc họ cần nhất.
Giải pháp nên là: Đo lường bằng Impact thực chất.
Với tư cách là một người làm Leadership, làm sao để phá vỡ vòng lặp độc hại này?
Thứ nhất, đừng đánh giá PM qua kỹ năng thuyết trình. Kỹ năng present tốt là một điểm cộng, nhưng không phải là cốt lõi. Cốt lõi của một PM là khả năng ra quyết định dựa trên dữ liệu và quản trị rủi ro. Hãy hỏi họ: “Em đã cân nhắc những rủi ro nào? Nếu plan A fail thì plan B là gì?” Người trả lời được câu này mới là người thực sự hiểu sản phẩm.
Thứ hai, tách biệt giữa “Xông xáo” và “Liều lĩnh”. Khuyến khích team thử nghiệm nhanh, nhưng phải có ranh giới. Launch một cái landing page marketing lỗi một tí thì không sao. Nhưng launch một tính năng liên quan đến tiền bạc, dữ liệu người dùng mà không có cơ chế rollback thì đó là sự thiếu trách nhiệm, không phải là sự dấn thân.
Thứ ba, ghi nhận những “Người hùng thầm lặng”. Hãy đưa việc “Phát hiện và ngăn chặn rủi ro” trở thành một KPI quan trọng. Khi một bạn Senior chỉ ra được một lỗ hổng chí mạng trước khi code, hãy khen ngợi bạn ấy công khai, giống như cách bạn khen một người chốt được hợp đồng lớn. Phòng bệnh bao giờ cũng rẻ hơn chữa bệnh.
Tổ chức của chúng ta cần những tiếng nói phản biện. Đừng để Dunning-Kruger giết chết sự tử tế và thận trọng của những người kỹ sư lành nghề.
T.D,
T7.2026