Mở đầu — vì sao bài này quan trọng
Trong một tech team, feedback (phản hồi) là dòng máu nuôi sống chất lượng công việc và mối quan hệ giữa các thành viên. Thế nhưng, đây cũng là kỹ năng bị né tránh nhiều nhất. Nhiều engineer giỏi về mặt kỹ thuật lại "đứng hình" khi phải nói với đồng nghiệp rằng cách họ trình bày demo hôm qua chưa ổn, hoặc khi phải tiếp nhận lời chê rằng code của mình khó đọc mà không cảm thấy bị tấn công cá nhân.
Vì sao khó đến vậy? Vì feedback chạm vào hai nỗi sợ nguyên thủy của con người: sợ làm tổn thương người khác (khi cho feedback) và sợ bị đánh giá thấp (khi nhận feedback). Ở môi trường công sở Việt Nam, nơi văn hóa "giữ hòa khí" và "sợ mất mặt" rất mạnh, hai nỗi sợ này còn được khuếch đại lên nhiều lần. Kết quả là feedback thường bị dồn nén cho đến kỳ đánh giá cuối năm, khi đã quá muộn để sửa; hoặc bị né tránh hoàn toàn, để rồi tích tụ thành mâu thuẫn ngầm.
Bài học này trang bị cho bạn một bộ khung tư duy và công cụ cụ thể để feedback trở thành một hành động bình thường, thường xuyên và mang tính xây dựng — chứ không phải một sự kiện căng thẳng. Chúng ta sẽ tập trung vào hai chiều: cho feedback (giving) một cách rõ ràng, tôn trọng và nhận feedback (receiving) một cách cởi mở, không phòng thủ. Đây là nền tảng để bạn xây dựng lòng tin trong đội, tăng tốc độ học hỏi và trở thành một người đồng nghiệp mà ai cũng muốn làm việc cùng.
Khái niệm cốt lõi
Feedback là món quà, không phải bản án
Điều đầu tiên cần thay đổi là tư duy (mindset). Feedback không phải là một phán quyết về giá trị con người bạn, mà là dữ liệu (data) về một hành vi cụ thể trong một hoàn cảnh cụ thể. Khi ai đó nói "phần API bạn viết thiếu tài liệu", họ không nói "bạn là engineer tồi". Họ đang trao cho bạn một thông tin để bạn tốt lên. Người cho feedback tốt luôn tách bạch giữa con người và hành vi.
Khung SBI: Situation — Behavior — Impact
Công cụ mạnh nhất và dễ áp dụng nhất để cho feedback là khung SBI, phát triển bởi Center for Creative Leadership. SBI buộc bạn mô tả sự việc một cách khách quan thay vì phán xét, gồm ba phần:
- Situation (Tình huống): Nêu chính xác thời điểm, bối cảnh. Ví dụ: "Trong buổi Sprint Review chiều thứ Ba vừa rồi..."
- Behavior (Hành vi): Mô tả hành vi quan sát được, cụ thể, không suy diễn động cơ. Ví dụ: "...bạn trình bày demo mà không chuẩn bị trước dữ liệu mẫu, nên phần thao tác live bị lỗi hai lần..."
- Impact (Tác động): Nêu tác động thực tế lên bạn, lên đội, hoặc lên kết quả. Ví dụ: "...điều đó khiến khách hàng bối rối và chúng ta mất khoảng 10 phút để giải thích lại tính năng."
- "Anh làm việc thiếu chuyên nghiệp." (nhãn dán, mơ hồ, gây phòng thủ)
- "Trong buổi Sprint Review thứ Ba (S), demo bị lỗi vì chưa chuẩn bị dữ liệu mẫu (B), khiến khách hàng bối rối và chúng ta mất 10 phút giải thích lại (I)." (cụ thể, có thể hành động)
Feedforward: hướng về tương lai
SBI dừng ở việc mô tả quá khứ. Để feedback thực sự hữu ích, hãy thêm một bước feedforward — cùng nhau đề xuất điều nên làm khác đi trong tương lai. Sau phần Impact, bạn có thể hỏi: "Lần tới, bạn nghĩ mình có thể chuẩn bị trước như thế nào?" Cách hỏi này biến feedback từ một chiều thành đối thoại, và trao quyền cho người nhận tự tìm giải pháp thay vì bị áp đặt.
Ba loại feedback: Appreciation, Coaching, Evaluation
Theo cuốn Thanks for the Feedback của Douglas Stone và Sheila Heen, có ba loại feedback khác nhau và hiểu lầm giữa chúng gây ra rất nhiều xung đột:
- Appreciation (Ghi nhận): "Cảm ơn bạn đã ở lại muộn fix bug production." Mục đích là động viên, kết nối.
- Coaching (Huấn luyện): "Đây là cách bạn có thể viết unit test gọn hơn." Mục đích là giúp người kia giỏi lên.
- Evaluation (Đánh giá): "Hiệu suất quý này của bạn ở mức đạt kỳ vọng." Mục đích là xếp hạng, so với một chuẩn.
Nhận feedback: mô hình 3 nỗi sợ kích hoạt (Triggers)
Khi nhận feedback, não bộ chúng ta thường bị "kích hoạt" (trigger) theo ba kiểu, làm ta phòng thủ:
- Truth trigger (Kích hoạt vì thấy sai): "Feedback này sai bét, người ta có hiểu gì đâu."
- Relationship trigger (Kích hoạt vì người nói): "Chính anh cũng đâu có giỏi mà đi dạy tôi."
- Identity trigger (Kích hoạt vì đụng cái tôi): "Nếu điều này đúng thì hóa ra tôi là kẻ vô dụng."
Tình huống thực tế
Tình huống 1: Feedback vòng vo tại một startup fintech ở TP.HCM
Minh là team lead tại một startup fintech khoảng 40 người ở Quận 1. Trong sprint vừa rồi, Hùng — một junior backend — liên tục merge code mà bỏ qua review, khiến production có hai sự cố nhỏ. Minh khó chịu nhưng ngại nói thẳng. Trong buổi standup, anh nói bâng quơ trước cả đội: "Mọi người nhớ tuân thủ quy trình review nhé, dạo này thấy hơi lỏng lẻo."
Kết quả: Hùng không nhận ra mình là người được nhắm tới, tiếp tục hành vi cũ. Còn ba thành viên khác vốn luôn review cẩn thận thì lại thấy bị oan và khó chịu vì bị "vơ đũa cả nắm".
Bài học rút ra: Feedback chung chung, gửi tới cả tập thể để tránh đối mặt cá nhân, gần như luôn thất bại. Người cần nghe thì không nhận ra, người không liên quan lại tổn thương. Đáng lẽ Minh nên gặp riêng Hùng và dùng SBI: "Trong sprint này (S), anh thấy có hai PR được merge thẳng lên main mà không qua review, dẫn tới hai lần rollback (B). Việc đó làm cả team mất niềm tin vào độ ổn định của nhánh main và tốn thời gian fix nóng (I). Lần tới mình thống nhất luôn chờ ít nhất một approve trước khi merge nhé?"
Tình huống 2: Nhận feedback trong code review tại một team outsourcing
Lan là mid-level developer tại một công ty outsourcing ở Đà Nẵng, làm dự án cho khách hàng Nhật. Trong một pull request, một senior reviewer để lại 15 comment, trong đó có câu: "Cách đặt tên biến này rất khó hiểu, và toàn bộ function nên được tách nhỏ."
Phản ứng đầu tiên của Lan là identity trigger: cô thấy bị chạm tự ái, nghĩ "mình code 3 năm rồi mà bị chê như junior". Cô định viết một comment dài để bảo vệ từng dòng code. Nhưng cô dừng lại, hít thở, và tự hỏi: "Bỏ qua cảm xúc, có bao nhiêu phần trong 15 comment này thực sự đúng?" Đọc lại, cô nhận ra 12/15 comment hoàn toàn hợp lý. Cô sửa 12 điểm đó, và với 3 điểm còn lại, cô trả lời lịch sự giải thích lý do thiết kế của mình để reviewer hiểu bối cảnh.
Sáu tháng sau, chính reviewer đó đề xuất Lan làm tech lead cho một module mới, vì đánh giá cao thái độ cầu thị của cô.
Bài học rút ra: Người nhận feedback giỏi không đo lường bản thân qua việc "mình đúng hay sai", mà qua việc "mình học được gì". Kỹ thuật tách cảm xúc ra khỏi nội dung — tạm dừng vài giây trước khi phản ứng — là kỹ năng có thể luyện được và tạo ra khác biệt lớn về mặt sự nghiệp.
Tình huống 3: Radical Candor bị hiểu sai tại một công ty product
Tại một công ty product khoảng 200 người, sau khi cả team đọc cuốn Radical Candor của Kim Scott, một engineering manager tên Sơn quyết định áp dụng nguyên tắc "thẳng thắn tuyệt đối". Anh bắt đầu chỉ trích công khai các quyết định kỹ thuật trong họp một cách gay gắt: "Cái thiết kế này dở tệ, ai nghĩ ra vậy?" Anh nghĩ mình đang "candid" (thẳng thắn).
Nhưng anh đã bỏ mất một nửa còn lại của mô hình. Radical Candor đòi hỏi đồng thời hai trục: Care Personally (thật lòng quan tâm đến người kia) và Challenge Directly (thẳng thắn thách thức). Sơn chỉ có trục thứ hai mà thiếu trục thứ nhất — đó không phải Radical Candor, mà là Obnoxious Aggression (hung hăng khó chịu). Cả team dần im lặng, không ai dám đưa ý tưởng mới, và hai người xin chuyển team trong vòng một quý.
Bài học rút ra: Thẳng thắn mà thiếu sự quan tâm chân thành thì chỉ là thô lỗ. Feedback hiệu quả phải làm người nhận cảm thấy "người này muốn mình tốt lên", chứ không phải "người này muốn hạ bệ mình". Trước khi cho một feedback khó, hãy tự hỏi: mình đang nói điều này để giúp họ, hay để xả cơn bực của mình?
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng ngay.
Khi CHO feedback:
- Chọn đúng thời điểm và không gian. Feedback tích cực (appreciation) có thể nói công khai để lan tỏa. Feedback mang tính sửa lỗi (coaching) thì gần như luôn nên nói riêng (1-on-1). Nói càng gần thời điểm sự việc xảy ra càng tốt, đừng để dồn đến cuối quý.
- Xin phép nếu cần. Một câu đơn giản như "Mình có vài quan sát về buổi demo hôm qua, bạn có sẵn sàng nghe không?" tạo tâm thế tiếp nhận, thay vì đẩy người kia vào thế bị động.
- Áp dụng SBI. Nêu Situation → Behavior → Impact một cách khách quan. Bám vào sự thật quan sát được, tránh từ ngữ phán xét như "luôn luôn", "chẳng bao giờ", "thiếu chuyên nghiệp".
- Thêm feedforward và lắng nghe. Hỏi ý kiến người kia và cùng đề xuất giải pháp cho lần sau. Đừng biến nó thành độc thoại.
- Kết thúc bằng sự hỗ trợ. "Mình có thể giúp gì để lần sau suôn sẻ hơn?" Điều này khẳng định bạn đứng cùng phía với họ.
- Lắng nghe hết trước khi phản ứng. Đừng ngắt lời để tự vệ. Mục tiêu ban đầu là hiểu, không phải đáp trả.
- Nhận diện trigger của mình. Tự hỏi: mình đang khó chịu vì thấy feedback sai (truth), vì ghét người nói (relationship), hay vì đụng cái tôi (identity)? Gọi tên nó ra sẽ hạ nhiệt phản ứng.
- Hỏi để làm rõ. "Bạn có thể cho mình một ví dụ cụ thể không?" Câu hỏi này vừa giúp bạn hiểu rõ hơn, vừa cho bạn thời gian bình tĩnh.
- Tìm hạt lúa trong đống trấu. Dù feedback được truyền đạt vụng về, hãy tách nội dung khỏi cách nói và tìm phần có giá trị.
- Cảm ơn và cam kết hành động. "Cảm ơn bạn đã nói thẳng, mình sẽ chú ý điểm này." Bạn không nhất thiết phải đồng ý 100%, nhưng luôn có thể cảm ơn thiện chí.
Lỗi thường gặp & mẹo
Lỗi 1 — "Feedback sandwich" máy móc. Nhiều người được dạy kẹp lời chê giữa hai lời khen (khen — chê — khen). Vấn đề là người nhận nhanh chóng nhận ra công thức và bắt đầu bỏ qua lời khen, chỉ chờ chữ "nhưng". Mẹo: Nói thẳng và tử tế, tách riêng lời ghi nhận thật lòng khỏi feedback sửa lỗi, đừng dùng khen như lớp vỏ bọc.
Lỗi 2 — Suy diễn động cơ. "Bạn cố tình bỏ qua review vì lười." Bạn không thể biết động cơ trong đầu người khác. Mẹo: Chỉ mô tả hành vi quan sát được (B trong SBI), để người kia tự giải thích lý do.
Lỗi 3 — Feedback lúc đang nóng giận. Cảm xúc mạnh biến feedback thành công kích. Mẹo: Nếu đang bực, hãy chờ vài giờ hoặc qua ngày hôm sau. Feedback nguội thường chính xác và tử tế hơn feedback nóng.
Lỗi 4 — Nhận feedback bằng phản xạ "Yes, but". Mỗi câu góp ý đều bị bạn phản bác lại. Điều này khiến người khác ngừng cho bạn feedback, và bạn mất đi kênh học hỏi quý giá. Mẹo: Tập nói "Để mình suy nghĩ thêm" thay vì phản bác ngay.
Lỗi 5 — Không đóng vòng (close the loop). Bạn nhận feedback rồi để đó, không thay đổi gì. Mẹo: Sau khi nhận feedback quan trọng, hãy chủ động cho người kia biết bạn đã hành động: "Lần trước bạn góp ý về việc mình viết PR quá lớn, sprint này mình đã chia nhỏ ra rồi đó." Đây là cách xây dựng lòng tin mạnh mẽ nhất.
Mẹo vàng — Chủ động xin feedback. Đừng chỉ chờ được nhận. Người phát triển nhanh nhất là người thường xuyên hỏi: "Có điều gì mình có thể làm tốt hơn không?" Câu hỏi cụ thể ("Phần trình bày của mình hôm nay có chỗ nào khó theo dõi không?") luôn hiệu quả hơn câu hỏi chung chung.
Bài tập thực hành
- Viết lại bằng SBI. Lấy một tình huống thật gần đây bạn thấy khó chịu với đồng nghiệp nhưng chưa nói ra. Viết feedback theo đúng cấu trúc Situation — Behavior — Impact, cộng thêm một câu feedforward. Đọc lại và loại bỏ mọi từ ngữ phán xét.
- Nhật ký trigger. Trong một tuần, mỗi lần bạn nhận feedback (kể cả trong code review), hãy ghi lại: mình có bị kích hoạt không, thuộc loại nào (truth/relationship/identity), và mình đã tìm ra được "hạt lúa" gì.
- Thực hành xin feedback. Chọn một đồng nghiệp bạn tin tưởng và hỏi họ một câu cụ thể về công việc của bạn tuần này. Ghi lại phản ứng cảm xúc của bạn và cách bạn xử lý nó.
- Phân loại feedback. Nhìn lại ba feedback gần nhất bạn đưa ra. Mỗi cái thuộc loại nào: Appreciation, Coaching hay Evaluation? Bạn có đang thiếu hụt loại nào không (đa số người thiếu Appreciation)?
Tóm tắt
Feedback là kỹ năng nền tảng của mọi tech team hiệu quả, và tin tốt là nó hoàn toàn có thể luyện được. Khi cho feedback, hãy dùng khung SBI (Situation — Behavior — Impact) để bám vào sự thật khách quan thay vì phán xét, thêm feedforward để hướng về giải pháp, và luôn xuất phát từ sự quan tâm chân thành (Care Personally) chứ không phải nhu cầu xả cảm xúc. Phân biệt ba loại feedback — Appreciation, Coaching, Evaluation — để khớp đúng kỳ vọng.
Khi nhận feedback, hãy nhận diện ba loại trigger (truth, relationship, identity) đang khiến bạn phòng thủ, tạm dừng phản ứng, và tìm cho được phần giá trị dù nhỏ. Đo bản thân qua việc "học được gì", không phải "đúng hay sai". Và quan trọng nhất: hãy đóng vòng — cho người cho feedback thấy bạn đã hành động, vì đó là cách xây lòng tin bền vững nhất.
Feedback không nên là sự kiện căng thẳng mỗi năm một lần. Khi nó trở thành thói quen nhỏ, thường xuyên và tử tế trong đội của bạn, chất lượng công việc lẫn mối quan hệ đều tăng lên — và bạn trở thành người đồng nghiệp mà ai cũng muốn cùng làm việc.