Hiệu suất và feedback: mô hình SBI, plan phát triển

Feedback là công cụ duy nhất giúp engineer phát triển. Làm tốt, bar của team tăng đều mỗi quý. Làm tệ, team đứng yên và những người mạnh nhất sẽ rời đi. Chương này giới thiệu mô hình SBI cho feedback cá nhân, growth plan dẫn dắt cuộc trò chuyện theo quý, và quy trình xử lý người dưới chuẩn theo cách công bằng.

Khi nào kỷ luật feedback chính thức bắt đầu quan trọng?

Có ba tín hiệu chính.

Bạn đang quản lý người. Từ ngày đầu tiên, bạn đã nợ họ feedback. Việc không cho feedback là tín hiệu còn tệ hơn cả việc cho feedback khó. Nhịp 1-on-1 là channel chính để chở feedback đi.

Cuộc trò chuyện promote hoặc demote đang đến gần. Một dấu vết giấy rõ ràng của feedback theo thời gian là cơ sở trung thực duy nhất cho cả hai phía.

Team đủ lớn để bạn không thể nhớ mọi khoảnh khắc. SBI feedback giúp tài liệu hoá lịch sử của mỗi engineer thành record có thể tra lại.

Nếu bạn là tech lead ngang hàng và không có direct report nào, feedback vẫn quan trọng nhưng diễn ra không chính thức - "này, review PR vừa rồi của bạn hơi gắt".

Cái giá của một văn hoá feedback yếu là gì?

Có ba kiểu lỗi thường gặp.

Sa thải bất ngờ. Một engineer bị cho nghỉ sau 2 năm; họ không hề biết hiệu suất đang là vấn đề đáng xử lý. Vừa hại sự nghiệp họ, vừa tạo rủi ro pháp lý cho bạn.

Người mạnh rời đi. Người hiệu suất cao luôn muốn feedback để phát triển. Không có, họ giả thiết là mình đang đứng yên và sẽ rời đi. Còn những người phẳng và không bao giờ hỏi feedback lại ở lại.

Review mơ hồ. "Hợp tác hơn" hay "lên cấp kỹ năng" - đó là những cụm không có nghĩa hành động. Engineer đọc xong, nhún vai, và không thay đổi gì.

Template feedback SBI là gì?

Cho một cuộc trò chuyện feedback:

# Feedback — {{ tên engineer }} — 2026-06-17

## Tình huống
Trong họp sprint planning hôm qua.

## Hành vi
Bạn cam kết team sẽ ship template email refund trong sprint này
mà không check với Carol, người sở hữu thiết kế và đang nghỉ ốm.

## Tác động
Carol đi làm lại hôm nay, thấy cam kết đã được đặt, và cảm thấy
team đã ra quyết định về phần việc của cô khi cô không có mặt.
Cô có nhắc rằng đang "nghĩ về vai trò" - đó là flag nghiêm trọng
cần xử lý.

## Tôi muốn thấy
Trước khi cam kết scope phụ thuộc vào ai đó, hãy ping họ trong
họp (Slack cũng được) hoặc hoãn quyết định. Cùng outcome, nhưng
không gây bất ngờ.

## Phản hồi của engineer
{{ Bắt live trong chính cuộc trò chuyện }}

Template là cho note phía manager. Cuộc trò chuyện thực tế trôi chảy hơn - SBI là sống còn của feedback, không phải kịch bản đọc nguyên văn.

Template review quý trông thế nào?

# Review hiệu suất — {{ engineer }} — Q2 2026

## Tóm tắt
{{ Một đoạn: cái họ đã ship, sự phát triển quan sát được, một
   vùng cần focus trong quý kế }}

## Thắng trong quý này
- {{ Dự án / outcome }}
- {{ Hành vi / đóng góp văn hoá }}
- {{ Mentorship / giúp đỡ xuyên team }}

## Theme phát triển (gộp từ feedback SBI trong quý)
- {{ Theme 1 — kèm ví dụ điểm mạnh }}
- {{ Theme 2 — vùng cần phát triển }}

## Mục tiêu cho quý kế
- {{ Outcome: ship X trước Y }}
- {{ Hành vi: lead 1 initiative xuyên team }}
- {{ Kỹ năng: hiểu sâu {{ vùng }} }}

## Cuộc trò chuyện sự nghiệp
- Cấp hiện tại: {{ cấp }}
- Khao khát 12 tháng: {{ từ phía engineer }}
- Cầu nối: {{ những việc sẽ làm trong quý này để chuyển hướng đó }}

## Không bất ngờ
Engineer nên nhận ra mọi thứ trong review này từ các 1-on-1
trước đó. Nếu có gì mới, manager đã fail và cần xin lỗi ngay
trong buổi họp.

Mệnh đề "không bất ngờ" là một loại hợp đồng. Engineer đọc review, thấy lại các theme đã đề cập trong 1-on-1 cũ, và biết nên focus vào đâu.

Feedback scale lên đa team như thế nào?

flowchart TB
    SBI[Feedback SBI hàng ngày<br/>qua 1-on-1] --> Quarterly[Review quý<br/>1 manager + 1 engineer]
    Quarterly --> Calibration[Calibration xuyên team<br/>các EM khớp bar]
    Calibration --> Promo[Quyết định promote / comp]
    Quarterly --> Growth[Cập nhật growth plan]

Calibration xuyên team là thứ giữ bar hiệu suất nhất quán. Không có nó, 'đạt bar' của Team A có thể trở thành 'vượt bar' của Team B, và chính trị promote sẽ nổi lên. Các EM review chéo review của nhau theo quý để khớp.

Feedback có thể tự tạo ra những lỗi nào?

• Feedback bị dồn lại. "Để mình nhắc ở review quý." Cách phòng: giao feedback trong vòng 48 giờ; review chỉ để gộp, không để giới thiệu cái mới.
• Toàn tích cực hoặc toàn tiêu cực. Tích cực mơ hồ thì vô dụng; tiêu cực thuần thì demoralise. Cách phòng: cân bằng, nhưng đừng bịa - nếu không có gì tích cực để nói, bản thân điều đó đã là thông điệp.
• Feedback so sánh. "Bạn nên giống Bob hơn." Cách phòng: chỉ nói về hành vi của chính engineer, đừng kéo Bob vào.
• Phát triển chỉ xảy ra lúc review. Engineer phải đợi 6 tháng mới có cuộc trò chuyện về phát triển. Cách phòng: đưa phát triển thành chủ đề 1-on-1 hàng tháng; review chỉ là chỗ gộp lại.

Khi nào feedback chính thức là quá liều?

Có một trường hợp. Pair-programming partner, ngang hàng, không có quan hệ manager: feedback xảy ra ngay trong thời điểm. Một câu "code review đó hơi gắt" nói luôn hôm nay là đủ.

Cấu trúc chính thức chỉ đáng overhead trong quan hệ manager-report và ở khoảng thời gian quý trở lên.

Đi tiếp từ đây như thế nào?

Bạn đã hoàn tất nhóm people. Chương tiếp theo: status report chạy được - artifact dùng để giao tiếp sức khoẻ dự án ra ngoài. Sau đó, decision log và ADR là chương artifact cuối cùng trước khi vào case study.