Có những buổi họp roadmap mà người nói ít nhất trong phòng lại là người giữ cho cả phòng không đi lạc. Designer muốn thêm trải nghiệm mới, engineering lo technical debt, sales nhắc đến lời hứa với khách hàng, support đem vào vài complaint vừa nhận sáng nay. Ai cũng có lý. Nếu không có một người bình tĩnh kéo câu chuyện về câu hỏi ban đầu, team rất dễ biến một buổi planning thành một cái chợ ý tưởng.
Đọc tư liệu về Đường Tăng trong Tây Du Ký, mình thấy nhân vật này thú vị hơn hình ảnh quen thuộc là yếu đuối và hay bị bắt. Nếu nhìn bằng lăng kính công sở, Đường Tăng không phải người giỏi đánh nhau nhất, không phải người xử lý incident nhanh nhất, cũng không phải người biết mọi đường đi nước bước. Nhưng ông là người giữ mục tiêu cuối cùng. Trong một project dài, đôi khi đó là năng lực ít hào nhoáng nhưng rất khó thay thế.
Ở văn phòng, một leader không nhất thiết phải là người code tốt nhất, bán hàng giỏi nhất, thiết kế đẹp nhất, hoặc hiểu từng chi tiết vận hành hơn mọi người. Nếu họ tự nhận mình giỏi hết, team sẽ rất dễ ngột ngạt. Nhưng nếu họ không giữ được hướng, team lại càng rối. Một product team có nhiều người giỏi mà không có mục tiêu chung rõ ràng giống như ai cũng cầm vô lăng một chút. Xe vẫn chạy, nhưng mỗi đoạn lại bị kéo sang một hướng.
Điều mình học được từ hình ảnh Đường Tăng là sự kiên định của người giữ mission. Khi team mệt, người này nhắc lại tại sao việc này đáng làm. Khi có quá nhiều lựa chọn, người này giúp cắt bớt cái hấp dẫn nhưng lệch hướng. Khi một khách hàng lớn đòi một custom feature có thể phá roadmap, người này cần đủ bình tĩnh để hỏi: nó có phục vụ hướng đi dài hạn không, hay chỉ làm mình đỡ khó xử trong tuần này?
Tư liệu cũng nhắc tới ba việc rất công sở: thấu hiểu năng lực, trao quyền và tin tưởng có kiểm tra. Đường Tăng biết Ngộ Không xử lý khủng hoảng, Bát Giới phù hợp hơn với những việc cần giao tiếp, Sa Tăng giữ nhịp ổn định, còn Bạch Long Mã là phần hạ tầng âm thầm. Trong team hiện đại cũng vậy. Có người giỏi mở đường, có người giỏi giữ quality, có người giỏi làm stakeholder bớt căng, có người giỏi vận hành đều đặn mà không gây tiếng vang. Giao việc không dựa trên thế mạnh thật là cách rất nhanh để làm một người tốt trở nên tệ trong mắt team.
Mình từng thấy những tình huống rất nhỏ nhưng giống bài học này. Một bạn engineer rất giỏi debug production nhưng lại bị giao viết tài liệu onboarding dài, rồi mọi người thất vọng vì tài liệu khô. Một bạn giao tiếp tốt bị ép làm owner của quyết định kiến trúc sâu, rồi phải phụ thuộc vào người khác ở từng bước. Một bạn QA nhìn edge case rất sắc nhưng chỉ được gọi vào cuối sprint, khi mọi thứ gần như đã đóng. Nhiều khi vấn đề không nằm ở con người không đủ giỏi, mà ở việc đặt họ sai chỗ.
Trao quyền cũng không có nghĩa là buông tay. Trong công sở, nếu giao cho lead engineer xử lý một incident, manager không nên đứng sau chỉ từng câu lệnh. Nhưng manager vẫn cần biết tình hình: impact tới khách hàng nào, rollback plan ra sao, ai đang thông báo cho stakeholder, sau incident có postmortem không. Tin tưởng không phải là không hỏi. Tin tưởng là hỏi để giữ hệ thống an toàn, không hỏi để chứng minh mình mới là người kiểm soát.
Điểm khó là leader phải biết khi nào bảo vệ người giỏi, khi nào giữ kỷ luật chung. Một star performer có thể cứu team nhiều lần, nhưng nếu họ liên tục làm người khác sợ góp ý, bỏ qua process, hoặc xử lý vấn đề bằng cách làm team khác tổn thương, thì tài năng bắt đầu tạo nợ. Đường Tăng nhiều lần cần Ngộ Không, nhưng vẫn có ranh giới về điều gì được phép và không được phép. Công sở cũng vậy: cảm ơn người giỏi không có nghĩa là cho họ đứng ngoài giá trị chung.
Ghi chép này làm mình nghĩ rằng một leader giữ vision không phải người lúc nào cũng nói những câu lớn lao. Đôi khi họ chỉ là người trong một buổi họp căng thẳng biết nhắc: mục tiêu của mình là gì, ai đang phù hợp nhất để xử lý phần nào, phần nào cần trao quyền, phần nào cần kiểm tra, và ranh giới nào không nên vượt qua dù áp lực lớn. Nếu một team đang đi qua một chặng dài, có lẽ điều họ cần không chỉ là thêm người giỏi, mà là một người đủ bình tĩnh để giữ cho người giỏi đi cùng một hướng.