Mở đầu — vì sao bài này quan trọng
Khi bạn còn là một Product Owner phụ trách một sản phẩm hay một team, OKRs nghe có vẻ đơn giản: đặt một Objective truyền cảm hứng, gắn 3-5 Key Results đo đếm được, rồi mỗi quý ngồi lại chấm điểm. Nhưng ở vị trí Senior PO, Head of Product hay Chief Product Officer — vai trò mà toàn bộ khóa PSPO III này hướng tới — bài toán OKRs thay đổi hoàn toàn về bản chất. Bạn không còn quản một bộ OKRs nữa, mà phải điều phối hàng chục, thậm chí hàng trăm bộ OKRs trải dài từ phòng họp ban điều hành xuống tới từng squad đang viết code. Khi đó, OKRs không còn là công cụ đặt mục tiêu cá nhân — nó trở thành hệ thần kinh chiến lược của cả tổ chức sản phẩm.
Đây chính xác là nơi rất nhiều tổ chức "agile" thất bại trong im lặng. Họ copy mô hình OKRs của Google, áp xuống 200 con người, rồi sau hai quý phát hiện ra: mỗi team đang chạy về một hướng khác nhau, OKRs cấp công ty thì treo trên slide không ai động tới, còn các team thì biến Key Results thành danh sách task trá hình. Bài này dạy bạn cách thiết kế hệ thống OKRs vận hành được ở quy mô tổ chức — cách cascade (phân tầng) đúng cách, cách tạo alignment (sự đồng bộ) theo cả chiều dọc lẫn chiều ngang, và cách giữ cho hệ thống đó vừa có kỷ luật vừa còn chỗ cho tự chủ. Đây là một năng lực lãnh đạo sản phẩm cốt lõi mà Scrum.org kỳ vọng ở một PSPO III.
Khái niệm cốt lõi
OKRs ở quy mô tổ chức khác gì OKRs của một team
Ở cấp team, OKRs trả lời câu hỏi "quý này chúng ta cố gắng đạt được điều gì?". Ở cấp tổ chức, OKRs phải trả lời thêm hai câu hỏi khó hơn nhiều: "làm sao để 30 team cùng kéo về một hướng?" và "làm sao biết một team đang đóng góp vào mục tiêu lớn, hay chỉ đang bận rộn?". Sự khác biệt nằm ở độ phức tạp của kết nối, không phải độ khó của từng mục tiêu.
Một tổ chức sản phẩm vận hành tốt thường có bốn tầng OKRs, dù không phải lúc nào cũng đủ cả bốn:
- Company OKRs (3-5 Objectives): Do ban điều hành/CEO sở hữu. Thể hiện canh bạc chiến lược lớn nhất của cả công ty trong năm hoặc nửa năm. Ví dụ: "Trở thành nền tảng thanh toán được tin dùng nhất cho SME tại Việt Nam".
- BU/Pillar OKRs (3-5 mỗi đơn vị): Cấp Business Unit, dòng sản phẩm, hoặc "pillar" chiến lược. Đây là tầng mà Head of Product thường sở hữu. Nó diễn giải canh bạc của công ty thành cam kết cụ thể của khối sản phẩm.
- Team/Squad OKRs (3-5 mỗi team): Do từng team sản phẩm sở hữu. Đây là nơi OKRs gặp thực tế giao hàng. Quan trọng: team OKRs nên xuất phát từ vấn đề/cơ hội mà team được giao giải quyết, chứ không phải từ danh sách tính năng.
- Individual OKRs (3-5, đôi khi): Tầng này gây tranh cãi nhất. Nhiều tổ chức trưởng thành (Google là ví dụ nổi tiếng) đã bỏ OKRs cá nhân vì nó dễ biến thành công cụ đánh giá hiệu suất, làm méo mó toàn bộ tinh thần OKRs. Lời khuyên của tôi: chỉ dùng OKRs cá nhân cho mục đích phát triển nghề nghiệp, và tuyệt đối tách rời khỏi lương thưởng.
Cascade không có nghĩa là "copy xuống"
Hiểu lầm tai hại nhất về cascade là nghĩ rằng Key Result của tầng trên trở thành Objective của tầng dưới một cách máy móc, như đổ nước từ tầng này xuống tầng kia. Khi làm vậy, bạn tạo ra một cây OKRs cứng nhắc: nếu cấp công ty thay đổi một con số, toàn bộ cây phía dưới sụp đổ, và mất hàng tuần để "tái cascade".
Cascade đúng cách là cascade của ý nghĩa, không phải cascade của số liệu. Tầng dưới nhìn vào Objective của tầng trên, hỏi "với bối cảnh và năng lực của mình, cách tốt nhất chúng tôi có thể đóng góp vào mục tiêu đó là gì?", rồi tự đề xuất OKRs của mình. Đây là quá trình hai chiều: lãnh đạo đặt định hướng (top-down), team đề xuất cách đạt được (bottom-up), và hai bên gặp nhau ở giữa qua đối thoại. Người ta gọi đây là mô hình "nested cadence" hoặc "aligned autonomy" — đồng bộ về hướng đi, tự chủ về cách đi.
Alignment: dọc và ngang
Alignment dọc (vertical) là thứ ai cũng nghĩ tới: team OKRs phải nối lên được BU OKRs, BU nối lên company. Nhưng ở quy mô tổ chức, alignment ngang (horizontal) mới là chỗ chết người. Hai team có thể hoàn toàn aligned theo chiều dọc nhưng vẫn xung đột với nhau: team A cần team B xây một API để đạt KR của mình, nhưng KR của team B lại không hề nhắc tới cái API đó. Đây là lý do nhiều tổ chức bổ sung khái niệm shared OKRs — những Key Results được hai hay nhiều team cùng sở hữu, buộc họ phải phối hợp.
Một công cụ hữu ích để kiểm tra alignment là "line of sight": bất kỳ ai trong tổ chức, khi nhìn vào OKR của mình, đều phải vạch được một đường nhìn thẳng tới ít nhất một Company OKR. Nếu không vạch được, hoặc là OKR đó không nên tồn tại, hoặc là chiến lược công ty đang có lỗ hổng.
Tình huống thực tế
Tình huống 1 — MoMo và cái bẫy "OKRs trên giấy"
Hãy hình dung một ví fintech quy mô lớn tại Việt Nam, tạm gọi theo mô hình MoMo, với khoảng 25 squad sản phẩm. Năm đầu triển khai OKRs, ban lãnh đạo đặt 4 Company OKRs rất hay, in ra dán ở văn phòng. Mỗi squad cũng có OKRs riêng. Nhưng đến cuối quý 2, một cuộc rà soát cho thấy: chỉ 6/25 squad có thể giải thích OKR của họ liên quan thế nào tới mục tiêu công ty. Số còn lại đặt OKRs kiểu "ra mắt 4 tính năng mới" hay "tăng tốc độ load app" — những thứ đo được nhưng không ai biết nó phục vụ canh bạc chiến lược nào.
Diễn giải: Vấn đề không phải là OKRs cấp công ty dở, mà là thiếu tầng trung gian dịch nghĩa. Khối sản phẩm không có BU/Pillar OKRs để làm cầu nối. Mỗi squad tự nhìn lên 4 Objective trừu tượng của công ty rồi tự suy diễn, dẫn đến 25 cách hiểu khác nhau. Sau đó họ bổ sung 3 "Product Pillar OKRs" (Tăng trưởng người dùng hoạt động, Mở rộng hệ sinh thái thanh toán, Giữ chân merchant), và mỗi squad bắt buộc phải nối OKR của mình vào một pillar cụ thể. Quý sau, tỷ lệ squad vạch được "line of sight" tăng từ 24% lên 80%.
Bài học: Ở quy mô lớn, đừng bắt team nhảy thẳng từ company xuống team. Tầng BU/Pillar OKRs không phải thủ tục thừa — nó là bộ phiên dịch chiến lược.
Tình huống 2 — Grab và shared OKRs để phá silo
Một super-app khu vực Đông Nam Á (mô hình Grab) có hai khối: Mobility (gọi xe) và Payments (ví điện tử). Company OKR năm đó là "Tăng tần suất giao dịch tài chính trên mỗi người dùng hoạt động lên 2,5 lần". Khối Payments đặt KR "30% chuyến xe được thanh toán bằng ví". Nhưng để đạt được, họ cần khối Mobility thay đổi luồng đặt xe để đẩy ví lên làm phương thức mặc định — điều mà KR của Mobility (vốn tập trung vào thời gian chờ xe) không hề đề cập. Hai khối aligned dọc hoàn hảo nhưng vẫn giẫm chân nhau.
Diễn giải: Giải pháp là tạo một shared KR thuộc sở hữu chung của cả hai khối: "Nâng tỷ lệ thanh toán không tiền mặt trên chuyến xe từ 18% lên 30%". Cả hai PM lead của hai khối cùng chịu trách nhiệm về con số này, cùng review hằng tuần. Khi một KR thuộc về cả hai, không bên nào có thể đổ lỗi cho bên kia — họ buộc phải ngồi lại thiết kế chung.
Bài học: Alignment ngang không tự sinh ra từ sơ đồ tổ chức đẹp. Nó cần được cấu trúc hóa bằng shared OKRs — những điểm neo buộc các team phụ thuộc lẫn nhau phải phối hợp thật sự.
Tình huống 3 — Tiki và việc đếm OKRs quá nhiều
Một sàn thương mại điện tử (mô hình Tiki) hào hứng triển khai OKRs toàn công ty. Để "không bỏ sót gì", họ yêu cầu mỗi tầng có đủ 5 Objective, mỗi Objective có 5 Key Results, và áp xuống cả 4 tầng kể cả cá nhân. Kết quả: một engineer cấp dưới phải theo dõi OKRs của bản thân, của team, của BU và của công ty — tổng cộng gần 80 Key Results có liên quan. Mọi người dành nhiều thời gian cập nhật spreadsheet OKRs hơn là làm việc. Tinh thần "tập trung vào điều quan trọng nhất" hoàn toàn biến mất.
Diễn giải: OKRs sinh ra để buộc lựa chọn, không phải để liệt kê mọi thứ đang làm. Họ cắt xuống còn 3 Company Objectives, mỗi BU tối đa 3, mỗi team tối đa 3, và bỏ hẳn OKRs cá nhân. Quan trọng hơn, họ chấp nhận rằng "công việc duy trì" (keep-the-lights-on) không cần nằm trong OKRs — OKRs chỉ dành cho những thay đổi tạo khác biệt. Sau khi tinh giản, các cuộc họp review trở nên sắc bén và năng suất cảm nhận tăng rõ rệt.
Bài học: Ở quy mô tổ chức, sức ép luôn là làm OKRs phình to. Vai trò của Product Leader là người gác cổng kỷ luật: ít hơn nhưng sắc hơn.
Hướng dẫn từng bước
Dưới đây là quy trình triển khai OKRs ở quy mô tổ chức mà bạn có thể áp dụng theo nhịp quý:
- Bắt đầu từ chiến lược, không từ template. Trước khi viết một Objective nào, ban điều hành phải thống nhất được 3-5 canh bạc chiến lược của năm. Nếu chưa có chiến lược rõ ràng, OKRs sẽ chỉ là cái vỏ. Company OKRs là sự diễn đạt chiến lược đó dưới dạng đo được.
- Xây tầng BU/Pillar OKRs làm cầu nối. Với mỗi Company Objective, Head of Product cùng các lead xác định khối sản phẩm sẽ đóng góp ra sao. Mỗi BU/Pillar OKR phải nối rõ ràng lên ít nhất một Company OKR. Đây là tầng "phiên dịch".
- Mở giai đoạn đối thoại hai chiều với team (1-2 tuần). Đừng giao OKRs cho team. Hãy chia sẻ định hướng tầng trên, rồi để mỗi team tự đề xuất OKRs của mình dựa trên cơ hội họ nhìn thấy. Lãnh đạo phản hồi, thách thức, tinh chỉnh. Đây là lúc aligned autonomy hình thành.
- Rà soát alignment ngang và tạo shared OKRs. Vẽ bản đồ phụ thuộc giữa các team. Ở đâu một team cần team khác để đạt KR, hãy cân nhắc biến nó thành shared KR có chủ sở hữu chung. Phát hiện sớm xung đột tài nguyên ở bước này.
- Kiểm tra "line of sight" toàn hệ thống. Đi qua từng team OKR và hỏi: nó nối lên đâu? Nếu có OKR mồ côi (không nối lên gì), hoặc Company OKR nào không có team nào đỡ, đó là tín hiệu cần xử lý trước khi khóa.
- Thiết lập nhịp check-in, tách khỏi grading. Đặt nhịp review nhẹ hằng tuần (cập nhật confidence level) và review sâu giữa quý. Cuối quý chấm điểm để học hỏi, không phải để phạt. Nhịp này — nested cadence — là thứ giữ OKRs sống.
- Đóng vòng lặp: retrospective về chính hệ thống OKRs. Mỗi quý, dành thời gian hỏi không chỉ "chúng ta đạt OKRs không" mà "hệ thống OKRs có đang giúp chúng ta không". Đây là điều phân biệt một Product Leader trưởng thành.
Lỗi thường gặp & mẹo
Lỗi 1 — Cascade số liệu thay vì ý nghĩa. Biến KR của sếp thành Objective của lính một cách máy móc tạo ra hệ thống giòn, dễ gãy. Mẹo: cascade câu hỏi "làm sao chúng tôi đóng góp tốt nhất?", không cascade con số.
Lỗi 2 — Nhầm OKRs với danh sách task. "Ra mắt tính năng X" không phải Key Result — nó là output, không phải outcome. KR tốt phải là kết quả đo lường tác động (ví dụ: "tăng tỷ lệ chuyển đổi từ 3% lên 5%"). Mẹo: với mỗi KR, hỏi "nếu làm xong việc này mà con số không đổi, ta có hài lòng không?". Nếu không, đó là output trá hình.
Lỗi 3 — Gắn OKRs vào lương thưởng. Đây là sai lầm phá hủy nhanh nhất. Khi OKRs ảnh hưởng thu nhập, ai cũng đặt mục tiêu dễ để chắc đạt, và sự trung thực biến mất. Mẹo: tách hoàn toàn OKRs khỏi đánh giá hiệu suất. OKRs là công cụ điều hướng, không phải công cụ chấm công.
Lỗi 4 — Quá nhiều OKRs. Năm Objective, mỗi cái năm KR, trên bốn tầng — đó là công thức làm OKRs trở thành gánh nặng hành chính. Mẹo: áp quy tắc "3 là đủ". Sự tập trung mới là giá trị cốt lõi của OKRs.
Lỗi 5 — Bỏ qua alignment ngang. Chỉ chăm chăm nối lên trên mà quên các phụ thuộc bên cạnh. Mẹo: dùng shared OKRs và bản đồ phụ thuộc cho những điểm giao thoa quan trọng.
Mẹo nâng cao: Đừng đòi hỏi sự hoàn hảo ngay năm đầu. Tổ chức cần 3-4 chu kỳ để OKRs "ngấm". Vai trò của bạn là kiên nhẫn cải tiến hệ thống, không phải áp đặt nó hoàn chỉnh ngày một ngày hai.
Bài tập thực hành
Bài tập 1 — Xây cây OKRs ba tầng. Chọn một công ty bạn quen (hoặc công ty bạn đang làm). Viết 1 Company Objective với 3 Key Results. Sau đó, đóng vai Head of Product, viết 1 BU/Pillar OKR nối lên Company OKR đó. Cuối cùng, viết 2 Team OKRs nối lên BU OKR. Vẽ mũi tên "line of sight" giữa các tầng và kiểm tra: mọi tầng dưới có nối được lên trên không?
Bài tập 2 — Phát hiện và sửa OKRs giả. Cho Key Result sau: "Hoàn thành migration sang hệ thống thanh toán mới và ra mắt 3 phương thức thanh toán mới trong Q3." Hãy chỉ ra tại sao đây là output chứ không phải outcome, rồi viết lại thành một KR đo lường tác động thực sự.
Bài tập 3 — Thiết kế một shared OKR. Tưởng tượng tổ chức của bạn có team "Tăng trưởng" và team "Hạ tầng dữ liệu" đang xung đột: Tăng trưởng cần dữ liệu real-time để cá nhân hóa, nhưng Hạ tầng dữ liệu không có KR nào nhắc tới việc đó. Hãy viết một shared Key Result mà cả hai team cùng sở hữu để buộc họ phối hợp.
Bài tập 4 — Phản biện. Viết một đoạn 150 từ trả lời câu hỏi: "Tổ chức của tôi có nên dùng OKRs cá nhân không, và vì sao?". Dùng lập luận về tách rời OKRs khỏi lương thưởng để bảo vệ quan điểm của bạn.
Tóm tắt
Ở quy mô tổ chức, OKRs không còn là công cụ đặt mục tiêu cá nhân mà là hệ thần kinh chiến lược kết nối từ ban điều hành xuống từng squad. Bốn tầng điển hình — Company, BU/Pillar, Team, và (tùy chọn) Individual — mỗi tầng nên giữ kỷ luật 3-5 Objectives để bảo toàn sự tập trung. Chìa khóa thành công không nằm ở việc cascade số liệu một cách máy móc, mà ở cascade ý nghĩa qua đối thoại hai chiều, tạo nên aligned autonomy: đồng bộ về hướng, tự chủ về cách đi.
Đừng quên rằng alignment có hai chiều. Alignment dọc giúp mọi người nối lên chiến lược chung; nhưng chính alignment ngang — được cấu trúc qua shared OKRs — mới phá vỡ các silo và ngăn các team giẫm chân nhau. Ba tình huống của MoMo, Grab và Tiki cho thấy ba cái bẫy phổ biến nhất: thiếu tầng phiên dịch, bỏ quên phụ thuộc ngang, và để OKRs phình to thành gánh nặng hành chính.
Cuối cùng, với vai trò Product Leader, công việc của bạn không chỉ là điền OKRs cho đúng template, mà là làm chủ và liên tục cải tiến chính hệ thống OKRs — giữ nó vừa có kỷ luật vừa còn không gian tự chủ, vừa đo được kết quả vừa không bóp nghẹt tinh thần thử nghiệm. Đó là khác biệt giữa một người quản lý OKRs và một người lãnh đạo bằng OKRs.