Phòng họp đã trống, nhưng câu nói lúc nãy vẫn còn lơ lửng trong không khí. Một pull request mất thêm ba vòng review so với dự kiến, và cuộc trao đổi trong comment thread đã sắc đến mức hai người gần như không nói với nhau suốt phần còn lại của buổi chiều. Ai cũng biết cần feedback. Không ai muốn nói theo cách làm lần review sau còn khó hơn.
Feedback khó là khó vì hai điều cùng đúng một lúc. Công việc cần sự trung thực, và con người cần dignity. Nếu chỉ bảo vệ sự dễ chịu, behavior sẽ lặp lại. Nếu chỉ bảo vệ cái đúng, trust bị mòn. Một kịch bản bình tĩnh hữu ích vì nó cho cuộc trò chuyện một con đường trước khi cảm xúc tự vẽ bản đồ riêng.
Phần đầu tiên của kịch bản xảy ra trước cuộc nói chuyện. Hãy viết xuống behavior, impact và next step mong muốn. Behavior là thứ quan sát được: review comment đã nói thế này, ticket thiếu acceptance criterion này, deployment note không có rollback. Impact là vì sao điều đó quan trọng: reviewer phải tự dựng lại context, QA test nhầm path, support không có câu trả lời. Next step là điều sẽ làm tình huống tốt hơn: thêm ví dụ, hỏi sớm hơn, chia nhỏ change, xác nhận ownership.
Sự chuẩn bị đó quan trọng vì feedback mơ hồ rất nhanh thành cá nhân. “Bạn cẩu thả” khiến người nghe phải phòng thủ cho identity của họ. “Migration note chưa nói rollback path, nên reviewer không đánh giá được release risk” cho cả hai người một chỗ cụ thể để làm việc. Mục tiêu không phải làm sự thật mềm đi đến mức biến mất. Mục tiêu là làm sự thật đủ cụ thể để có thể hành động.
Thử đi theo câu này: Tôi nhận thấy behavior này. Impact là thế này. Tôi muốn hiểu phía bạn đã xảy ra điều gì. Lần sau, tôi cần adjustment cụ thể này.
Cuộc trò chuyện có thể bắt đầu nhẹ mà không mơ hồ. “Tôi muốn nói về buổi review hôm qua vì tôi nghĩ lần sau mình có thể làm nó dễ hơn.” Câu này gọi tên chủ đề và ý định. Nó không giả vờ như không có gì xảy ra, và cũng không mở đầu bằng một bản án. Người kia vẫn có thể thấy khó chịu. Điều đó bình thường. Feedback không tử tế hơn bằng cách xóa hết discomfort. Nó tử tế hơn khi giữ discomfort gắn với một mục đích công bằng.
Sau khi gọi tên behavior và impact, hãy để chỗ cho context. “Từ phía bạn lúc đó đang có chuyện gì?” không phải câu hỏi bẫy. Có thể người kia bị deadline ép. Có thể requirement đổi trong một cuộc nói chuyện bên lề. Có thể họ chưa biết standard. Context không xóa impact, nhưng nó có thể đổi next step. Skill gap, priority conflict và trust problem cần cách xử lý khác nhau.
Một lỗi thường gặp là cố thắng cuộc trò chuyện. Feedback không phải tòa án. Nếu người kia phòng thủ, lặp lại bằng chứng to hơn hiếm khi giúp. Hãy hạ mức cược đủ để họ quay lại cuộc trò chuyện. “Tôi không nghi ngờ intent của bạn. Tôi đang nói về effect việc này tạo ra cho team.” Câu đó tách character khỏi behavior. Nó cho người nghe một lối vào để lắng nghe mà không cảm thấy cả con người mình bị xét xử.
Phần kết nên thực tế. Thống nhất behavior tiếp theo có thể nhìn thấy được. Ví dụ: pull request lớn lần sau có risk section ngắn; review căng lần sau chuyển sang call trước khi comment thread dài thêm; estimate lần sau ghi assumption; handoff lần sau có owner, status và open questions. Một cuộc feedback không có next behavior thường chỉ là dọn cảm xúc, không phải improvement.
Follow-up quan trọng hơn câu chữ hoàn hảo. Nếu người kia điều chỉnh, hãy ghi nhận. Nếu pattern lặp lại, quay về behavior cụ thể thay vì bắt đầu lại từ bực bội. Trust lớn lên khi feedback nhất quán, đúng mức và gắn với công việc. Con người chịu được sự thật khó tốt hơn khi họ thấy standard ổn định và căn phòng không cố làm họ mất mặt.
Tôi cố nhớ rằng feedback khó là một phần của sự chăm sóc dành cho team. Nó bảo vệ codebase, customer, reviewer và cả người nhận feedback khỏi một pattern có thể đắt hơn về sau. Phiên bản bình tĩnh không mềm yếu. Nó có kỷ luật. Nó nói thật đủ rõ để một người có thể thay đổi, và đủ tôn trọng để họ vẫn muốn thay đổi. Nếu bạn từng nhận một feedback giúp mình mở ra thay vì đóng lại, điều gì đã làm nó dễ nghe hơn?