mảng an ninh công nghệ và một nhóm khác nữa phụ trách công nghệ tìm
kiếm, v.v.
Điều cốt lõi là, tuy họ có những kỹ năng chuyên biệt, đến từ những bộ phận
chức năng khác nhau, nhưng tất cả sẽ cùng ngồi lại để làm việc, giải quyết
những vấn đề về công nghệ hay khó khăn trong kinh doanh. Những tổ chức
lớn thậm chí thường có từ 20-50 nhóm đa chức năng, mỗi nhóm hoạt động
ở một lĩnh vực khác nhau và đều có những mục tiêu riêng. Vấn đề họ phải
giải quyết chính là làm sao để truyền đạt và theo dõi những OKRs đã đặt ra.
OKRs của mỗi nhóm cũng giúp đảm bảo họ đang hướng về mục tiêu chung
của công ty. Hơn thế nữa, khi quy mô của tổ chức tăng lên, OKRs sẽ ngày
càng trở thành công cụ thiết yếu cho mỗi nhóm sản phẩm để thấy được sự
đóng góp của họ vào cái chung, cũng như những công việc cần hợp tác giữa
các nhóm và tránh sự trùng lặp.
Tôi cần phải giải thích điều này thật cặn kẽ vì khi các tổ chức lần đầu áp
dụng OKRs, họ thường có xu hướng để từng bộ phận chức năng thiết kế
OKRs cho cả công ty. Ví dụ, bộ phận thiết kế có thể đặt ra Mục tiêu liên
quan đến việc chuyển sang một thiết kế tương tác mới; bộ phận kỹ thuật có
thể đặt ra Mục tiêu liên quan đến việc tăng quy mô và hiệu suất của mô
hình xây dựng; bộ phận chất lượng sẽ đặt ra Mục tiêu kiểm tra và triển khai
hệ thống tự động hóa.
Vấn đề nằm ở chỗ, mỗi thành viên trong từng nhóm cũng chính là thành
viên của cả bộ phận sản phẩm đa chức năng. Nhóm sản phẩm có những
Mục tiêu liên quan đến kinh doanh (ví dụ như giảm chi phí cho khách hàng,
tăng số lượng người dùng mỗi ngày hoặc tiết kiệm thời gian hướng dẫn sử
dụng cho khách hàng mới), nhưng mỗi người trong nhóm lại có OKRs riêng
do giám đốc bộ phận áp đặt.
Giả sử công việc của kỹ sư chỉ là nghiên cứu giao diện, còn nhà thiết kế chỉ
phụ trách thiết lập trang web tương tác mới còn nhân viên đảm bảo chất
lượng phải cập nhật tình hình trang thiết bị. Dù chúng thực sự cần thiết,
