Empowered Teams: Thôi giao Task, hãy giao đúng Vấn đề.
Trao quyền không nằm ở việc để team tự do làm những gì họ thích, mà là cung cấp kết quả mong đợi thay vì đưa danh sách chức năng cần làm theo góc nhìn chủ quan.
Có một khoảng thời gian bắt đầu chuyển sang làm lead, mình từng rất tự hào về những bản công việc cần làm cụ thể vì mình tin rằng càng rõ thì ae bên dưới càng dễ làm. Mình vẽ sẵn mọi mockup sơ bộ, lên danh sách đầy đủ các vấn đề, thậm chí đôi lúc còn ngồi trước với các team liên quan để team có thể chạy tốt hơn.
Và mình tưởng đó là quản lý sản phẩm.
Thực ra, nếu làm theo cách đó, mình đang vô tình biến đội ngũ thành một nhóm cỗ máy nhận lệnh hay còn gọi là mô hình Feature Factory mình hay nói trước đó.
Nhưng mọi thứ thay đổi khi mình bắt đầu quản lý nhiều người và các mục tiêu thành công không còn trong việc delivery, và vụ này cũng được nói nhiều trong cuốn Empowered của bác Marty Cagan. Trong đó, ông chỉ ra một sự khác biệt cốt lõi giữa Feature Teams và Empowered Product Teams.
Ở mô hình cũ, sếp mang xuống một cái roadmap đầy task. Ở mô hình mới, leader mang xuống một Mục tiêu cần đạt. Ví dụ: Thay vì bảo Hãy làm chức năng OTP qua Zalo,
PM sẽ bảo Chúng ta cần giảm 20% chi phí gửi SMS trên mỗi user mà vẫn đảm bảo tỷ lệ xác thực thành công”.
Lúc này, hãy để team tự suy nghĩ trước khi đưa thêm các đầu mục bạn nghĩ hiệu quả khi đó có thể phép màu mới thực sự xảy ra.
Khi bạn chia sẻ bối cảnh và lý do thay vì chỉ chăm chăm vào cách làm, bạn sẽ thấy những con người ngồi code hàng ngày cạnh mình là những cái đầu cực kỳ thông minh. Một bạn Dev có thể đề xuất một flow xác thực hoàn toàn khác không cần Zalo, không cần SMS mà vẫn đạt được mục tiêu. Đó là sự trao quyền.
Cảm giác thả lỏng kiểm soát ban đầu có thể hơi đáng sợ. Nhưng một khi chúng ta buông bỏ được cái tôi thích chỉ tay năm ngón, đội ngũ của bạn sẽ chủ động hơn, cam kết hơn, và đáng ngạc nhiên nhất sản phẩm tạo ra lại tốt hơn những gì bạn tự tưởng tượng rất nhiều.
Đề xuất hướng tiếp cận đơn giản bạn nên thử.
Từ What sang Why: Lần tới khi bạn sprint planning, thay vì chỉ mở Jira ra đọc các tính năng phải làm tập trung quá nhiều vào What, hãy dành 10 phút nói về lý do và chỉ số kinh doanh chúng ta kỳ vọng việc này mang lại Why. Việc này rất hay đc nói trong mọi câu chuyện nhưng hiếm khi thấy được làm đúng nghĩa.
Khuyến khích tranh luận để tập Discovery: Hãy tạo thói quen ngồi lại với Dev Lead và Product Designer từ rất sớm chưa có spec nào cả để brainstorm tìm cách tiếp cận bài toán. Thừa nhận với team rằng Mình không có sẵn giải pháp tốt nhất đâu, chúng ta cùng bàn.
Đừng quản lý tiến độ, quản lý kết quả: Hãy khen thưởng một team làm được tính năng tăng 10% chuyển đổi, thay vì khen một team code xong 100 features trong tháng nhưng chả có ai dùng.
Trao quyền không nằm ở việc để team làm gì thì làm, mà là đưa cho họ một bài toán kinh doanh cần giải thực sự chính xác.”
T.D
3.2026