Mở đầu — vì sao bài này quan trọng
Có một sự thật khó nghe: phần lớn kỹ sư giỏi kỹ thuật lại rất kém trong việc nhận feedback. Không phải vì họ kiêu ngạo, mà vì bộ não con người được lập trình để coi mọi lời chê là một mối đe dọa. Khi ai đó nói "đoạn code này có vấn đề" hoặc "cách bạn giao tiếp trong sprint vừa rồi làm team khó chịu", cùng một vùng não xử lý nguy hiểm thể chất — hạch hạnh nhân (amygdala) — sẽ kích hoạt. Tim đập nhanh, mặt nóng, và trong đầu bạn lập tức xuất hiện câu trả lời phòng thủ trước cả khi người kia nói xong.
Ở bài trước (Bài 13), bạn đã học cách đưa feedback trong code review sao cho tử tế và hiệu quả. Nhưng feedback là một cuộc trao đổi hai chiều. Một team chỉ mạnh khi cả người cho và người nhận đều làm tốt phần của mình. Bài này tập trung hoàn toàn vào phía nhận — một kỹ năng ít được dạy nhưng lại quyết định trực tiếp tốc độ trưởng thành của bạn với tư cách một Individual Contributor (IC — người đóng góp cá nhân, không quản lý ai).
Đây không phải chuyện "làm người tốt". Đây là chuyện sự nghiệp. Người biết nhận feedback tốt sẽ được đồng nghiệp góp ý thẳng thắn hơn, được tin tưởng giao việc khó hơn, và tiến bộ nhanh gấp nhiều lần người mà ai cũng ngại nói thật. Ngược lại, nếu bạn phòng thủ mỗi lần bị góp ý, dần dần mọi người sẽ ngừng nói — và bạn sẽ mắc kẹt ở đúng chỗ đó suốt nhiều năm mà không hiểu vì sao.
Khái niệm cốt lõi
Phản ứng mặc định: phòng thủ
Điều đầu tiên cần chấp nhận: phản ứng phòng thủ không phải là lỗi đạo đức của bạn. Nó là bản năng sinh học. Khi nhận feedback tiêu cực, não bộ diễn giải đó là một "cuộc tấn công" vào địa vị xã hội (social status) của bạn trong nhóm — và với tổ tiên chúng ta, mất địa vị trong bộ lạc gần như đồng nghĩa với nguy hiểm tính mạng. Vì vậy cơ thể phản ứng y như gặp thú dữ: chiến đấu (cãi lại), bỏ chạy (im lặng rút lui), hoặc đóng băng (đơ ra không nói được gì).
Vì đây là phản ứng tự động, bạn không thể trông chờ mình "tự nhiên bình tĩnh". Bạn phải chủ động ghi đè (actively override) nó bằng một quy trình có ý thức. Giống như bạn không thể ra lệnh cho tim đập chậm lại, nhưng bạn có thể hít thở sâu để làm điều đó gián tiếp. Nhận feedback tốt là một kỹ năng luyện tập được, không phải tính cách bẩm sinh.
Tách "feedback" khỏi "bản thân"
Sai lầm nền tảng nhất là đồng nhất code của tôi với tôi. Khi ai đó nói "hàm này khó đọc", bạn nghe thành "bạn là một kỹ sư tệ". Đó là hai điều hoàn toàn khác nhau. Code là sản phẩm bạn tạo ra tại một thời điểm, với thông tin và deadline lúc đó. Nó không phải là con người bạn, không phải chỉ số IQ của bạn, không phải giá trị của bạn.
Người nhận feedback giỏi có một câu thần chú trong đầu: "Họ đang nói về công việc, không phải về tôi." Ngay cả khi feedback được đưa vụng về, thậm chí có phần công kích, thì phần thông tin hữu ích trong đó vẫn nói về công việc. Nhiệm vụ của bạn là bóc lấy phần thông tin đó và bỏ đi phần cảm xúc dư thừa — của cả người kia lẫn của chính bạn.
Quy trình 5 bước để "tạm dừng" (5-step pause)
Đây là bộ khung xương sống của bài học. Khi feedback đến và bạn cảm thấy máu dồn lên mặt, hãy chạy qua 5 bước sau — ban đầu có ý thức, sau này thành phản xạ:
- Stop (Dừng lại) — Không trả lời ngay khi cảm xúc còn nóng. Bước quan trọng nhất và cũng khó nhất. Ngay khoảnh khắc bạn muốn gõ "Nhưng mà..." hay "Thực ra thì..." — đó chính là lúc phải dừng tay. Đếm thầm đến ba. Với feedback qua văn bản (comment PR, tin nhắn Slack), lợi thế lớn là bạn có thể im lặng vài phút mà không ai biết. Hãy tận dụng.
- Breathe & acknowledge (Thở và ghi nhận cảm xúc) — Thầm gọi tên cảm xúc: "À, mình đang thấy bị chạm tự ái." Việc gọi tên cảm xúc (một kỹ thuật gọi là affect labeling) đã được nghiên cứu chứng minh làm giảm hoạt động của amygdala. Bạn không cần đè nén cảm xúc, chỉ cần nhận ra nó đang ở đó để nó không lái tay bạn.
- Listen for the signal (Lắng nghe tín hiệu) — Tự hỏi: "Nếu 10% điều họ nói là đúng, thì đó là 10% nào?" Ngay cả feedback tệ nhất thường vẫn chứa một hạt sự thật. Tìm hạt đó thay vì tìm lỗ hổng để phản bác.
- Clarify, don't defend (Hỏi lại, đừng biện minh) — Thay vì giải thích tại sao bạn làm vậy, hãy hỏi để hiểu rõ hơn: "Bạn có thể cho mình một ví dụ cụ thể chỗ nào khó đọc không?" Câu hỏi làm chậm cuộc trò chuyện lại và chuyển bạn từ thế phòng thủ sang thế tò mò.
- Decide & respond (Quyết định và phản hồi) — Sau khi đã hiểu, bạn mới quyết định: đồng ý và sửa, đồng ý một phần, hay không đồng ý (một cách tôn trọng). Quan trọng: bạn có toàn quyền không đồng ý. Nhận feedback không có nghĩa là phải làm theo mọi thứ. Nó chỉ có nghĩa là bạn thật sự cân nhắc trước khi quyết định.
Phân loại feedback trước khi phản ứng
Không phải mọi feedback đều giống nhau. Trước khi phản hồi, hãy nhanh chóng phân loại:
- Feedback về sự thật kỹ thuật (bug, security hole, hiệu năng): thường khách quan, dễ kiểm chứng. Đón nhận nhanh, cảm ơn, sửa.
- Feedback về phong cách/quan điểm (đặt tên biến, cấu trúc thư mục): mang tính chủ quan, có thể thương lượng. Đây là chỗ để hỏi "team mình có convention chung nào cho việc này không?"
- Feedback về hành vi/giao tiếp ("bạn hay ngắt lời trong họp"): nhạy cảm nhất, khó nghe nhất, nhưng thường quý giá nhất cho sự nghiệp lâu dài.
Tình huống thực tế
Ví dụ 1: Cú comment "This whole approach is wrong" lúc 9 giờ tối
Minh, một Backend Engineer 2 năm kinh nghiệm tại một fintech startup ở TP.HCM (khoảng 40 kỹ sư), mở một Pull Request cho tính năng tính lãi suất mà cậu đã làm suốt ba ngày. Tối hôm đó, một senior tên Đức để lại comment cụt lủn: "This whole approach is wrong, chúng ta không nên tính lãi ở tầng service."
Máu Minh dồn lên mặt. Cậu gõ ngay một đoạn dài giải thích tại sao mình làm vậy, kèm hai câu hơi gắt. May thay, trước khi bấm gửi, Minh nhớ tới quy trình 5 bước. Cậu dừng lại, đóng laptop, đi uống nước. Mười phút sau quay lại, cậu xóa đoạn phản pháo và thay bằng: "Cảm ơn anh. Anh nói tính lãi không nên ở tầng service — anh có thể chỉ giúp em nên đặt ở tầng nào và vì lý do gì không? Em muốn hiểu rõ hướng đúng."
Đức trả lời sáng hôm sau, giải thích rằng logic lãi suất sắp được ba team khác dùng chung nên cần tách thành một domain module riêng để tránh trùng lặp. Hóa ra Đức đúng về mặt kiến trúc, chỉ là cách nói của anh quá cộc.
Bài học: Nếu Minh gửi đoạn phản pháo tối hôm đó, cậu đã tạo ra một cuộc tranh cãi vô ích và bỏ lỡ một thông tin kiến trúc quan trọng. Việc "dừng lại 10 phút" gần như luôn miễn phí trong giao tiếp async — và nó cứu bạn khỏi những phản ứng bạn sẽ hối hận. Đồng thời chú ý: feedback đúng vẫn có thể được đưa dở. Đừng để cách đóng gói tệ làm bạn vứt bỏ nội dung tốt.
Ví dụ 2: Feedback về hành vi trong buổi 1-on-1
Lan là Frontend IC tại một công ty SaaS ở Singapore, làm việc trong team đa quốc gia. Trong buổi 1-on-1, manager của cô — anh Raj — nói nhẹ nhàng: "Có vài bạn phản ánh rằng trong các buổi design review, em thường phản bác ý tưởng của người khác khá nhanh, đôi khi trước khi họ trình bày xong. Anh nghĩ em nên biết điều này."
Phản ứng đầu tiên của Lan là sốc và tổn thương — "Ai nói vậy? Em chỉ đang thẳng thắn thôi mà!" Nhưng cô kịp thở và gọi tên cảm xúc: "Mình đang thấy bị oan." Thay vì phản bác, cô dùng bước clarify: "Anh có thể cho em một ví dụ gần đây không? Em muốn hiểu cụ thể mình đã làm gì tạo ra cảm giác đó."
Raj kể lại một buổi họp tuần trước. Nghe xong, Lan nhận ra: cô không sai về nội dung, nhưng thời điểm và cách cô chen vào đúng là khiến người khác cảm thấy bị gạt đi. Đó là 10% (thực ra là hơn thế) sự thật mà cô cần nghe. Cô nói: "Cảm ơn anh đã nói thẳng. Em sẽ thử để mọi người trình bày hết rồi mới góp ý, và bắt đầu bằng câu hỏi thay vì phản bác."
Ba tháng sau, chính những đồng nghiệp từng phàn nàn lại là người khen Lan trong đợt review hiệu suất.
Bài học: Feedback về hành vi là loại khó nuốt nhất vì nó chạm vào hình ảnh bản thân. Nhưng một manager dám nói thẳng với bạn là một manager quan tâm đến sự nghiệp của bạn. Người ta chỉ góp ý cho người họ tin là sẽ tiến bộ. Hãy đối xử với feedback đó như một món quà đắt giá, dù nó được gói trong giấy nhám.
Ví dụ 3: Khi feedback thực sự sai — và cách không đồng ý một cách chuyên nghiệp
Tuấn, một DevOps Engineer, nhận review từ một đồng nghiệp đề nghị đổi toàn bộ pipeline CI sang một công cụ mới vì "team bên kia đang dùng và thấy hay". Sau khi chạy qua quy trình 5 bước, Tuấn xác định đây là feedback mà cậu không đồng ý — việc chuyển đổi sẽ tốn hai tuần và không giải quyết vấn đề thực tế nào của team.
Điểm mấu chốt: Tuấn không im lặng làm theo, cũng không gạt phắt đi. Cậu viết: "Cảm ơn gợi ý của bạn. Mình đã cân nhắc: công cụ đó mạnh ở mảng X, nhưng vấn đề hiện tại của pipeline mình là thời gian build chậm ở khâu Y, mà việc đổi công cụ không chạm tới. Mình đề xuất giữ nguyên và tập trung tối ưu Y trước. Nếu bạn thấy mình bỏ sót gì, nói mình biết nhé."
Bài học: Nhận feedback tốt không đồng nghĩa với vâng lời. Nó nghĩa là bạn lắng nghe đầy đủ, cân nhắc thật sự, rồi ra quyết định dựa trên lý lẽ chứ không dựa trên cảm xúc phòng thủ. Cách từ chối này ghi nhận công người góp ý, nêu lý do rõ ràng, và để cửa mở cho đối thoại tiếp. Đó là dấu hiệu của một IC trưởng thành.
Hướng dẫn từng bước
Khi một feedback đến (dù qua comment, chat hay trực tiếp), hãy làm theo trình tự này:
- Nhận diện phản ứng cơ thể. Ngay khi thấy nóng mặt, tim đập nhanh, hoặc muốn gõ "Nhưng mà" — đó là tín hiệu báo động. Coi nó như đèn đỏ: dừng.
- Mua thời gian. Với feedback async: đừng trả lời trong 10–30 phút đầu. Với feedback trực tiếp: dùng câu đệm trung tính như "Để mình suy nghĩ một chút" hoặc "Cảm ơn bạn, cho mình xử lý cái này chút nhé." Không câu nào trong số này bắt bạn phải đồng ý — chúng chỉ tạo khoảng lặng.
- Đọc/nghe lại để tìm tín hiệu. Bỏ qua tông giọng, tìm phần nội dung. Tự hỏi: "Người này đang cố giúp mình tránh vấn đề gì?"
- Đặt câu hỏi làm rõ trước khi phản hồi bản chất. "Bạn có thể cho ví dụ cụ thể không?" / "Ý bạn là chỗ nào?" / "Nếu là bạn, bạn sẽ làm khác thế nào?" Câu hỏi vừa giúp bạn hiểu, vừa cho bạn thời gian bình tĩnh.
- Cảm ơn — thật lòng. Một câu "Cảm ơn đã dành thời gian review" nên thành phản xạ, kể cả khi bạn chưa đồng ý. Nó báo hiệu bạn an toàn để góp ý, và mọi người sẽ tiếp tục nói thật với bạn.
- Quyết định rõ ràng và đóng vòng lặp (close the loop). Nói rõ bạn sẽ làm gì: "Mình sẽ sửa theo hướng này" hoặc "Mình xin giữ nguyên vì lý do X". Nếu đã sửa, báo lại: "Đã update theo góp ý của bạn, cảm ơn nhé." Việc đóng vòng lặp khiến người góp ý thấy công sức của họ có ý nghĩa.
- Ghi lại các mẫu lặp. Nếu ba người khác nhau cùng nói bạn viết commit message quá sơ sài, đó không còn là ý kiến cá nhân — đó là một mẫu (pattern) bạn cần xử lý. Giữ một ghi chú riêng những feedback lặp lại; đó chính là bản đồ phát triển của bạn.
Lỗi thường gặp & mẹo
Lỗi 1: Giải thích ngay lập tức ("defensive explaining"). Bạn vội kể ra mọi ràng buộc, deadline, lý do khiến code thành ra như vậy. Người kia nghe thành "tôi không sai, bạn không hiểu đấy thôi". Mẹo: chỉ giải thích sau khi đã hỏi làm rõ và khi được hỏi. Phần lớn lời giải thích tự phát là để xoa dịu cái tôi của bạn, không phải để giúp người kia.
Lỗi 2: "Sniper thanks" — cảm ơn cho có rồi lờ đi. Nói "cảm ơn góp ý" nhưng không hề thay đổi gì và cũng không giải thích tại sao. Lần sau người ta sẽ ngừng góp ý. Mẹo: luôn đóng vòng lặp — hoặc sửa, hoặc nêu lý do không sửa.
Lỗi 3: Vơ đũa cả nắm cảm xúc. Một comment tiêu cực làm bạn kết luận "cả PR của mình dở tệ" hoặc "mình không hợp làm nghề này". Mẹo: đếm lại. Một feedback tiêu cực giữa mười file tốt vẫn nghĩa là chín phần công việc của bạn ổn.
Lỗi 4: Nhầm feedback dở với feedback sai. Người ta nói cộc lốc, thiếu tế nhị, không có nghĩa là họ sai về nội dung. Mẹo: tách "cách nói" khỏi "điều được nói". Bóc lấy tín hiệu, bỏ đi tiếng ồn.
Lỗi 5: Xin lỗi quá mức. "Ôi mình xin lỗi, mình ngu quá, mình tệ thật" — nghe thì khiêm tốn nhưng thực ra làm người khác khó xử và tự hạ thấp bạn. Mẹo: thay "xin lỗi" bằng "cảm ơn". "Cảm ơn đã bắt được lỗi này" mạnh mẽ và chuyên nghiệp hơn nhiều "xin lỗi mình cẩu thả quá".
Mẹo vàng — Chủ động đi xin feedback (solicit feedback). Người nhận feedback giỏi nhất không ngồi đợi. Họ hỏi cụ thể: "Trong PR này, mình đặc biệt muốn nghe góp ý về cách xử lý lỗi — bạn thấy sao?" Câu hỏi cụ thể dễ trả lời hơn "review giúp mình nhé", và nó đặt bạn vào thế chủ động, khiến việc nhận feedback bớt bị động, bớt như bị phán xét.
Bài tập thực hành
- Nhật ký phản ứng (1 tuần). Mỗi lần nhận feedback trong tuần này, ghi lại ba dòng: (a) phản ứng cơ thể đầu tiên của bạn, (b) điều bạn muốn nói ngay lúc đó, (c) điều bạn thực sự nói sau khi tạm dừng. Cuối tuần nhìn lại khoảng cách giữa (b) và (c) — đó là mức độ trưởng thành bạn đang xây.
- Viết lại phản pháo. Lấy một feedback gần đây từng khiến bạn khó chịu. Viết ra đoạn phản hồi "nóng" mà bạn muốn gửi lúc đó. Rồi viết lại nó theo quy trình 5 bước: bắt đầu bằng một câu hỏi làm rõ và một lời cảm ơn. So sánh hai phiên bản.
- Chủ động xin feedback cụ thể. Trong PR hoặc buổi họp tới, đặt đúng một câu hỏi feedback cụ thể ("Cho mình xin góp ý riêng về phần X"). Ghi lại: câu hỏi cụ thể có mang lại phản hồi hữu ích hơn không?
- Bài tập "10% sự thật". Nhớ lại một feedback bạn từng thấy hoàn toàn sai. Ép mình tìm ra 10% có thể đúng trong đó. Chỉ cần một hạt sự thật cũng đủ.
Tóm tắt
- Phản ứng phòng thủ khi nhận feedback là bản năng sinh học, không phải lỗi của bạn — nhưng bạn phải chủ động ghi đè nó bằng một quy trình có ý thức.
- Tách feedback về công việc ra khỏi giá trị bản thân: họ nói về code, không phải về con người bạn.
- Chạy qua quy trình 5 bước: Dừng → Thở & gọi tên cảm xúc → Nghe tín hiệu → Hỏi làm rõ (đừng biện minh) → Quyết định & phản hồi.
- Nhận feedback tốt không phải là vâng lời. Bạn có quyền không đồng ý — miễn là bạn đã thật sự lắng nghe và nêu lý do rõ ràng, tôn trọng.
- Luôn đóng vòng lặp và thay lời "xin lỗi" bằng "cảm ơn". Người biết nhận feedback là người được góp ý thẳng thắn nhất — và vì thế tiến bộ nhanh nhất.