Communication Skills — Tại Sao Kỹ Thuật Giỏi Vẫn Không Thăng Tiến
🎯 Mục Tiêu Bài Viết
📺 Video gốc: https://www.youtube.com/watch?v=kdy-C61fb5g
Nhiều engineer giỏi kỹ thuật nhưng sự nghiệp vẫn chậm phát triển. Lý do thật sự thường không phải thiếu skill code — mà là cách giao tiếp chưa hiệu quả: nói vòng vo, đưa quá nhiều context, không nói theo cách người nghe tiếp nhận.
✅ Hiểu root cause thật sự khiến career không phát triển
✅ 3 kỹ thuật giao tiếp cốt lõi: BLUF, Just-In-Time Context, Zoom In
✅ Diagram rõ ràng từng method
✅ So sánh sai lầm phổ biến vs cách đúng
✅ Áp dụng thực tế: họp, báo cáo manager, giải thích kỹ thuật
✅ Mid vs Senior perspective về communication
“Communicate the way people listen — not the way you think.”
🗺️ 1. Big Picture — Root Cause
WHY CAREER ISN'T GROWING
│
└── Root cause thật sự:
Communication issue — không phải thiếu kỹ thuật
│
├── Nói vòng vo, build-up context quá lâu
├── Đưa quá nhiều thông tin không cần thiết
└── Không nói theo cách người nghe tiếp nhận
3 CORE COMMUNICATION METHODS
│
├── 1. BLUF → Nói kết luận TRƯỚC
├── 2. Just-In-Time → Chỉ đưa đủ context để hành động
└── 3. Zoom In → Đào sâu dần từ nền tảng chung
Nhầm Lẫn Phổ Biến Của Engineer
❌ SAI (cách engineer thường nghĩ):
"Mình phải giải thích đầy đủ để người kia hiểu rõ"
→ Dump toàn bộ context → analysis → mới nói kết luận
→ Người nghe lost, không nhớ ý chính
✅ ĐÚNG (cách người nghe thật sự tiếp nhận):
Kết luận / recommendation trước
→ Rồi mới hỏi/nghe thêm chi tiết nếu cần
→ Người nghe biết họ đang lắng nghe vì lý do gì
🔵 2. Method 1 — BLUF (Bottom Line Up Front)
Nguyên Tắc
┌─────────────────────────────────────────────────────────┐
│ BLUF — Nói Điểm Chính Trước │
│ │
│ Người nghe KHÔNG cần: │
│ ├─ Hành trình suy nghĩ của bạn │
│ ├─ Context đầy đủ trước khi nghe kết luận │
│ └─ Mọi analysis bạn đã làm │
│ │
│ Người nghe CẦN: │
│ ├─ Biết ý chính là gì (đích đến) │
│ └─ Rồi mới cần chi tiết (nếu muốn biết thêm) │
│ │
└─────────────────────────────────────────────────────────┘
Sai vs Đúng
❌ SAI — Cách engineer thường nói:
"Tuần trước mình có nghiên cứu vấn đề authentication,
xem qua 3 approach khác nhau, so sánh về security,
performance, và maintainability, dựa trên team size
hiện tại và roadmap Q2... và mình nghĩ nên dùng JWT."
Flow: Context → Analysis → Recommendation
──────────────────────────────────────────────────────────
✅ ĐÚNG — BLUF:
"Mình recommend dùng JWT cho authentication.
Lý do: đơn giản hơn OAuth2 cho use case hiện tại,
team đã quen, và giảm dependency vào external service."
Flow: Recommendation → Supporting details
BLUF Template
BLUF Template:
[KẾT LUẬN / RECOMMENDATION]
│
├── Lý do 1: ...
├── Lý do 2: ...
└── Lý do 3: ...
(Nếu cần thêm chi tiết, mình có thể giải thích thêm về...)
──────────────────────────────────────────────────────────
Ví dụ thực tế:
"PR này cần request changes — có memory leak tiềm ẩn.
Cụ thể: setInterval ở line 42 không được clear
khi component unmount. Fix: thêm cleanup function
trong useEffect/onUnmounted."
Khi Nào Dùng BLUF?
Dùng BLUF khi:
├─ Báo cáo với manager / stakeholder
├─ Đề xuất technical decision
├─ Code review comment
├─ Update status trong standup
└─ Slack/email cần response nhanh
Không phù hợp khi:
└─ Brainstorming mở (cần explore thay vì conclude)
🟢 3. Method 2 — Just-In-Time Context
Nguyên Tắc
┌─────────────────────────────────────────────────────────┐
│ JUST-IN-TIME CONTEXT │
│ │
│ Không phải: "Nói hết mọi thứ mình biết" │
│ Mà là: "Nói đúng thứ người kia cần để làm tiếp" │
│ │
│ Câu hỏi cần hỏi trước khi nói: │
│ "Người này cần làm gì với thông tin này?" │
│ │
│ Chỉ đưa context vừa đủ để họ: │
│ ├─ Ra quyết định │
│ ├─ Thực hiện bước tiếp theo │
│ └─ Hiểu đủ để không bị block │
│ │
└─────────────────────────────────────────────────────────┘
Sai vs Đúng
❌ SAI — Dump toàn bộ context:
(Với designer): "Cái animation này dùng CSS transform
kết hợp với will-change property để tận dụng GPU
acceleration, tránh layout thrashing, timing function
dùng cubic-bezier(0.4, 0, 0.2, 1) theo Material spec..."
→ Designer không cần biết điều này để làm việc
──────────────────────────────────────────────────────────
✅ ĐÚNG — Just-In-Time Context:
(Với designer): "Animation đang chạy đúng spec.
Nếu muốn điều chỉnh tốc độ, cứ nói mình —
mình sẽ update giúp."
(Với manager): "Feature xong, đang QA.
Dự kiến deploy cuối tuần này."
(Với senior engineer): "Dùng CSS transform + GPU layer,
benchmark cho thấy 60fps stable trên mid-range device."
Just-In-Time Decision Flow
Trước khi nói / viết:
│
▼
Người này là ai? (role, background)
│
▼
Họ cần làm gì với thông tin này?
│
├── Ra quyết định? → Cho kết quả + options
├── Thực hiện task? → Cho instruction + context cần thiết
├── Update status? → Cho trạng thái + blockers nếu có
└── Hiểu technical? → Tùy level → xem Method 3
│
▼
Lọc: Bỏ phần nào người này KHÔNG cần để làm việc tiếp
│
▼
Nói phần còn lại
🟡 4. Method 3 — Zoom In Method
Nguyên Tắc
┌─────────────────────────────────────────────────────────┐
│ ZOOM IN METHOD │
│ │
│ Khi cần giải thích sâu: │
│ KHÔNG bắt đầu từ định nghĩa / gốc vấn đề phức tạp │
│ MÀ bắt đầu từ điều người nghe ĐÃ BIẾT │
│ │
│ Rồi đi sâu từng lớp nhỏ cho đến khi: │
│ → Họ đủ hiểu để làm bước tiếp theo │
│ → Hoặc họ tự muốn đào sâu thêm │
│ │
└─────────────────────────────────────────────────────────┘
Quy Trình Zoom In
ZOOM IN PROCESS:
Bước 1: Shared Understanding
────────────────────────────
"Bạn biết [điều X] rồi đúng không?"
→ Xác nhận điểm chung trước khi đi sâu
Bước 2: Deeper 1 Layer
──────────────────────
→ Từ điểm chung, đi thêm 1 lớp sâu hơn
Bước 3: Chia thành 2-3 nhánh
─────────────────────────────
→ Nêu có mấy khía cạnh / phần liên quan
Bước 4: Chọn phần quan trọng nhất
──────────────────────────────────
→ Focus vào phần phù hợp với nhu cầu người nghe
Bước 5: Đào sâu tiếp (nếu cần)
────────────────────────────────
→ Lặp lại bước 2-4
Bước 6: Dừng đúng lúc
──────────────────────
→ Dừng khi người nghe đủ để bước tiếp
→ Không cần giải thích đến cùng
Ví Dụ Thực Tế
Giải thích "tại sao dùng Observable thay vì Promise"
cho một dev backend mới join team:
──────────────────────────────────────────────────────────
❌ SAI — Bắt đầu từ gốc phức tạp:
"Observable là implementation của ReactiveX pattern,
dựa trên Observer design pattern, cho phép bạn
compose asynchronous và event-based programs using
observable sequences..."
→ Dev backend nghe 10 giây đầu đã lost
──────────────────────────────────────────────────────────
✅ ĐÚNG — Zoom In:
[Shared understanding]
"Bạn biết Promise rồi đúng? — async, resolve một lần."
[1 layer deeper]
"Observable cũng async, nhưng khác ở chỗ:
nó có thể emit nhiều giá trị theo thời gian,
không chỉ resolve 1 lần."
[Ví dụ cụ thể]
"Ví dụ: WebSocket stream, search-as-you-type —
những thứ cần xử lý nhiều event liên tiếp."
[Dừng tại đây nếu đủ]
"Trong project mình dùng nó cho HTTP call
vì có thêm operators như retry, timeout, cancel."
→ Dev backend đã hiểu đủ để làm việc
⚖️ 5. So Sánh 3 Methods
| Method | Khi nào dùng? | Mục tiêu |
|---|---|---|
| BLUF | Báo cáo, đề xuất, update nhanh | Người nghe biết ý chính ngay |
| Just-In-Time | Mọi giao tiếp với người khác role | Giảm overload, tăng hữu dụng |
| Zoom In | Giải thích kỹ thuật, training | Sâu mà vẫn dễ hiểu |
Kết Hợp Cả 3
BLUF + Just-In-Time + Zoom In — Ví dụ họp với manager:
[BLUF]
"System performance đã cải thiện 40% sau optimization."
[Just-In-Time Context]
"Không cần action gì từ phía anh — đã deploy staging,
plan deploy production thứ 6 này."
[Zoom In — chỉ khi manager hỏi thêm]
Manager: "Optimization là làm gì vậy?"
→ "Database query chạy lâu nhất — bắt đầu từ đó..."
→ [Zoom In từng bước theo mức độ manager muốn biết]
🔄 6. Overall Communication Flow
┌─────────────────────────────────────────────────────────┐
│ COMMUNICATE THE WAY PEOPLE LISTEN │
│ │
│ Trước khi nói, tự hỏi: │
│ │
│ 1. Người này cần biết GÌ để làm việc tiếp? │
│ → Just-In-Time Context │
│ │
│ 2. Ý chính của mình là gì? │
│ → BLUF: Nói nó TRƯỚC TIÊN │
│ │
│ 3. Nếu cần giải thích sâu hơn? │
│ → Zoom In: Bắt đầu từ điều họ ĐÃ BIẾT │
│ │
└─────────────────────────────────────────────────────────┘
FLOW:
Lead with the point ← BLUF
│
▼
Give just enough context ← Just-In-Time
│
▼
Go deeper if needed ← Zoom In (từ shared understanding)
🚦 7. Những Sai Lầm Phổ Biến Của Engineer
╔══════════════════════════════════════════════════════════╗
║ COMMUNICATION ANTI-PATTERNS CỦA ENGINEER ║
╚══════════════════════════════════════════════════════════╝
❌ ANTI-PATTERN 1: Context Dump
─────────────────────────────
Nói hết mọi thứ mình biết trước khi vào ý chính
→ Người nghe lost, không nhớ điểm quan trọng
Fix: BLUF — kết luận trước, chi tiết sau
❌ ANTI-PATTERN 2: Giải thích từ định nghĩa hàn lâm
──────────────────────────────────────────────────
"Observable là implementation của ReactiveX pattern..."
→ Người nghe không có nền tảng đó sẽ lost ngay lập tức
Fix: Zoom In — bắt đầu từ điều họ đã biết
❌ ANTI-PATTERN 3: One-Size-Fits-All Communication
──────────────────────────────────────────────────
Giải thích giống nhau với designer, manager, senior dev
→ Mỗi người có nhu cầu thông tin khác nhau
Fix: Just-In-Time — điều chỉnh theo role và nhu cầu
❌ ANTI-PATTERN 4: Nói xong không check understanding
──────────────────────────────────────────────────
Giải thích dài → không hỏi "Bạn cần thêm gì không?"
→ Không biết họ có hiểu đủ để làm tiếp không
Fix: Pause, hỏi — rồi Zoom In thêm nếu cần
❌ ANTI-PATTERN 5: Prove intelligence thay vì transfer knowledge
──────────────────────────────────────────────────────────────
Dùng thuật ngữ phức tạp để nghe "pro"
→ Người nghe ấn tượng nhưng không hiểu gì
Fix: Mục tiêu là người nghe hiểu — không phải bạn nghe pro
📝 8. Áp Dụng Thực Tế
Standup / Daily Meeting
❌ SAI:
"Hôm qua mình làm feature login, gặp issue với JWT,
debug khoảng 2 tiếng, tìm ra do token expiry không
đồng bộ với timezone server, đã fix và test..."
✅ ĐÚNG (BLUF + Just-In-Time):
"Feature login: done, đang PR review.
Hôm nay: move sang feature profile.
Blocker: cần design spec cho avatar upload."
Code Review Comment
❌ SAI:
"Chỗ này có vẻ không ổn."
✅ ĐÚNG (BLUF + actionable):
"Line 42: Memory leak tiềm ẩn.
setInterval không được clear khi component unmount.
Fix: thêm return () => clearInterval(id) trong useEffect."
Giải Thích Technical Với Non-Tech
❌ SAI:
"Cần refactor vì technical debt đang accumulate,
coupling quá cao, vi phạm SOLID principles..."
✅ ĐÚNG (BLUF + Zoom In từ điều họ biết):
"Cần 1 sprint để dọn dẹp code — như bảo trì định kỳ.
Nếu không làm, feature mới sẽ mất gấp đôi thời gian.
[Nếu muốn biết thêm]: Cụ thể là..."
Đề Xuất Technical Decision Với Manager
Template:
[BLUF] "Recommend [option X] cho [vấn đề Y]."
[Why] "Vì [lý do 1], [lý do 2], [lý do 3]."
[Context] "Đã xem xét [option A], [option B]."
[Risk] "Trade-off: [điều cần đánh đổi]."
[Next] "Nếu đồng ý, bước tiếp theo là..."
📊 9. Tổng Kết — Cheat Sheet
| Tình huống | Method áp dụng |
|---|---|
| Báo cáo với manager | BLUF trước, details nếu được hỏi |
| Standup / status update | BLUF: done / doing / blocker |
| Code review comment | BLUF + line số + lý do + fix gợi ý |
| Giải thích technical với junior | Zoom In từ điều họ đã biết |
| Giải thích với non-tech | BLUF + ví dụ thực tế + tránh jargon |
| Đề xuất architecture | BLUF + Just-In-Time context theo role |
| Giải thích sâu khi được hỏi | Zoom In — dừng khi họ đủ để tiếp tục |
Mid vs Senior Perspective
MID-LEVEL:
"Giao tiếp = giải thích đầy đủ nhất có thể."
"Manager/stakeholder cần biết hết context."
"Giải thích kỹ thuật = dùng đúng thuật ngữ."
"Nói nhiều = pro hơn."
SENIOR:
"Giao tiếp = người nghe nhận được thứ họ cần."
"Manager cần biết status + blocker + next step."
"Kỹ thuật phức tạp → Zoom In từ điều họ biết."
"Nói ít nhưng đúng > nói nhiều mà lost."
"BLUF là respect với thời gian của người nghe."
"Just-In-Time: điều chỉnh context theo audience."
🎯 Nguyên Tắc Vàng
╔══════════════════════════════════════════════════════════╗
║ NGUYÊN TẮC VÀNG VỀ COMMUNICATION ║
║ ║
║ 1. Lead with the point — BLUF, không build-up ║
║ 2. Just enough context — điều chỉnh theo audience ║
║ 3. Zoom In — bắt đầu từ shared understanding ║
║ 4. Mục tiêu: người nghe hiểu — không phải bạn pro ║
║ 5. Pause & check — họ có đủ để tiếp tục không? ║
║ 6. Respect thời gian người nghe = respect họ ║
║ 7. Communication là skill — practice được ║
║ ║
╚══════════════════════════════════════════════════════════╝
📚 Tài Liệu Tham Khảo
- Video: Communication Skills for Engineers
- Guide: BLUF: The Military Standard That Will Make You a Better Writer
- Book: The Pyramid Principle — Barbara Minto (nền tảng của BLUF trong business writing)
“The single biggest problem in communication is the illusion that it has taken place.” — George Bernard Shaw