Yêu cầu đến gần cuối ngày, đúng lúc mọi người đang đóng tab và nhìn lại checklist release. Nó nghe nhỏ theo cách nhiều yêu cầu rủi ro thường nghe rất nhỏ lúc đầu: "Mình thêm cái này trước ngày mai được không?" Có thể chỉ là một field trên form, một nút export, hoặc một edge case ai đó vừa nhớ ra. Cả phòng đã mệt. Ai cũng muốn hữu ích. Phiên bản trẻ hơn của mình có lẽ đã nói có rất nhanh, một phần vì lạc quan, một phần vì sợ bị xem là khó chịu.
Developer thường được rèn để giải quyết, không phải từ chối. Ta thích tìm đường trong ràng buộc. Ta thích hữu ích. Ở nhiều team, người nói có được xem là hợp tác, còn người dừng lại một chút dễ bị nghi là làm chậm. Thế là ta nhận thêm một task, rồi thêm một ngoại lệ, rồi thêm một thay đổi khẩn, cho đến khi công việc không còn trung thực về thời gian, chất lượng hay sự chú ý.
Học nói không không phải học tiêu cực. Nó là học bảo vệ điều kiện để một lời có thật sự có nghĩa. Một lời có che rủi ro không phải lòng tốt. Một lời có đòi overtime im lặng, bỏ qua testing, ownership mơ hồ hoặc release vội không phải lúc nào cũng là teamwork. Đôi khi nó chỉ là vấn đề bị trì hoãn trong vẻ ngoài thân thiện.
Bước đầu là thay từ chối bằng ngôn ngữ tradeoff. "Không" dễ được nghe hơn khi nó giải thích điều đang được bảo vệ. Mình có thể làm việc này ngày mai, nhưng nghĩa là dời task reporting. Mình có thể đưa vào release, nhưng nên bỏ một thay đổi khác hoặc chấp nhận test pass hẹp hơn. Mình có thể prototype hôm nay, nhưng chưa thể productionize an toàn hôm nay.
Bước thứ hai là tách khẩn cấp khỏi quan trọng. Có việc thật sự khẩn: production down, customer bị chặn, yêu cầu pháp lý đổi, security issue cần xử lý. Có việc chỉ khẩn cấp về cảm xúc vì ai đó vừa nhìn thấy, vì một cuộc họp tạo áp lực, hoặc vì trì hoãn làm mọi người khó chịu. Developer không cần phủ nhận áp lực đó, nhưng nên giúp team gọi tên nó đúng.
Bước thứ ba là đưa ra lựa chọn thay thế hữu ích. Một chữ không phẳng có thể đóng cửa. Một chữ không tử tế có thể mở cửa tốt hơn. "Không trong release này, nhưng mình có thể viết technical note và estimate đường đúng." "Không như custom exception, nhưng sprint sau mình có thể giải rule gốc." "Không với API shape này, nhưng đây là phiên bản nhỏ hơn giữ mình an toàn."
Nói không cũng cần niềm tin vào judgment kỹ thuật của chính mình. Điều này cần thời gian. Đầu sự nghiệp, ta dễ nghĩ senior, product hoặc manager đang thấy bức tranh đầy đủ hơn mình. Đôi khi đúng. Nhưng đôi khi họ thiếu chi phí implementation mà chỉ bạn thấy từ bên trong codebase. Việc của bạn không phải phủ quyết mọi người. Việc của bạn là thêm sự thật bạn đứng gần nhất.
Mình học được rằng chữ không tốt nhất thường bình tĩnh, cụ thể và sớm. Bình tĩnh vì hoảng làm người khác phòng thủ. Cụ thể vì chống đối mơ hồ nghe giống sở thích. Sớm vì chữ không muộn cảm giác như phản bội, dù về kỹ thuật nó đúng. Rủi ro được gọi tên càng sớm, team càng còn nhiều lựa chọn.
Có một sự trưởng thành lặng lẽ trong câu: mình muốn giúp, và phiên bản kế hoạch này sẽ làm mình đau về sau. Câu đó giữ cả sự quan tâm lẫn boundary. Nó từ chối lựa chọn giả giữa hợp tác và trung thực. Trong team tốt, kiểu không đó trở thành một dạng đáng tin. Mọi người học rằng khi bạn nói có, bạn thật sự có nghĩa là có.
Có một câu mình vẫn giữ lại: mình có thể giúp với mục tiêu này, nhưng không an toàn trong hình dạng kế hoạch hiện tại. Câu đó vẫn mở cửa cho cộng tác, nhưng làm ràng buộc đủ rõ để mọi người cùng xử lý.