Giao tiếp với PM, incident comms, mentoring và feedback

"Gần xong" là câu PM sợ nhất, vì nó không cho họ quyết định được gì. Bài này gom các tình huống giao tiếp senior gặp hằng ngày trên shop-app.

1. Bài toán

Tuần 3 của migrate payment:
  - PM cần biết: có kịp 30/11 không? cần anh làm gì?
  - CS team cần biết: khách hỏi refund thì nói gì?
  - Junior Hà đang kẹt webhook 2 ngày, không dám hỏi
  - Thứ Sáu: checkout lỗi 15 phút, sếp nhắn "chuyện gì vậy?"

2. Vấn đề

• Dev viết theo góc nhìn kỹ thuật ("refactor adapter"), người nghe cần góc nhìn kết quả ("có kịp không").
• Tin xấu báo muộn thì mất lựa chọn.
• Lúc incident, im lặng làm mọi người đoán và hỏi dồn, làm chậm người đang sửa.
• Senior ôm việc khó thay vì giao, junior không lớn.

3. Giải pháp: nguyên tắc chung

4. Mẫu dùng ngay

Mẫu 1: Status update hàng tuần (RAG)

Migrate Payment B — tuần 3/5 — 🟡 AMBER

Tóm tắt: Vẫn kịp 30/11 nếu B gửi sandbox webhook trước thứ Tư.
Xong tuần này: adapter B, feature flag, contract test.
Tuần sau: webhook + idempotency, refund đơn cũ.
Rủi ro: B chậm gửi webhook sandbox (đã hỏi 2 lần).
Cần: anh Minh (PM) escalate với account manager B trước thứ Ba.

So với "đang làm webhook, gần xong": PM biết ngay trạng thái, rủi ro và việc họ phải làm.

