Sếp càng giỏi, team càng chậm

9 giờ sáng, Designer nhắn:

“Anh ơi, empty state này dùng câu A hay câu B ạ?”

9 giờ 30, Developer hỏi:

“Anh ơi, trường hợp này mình hiện popup hay chuyển sang trang mới?”

10 giờ, Marketing nhắn tiếp:

“Anh xem giúp em nội dung thông báo này ổn chưa nhé.”

Người manager trả lời rất nhanh. Câu chữ nào chưa ổn thì sửa luôn. Flow nào chưa hợp lý thì chụp màn hình khoanh đỏ. Có lúc thấy team làm hơi lâu, anh tiện tay làm hộ luôn cho nhanh.

Mọi thứ có vẻ rất hiệu quả.

Cho đến chiều hôm đó, manager phải vào họp liên tục. Không ai trả lời tin nhắn nữa. Designer dừng ở empty state. Developer chuyển sang task khác. Marketing ngồi chờ duyệt nội dung.

Cả team bỗng dưng đứng hình vì “server sếp” đang bận.

Trớ trêu là người manager này không hề yếu. Ngược lại, anh hiểu sản phẩm, quyết định nhanh và thường xuyên đưa ra đáp án khá tốt.

Nhưng chính vì anh luôn có đáp án, team dần không cần tự tìm đáp án nữa.

Chapter 01

Manager trở thành API của team

Khi mới quản lý, chúng mình rất dễ nghĩ rằng trách nhiệm của manager là đưa ra quyết định.

Team gặp khó khăn thì mình giải quyết.

Mọi người chưa biết làm gì thì mình hướng dẫn.

Chất lượng chưa đủ tốt thì mình nhảy vào sửa.

Suy nghĩ này không sai. Manager rõ ràng phải chịu trách nhiệm với kết quả của team. Nhưng nếu mọi quyết định, dù lớn hay nhỏ, đều phải gọi lên “API manager”, hệ thống sẽ sớm gặp hai vấn đề.

Đầu tiên là manager trở thành nút thắt.

Một người chỉ có từng đó thời gian và năng lượng. Khi số lượng công việc tăng lên, tốc độ của cả team sẽ bị giới hạn bởi tốc độ đọc tin nhắn, tham gia họp và đưa ra quyết định của người đó.

Vấn đề thứ hai còn khó giải quyết hơn: team mất dần khả năng tự quyết định.

Lúc đầu, mọi người hỏi vì chưa đủ thông tin.

Sau vài lần được trả lời ngay, mọi người hỏi vì cách đó nhanh hơn tự suy nghĩ.

Sau vài tháng, mọi người hỏi vì không còn chắc mình có quyền quyết định hay không.

Thế là manager ngày càng bận, còn team ngày càng bị động. Manager nhìn xuống thấy mọi người thiếu chủ động nên lại nhảy vào nhiều hơn. Team thấy việc gì sếp cũng sửa nên càng chờ sếp chốt.

Một vòng lặp hoàn hảo.

Hoàn hảo theo nghĩa càng vận hành, tình trạng phụ thuộc càng nặng.

Chapter 02

Tại sao team cứ phải hỏi?

Phản ứng dễ nhất của manager lúc này là:

“Có việc bé tý mà cũng phải hỏi anh à? Các em chủ động lên chứ!”

Nhưng “hãy chủ động lên” cũng mơ hồ chẳng kém gì “hãy thiết kế đẹp lên”.

Muốn team tự quyết định, ít nhất mọi người phải biết mình đang dựa vào đâu để quyết định.

Quay lại câu hỏi về empty state lúc đầu. Designer được giao thiết kế một màn hình nhưng có thể chưa biết:

Mục tiêu quan trọng nhất của màn hình này là gì?

Người dùng đang ở trạng thái nào?

Team muốn họ thực hiện hành động gì tiếp theo?

Có nguyên tắc nội dung nào cần tuân thủ?

Quyết định này có ảnh hưởng đến pháp lý, doanh thu hay một team khác không?

Nếu toàn bộ bối cảnh chỉ nằm trong đầu manager, việc Designer liên tục hỏi là điều dễ hiểu. Không hỏi thì sợ làm sai. Tự quyết rồi bị sửa thì lại mất công.

Do đó, vấn đề đôi khi không phải team thiếu chủ động.

Team đang thiếu nguyên liệu để chủ động.

Manager thường giao phần việc nhìn thấy được: thiết kế màn hình, viết nội dung, phát triển tính năng. Nhưng lại giữ phần quan trọng nhất trong đầu mình: tại sao phải làm, đâu là ưu tiên và đánh đổi nào có thể chấp nhận.

Sau đó chúng mình ngạc nhiên khi thành viên không đưa ra được một quyết định giống mình.

Khó thật. Đề bài nằm trong đầu sếp mà team vẫn phải tự đoán cho đúng.

Chapter 03

