Cách Giao Tiếp Hiệu Quả Với Sếp

Có một pattern tôi nhận ra ở những developer chững lại sớm trong sự nghiệp.

Không phải họ code kém. Phần lớn trong số đó làm việc khá tốt. Nhưng mỗi khi cần báo cáo một vấn đề bị tắc, giải thích tại sao task bị trễ, hay xin quyết định từ sếp — họ hoặc kể từ đầu đến cuối mọi thứ họ đã làm, hoặc im lặng đến khi quá muộn.

Cả hai đều tệ như nhau.

Thời gian của sếp có hạn. Đầu óc họ bị chia cho nhiều người, nhiều việc, nhiều deadline. Học cách nói chuyện rõ ràng với cấp trên không phải là "điểm cộng thêm" — đó là một phần cốt lõi của việc làm việc hiệu quả trong team.

Đây là cách làm đúng.

1. Tóm Tắt Vấn Đề Trước — Đừng Kể Lại Hành Trình

Khi bạn bước vào phòng sếp (hoặc nhắn Slack) để hỏi, bản năng của bạn có thể là giải thích tất cả những gì mình đã làm. Từng bước. Từng lần thử. Từng ngõ cụt.

Cưỡng lại bản năng đó.

Sếp không cần nghe lại toàn bộ hành trình. Họ cần hiểu tình huống nhanh để có thể giúp bạn. Mở đầu bằng vấn đề, không phải bằng quá trình.

Thay vì:

"Thì em bắt đầu nhìn vào config file, rồi em check log, rồi em thử restart service, rồi em nghĩ có thể là network issue, nên em..."

Nói thế này:

"Bên production đang có vấn đề — payment service trả về lỗi 503 liên tục từ sau lần deploy gần nhất. Em đã loại trừ config và network rồi. Em nghĩ vấn đề nằm ở phần xử lý retry."

Một cách mất năm phút. Cách kia mất ba mươi giây và đã đến được trọng tâm.

Mục tiêu không phải là chứng minh bạn đã làm việc chăm chỉ. Mục tiêu là đến giải pháp nhanh nhất có thể.

2. Cung Cấp Thông Tin Chính Xác — Không Thiếu, Không Thừa

Sau khi đã nêu được vấn đề, hãy cho sếp đúng những thông tin họ cần để giúp bạn. Không phải mọi thứ bạn biết — chỉ những phần liên quan.

Cụ thể là:

Kỳ vọng ban đầu là gì?
Thực tế đang xảy ra gì?
Mức độ ảnh hưởng như thế nào? (Ai bị ảnh hưởng? Nặng đến đâu?)

Thiếu thông tin thì sếp sẽ phải hỏi lại. Thừa thông tin thì vấn đề chính bị chôn vùi trong đống chi tiết không cần thiết. Nhiệm vụ của bạn là tìm đúng lượng cần thiết.

Một cách trình bày hữu ích:

Kỳ vọng: Payment xác nhận trong vòng 2 giây
Thực tế: ~30% request bị timeout sau 10 giây
Ảnh hưởng: Khách hàng thấy màn hình thanh toán thất bại, số ticket hỗ trợ tăng 40%

Súc tích, dễ đọc, sếp có thể phản hồi ngay thay vì mất năm phút hỏi thêm.

3. Dùng Một Khung Giao Tiếp Nhất Quán

Mỗi khi cần báo cáo vấn đề tắc nghẽn hay xin quyết định, hãy trình bày theo cùng một cấu trúc. Điều này giúp sếp tin tưởng vào các báo cáo của bạn — họ biết cần chờ đợi gì và xử lý được nhanh hơn.

Một cấu trúc đáng tin cậy:

Kỳ vọng — Điều gì đáng lẽ phải xảy ra?
Thực trạng — Thực tế đang xảy ra gì?
Khoảng cách — Sự khác biệt là gì và tại sao nó quan trọng?
Các hướng giải quyết — Bạn đã cân nhắc những gì? (Nếu có ý tưởng)
Đánh đổi — Ưu/nhược điểm của từng hướng?
Những gì đã thử — Nếu đã thử gì đó rồi, kết quả như thế nào?

Không phải lúc nào cũng cần đủ sáu bước. Nhưng có cấu trúc này trong đầu có nghĩa là bạn sẽ không bao giờ vào gặp sếp mà chưa chuẩn bị.

Ví dụ thực tế:

