• Chúng tôi đã yêu cầu báo cáo trực tiếp cho giám đốc sản phẩm để cung
cấp dự thảo OKRs của họ.
• Chúng tôi đã tổ chức các phiên xung đột để các nhóm khác nhau thỏa
thuận về những gì sẽ và sẽ không tạo ra OKRs tốt (và xử lý các phụ thuộc
ngay từ đầu).
• Chúng tôi đã xuất bản chúng lên một trang web công cộng và phổ biến
trong toàn bộ tổ chức. Chúng tôi cảm thấy điều quan trọng là mọi người nên
biết về những gì chúng tôi đã làm việc trên đó.
• Cuối cùng, chúng tôi đã tổ chức một cuộc họp toàn thể khác để xem xét
các OKRs đã hoàn thành.
Quả thực, buổi ban đầu rất gian nan. Chúng tôi mất khoảng ba quý để thoát
khỏi những khúc mắc và sự nhầm lẫn của OKRs. Các vấn đề phổ biến nhất
là:
Quá nhiều công việc và không đủ tập trung (những gì thực sự quan trọng!).
Một khuynh hướng để sử dụng OKRs làm tài liệu bắt buộc (cà rốt so với
cây gậy). Thách thức với OKRs là đôi khi chúng trông giống như các hợp
đồng. Các mục tiêu và kết quả then chốt là một quá trình lặp đi lặp lại, trong
đó có thiết lập đàm phán và mở rộng mục tiêu. Điều này đòi hỏi sự tin
tưởng ghê gớm trong toàn bộ tổ chức. Một ví dụ là cho phép các nhóm thực
hiện những đánh giá từ dưới lên về không chỉ những gì nên làm, mà cả
những kết quả có thể làm. Nếu chỉ là từ trên xuống và kết quả gắn liền một
cách “trực tiếp” với hiệu suất, OKRs trở nên giống như những hợp đồng mà
cuối cùng các đội sẽ sử dụng để thúc đẩy nhau hoàn thành công việc. OKRs
thực sự giúp các tổ chức phức tạp làm việc cùng nhau bằng cách cho thấy
bức tranh lớn hơn và những tương tác phức tạp giữa các dịch vụ và các
nhóm. Niềm tin vào bức tranh lớn hơn thúc đẩy các nhóm hướng tới sự hội
tụ và phân chia công bằng (và tái thiết lập ưu tiên) khi cần thiết. Nếu OKRs
