Mở đầu — vì sao bài này quan trọng
Nếu bạn làm kỹ thuật tại một công ty Việt Nam, khả năng rất cao là sếp cao nhất của bạn — founder, CEO, hay giám đốc — xuất thân từ kinh doanh, bán hàng, tài chính, hoặc marketing, chứ không phải từ code. Đây không phải ngoại lệ mà là chuẩn mực ở phần lớn startup và doanh nghiệp vừa và nhỏ tại Việt Nam. Người đó có tầm nhìn, có tiền, có quan hệ, có khách hàng — nhưng khi bạn nói "chúng ta cần refactor cái legacy monolith vì technical debt đang làm chậm velocity", họ nghe như bạn đang nói tiếng nước ngoài.
Khoảng cách ngôn ngữ này chính là nơi sự nghiệp kỹ thuật của bạn hoặc cất cánh, hoặc mắc kẹt. Kỹ sư giỏi mà không "manage up" được với sếp non-tech thường bị đánh giá là "làm việc thì được nhưng khó nói chuyện", bị gạt khỏi các quyết định quan trọng, và cay đắng nhất: những đề xuất kỹ thuật đúng đắn của họ bị từ chối chỉ vì không được diễn giải đúng cách.
"Managing up" không phải là nịnh sếp hay chính trị văn phòng. Đó là kỹ năng chủ động giúp cấp trên của bạn ra quyết định tốt hơn bằng cách cung cấp thông tin đúng, đúng lúc, đúng ngôn ngữ họ hiểu. Với sếp non-tech, phần khó nhất — và cũng là giá trị lớn nhất bạn tạo ra — là việc dịch (translation): biến những thứ trừu tượng về mặt kỹ thuật thành thứ liên quan trực tiếp đến tiền, khách hàng, rủi ro và thời gian. Bài này tập trung hoàn toàn vào nghệ thuật dịch đó.
Khái niệm cốt lõi
Sếp non-tech không quan tâm "cái gì", họ quan tâm "vậy thì sao"
Đây là nguyên tắc nền tảng. Khi bạn nói với sếp về một vấn đề kỹ thuật, trong đầu họ luôn chạy một câu hỏi ngầm: "So what? Điều này ảnh hưởng gì đến những thứ tôi phải lo?". Những thứ sếp non-tech phải lo thường quy về bốn nhóm:
- Tiền (doanh thu, chi phí, dòng tiền, runway).
- Khách hàng (giữ chân, mất khách, trải nghiệm, uy tín).
- Thời gian (bao giờ xong, kịp deadline ra mắt không).
- Rủi ro (nguy cơ sập hệ thống, mất dữ liệu, lộ thông tin, kiện tụng).
Bảng dịch thuật — mô hình tư duy quan trọng nhất của bài
Hãy tập thói quen mỗi lần định nói một câu kỹ thuật, bạn tự dịch nó sang tác động kinh doanh:
| Bạn muốn nói (tech) | Dịch cho sếp non-tech |
|---|---|
| "Cần trả technical debt" | "Mỗi tính năng mới hiện tốn gấp đôi thời gian so với năm ngoái; nếu ta dành 3 tuần dọn dẹp, tốc độ ra tính năng sẽ nhanh lại 40%" |
| "Test coverage thấp" | "Cứ mỗi lần sửa một chỗ, ta có nguy cơ làm hỏng chỗ khác mà không biết, dẫn tới lỗi khách hàng nhìn thấy" |
| "Cần migrate lên cloud/microservices" | "Chi phí server hiện tăng 15%/tháng theo lượng người dùng; kiến trúc mới giúp chi phí tăng chậm hơn và ít downtime hơn" |
| "Estimate là 3 tuần nhưng có nhiều unknown" | "Phần chắc chắn mất 3 tuần. Có một số điểm ta chưa từng làm nên có thể phát sinh; realistic là 3–5 tuần, tôi sẽ báo lại sau tuần đầu" |
| "API bên thứ ba không ổn định" | "Tính năng thanh toán phụ thuộc đối tác X; khi họ trục trặc, khách ta không thanh toán được và đó không nằm trong tầm kiểm soát của mình" |
Ba vai trò bạn đóng khi manage up
- Người dịch (Translator): biến tech thành business impact như trên.
- Người cảnh báo sớm (Early warning system): sếp non-tech ghét bất ngờ. Rủi ro lớn nhất với họ không phải là tin xấu, mà là tin xấu đến muộn. Vai trò của bạn là đưa ra tín hiệu sớm, có mức độ, để họ còn kịp xoay xở.
- Người đưa lựa chọn (Options-giver): đừng chỉ mang vấn đề đến. Sếp non-tech không có đủ kiến thức kỹ thuật để tự nghĩ ra giải pháp, nên nếu bạn chỉ than "cái này khó lắm", bạn đang đẩy gánh nặng ngược lên người ít khả năng xử lý nhất. Hãy mang theo 2–3 phương án kèm đánh đổi.
Nguyên tắc "no surprises" và giao tiếp theo nhịp
Với sếp non-tech, sự tin tưởng được xây bằng tính dự đoán được (predictability). Họ cần cảm giác "đội kỹ thuật này luôn nói cho tôi biết điều tôi cần biết, đúng lúc". Điều này đạt được không phải bằng những cuộc họp dài mà bằng nhịp giao tiếp đều đặn, ngắn gọn: một update ngắn mỗi tuần, một tín hiệu ngay khi có rủi ro, một bản tóm tắt sau mỗi cột mốc.
Tình huống thực tế
Tình huống 1 — Founder sales và cuộc chiến technical debt
Minh là tech lead tại một startup thương mại điện tử ở TP.HCM, khoảng 25 người, founder là anh Tuấn — dân sales kỳ cựu, từng bán bảo hiểm và bất động sản. Sản phẩm chạy trên một codebase PHP viết vội từ 3 năm trước. Mỗi tính năng mới ngày càng chậm, bug ngày càng nhiều.
Minh vào phòng anh Tuấn và nói: "Anh ơi, code của mình technical debt nặng lắm rồi, cần refactor toàn bộ, em cần 2 tháng không làm feature mới." Anh Tuấn nghe xong, mặt lạnh: "2 tháng không có gì mới để bán? Không được. Khách đang chờ tính năng loyalty point kìa."
Minh về, ức chế, nghĩ sếp không hiểu gì. Nhưng sau khi bình tĩnh, cậu làm lại. Lần thứ hai, Minh mang theo một tờ A4 với ba con số: (1) sáu tháng trước, một tính năng cỡ trung mất trung bình 5 ngày; giờ mất 11 ngày. (2) Số bug khách báo tăng từ 8 lên 23 mỗi tháng. (3) Đội đang dành 40% thời gian chỉ để chữa cháy. Rồi cậu nói: "Em không xin dừng 2 tháng. Em đề xuất: dành 20% thời gian mỗi sprint để dọn dần trong 3 tháng. Tính năng mới vẫn ra, chỉ chậm hơn chút, nhưng đến quý sau tốc độ ra tính năng sẽ nhanh gần gấp đôi hiện tại. Đây là cách ta vừa bán được vừa không tự bóp nghẹt mình."
Anh Tuấn gật đầu ngay. Bài học: lần một Minh nói bằng ngôn ngữ tech ("refactor", "technical debt") và đòi một cái giá kinh doanh khổng lồ (dừng feature 2 tháng). Lần hai, cậu dịch sang tốc độ giao hàng và số bug (thứ sếp cảm nhận được), rồi đưa một phương án có nhịp thay vì một tối hậu thư.
Tình huống 2 — Báo tin xấu về deadline mà không mất niềm tin
Chị Lan là CEO một công ty fintech ở Hà Nội, xuất thân ngân hàng. Đội của bạn đã cam kết ra mắt tính năng eKYC (định danh khách hàng điện tử) trước ngày 30/6 để kịp một hợp đồng với đối tác. Đến giữa tháng 6, đội phát hiện SDK nhận diện khuôn mặt của nhà cung cấp có vấn đề tương thích, ước tính trễ 2 tuần.
Cách sai: im lặng cày cuốc, hy vọng gỡ kịp, và đến 29/6 mới báo "em không kịp rồi chị ơi". Đây là ác mộng với sếp non-tech vì họ đã hứa với đối tác dựa trên lời hứa của bạn.
Cách đúng mà tech lead Hùng đã làm: ngay ngày phát hiện, cậu nhắn chị Lan xin 15 phút. Cậu nói: "Chị ơi, em báo sớm để mình còn đường xoay. SDK nhận diện của nhà cung cấp Y bị lỗi tương thích, không phải lỗi đội mình nhưng nó chặn tiến độ. Em có ba phương án: (A) chờ họ fix, an toàn nhất nhưng trễ 2 tuần, ra mắt 14/7. (B) Đổi sang nhà cung cấp Z, ra kịp 30/6 nhưng chi phí cao hơn 40 triệu/tháng và độ chính xác thấp hơn chút. (C) Ra mắt 30/6 với bản làm KYC thủ công tạm thời cho 100 khách đầu, tự động hóa sau. Em nghiêng về phương án C vì giữ được lời hứa với đối tác mà không đội chi phí. Chị thấy sao?"
Chị Lan chọn C, chủ động báo đối tác rằng giai đoạn đầu sẽ có hỗ trợ thủ công như một "dịch vụ VIP", biến điểm yếu thành điểm mạnh. Bài học: báo sớm + gọi đúng bản chất (đây là rủi ro từ bên thứ ba, không đổ lỗi cũng không giấu) + mang lựa chọn có đánh đổi rõ ràng + có khuyến nghị của riêng bạn. Sếp non-tech không cần bạn hoàn hảo; họ cần bạn đáng tin và không làm họ bị bất ngờ trước mặt đối tác.
Tình huống 3 — Khi sếp đòi một thứ "đơn giản" mà không hề đơn giản
Anh Đức, giám đốc một chuỗi F&B, thấy đối thủ có app đặt bàn và bảo đội IT nội bộ (3 người): "Làm cho anh cái app như Grab, tuần sau có nhé, đơn giản mà." Với người non-tech, "app đặt bàn" nghe đơn giản như một cái menu.
Bạn không thể nói "anh không hiểu gì cả, cái này phức tạp lắm" — đó là cách nhanh nhất để mất uy tín. Trưởng nhóm là Nam đã làm thế này: "Em hiểu ý anh, để em phác cho anh thấy 'cái app như Grab' gồm những mảnh gì nhé." Rồi Nam vẽ nhanh: phần khách đặt bàn (1 tuần), phần nhà hàng nhận và xác nhận (1 tuần), thanh toán online (2 tuần vì phải tích hợp cổng và kiểm thử bảo mật), thông báo real-time (1 tuần). "Nếu tuần sau anh cần demo để đi gặp nhà đầu tư, em làm được phần khách đặt bàn thôi, đủ để trình diễn. Còn bản chạy thật với thanh toán thì cần khoảng 5 tuần. Anh muốn ưu tiên cái nào trước?"
Anh Đức à lên, hóa ra cậu chỉ cần bản demo cho nhà đầu tư. Bài học: thay vì phản bác độ khó, hãy bóc tách yêu cầu thành các mảnh có thời gian cụ thể, để chính sếp nhìn thấy độ phức tạp mà không cần bạn nói "khó". Đồng thời hỏi ngược để tìm nhu cầu thật đằng sau (họ cần demo, không cần sản phẩm hoàn chỉnh).
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng cho gần như mọi cuộc "manage up" với sếp non-tech:
- Xác định nhu cầu kinh doanh thật sự trước khi mở miệng. Hỏi bản thân: quyết định này ảnh hưởng đến tiền, khách, thời gian hay rủi ro của sếp như thế nào? Nếu bạn không trả lời được, bạn chưa sẵn sàng nói chuyện.
- Dịch thông điệp sang ngôn ngữ tác động. Bắt đầu bằng kết luận và tác động, không phải bằng chi tiết kỹ thuật. Nói "điều này khiến ta mất khoảng X" trước, rồi mới giải thích lý do nếu họ hỏi. Đây là nguyên tắc "bottom line up front".
- Bỏ jargon, dùng ẩn dụ đời thường. "Technical debt" thành "nợ mua đồ rẻ mau hỏng, càng để lâu càng tốn tiền sửa". "Scaling" thành "chuẩn bị nhà hàng đón lượng khách gấp 10 vào dịp lễ".
- Luôn mang 2–3 phương án kèm đánh đổi. Mỗi phương án ghi rõ: mất bao lâu, tốn bao nhiêu, được gì, mất gì. Và luôn kèm khuyến nghị của bạn — sếp thuê bạn để có chính kiến, không phải để bạn đẩy trách nhiệm.
- Báo sớm, báo theo mức độ. Đừng chờ chắc chắn 100% mới báo tin xấu. Một tín hiệu "em thấy có rủi ro trễ, đang theo dõi" ở tuần 1 quý giá hơn nhiều một lời thú nhận ở tuần cuối.
- Thiết lập nhịp giao tiếp đều đặn. Một weekly update ngắn 5 dòng (làm được gì, sắp làm gì, có gì cản trở, có gì cần sếp quyết) tạo ra sự tin tưởng bền vững hơn mọi bài thuyết trình hoành tráng.
- Đóng vòng lặp (close the loop). Sau khi sếp quyết, báo lại kết quả. "Anh nhớ vụ mình chọn phương án C không, giờ nó chạy tốt, khách phản hồi tích cực." Điều này dạy sếp rằng lời khuyên của bạn đáng tin, và lần sau họ sẽ nghe bạn nhiều hơn.
Lỗi thường gặp & mẹo
Lỗi 1 — Trút hết chi tiết kỹ thuật để chứng minh mình giỏi. Nhiều kỹ sư nghĩ càng nói nhiều thuật ngữ càng được nể. Thực tế ngược lại: sếp non-tech cảm thấy bị nói xuống nước hoặc bị làm cho rối, và mất tin tưởng. Mẹo: nếu sếp chưa hỏi "tại sao", đừng giải thích cơ chế.
Lỗi 2 — Chỉ mang vấn đề, không mang giải pháp. "Cái này khó lắm anh", "server hay sập lắm" mà không có đề xuất khiến bạn trở thành người gây lo lắng chứ không phải người giải quyết. Luôn kết thúc bằng "và đây là điều em đề xuất mình làm".
Lỗi 3 — Nói "không thể" thay vì "đánh đổi". Rất ít thứ trong kỹ thuật là "không thể"; hầu hết là "được, nhưng tốn thời gian/tiền/chất lượng". Trình bày dạng đánh đổi cho sếp tự chọn thay vì đóng cửa.
Lỗi 4 — Giấu tin xấu vì sợ. Đây là lỗi phá hủy sự nghiệp nhanh nhất. Sếp non-tech tha thứ cho trục trặc kỹ thuật, nhưng không tha thứ cho việc bị bất ngờ trước khách hàng hay nhà đầu tư.
Lỗi 5 — Nói theo trục sai. Đừng dùng trục "code đẹp hơn" với một CEO đang lo dòng tiền. Hãy đọc xem sếp của bạn ưu tiên trục nào (tiền, khách, thời gian, rủi ro) và dịch theo đúng trục đó.
Mẹo vàng: Trước mỗi cuộc họp quan trọng, viết ra một câu duy nhất — "điều tôi muốn sếp quyết là gì, và tại sao điều đó tốt cho việc kinh doanh". Nếu bạn không viết được câu đó gọn gàng, bạn chưa nên vào phòng họp.
Bài tập thực hành
- Lập bảng dịch của riêng bạn. Liệt kê 5 vấn đề kỹ thuật đang tồn tại trong dự án hiện tại của bạn. Với mỗi cái, viết một câu dịch sang tác động kinh doanh theo đúng một trong bốn trục (tiền/khách/thời gian/rủi ro). Loại bỏ hết jargon.
- Viết lại một câu. Lấy câu này: "Chúng ta cần nâng cấp database vì đang bị bottleneck ở query performance khi số record vượt 1 triệu." Viết lại thành một câu mà một CEO bán lẻ sẽ hiểu và quan tâm.
- Dựng kịch bản 3 phương án. Chọn một quyết định kỹ thuật sắp tới của đội bạn. Viết ra 3 phương án, mỗi phương án gồm: thời gian, chi phí, lợi ích, đánh đổi. Kết thúc bằng một khuyến nghị rõ ràng của bạn kèm lý do kinh doanh.
- Soạn mẫu weekly update. Viết một bản update 5 dòng gửi sếp non-tech: đã làm gì, sắp làm gì, rủi ro nào, cần sếp quyết gì. Dùng ngôn ngữ hoàn toàn không kỹ thuật. Thử gửi thật trong tuần này.
- Diễn tập báo tin xấu. Tưởng tượng dự án của bạn sắp trễ deadline 2 tuần. Viết ra kịch bản bạn sẽ nói với sếp: mở đầu thế nào, gọi tên vấn đề ra sao, đưa mấy lựa chọn, khuyến nghị gì.
Tóm tắt
Ở phần lớn công ty Việt Nam, sếp cao nhất của bạn là người non-tech, và giá trị lớn nhất bạn tạo ra khi manage up chính là dịch thuật: biến điều trừu tượng về kỹ thuật thành điều cụ thể về tiền, khách hàng, thời gian và rủi ro. Sếp không quan tâm "cái gì", họ quan tâm "vậy thì sao".
Ba vai trò cần đóng: người dịch, hệ thống cảnh báo sớm, và người đưa lựa chọn. Ba nguyên tắc cần khắc cốt: bắt đầu bằng tác động chứ không phải chi tiết, luôn mang phương án kèm đánh đổi và khuyến nghị, và tuyệt đối không để sếp bị bất ngờ. Sự tin tưởng của sếp non-tech không được xây bằng sự hoàn hảo mà bằng tính dự đoán được — một nhịp giao tiếp đều đặn, trung thực và luôn hướng về việc kinh doanh. Khi bạn làm được điều này, bạn không chỉ là người viết code giỏi; bạn trở thành người mà cả ban lãnh đạo muốn có mặt trong mọi quyết định quan trọng.