API bên thứ ba đang giới hạn số lượng request khá nặng. Mình kỳ vọng được 1.000 request/phút; thực tế bị chặn ở mức 200. Em thấy hai hướng: một là tăng cường cache về phía mình, hai là thương lượng mức giới hạn cao hơn với bên cung cấp. Cache thì triển khai nhanh hơn nhưng có nguy cơ dữ liệu bị cũ; thương lượng lại quota có thể mất vài tuần. Em đã làm cache cơ bản rồi nhưng chỉ giảm được 30% số request — chưa đủ. Em muốn hỏi ý kiến anh trước khi đi tiếp.

Tin nhắn đó rõ ràng, đầy đủ, và chứng minh bạn đã suy nghĩ kỹ. Nó tôn trọng thời gian của sếp và cho thấy bạn là người chủ động giải quyết vấn đề, không chỉ đơn thuần báo cáo.

4. Thẳng Thắn — Thừa Nhận Những Gì Bạn Không Biết

Điều này đơn giản nhưng nhiều người lại rất khó làm: nói thẳng khi bạn không biết điều gì đó.

Đừng vòng vo. Đừng né tránh. Đừng cố giả vờ hiểu bằng cách nói quanh vấn đề.

Những sếp giỏi nhận ra ngay khi ai đó đang nói bừa. Và không gì phá vỡ niềm tin nhanh hơn việc thấy ai đó cố giấu việc mình đang không hiểu gì.

Nếu bạn không biết, hãy nói thẳng:

"Em chưa rõ — để em tìm hiểu thêm rồi báo lại anh."
"Em không chắc nên chọn hướng nào. Anh có thể giúp em suy nghĩ qua không?"
"Em có thể sai, nhưng theo hiểu biết hiện tại của em thì..."

Cần sự tự tin để làm được điều này, nhưng đây luôn là nước cờ đúng. Một developer thừa nhận điểm yếu và nhanh chóng lấp đầy nó có giá trị hơn vô số lần so với người ẩn náu sau những câu trả lời mập mờ.

Thừa nhận mình không biết là dấu hiệu của người trưởng thành, không phải của người yếu kém.

5. Suy Nghĩ Cho Sản Phẩm, Không Chỉ Cho Task Của Mình

Đây là điều phân biệt người kỹ sư giỏi với người kỹ sư xuất sắc.

Suy nghĩ cho sản phẩm có nghĩa là bạn quan tâm đến kết quả cuối cùng — cho người dùng, cho công ty, cho team — không chỉ là task của mình được đánh dấu hoàn thành. Nó thay đổi cách bạn giao tiếp hoàn toàn.

Thay vì: "Em làm xong feature rồi."

Bạn nói: "Feature đã lên production. Em đã test qua luồng chính và ba trường hợp đặc biệt mình đã bàn. Thời gian tải dưới 200ms. Em sẽ theo dõi tỷ lệ lỗi trong 24 giờ tới."

Thay vì: "Có bug."

Bạn nói: "Có bug ảnh hưởng đến người dùng đăng nhập bằng Google. Khoảng 8% người dùng của mình. Em đã xác định nguyên nhân và có bản fix sẵn rồi — chỉ muốn báo trước khi merge."

Cách giao tiếp đó cho thấy bạn nhìn thấy toàn cảnh. Rằng bạn không chỉ là người viết code — mà là người thực sự quan tâm đến thứ được đưa ra cho người dùng.

Sếp nhận ra điều này. Đây là một trong những cách nhanh nhất để chuyển từ "người thực thi đáng tin cậy" thành "người được tin tưởng giao việc lớn hơn."

Lời Kết

Giao tiếp là một kỹ năng, và như mọi kỹ năng khác, nó cải thiện theo thời gian nếu bạn luyện tập có ý thức.

Những gì chia sẻ ở đây không phức tạp: mở đầu bằng vấn đề, cung cấp thông tin đúng mức, trình bày nhất quán, thành thật về những gì bạn chưa biết, và suy nghĩ như người quan tâm đến sản phẩm.

Làm điều này đều đặn và bạn sẽ nổi bật — không phải vì bạn nói nhiều hơn hay hung hăng hơn, mà vì bạn làm cho công việc của sếp dễ hơn. Và đó chính xác là kiểu người được giao thêm trách nhiệm.

Điểm mấu chốt:
✅ Tóm tắt vấn đề trước — bỏ qua phần kể lại từng bước
✅ Cung cấp thông tin chính xác: kỳ vọng, thực tế, mức độ ảnh hưởng
✅ Dùng cấu trúc nhất quán: thực trạng → khoảng cách → hướng giải quyết → đánh đổi
✅ Thẳng thắn về những gì chưa biết — xây dựng niềm tin nhanh hơn nhiều so với nói bừa
✅ Suy nghĩ cho sản phẩm — quan tâm đến kết quả cuối, không chỉ hoàn thành task