Kênh deployment im lặng vài giây sau khi bản fix được merge. Production issue đã mở gần cả buổi chiều, khách hàng đang chờ, và một engineer tìm ra điều kiện bị thiếu nhanh hơn tất cả mọi người. Release chạy tiếp. Dashboard hồi lại. Một người gửi lời cảm ơn ngắn. Rồi những tin nhắn nhỏ hơn bắt đầu đi riêng: review đã bị bỏ qua, hai người thấy mình bị gạt khỏi cuộc gọi, và một junior engineer từng tìm ra manh mối sớm hơn nói rằng lần sau chắc bạn ấy sẽ im lặng.
Đó là hình dạng khó chịu phía sau cụm từ toxic rockstar. Mình không thích cụm từ này lắm, vì nó dễ biến một con người thành một nhãn dán và làm một vấn đề quản lý phức tạp nghe như phán xét tính cách. Nhưng pattern mà nó chỉ tới là có thật. Có những người tạo ra rất nhiều output nhìn thấy được, trong khi để lại phần hư hại khó đo hơn: niềm tin mỏng đi, feedback đến muộn hơn, những người ít nói rút lại, và team bắt đầu trả một loại thuế cộng tác cho mọi quyết định quan trọng.
Điều làm mọi chuyện rối là phần việc của người đó có thể thật sự mạnh. Họ debug nhanh, hiểu codebase sâu, cứu release, và giữ nhiều context mà người khác vẫn cần. Vì vậy team chần chừ. Thách thức một người ship tốt nghe có vẻ lãng phí. Làm phật lòng người biết các phần mong manh của hệ thống nghe có vẻ rủi ro. Thế là tổ chức lặng lẽ chấp nhận một giao kèo: output cao đổi lấy hành vi khó chịu. Vấn đề là giao kèo đó thường đắt lên sau mỗi tháng.
Hành vi gây hại của một người high-output thường làm team hỏng theo đường vòng. Mọi người bớt hỏi vì câu hỏi bị xem là chậm. Code review thành hình thức vì bất đồng quá mệt. Quyết định kiến trúc chuyển sang các cuộc nói chuyện riêng vì căn phòng chung không còn an toàn. Incident trở thành sân khấu thể hiện thay vì một learning loop. Nhìn từ xa, team vẫn có vẻ năng suất. Nhìn gần, luồng thông tin đang hẹp lại.
Chính sự hẹp lại đó mới là rủi ro thật. Engineering team sống nhờ các tín hiệu sớm: một lo ngại chưa thành hình trong planning, một câu hỏi hơi ngại của junior, một reviewer nói abstraction này chưa rõ, một on-call engineer thừa nhận mình chưa chắc. Khi một người có status cao liên tục trừng phạt các tín hiệu đó, team không chỉ mất sự tử tế. Team mất dữ liệu. Bug tiếp theo sẽ xuất hiện muộn hơn, với ít người dám gọi tên nó sớm hơn.
Manager thường cũng là một phần của hệ thống, kể cả khi họ không thích hành vi đó. Ta thưởng cho người cứu release rõ ràng hơn những người làm release sau bình tĩnh hơn. Ta khen tốc độ mà không hỏi ai phải dọn phần còn lại. Ta ghi nhận ownership trong promotion nhưng bỏ qua chuyện ownership đó có biến thành một vương quốc riêng không. Ta viết collaboration trong tài liệu giá trị, rồi chấp nhận điều ngược lại khi metrics trông vẫn đủ ổn.
Bước hữu ích đầu tiên là làm mọi thứ cụ thể. Thay vì nói một người toxic, hãy gọi tên hành vi quan sát được và tác động của nó. Trong design review hôm qua, người đó ngắt lời ba lần trước khi proposal được giải thích xong. Trong hai incident gần nhất, người đó merge thẳng vào main mà không có reviewer thứ hai. Trong planning, người đó gọi một lo ngại là hiển nhiên và teammate kia ngừng góp ý. Sự cụ thể bảo vệ cả hai phía: người nhận feedback có thứ thật để nhìn lại, và team bớt giấu sự bực bội mơ hồ sau một nhãn quá nặng.
Bước thứ hai là tách đường sửa khỏi sự cho phép. Đường sửa nói rằng hành vi có thể thay đổi và team sẽ nói rõ phiên bản tốt hơn trông như thế nào. Sự cho phép nói rằng vì bạn có giá trị, tiêu chuẩn này không áp dụng cho bạn. Hai điều đó rất khác nhau. Một team lành mạnh có thể đưa feedback thẳng, coaching và thời gian để cải thiện, trong khi vẫn đặt những boundary không thương lượng: không làm người khác mất mặt công khai, không bỏ qua review khi không phải emergency, không biến hệ thống chung thành tài sản riêng, không trả đũa khi người khác bất đồng.
Boundary cần xuất hiện trong cách team làm việc, không chỉ trong một cuộc nói chuyện riêng. Nếu review là bắt buộc, tooling và release process nên làm việc bypass trở nên nhìn thấy được. Nếu incident review là blameless, facilitator cần chặn blame ngay trong phòng, chứ không xin lỗi sau đó. Nếu một người giữ quá nhiều context quan trọng, team cần pairing, documentation và rotation cho tới khi hệ thống không còn phụ thuộc vào một trí nhớ duy nhất. Culture đổi khi đường mặc định đổi.
Cũng cần bảo vệ những người đứng quanh pattern đó. Leader đôi khi dành hết năng lượng để quản lý người high performer khó tính và quên những teammate đã gánh chi phí. Những teammate đó cần tín hiệu rõ ràng rằng việc nói ra không phải là một sai lầm nghề nghiệp. Họ cần phần đóng góp được nhìn thấy, lo ngại được theo tới cùng, và boundary của họ được tôn trọng. Nếu không, team sẽ học bài học lặng lẽ: tiêu chuẩn chính thức là collaboration, nhưng tiêu chuẩn thật là người có giá trị nhất được phép đi xa tới đâu.
Không điều nào trong này đòi hỏi biến người high-output thành phản diện. Nhiều người học các pattern thô ráp trong môi trường từng thưởng cho việc cứu nguy, tốc độ, sự chắc chắn và cảm giác không thể thay thế. Có người bất ngờ khi lần đầu nghe rõ impact. Có người sửa rất tốt khi feedback đủ cụ thể và boundary đủ nhất quán. Có người thì không. Việc của leader không phải là dự đoán tính cách của một người mãi mãi. Việc cần làm là làm impact hiện tại trở nên nhìn thấy được và quyết định team có thể chịu trách nhiệm tới đâu trong khi việc sửa đang được thử.
Một engineer rất giỏi nhưng làm mòn trust không phải là lợi thế của team. Đó là một tối ưu cục bộ với chi phí hệ thống đang lớn dần. Mục tiêu không phải là trừng phạt sự xuất sắc hay bắt mọi người dịu dàng như nhau. Mục tiêu là giữ tiêu chuẩn cao bao gồm cả cách công việc đi qua con người, không chỉ thứ cuối cùng được merge. Nếu bạn từng thấy pattern này từ bên trong, mình rất muốn nghe điều gì đã giúp team gọi tên hành vi mà không đánh mất con người, và boundary nào cuối cùng đã trở nên rõ ràng.