Spreadsheet planning nhìn rất gọn, nhưng team vẫn có vẻ chưa chắc. Ba objective, chín key result, nhiều ô màu xanh, nhưng không ai trả lời tự tin được câu đơn giản nhất: nếu tất cả những thứ này xanh, điều gì sẽ tốt hơn cho user, business hoặc engineering system?
Đó là nguy cơ của OKRs trong engineering team. Chúng có thể tạo clarity, hoặc biến thành task list được trang trí. Một hệ thống Objective and Key Results tốt nối work với outcome. Một hệ thống yếu đổi tên delivery commitment thành strategy, rồi bắt mọi người update percentage cho đến hết quý.
Objective nên mô tả một hướng có ý nghĩa bằng ngôn ngữ đơn giản. Cải thiện reliability của checkout. Làm onboarding nhanh hơn cho customer mới. Giảm operational pain trong release process. Tăng nền tảng data cho product decision. Objective nên đủ cụ thể để mọi người nhớ được khi trade-off, nhưng đủ rộng để team chọn đường tốt nhất khi học thêm.
Key result nên mô tả evidence của progress, không chỉ là việc đã làm. Ship retry logic mới là một task. Giảm failed checkout attempts 30 percent gần với outcome hơn. Tạo runbook là task. Giảm average incident diagnosis time từ 40 phút xuống 15 phút là evidence. Khác biệt này quan trọng vì team có thể hoàn thành rất nhiều task trong khi vấn đề thật gần như vẫn còn.
Engineering OKRs cần một mix cẩn thận giữa product outcome và system outcome. Nếu mọi thứ đều là product growth, team có thể bỏ qua reliability, maintainability và developer experience cho đến khi system phản ứng lại. Nếu mọi thứ đều là internal hygiene, work có thể trôi xa khỏi customer value. Một bộ khỏe có thể gồm một customer-facing outcome, một reliability hoặc quality outcome, và một capability-building outcome làm delivery tương lai dễ hơn.
Measurement không cần hoàn hảo, nhưng nên trung thực. Một số metric noisy. Một số baseline chưa đủ. Một số outcome cần proxy signal. Điều đó chấp nhận được nếu team gọi tên điểm yếu. Một key result có evidence chưa hoàn hảo nhưng nhìn thấy được thường tốt hơn một lời hứa mơ hồ không ai inspect được. Mục tiêu không phải vẻ đẹp toán học. Mục tiêu là cuộc trò chuyện tốt hơn về việc work có thật sự giúp ích không.
OKRs trở nên có hại khi bị dùng như bẫy performance cá nhân. Nếu mỗi key result thành scorecard riêng, con người sẽ học cách đặt mục tiêu thấp, giấu uncertainty hoặc chọn việc quá an toàn. Engineering work có dependency, discovery, incident và constraint thay đổi. OKRs nên hướng dẫn team learning và prioritization, không trừng phạt con người vì thực tế phức tạp hơn planning meeting.
Cadence cũng quan trọng. Viết OKRs đầu quý rồi chấm điểm cuối quý là quá muộn. Team cần check-in ngắn trong quý: điều gì thay đổi, mình học được gì, key result nào không còn đại diện cho đường tốt nhất, và việc gì nên dừng? Đây là lúc OKRs trở nên hữu ích. Chúng bảo vệ focus, nhưng cũng cho phép thích nghi khi evidence thay đổi.
Một engineering OKR tốt thường cải thiện chất lượng của chữ không. Khi một request mới đến, team có thể hỏi nó có phục vụ objective không hay chỉ tạo cảm giác urgent. Khi một refactor được đề xuất, team có thể nối nó với reliability hoặc speed outcome thay vì bảo vệ nó như sở thích cá nhân. Khi leadership hỏi progress, team có thể đưa evidence thay vì chỉ đưa activity.
Tôi thích OKRs khi chúng làm work dễ hiểu hơn và ít trình diễn hơn. Chúng nên giúp team nói: đây là thay đổi mình muốn tạo ra, đây là cách mình biết, đây là trade-off mình chấp nhận, và đây là chỗ mình vẫn cần học. Nếu team của bạn từng dùng OKRs tốt, câu chuyện thú vị thường không nằm ở template. Nó nằm ở khoảnh khắc OKR giúp team ra quyết định tốt hơn so với chỉ nhìn vào task list.