Mẫu 2: Incident comms (gửi kênh #incident mỗi 15–30 phút)

[14:05] 🔴 INVESTIGATING — Checkout lỗi ~40% từ 13:58.
Ảnh hưởng: khách không thanh toán được bằng thẻ. Ví vẫn OK.
Incident lead: Lan. Update tiếp: 14:20.

[14:20] 🟠 IDENTIFIED — Provider B trả timeout. Đã tắt flag
checkout.provider-b, route về A. Lỗi đang giảm.
Update tiếp: 14:35.

[14:35] 🟢 MONITORING — Lỗi về 0.1% (bình thường). ~180 đơn thất bại
13:58–14:12, CS đã có danh sách để liên hệ.
Postmortem: thứ Hai.

Một người viết comms, người khác sửa lỗi. Không đoán nguyên nhân khi chưa chắc. Chi tiết vai trò và postmortem xem bài Incident & postmortem.

Mẫu 3: Mentoring junior

1:1 với Hà (30 phút / 2 tuần)
  - Tuần này em kẹt chỗ nào?       (hỏi, đừng đoán)
  - Em muốn giỏi lên phần nào?      (mục tiêu của Hà, không phải của mình)
  - Một việc mình giao để em thử    (stretch nhưng an toàn)

Khi Hà hỏi bug:
  Không: "Để anh sửa cho."
  Có:    "Em đã thử gì? Log nói gì? Nếu là em, em check gì tiếp?"
         → gợi ý dần, chỉ đưa đáp án khi kẹt thật hoặc đang gấp

Thêm luật 30 phút: "Kẹt quá 30 phút thì hỏi, kèm những gì đã thử". Junior không phải đoán khi nào được phép hỏi.

Mẫu 4: Delegation theo mức độ

Giao kết quả cần đạt, không giao từng bước; nói rõ ràng buộc (deadline, phải có test, không đổi API public) và lịch check-in.

Mẫu 5: Feedback kiểu SBI (Situation – Behavior – Impact)

Feedback cải thiện:
  S: "Trong PR webhook hôm thứ Ba,
  B:  em merge khi CI còn đỏ phần contract test,
  I:  nên staging bị lỗi 2 tiếng, QA không test được.
  →  Lần sau mình đợi CI xanh nhé. Có gì làm em phải vội không?"

Feedback tích cực:
  S: "Trong incident thứ Sáu,
  B:  em đã tìm ra timeout của B trong log rất nhanh và nói ngay,
  I:  nhờ vậy mình tắt flag sớm 10 phút, ít khách bị ảnh hưởng hơn."

Khen nơi đông người, góp ý riêng. Gần sự việc, không đợi review cuối năm.

5. Cách hoạt động: ai cần biết gì

                 Chi tiết kỹ thuật
                        ^
   Dev team   ●         |
                        |
   QA / SRE      ●      |
                        |
   PM                ●  |
                        |
   CS / Sales            ●
                        |
   Sếp / Business          ●
                        +------------------------->  Tác động business
Càng xuống dưới: ít chi tiết, nhiều "ảnh hưởng gì, cần làm gì".

6. So sánh

7. Khi nào nên / không nên

• Nên sửa hộ junior khi đang incident. Dạy sau, trong postmortem hoặc 1:1.
• Không nên giao việc tự chủ hoàn toàn cho người chưa làm mức 2 bao giờ, nhất là đường tiền.
• Không nên dùng thuật ngữ kỹ thuật với CS/sales; nói bằng ảnh hưởng tới khách.

Đúng rồi, chuyện này hay gặp, và thường là vì PM thiếu thông tin, không phải vì họ không tin bạn. Cách xử lý là chủ động cho họ thông tin trước khi họ hỏi:

• Thống nhất nhịp: "Em gửi update 9h sáng hằng ngày trong kênh #payment-migration, có gì gấp em báo ngay."
• Cho họ chỗ tự xem: board Jira, dashboard rollout %.
• Hỏi thẳng: "Anh cần thông tin này để báo ai? Em format theo đó cho tiện."

Sau 1 tuần update đều đặn, câu hỏi mỗi 2 tiếng thường tự hết.

Bạn hiểu gần đúng: tự làm nhanh hơn lần này. Nhưng lần sau, lần sau nữa vẫn là bạn làm, và bạn thành nút thắt cổ chai. Cách cân:

Việc gấp + rủi ro cao (fix double charge hôm nay)  → mình làm, junior pair xem
Việc không gấp + rủi ro vừa (refund đơn cũ)        → junior làm mức 2, mình review thiết kế
Việc lặp lại (thêm provider mới sau này)           → junior own luôn

Cộng thêm buffer vào ước lượng cho phần học. Đó là đầu tư, và bạn nói rõ với PM như vậy.

Q1. Bạn giao tiếp với stakeholder không kỹ thuật thế nào?

🇻🇳 Tiếng Việt:

Em nói kết luận trước, rồi tác động và điều em cần từ họ. Em dùng ngôn ngữ business như ngày ra mắt, số khách bị ảnh hưởng, thay vì thuật ngữ kỹ thuật. Với dự án dài, em gửi update hằng tuần dạng xanh/vàng/đỏ, và báo rủi ro sớm kèm phương án để họ chọn.

🇬🇧 English:

I lead with the conclusion, then the impact and what I need from them. I use business language like launch dates and number of affected customers instead of jargon. For longer projects I send a weekly red/amber/green update, and I raise risks early together with options for them to choose from.

Q2. Bạn mentor junior ra sao?

🇻🇳 Tiếng Việt:

Em có 1:1 hai tuần một lần, hỏi họ muốn phát triển phần nào. Khi họ hỏi, em hỏi gợi mở trước thay vì sửa hộ. Em giao việc tăng dần mức tự chủ: từ làm theo thiết kế đến tự đề xuất rồi tự own. Ví dụ một junior trong team em từ viết adapter theo interface đã own luôn module refund sau ba tháng.

🇬🇧 English:

I hold a 1:1 every two weeks and ask what they want to grow in. When they ask for help, I ask guiding questions before giving answers. I delegate with increasing autonomy, from implementing a given design to proposing designs to owning a module. One junior on my team went from writing an adapter against an existing interface to owning the refund module within three months.

Q3. Bạn giao tiếp thế nào trong incident?

🇻🇳 Tiếng Việt:

Tách vai trò: một người sửa, một người viết comms. Em gửi update theo nhịp cố định gồm trạng thái, ảnh hưởng, việc đang làm và giờ update tiếp. Không đoán nguyên nhân khi chưa chắc. Xong thì viết postmortem không đổ lỗi.

🇬🇧 English:

I separate roles: one person fixes, one person handles communication. Updates go out on a fixed cadence with status, impact, current action and the next update time. We don't speculate about root cause. Afterwards we write a blameless postmortem.

Cách nhớ ngắn gọn

• Status: kết luận + RAG + rủi ro + ask.
• Incident: một người sửa, một người nói; update có giờ hẹn.
• Mentor: hỏi trước, giao tăng dần tự chủ.
• Feedback: SBI, khen công khai, góp ý riêng.