Tư duy (Mindset) khi làm Leader Bài 7: Nghệ thuật "Managing Up" - Trở thành API Gateway của đội ngũ

Nhiều Leader mắc sai lầm cực lớn là cố gắng làm "người tốt" với tất cả mọi người . Sếp giao gì cũng nhận, BA đổi yêu cầu giữa Sprint cũng gật đầu, hậu quả là team Tech ở dưới phải gánh khối lượng công việc khổng lồ, OT liên miên và sinh ra bất mãn .

Leader thực thụ phải là một API Gateway của team .

1. Nguyên tắc "Rate Limiting" - Bảo vệ team khỏi các yêu cầu rác

Giống như cách một API Gateway thiết lập Rate Limit (giới hạn request) để bảo vệ server Backend khỏi bị sập do DDoS, Leader phải biết chặn đứng hoặc điều hướng những yêu cầu "từ trên trời rơi xuống" .

• Tình huống: Giữa Sprint, sếp đi gặp đối tác về và hứng lên ném cho team một tính năng: "Cái này anh thấy hay, làm nhanh cho anh trong tuần này nhé!"
• Tư duy Leader yếu: "Vâng, để em bảo anh em cố gắng cày đêm." (Team sẽ oán hận bạn) .
• Tư duy Leader xuất sắc (API Gateway): Không từ chối thẳng thừng, nhưng yêu cầu đánh đổi (Trade-offs) . "Tính năng này rất tiềm năng sếp ạ. Nhưng băng thông (capacity) của team tuần này đã full. Nếu bắt buộc chèn tính năng này vào, sếp đồng ý cho em cắt tính năng A hoặc dời deadline của tính năng B sang tuần sau nhé. Sếp quyết định ưu tiên cái nào giúp em?"

Kết quả: Bạn đẩy quyền quyết định sự ưu tiên về lại cho cấp trên, bảo vệ được khối lượng công việc của team mà không mang tiếng là chống đối .

2. Quản trị Kỳ vọng - Thà thất vọng trước, còn hơn thất hứa sau

Có một cụm từ mà các Developer khi mới lên Leader rất hay dùng để xoa dịu sếp: "Em sẽ cố gắng". Đây là một cái bẫy chết người. Khi bạn nói "cố gắng", sếp mặc định là bạn "sẽ làm được" .

• Đừng cung cấp những lời hứa mơ hồ, hãy cung cấp SLAs (Cam kết chất lượng dịch vụ) .
• Thay vì nói: "Bọn em sẽ ráng xong hệ thống thanh toán sớm", hãy nói: "Dựa trên nguồn lực hiện tại, 15/4 team sẽ release bản Beta, 25/4 sẽ golive chính thức. Tỉ lệ rủi ro trễ hẹn là khoảng 10% do đang phụ thuộc API bên thứ 3."

Nguyên tắc: Under-promise and Over-deliver (Hứa ít, làm nhiều) . Hãy đưa ra một con số an toàn có buffer (thời gian dự phòng), nếu hoàn thành sớm, bạn là anh hùng . Nếu hứa sớm mà trễ hạn, bạn là kẻ thất bại .

3. Bán "Tech Debt" cho Business - Dịch kỹ thuật ra tiền

Team Tech luôn muốn đập đi viết lại (Refactor), nâng cấp thư viện, viết thêm Unit Test . Nhưng Sếp và PO thì không quan tâm đến "Clean Code" hay "Microservices" . Họ chỉ quan tâm đến tốc độ ra mắt tính năng và doanh thu .

Làm sao để xin được thời gian làm Tech Debt mà sếp vẫn vui vẻ duyệt? Hãy dịch nó sang bài toán rủi ro và chi phí .

• Cách nói sai: "Sếp ơi cho team 1 tuần để refactor lại core module, code cũ anh X viết bốc mùi quá rồi, khó maintain lắm." (Sếp sẽ từ chối vì thấy không mang lại lợi ích kinh doanh) .
• Cách nói đúng: "Sếp ơi, luồng dữ liệu hiện tại đang có nguy cơ nghên (bottleneck) nếu lượng user tăng gấp đôi trong chiến dịch tháng sau. Tháng trước hệ thống từng rớt mạng 30 phút vì lỗi này, ước tính công ty mất khoảng X triệu. Em đề xuất Sprint này trích ra 20% thời gian để đưa hàng đợi (Message Queue) vào xử lý. Nó giống như việc mở rộng đường ống trước khi bơm nước mạnh hơn, giúp đảm bảo server không sập lúc sale lớn."

📝 Bài tập thực hành cho Bài 7 (Trong tuần này)

1. Khung giao tiếp "Yes, and..." (Vâng, và...): Trong tuần này, nếu có bất kỳ ai (sếp, PO, hay phòng ban khác) nhờ bạn một việc đột xuất hoặc thay đổi yêu cầu, tuyệt đối không nói "Không" . Hãy tập nói: "Okay em làm được, VÀ để làm được việc này thì em sẽ cần đánh đổi..." (Đưa ra điều kiện về thời gian, nhân sự, hoặc tính năng bị cắt giảm) .
2. Pitching 1 bài toán kỹ thuật: Hãy chọn 1 vấn đề kỹ thuật (Tech Debt) bạn rất muốn sửa trong hệ thống (ví dụ: tối ưu lại database index, dọn dẹp các API cũ không dùng) . Viết ra 3 dòng để "bán" ý tưởng này cho sếp, tập trung hoàn toàn vào 1 trong 3 yếu tố :
   • (1) Tiết kiệm chi phí server
   • (2) Giảm rủi ro sập hệ thống/mất data
   • (3) Tăng tốc độ phát triển tính năng mới sau này .

Bí quyết: Quản trị cấp trên không phải là xu nịnh . Đó là khả năng cung cấp cho họ bức tranh thực tế, những lựa chọn rõ ràng và hậu quả của từng lựa chọn, để họ có thể đưa ra quyết định kinh doanh chính xác nhất . Đứng mũi chịu sào, bảo vệ anh em tech mới chính là cốt cách của người làm tướng .