Extreme Ownership: Trách nhiệm tuyệt đối. Không có team tồi, chỉ có Leader tồi.
Đừng đổ lỗi cho Dev viết code lỗi hay Sale bán sai cam kết. Khi bạn là PM, mọi thất bại của sản phẩm đều là lỗi của bạn.
Lần đầu tiên đọc cuốn Extreme Ownership của cựu chỉ huy đặc nhiệm SEAL Jocko Willink, mình cảm thấy quá lý tưởng hoá vấn đề và rất nhãm nhí vì leader cũng đi làm công ăn lương thì đúng ra nên rõ ai có lỗi. Vì tác giả khẳng định: Trong một tổ chức, từ việc nhỏ nhất đến lớn nhất bị hỏng, người lãnh đạo phải nhận 100% trách nhiệm về mình. Không có nhưng, càng không có tại, bị, vì, nếu, như.
Mình nhớ lại một dự án cũ. Khi ra mắt tính năng bỗng nhiên app crash liên tục vì hệ thống quá tải. Trong buổi họp xem vấn đề sau đó, mình đã rất bức xúc và dồn ép đội Dev: “Tại sao lúc viết spec mình đã dặn rõ là phải handle 10.000 CCU truy cập đồng thời mà mọi người lại quên test?”. Bạn Dev Lead thì cãi lại: Thời gian ép quá, QA lại nghỉ ốm, bọn em làm sao test kịp!.
Hôm đó, mình bước ra khỏi phòng họp với suy nghĩ “Team này làm ăn chán thật tôi muốn team đúng vấn đề chứ đã bắt ai chịu trách nhiệm đâu”.
Nhưng nếu áp dụng tư duy Extreme Ownership, mình ép bản thân nhìn lại toàn bộ quá trình dưới góc độ lỗi-của-mình:
Lỗi của mình: Mình biết thời gian gấp nhưng không chủ động cắt giảm scope tính năng để team có thời gian test.
Lỗi của mình: Mình biết QA nghỉ ốm nhưng không bổ sung thêm người support, cũng không báo cáo rủi ro này lên cấp trên để lùi ngày mộc release nếu không thực sự chưa an toàn.
Lỗi của mình: Mình bỏ mặc team Dev tự bơi trong áp lực thay vì đứng ra bảo vệ họ.
Khi bạn dám thốt lên câu Tất cả là lỗi của tôi, tôi đã không tạo đủ điều kiện để team làm tốt, một điều kỳ diệu sẽ xảy ra. Đội ngũ không những không khinh thường bạn, mà ngược lại, sự tôn trọng họ dành cho bạn sẽ tăng vọt. Và quan trọng nhất, khi bạn nhận lỗi, mọi người sẽ ngừng phòng thủ và bắt đầu xắn tay vào giải quyết nguyên nhân gốc rễ.
Cuối cùng, không ai muốn theo một người Leader luôn chỉ tay đổ lỗi khi tàu chìm, và tranh công khi tàu cập bến an toàn.
Đề xuất áp dụng để trở thành Leader.
Ngừng Chỉ tay 5 ngón: Lần tới khi có bug nghiêm trọng lọt lên production, câu đầu tiên bạn nói trước cả công ty không phải là Dev A code lỗi, mà là “Là PM, mình đã không rà soát kĩ rủi ro ở use case này. Team đang tập trung fix, mình sẽ cập nhật lại sau”.
Kiểm tra sự hiểu biết của bản thân liên tục: Khi giao một spec khó, đừng chỉ hỏi Mọi người hiểu chưa?. Hãy hỏi: “Để chắc chắn mình giải thích không thiếu sót, một bạn có thể tóm tắt lại cách chúng ta sẽ giải quyết logic này không?”. Nếu họ nói sai, đó là do bạn giải thích kém.
Phân quyền nhưng không đùn đẩy trách nhiệm: Bạn giao cho một bạn Associate PM quản lý một tiến độ dự án nhỏ. Nếu dự án đó fail, trước mặt sếp lớn, lỗi là của bạn vì đã tin tưởng mù quáng mà thiếu sự kiểm tra định kỳ và có cáccheckpoint. Hãy tự chịu đòn, sau đó về họp 1-1 để đào tạo lại bạn Associate đó.
Sẽ không bao giờ có chuyện Team tôi không hiểu ý tôi hay Nhân sự của tôi quá non kém. Nếu team thất bại, đó là do bạn người Leader đã không giải thích đủ rõ ràng hoặc không đo lường đúng rủi ro."
T.D
3.2026