Tình huống thực tế
Bạn đang là Tech Lead trong một sprint review. Một junior developer vừa demo tính năng — code chạy được nhưng có vài chỗ cần cải thiện về performance và cách đặt tên biến. Bạn cần give feedback sao cho người kia không tự ái, nhưng vẫn rõ ràng về những gì cần sửa.
Hoặc ngược lại: sếp bạn vừa góp ý về một technical decision của bạn trong buổi architecture review. Bạn không đồng ý một phần — làm sao respond mà vẫn professional?
Đây là hai kỹ năng người đi làm tech cần mỗi tuần, nhưng ít ai được dạy bài bản.
Câu mẫu hay dùng
🟢 Khi bạn GIVE feedback (góp ý cho người khác)
1. Bắt đầu bằng điểm tích cực — nhưng đừng giả tạo
“This is a solid first pass. The logic is clear and the tests cover the main cases.”
Giải thích: “solid first pass” = cố gắng tốt cho lần đầu. Không quá khen, không hạ thấp. Dùng khi bạn thật sự thấy có điểm tốt để khen.
2. Đưa ra vấn đề không mang tính tấn công cá nhân
“I’m wondering if we could rename this variable to make the intent clearer — something like
userSessionTokeninstead ofdata.”
Giải thích: “I’m wondering if…” nghe như đề xuất, không phải lệnh. Phù hợp khi bạn muốn người kia suy nghĩ cùng, không bị defensive.
3. Khi vấn đề nghiêm trọng hơn, cần direct hơn
“This approach works for now, but it won’t scale once we hit 10k concurrent users. Can we revisit the caching strategy before we merge?”
Giải thích: Đưa lý do kỹ thuật cụ thể trước, rồi mới đề nghị hành động. Không có “bạn sai” — chỉ có “vấn đề là X, nên làm Y.”
4. Kết feedback bằng câu mở
“Happy to pair on this if it’s helpful — let me know what you think.”
Giải thích: “Pair on this” = cùng ngồi làm (pair programming). Câu này cho thấy bạn sẵn sàng hỗ trợ, không chỉ phê bình.
🔵 Khi bạn RECEIVE feedback (nhận góp ý từ người khác)
5. Acknowledge trước khi phản hồi
“That’s a fair point — I hadn’t considered the impact on the mobile clients.”
Giải thích: “That’s a fair point” = mình công nhận điều này hợp lý. Không có nghĩa là bạn sai hoàn toàn — chỉ là bạn nghe và ghi nhận.
6. Khi bạn không đồng ý — cách nói để không tạo conflict
“I see where you’re coming from. My concern with that approach is the additional latency it introduces. Could we explore a middle ground?”
Giải thích: “I see where you’re coming from” = tôi hiểu góc nhìn của bạn. Sau đó nêu concern cụ thể, rồi đề nghị tìm giải pháp chung. Tránh nói “But I think…” ngay — nghe rất defensive.
7. Khi cần thêm thời gian để suy nghĩ
“That’s something I’d like to think through more carefully. Can we circle back on this after standup tomorrow?”
Giải thích: “Circle back” = quay lại chủ đề này sau. Dùng khi bạn không muốn quyết định vội, tránh bị đẩy vào góc.
8. Khi bạn nhận feedback từ performance review
“Thank you for being direct about this. I’d appreciate any specific examples so I can focus on improving the right areas.”
Giải thích: Câu này vừa lịch sự, vừa professional, vừa cho thấy bạn muốn grow — không phải chỉ nghe cho có.
Sắc thái quan trọng
Formal vs Informal
| Tình huống | Nên dùng | Tránh dùng |
|---|---|---|
| Code review comment trên GitHub | ”Consider extracting this into a separate method" | "This is messy, fix it” |
| Slack với đồng nghiệp thân | ”Hey, quick thought — this might cause issues if X happens 🤔" | "That approach is wrong” |
| 1-on-1 với junior của bạn | ”I noticed a pattern in your recent PRs I wanted to talk about…" | "You always do this” |
| Performance review với sếp | ”I’d welcome more specific feedback on how I can improve in this area" | "I don’t agree with that assessment” |
⚠️ Những lỗi hay gặp
Lỗi 1: “But why did you do it this way?” → Nghe như accusation. Thay bằng: “What was the thinking behind this approach?”
Lỗi 2: “That’s wrong.” → Quá blunt trong văn hóa tech Việt Nam khi nói với đồng nghiệp ngang hàng. Thay bằng: “I think there might be an edge case here — what happens if…?”
Lỗi 3: Không confirm lại feedback → Sau khi nhận feedback, nên nói: “So just to make sure I understand — you’d like me to [X], is that right?” Tránh về làm sai rồi lại phải sửa.
Lỗi 4: Dùng “you” quá nhiều khi criticize → Shift từ “you didn’t handle the error” sang “the error handling here could be more robust.” Nói về code, không nói về người.
Luyện tập nhanh
Hãy viết lại các câu sau theo cách professional hơn:
1. “Your code is hard to read.”
Gợi ý
“I found this section a bit tricky to follow — adding a comment here explaining the intent would really help future readers.”
2. “I don’t think your idea will work.”
Gợi ý
“I have some concerns about scalability with this approach — can you walk me through how it handles peak load?”
3. Bạn nhận được feedback: “You’re not communicating enough with the team.” Viết câu response.
Gợi ý
“That’s helpful to know. Could you share a specific example so I can understand what better communication looks like in practice?”
Câu gợi nhớ
“Attack the problem, not the person.” (Tấn công vấn đề, không tấn công con người.)
Mỗi khi bạn sắp nói một câu feedback, hãy hỏi: “Câu này tôi đang nhắm vào code/behavior/vấn đề — hay đang nhắm vào người?” Nếu nhắm vào người, viết lại.
Bài tiếp theo: Cách viết email escalate vấn đề mà không mất lòng ai — từ delay ticket đến báo cáo risk cho stakeholder.