Mở đầu — vì sao bài này quan trọng
Nếu bạn hỏi mười tech lead rằng kỹ năng nào họ ước mình học sớm hơn, ít nhất bảy người sẽ trả lời: cho và nhận feedback. Không phải vì nó nghe "sang", mà vì nó là công cụ đòn bẩy lớn nhất bạn có để thay đổi hành vi của người khác — và của chính mình — mà không cần quyền lực chính thức.
Với một tech lead, quyền hạn thường mờ nhạt. Bạn không ký lương, không quyết thăng chức, đôi khi những người bạn "dẫn dắt" còn senior hơn bạn về tuổi nghề. Thứ duy nhất khiến người ta điều chỉnh cách làm việc là chất lượng thông tin bạn phản hồi lại cho họ, và mức độ họ tin rằng bạn nói vì muốn họ tốt lên. Feedback tồi làm hỏng cả hai: thông tin sai lệch và niềm tin sứt mẻ.
Ở Việt Nam, chủ đề này còn nhạy cảm hơn. Văn hóa "giữ thể diện" khiến nhiều người ngại nói thẳng, sợ làm mất lòng, nên feedback bị nén lại đến khi thành cơn giận, hoặc bị bọc trong quá nhiều lời khen đến mức người nghe không hiểu vấn đề. Ngược lại, một số leader lại nhầm "thẳng thắn" với "cộc cằn", buông những câu như "code kiểu này không ổn đâu em" mà không ai học được gì. Bài này cho bạn một khung cụ thể — SBI model — cùng cách nhận feedback không phòng thủ, để feedback trở thành thói quen hằng ngày chứ không phải sự kiện đáng sợ mỗi kỳ review.
Khái niệm cốt lõi
Feedback là dữ liệu, không phải phán xét
Điểm gốc rễ cần thay đổi trong đầu bạn: feedback không phải để "chấm điểm" con người, mà để cung cấp dữ liệu giúp họ điều chỉnh. Khi bạn nói "em cẩu thả quá", bạn đang dán nhãn tính cách — một thứ người ta khó thay đổi và dễ phản kháng. Khi bạn nói "trong PR hôm qua có ba chỗ thiếu test cho edge case", bạn đưa ra dữ liệu — một thứ có thể hành động ngay.
Feedback tốt có hai loại, và cả hai đều cần thiết:
- Reinforcing feedback (củng cố): chỉ ra hành vi tốt để người ta lặp lại. Đây là loại bị bỏ quên nhiều nhất. Nhiều leader chỉ mở miệng khi có vấn đề, khiến nhân viên mặc định "sếp gọi tên là có chuyện".
- Redirecting feedback (điều chỉnh): chỉ ra hành vi cần thay đổi. Đây là loại người ta sợ đưa ra, và cũng là loại bài này tập trung giúp bạn làm cho đúng.
SBI Model — xương sống của một feedback rõ ràng
SBI là viết tắt của Situation – Behavior – Impact, được phát triển bởi Center for Creative Leadership. Nó buộc bạn tách bạch ba tầng thông tin mà người ta thường trộn lẫn.
S — Situation (Bối cảnh cụ thể). Neo feedback vào một thời điểm, một sự kiện cụ thể: "Trong buổi standup sáng thứ Ba", "Ở PR #482 tối qua". Bối cảnh cụ thể làm hai việc: giúp người nghe nhớ lại chính xác khoảnh khắc đó, và ngăn feedback trượt sang khái quát hóa nguy hiểm ("lúc nào em cũng...", "chẳng bao giờ em..."). Chữ "lúc nào" và "chẳng bao giờ" gần như luôn là dấu hiệu của feedback tồi.
B — Behavior (Hành vi quan sát được). Mô tả điều bạn thấy và nghe, không phải điều bạn suy diễn. Đây là phần khó nhất và quan trọng nhất. "Em ngắt lời chị Lan ba lần trong buổi họp" là hành vi. "Em không tôn trọng chị Lan" là suy diễn về ý định (intent). Bạn không bao giờ biết chắc ý định của người khác — có thể họ hào hứng, có thể họ lo lắng, có thể họ nghĩ mình đang giúp. Khi bạn gán ý định, người nghe sẽ ngay lập tức phản bác ("em có ý đó đâu"), và cuộc trò chuyện chuyển từ hành vi sang tranh cãi về động cơ — nơi không ai thắng.
I — Impact (Tác động). Nói rõ hành vi đó tạo ra tác động gì tới bạn, tới người khác, tới dự án. "Vì thế chị Lan im lặng suốt phần còn lại, và ý tưởng về caching của chị ấy không được nghe." Impact là phần trả lời câu hỏi ngầm trong đầu người nghe: "Thì sao? Tại sao tôi phải quan tâm?". Không có Impact, feedback nghe như một lời than phiền tùy hứng.
Ghép lại, một feedback SBI hoàn chỉnh nghe như: "Trong buổi họp review sáng nay (S), anh để ý em ngắt lời chị Lan ba lần khi chị đang trình bày (B). Kết quả là chị dừng lại, không nói tiếp phần giải pháp caching, mà đó lại là phần team đang cần nghe (I)." Không dán nhãn, không suy diễn, không "lúc nào cũng". Chỉ có dữ liệu.
Vì sao "không infer intent" là ranh giới sống còn
Ghi chú gốc của bài nhấn mạnh: không suy diễn ý định. Đây không phải tiểu tiết. Bộ não con người có xu hướng gọi là "fundamental attribution error" — khi người khác làm sai, ta quy cho tính cách họ ("vì lười"); khi ta làm sai, ta quy cho hoàn cảnh ("vì hôm đó deadline gấp"). Nếu bạn để thiên kiến này lọt vào feedback, bạn tự động biến nó thành lời buộc tội. Kỷ luật của SBI là dừng ở tầng B — hành vi quan sát được — và để người nghe tự giải thích ý định của họ.
Radical Candor — la bàn cảm xúc phía sau SBI
Kim Scott, trong cuốn Radical Candor, đưa ra hai trục: Care Personally (thật lòng quan tâm) và Challenge Directly (thẳng thắn thách thức). Feedback tốt nằm ở góc có cả hai. Thiếu "quan tâm" mà chỉ có "thẳng thắn" thì thành Obnoxious Aggression (hung hăng khó chịu). Thiếu "thẳng thắn" mà chỉ có "quan tâm" thì thành Ruinous Empathy (đồng cảm phá hoại) — kiểu leader Việt Nam hay mắc: thương nhân viên nên không nỡ nói, để rồi họ dậm chân tại chỗ và bị PIP sau sáu tháng. SBI là kỹ thuật; Radical Candor là thái độ nên có khi dùng kỹ thuật đó.
Tình huống thực tế
Tình huống 1 — Feedback bọc đường ở một startup fintech tại TP.HCM
Minh là tech lead một team 6 người tại một startup ví điện tử ở Quận 1. Một dev tên Tuấn liên tục merge code mà bỏ qua bước viết integration test, khiến hai lần production bị lỗi thanh toán trong tháng. Minh áp dụng cái mà anh học lỏm được gọi là "sandwich feedback" — kẹp lời chê giữa hai lời khen: "Tuấn code nhanh lắm, ship đều tay. Mà đợt này test hơi thiếu chút. Nhưng nói chung em là người anh tin tưởng nhất team."
Kết quả? Tuấn bước ra khỏi phòng và nhớ đúng hai vế đầu và cuối: mình được khen. Tuần sau, lại một PR không test, lại một incident. Minh bực bội nghĩ "mình nói rồi mà nó không nghe".
Diễn giải: Sandwich feedback thất bại vì người nghe được huấn luyện để "đợi cú but" và giảm nhẹ nó. Lời khen bọc quanh khiến Impact bị pha loãng. Minh cũng chưa hề nói rõ tác động — anh nói "test hơi thiếu" chứ không nói "hai incident thanh toán tháng này đều bắt nguồn từ thiếu test, và mỗi lần mất khoảng 40 phút cả team dừng việc để hotfix".
Bài học: Nếu Minh dùng SBI: "PR #482 và #491 tuần này merge mà không có integration test cho luồng thanh toán (S+B). Cả hai đều gây lỗi production, mỗi lần team phải dừng khoảng 40 phút để hotfix và có giao dịch của khách bị treo (I). Anh muốn từ giờ luồng payment bắt buộc có test trước khi merge — mình bàn cách làm nhé?" Rõ ràng, không bọc đường, và mở đường cho giải pháp.
Tình huống 2 — Suy diễn ý định làm hỏng một cuộc họp ở công ty outsourcing
Tại một công ty outsourcing 200 người ở Hà Nội, chị Hương — engineering manager — nhận thấy một senior tên Đức thường xuyên phản bác gay gắt trong các buổi design review, đặc biệt với đề xuất của các bạn junior. Chị gọi Đức vào và nói: "Anh thấy em coi thường ý kiến của mấy bạn mới. Em nghĩ mình giỏi hơn nên không thèm nghe ai."
Đức lập tức đỏ mặt: "Em coi thường ai lúc nào? Em góp ý cho tụi nó tốt lên chứ!". Cuộc trò chuyện biến thành trận cãi về việc Đức "có kiêu hay không", kéo dài 30 phút, kết thúc trong căng thẳng và chẳng thay đổi được gì.
Diễn giải: Chị Hương phạm đúng lỗi infer intent. "Coi thường", "nghĩ mình giỏi hơn" đều là suy diễn động cơ, không phải hành vi. Và trớ trêu là Đức nói thật — ý định của cậu là giúp. Vấn đề nằm ở cách cậu góp ý, không phải ở lý do cậu góp ý.
Bài học: Nếu chị Hương dừng ở tầng hành vi: "Trong hai buổi review gần nhất, khi Nam trình bày, em cắt ngang và nói 'cái này sai từ đầu rồi' trước khi bạn trình bày hết (B). Sau đó Nam không đưa thêm ý tưởng nào nữa, và mấy bạn junior khác cũng im lặng theo (I)." Từ điểm này, Đức không có gì để phản bác vì đó là sự thật quan sát được, và cậu có thể tự nhận ra tác động mà không cảm thấy bị buộc tội là người xấu.
Tình huống 3 — Nhận feedback không phòng thủ tại Grab
Một tech lead tên Linh tại một team ở Grab nhận được feedback trong buổi 1:1 từ sếp: "Trong buổi planning tuần trước, chị để ý em quyết luôn hướng kiến trúc mà không hỏi ý team, hai bạn trong nhóm sau đó nói riêng với chị là họ thấy bị bỏ ngoài cuộc." Phản ứng đầu tiên trong đầu Linh là muốn giải thích ngay: "Tại lúc đó deadline gấp, em phải quyết nhanh".
Nhưng Linh kịp dừng lại, và thay vào đó nói: "Cảm ơn chị. Em muốn hiểu rõ hơn — cụ thể lúc nào chị thấy em quyết mà không hỏi? Để em hình dung lại." Sau khi nghe rõ, cô nói: "Em hiểu rồi. Đúng là em đã bỏ qua phần lấy ý kiến. Em sẽ để 10 phút cho team phản biện trước khi chốt kiến trúc ở buổi sau."
Diễn giải: Phản xạ tự nhiên khi nhận feedback là phòng thủ và biện minh. Linh làm ba việc đúng: (1) không phản bác ngay, (2) hỏi để làm rõ dữ liệu thay vì tranh luận về cảm xúc, (3) cam kết một hành động cụ thể. Việc hỏi "cụ thể lúc nào" không phải để cãi, mà để biến feedback mơ hồ thành dữ liệu hành động được.
Bài học: Cách bạn nhận feedback quyết định việc người ta có dám cho bạn feedback lần sau không. Một lần bạn nổi đóa hay biện minh, cánh cửa đóng lại — và một leader không nhận được feedback trung thực là một leader mù.
Hướng dẫn từng bước
Khi cần đưa một feedback điều chỉnh:
- Kiểm tra động cơ của chính bạn. Bạn đang muốn giúp người ta tốt lên, hay chỉ muốn xả bực? Nếu là vế sau, hãy đợi đến khi bình tĩnh. Feedback trong lúc giận gần như luôn là feedback tồi.
- Chọn đúng thời điểm và nơi chốn. Feedback điều chỉnh nói riêng (private), càng gần thời điểm sự việc càng tốt — feedback về chuyện xảy ra hai tháng trước gần như vô dụng. Feedback khen ngợi thì có thể nói công khai.
- Xin phép hoặc mở đầu nhẹ nhàng. "Anh có vài quan sát về buổi họp sáng nay, em nghe được không?" Một câu hỏi nhỏ khiến người nghe chuyển sang trạng thái sẵn sàng thay vì phòng thủ.
- Nói S — bối cảnh cụ thể. Neo vào thời điểm xác định.
- Nói B — hành vi quan sát được. Chỉ điều bạn thấy/nghe. Tự hỏi: "Nếu quay camera lại, có ghi được điều này không?" Nếu không, bạn đang suy diễn.
- Nói I — tác động. Với bạn, với người khác, với dự án. Dùng "anh thấy", "anh lo" thay vì "mọi người đều nghĩ".
- Dừng lại và lắng nghe. Đây là đối thoại, không phải bài giảng. Cho người ta cơ hội giải thích bối cảnh mà bạn có thể chưa biết.
- Cùng thống nhất bước tiếp theo. Feedback không có hành động đi kèm chỉ là lời nhận xét. Kết thúc bằng một cam kết cụ thể, đo được.
- Hít thở, chưa nói gì. Kìm phản xạ biện minh trong 3 giây đầu.
- Nói cảm ơn trước. Người ta vừa mạo hiểm sự thoải mái để nói với bạn.
- Hỏi để làm rõ, không phải để phản công. "Cụ thể ở tình huống nào?" khác hoàn toàn với "Sao anh lại nghĩ vậy?".
- Tách hành vi khỏi con người. Feedback nói về một hành vi, không phủ nhận giá trị của bạn.
- Cam kết một thay đổi nhỏ, cụ thể — hoặc nói rõ nếu bạn cần thời gian suy nghĩ. Bạn không bắt buộc phải đồng ý với mọi feedback, nhưng bạn bắt buộc phải cân nhắc nghiêm túc.
Lỗi thường gặp & mẹo
Lỗi 1 — Feedback sandwich. Kẹp lời chê giữa hai lời khen làm loãng thông điệp. Thay vì thế, tách riêng: khen là khen thật lòng, điều chỉnh là điều chỉnh rõ ràng, không trộn.
Lỗi 2 — Suy diễn ý định. "Em không quan tâm", "em lười", "em nghĩ mình đúng" — tất cả đều là đọc suy nghĩ. Dừng ở hành vi quan sát được.
Lỗi 3 — Khái quát hóa. "Lúc nào em cũng trễ", "em chẳng bao giờ viết test". Một phản ví dụ duy nhất là người nghe bác bỏ toàn bộ feedback của bạn. Neo vào sự kiện cụ thể.
Lỗi 4 — Gom một đống feedback dồn vào kỳ review. Feedback nên là dòng chảy liên tục, không phải cơn lũ mỗi sáu tháng. Không có gì trong buổi performance review được phép là bất ngờ.
Lỗi 5 — Chỉ đưa redirecting, không đưa reinforcing. Nếu bạn chỉ gọi tên khi có vấn đề, người ta sẽ sợ mỗi khi bạn nhắn "rảnh không em?". Cân bằng bằng feedback củng cố cụ thể, không phải "làm tốt lắm" chung chung.
Mẹo: Ghi chú nhanh (một dòng trong Notes hay Notion) mỗi khi bạn quan sát được một hành vi đáng feedback, kèm bối cảnh. Đến buổi 1:1 bạn có sẵn "dữ liệu S và B" thay vì cố nhớ mơ hồ.
Mẹo: Với văn hóa Việt Nam ngại nói thẳng, hãy normalize feedback bằng cách chủ động xin feedback về chính bạn trước. Khi leader hỏi "có điều gì anh nên làm khác không?", nó cho phép cả team làm điều tương tự.
Bài tập thực hành
- Chuyển đổi 3 câu. Lấy ba câu feedback "tồi" sau và viết lại theo SBI: (a) "Em làm việc thiếu trách nhiệm quá"; (b) "Code của em khó đọc lắm"; (c) "Em không chịu hợp tác với team QA". Với mỗi câu, tách rõ đâu là suy diễn ý định bạn phải loại bỏ.
- Nhật ký quan sát một tuần. Trong 5 ngày làm việc, mỗi ngày ghi lại một hành vi (tốt hoặc cần điều chỉnh) của một đồng nghiệp theo đúng định dạng S–B–I. Cuối tuần, chọn một mục và thực sự đưa feedback đó.
- Đóng vai nhận feedback. Nhờ một đồng nghiệp đưa cho bạn một feedback thật (dù nhỏ). Luyện quy trình 5 bước nhận feedback: dừng – cảm ơn – hỏi làm rõ – tách hành vi khỏi con người – cam kết. Tự đánh giá: bạn có kịp kìm phản xạ biện minh không?
- Audit thói quen của bạn. Nhìn lại tháng vừa rồi: bạn đã đưa bao nhiêu feedback reinforcing so với redirecting? Nếu tỉ lệ lệch hẳn về một phía, đó là điểm cần điều chỉnh.
Tóm tắt
Feedback là đòn bẩy lớn nhất của một tech lead vốn thiếu quyền lực chính thức — nhưng chỉ khi nó rõ ràng và đáng tin. SBI model cho bạn xương sống: neo vào Situation cụ thể, mô tả Behavior quan sát được (tuyệt đối không suy diễn ý định), và nói rõ Impact. Tránh feedback sandwich, tránh khái quát hóa "lúc nào cũng", và cân bằng giữa feedback củng cố lẫn điều chỉnh.
Quan trọng không kém: cách bạn nhận feedback quyết định việc người ta có dám nói thật với bạn nữa không. Dừng phản xạ biện minh, cảm ơn, hỏi để làm rõ dữ liệu, và cam kết một thay đổi cụ thể. Khi feedback trở thành dòng chảy hằng ngày — chứ không phải sự kiện đáng sợ mỗi kỳ review — bạn đã đặt nền cho một team học hỏi nhanh và tin nhau. Đó là dấu hiệu của technical leadership trưởng thành.