Trao quyền không phải là “cứ tự quyết đi em”

Sau khi nhận ra mình đang trở thành nút thắt, một số manager chuyển sang thái cực còn lại:

“Từ giờ mọi người cứ tự quyết nhé. Anh trao quyền hoàn toàn.”

Nghe rất Leadership.

Nhưng nếu không có thêm bối cảnh hay giới hạn nào, đây không phải trao quyền. Đây là giao rủi ro cho team rồi cầu nguyện.

Để một người có thể tự quyết định, họ cần biết ba thứ.

Chúng mình đang cố đạt được điều gì?

Thay vì chỉ nói “viết lại empty state”, manager có thể làm rõ:

“Nhóm người dùng này vừa tạo tài khoản nhưng chưa có dữ liệu. Mục tiêu của màn hình là giúp họ hiểu bước đầu tiên cần làm và bắt đầu nhanh nhất có thể.”

Khi mục tiêu đã rõ, Designer có cơ sở để chọn nội dung. Câu nào giúp người dùng hành động tốt hơn thì dùng, thay vì chọn câu mà manager cảm thấy “nghe xuôi tai”.

Giới hạn nằm ở đâu?

Không phải quyết định nào cũng có mức độ rủi ro giống nhau.

Thay đổi một câu hướng dẫn có thể dễ dàng sửa lại. Thay đổi giá bán, cam kết với khách hàng hoặc cách lưu trữ dữ liệu thì không.

Manager cần cho team biết đâu là các ràng buộc:

Nội dung có thể thay đổi, nhưng không được tạo ra cam kết sai về sản phẩm.

Flow có thể tối ưu, nhưng không được bỏ bước xác thực bắt buộc.

Team được thử nghiệm, nhưng phải đo lường kết quả sau khi release.

Có hàng rào rồi, mọi người mới biết khoảng sân nào mình có thể tự chạy.

Quyết định nào thực sự cần manager?

Một cách đơn giản là chia quyết định thành ba nhóm.

Team tự quyết: Những việc có rủi ro thấp, dễ thay đổi và nằm trong chuyên môn của người thực hiện.

Team đề xuất, manager chốt: Những việc ảnh hưởng đến nhiều bộ phận, nguồn lực hoặc mục tiêu lớn của sản phẩm.

Manager trực tiếp quyết định: Những việc liên quan đến chiến lược, cam kết quan trọng hoặc rủi ro mà manager là người chịu trách nhiệm cuối cùng.

Việc phân chia này không nhất thiết phải biến thành một quy trình dài ba trang. Nhiều khi chỉ cần nói rõ ngay lúc giao việc:

“Phần nội dung em tự quyết nhé. Nếu thay đổi cả flow hoặc ảnh hưởng tới tracking thì báo lại anh.”

Một câu như vậy có thể tiết kiệm được hàng chục tin nhắn xin duyệt về sau.

Đừng trả lời quá nhanh

Có một nghịch lý là manager càng giỏi chuyên môn càng dễ mắc vào vấn đề này.

Khi thành viên hỏi, manager thường nhìn ra đáp án rất nhanh. Việc trả lời luôn mất ít thời gian hơn việc giải thích bối cảnh rồi để người khác tự suy nghĩ.

Ít nhất là trong hôm nay.

Nhưng nếu lần nào manager cũng đưa đáp án, ngày mai team vẫn tiếp tục hỏi câu tương tự.

Thay vì trả lời ngay, manager có thể hỏi lại:

“Em đang cân nhắc giữa những phương án nào?”

“Dựa trên mục tiêu của flow, em nghiêng về phương án nào hơn?”

“Nếu tự quyết thì em sẽ chọn gì?”

Đây không phải chiêu giả vờ không biết để thử lòng nhân viên. Manager vẫn cần bổ sung thông tin nếu team đang thiếu.

Mục đích là để phân biệt hai trường hợp:

Team không có đủ bối cảnh để quyết định.

Hay team đã có đủ bối cảnh nhưng quen chờ người khác quyết định hộ.

Hai vấn đề này nhìn bên ngoài khá giống nhau, nhưng cách giải quyết hoàn toàn khác.

Lời nhắn

Một manager có thể tự tay đưa ra quyết định tốt hơn từng thành viên trong team.

Nhưng nếu manager phải tự quyết định mọi thứ, cả team cộng lại vẫn chỉ có năng lực của một người.

Trao quyền không phải là mặc kệ mọi người tự bơi. Nó là chia sẻ đủ bối cảnh, làm rõ giới hạn và chấp nhận rằng đôi khi team sẽ chọn một phương án khác với phương án mình thích.

Thế nên lần tới, khi có ai đó nhắn:

“Anh ơi, cái này làm thế nào ạ?”

Có lẽ chưa cần trả lời ngay.

Hãy thử kiểm tra xem team đang thiếu đáp án, hay thiếu quyền để tự tìm ra đáp án.