Mở đầu — vì sao bài này quan trọng
Bạn có một tầm nhìn kỹ thuật (tech vision) tuyệt vời: bạn muốn tách monolith thành microservices, đầu tư vào một internal platform, hay chuyển toàn bộ hệ thống lên event-driven architecture. Bạn đã suy nghĩ nhiều tháng, đọc hàng chục bài blog, vẽ đủ loại sơ đồ. Nhưng khi bạn trình bày với CEO, CFO hay Head of Sales, bạn nhận lại những ánh mắt trống rỗng, vài cái gật đầu lịch sự, rồi… ngân sách bị cắt, dự án không được ưu tiên, và team của bạn tiếp tục "chữa cháy" với hệ thống cũ.
Vấn đề không nằm ở tầm nhìn. Vấn đề nằm ở việc bạn communicate (truyền đạt) tầm nhìn đó tới đúng đối tượng, bằng đúng ngôn ngữ họ hiểu và quan tâm.
Đây là một trong những kỹ năng phân biệt rõ nhất giữa một senior engineer giỏi và một technical leader thực thụ. Một senior engineer có thể thuyết phục đồng nghiệp bằng RFC và design doc. Nhưng một technical leader phải bán được tầm nhìn kỹ thuật cho những người không phải dân kỹ thuật — những người nắm ngân sách, ưu tiên chiến lược, và quyết định số phận của dự án. Nếu bạn không làm được điều này, tầm nhìn của bạn mãi chỉ là một tài liệu đẹp nằm im trong Confluence.
Bài học này tập trung vào một câu hỏi cụ thể: Làm thế nào để truyền đạt tầm nhìn kỹ thuật cho các đối tượng khác nhau — đặc biệt là những người không có nền tảng kỹ thuật (non-tech)?
Khái niệm cốt lõi
Tech Vision là gì và không phải là gì
Tech vision là một bức tranh về trạng thái tương lai của hệ thống kỹ thuật, và lý do tại sao trạng thái đó phục vụ mục tiêu kinh doanh. Lưu ý: nó không phải là danh sách công nghệ (Kubernetes, Kafka, GraphQL...), cũng không phải là kiến trúc chi tiết. Đó là những thứ thuộc về cách thực thi. Tech vision trả lời câu hỏi "Chúng ta muốn hệ thống trông như thế nào trong 12–24 tháng tới, và điều đó giúp công ty đạt được gì?"
Ví dụ, một tech vision tồi: "Chúng ta sẽ migrate sang microservices với Kubernetes." Một tech vision tốt: "Chúng ta sẽ xây dựng nền tảng cho phép mỗi team ship tính năng độc lập, để công ty ra mắt sản phẩm mới nhanh gấp 3 lần mà không phá vỡ hệ thống hiện tại."
Bạn thấy sự khác biệt chứ? Cái đầu nói về công cụ. Cái sau nói về kết quả kinh doanh.
Nguyên tắc nền tảng: Audience hierarchy
Sai lầm chết người nhất là dùng cùng một cách trình bày cho mọi đối tượng. Mỗi nhóm khán giả có mối quan tâm, ngôn ngữ và định dạng ưa thích khác nhau. Đây là khung phân tầng đối tượng (audience hierarchy) mà bạn nên nằm lòng:
| Đối tượng | Họ quan tâm điều gì | Định dạng phù hợp | Ngôn ngữ nên dùng |
|---|---|---|---|
| Engineers | Chi tiết kỹ thuật + lý do | RFC, design doc, tech talk | Trade-off, kiến trúc, độ phức tạp |
| Engineering Managers / Leads | Effort, rủi ro, ảnh hưởng team | One-pager, roadmap slide | Timeline, dependency, resourcing |
| Product / Design | Ảnh hưởng tới trải nghiệm & tính năng | Storyboard, demo, before/after | Tốc độ ship, khả năng làm được gì mới |
| Executives (CEO/CTO/CFO) | Business outcome, tiền, rủi ro | 1 slide, analogy, số liệu ROI | Doanh thu, chi phí, thời gian ra thị trường, rủi ro |
| Board / Investors | Chiến lược, lợi thế cạnh tranh | Narrative, 1–2 slide | Tăng trưởng, moat, khả năng mở rộng |
- Bớt chi tiết kỹ thuật, thêm kết quả kinh doanh.
- Bớt "làm như thế nào", thêm "để làm gì".
- Rút ngắn thời lượng. CEO của bạn có thể chỉ cho bạn 5 phút, không phải 45 phút.
Ba đòn bẩy để truyền đạt với non-tech
1. Ngôn ngữ kinh doanh (business framing). Mọi thứ kỹ thuật đều phải được "dịch" sang một trong bốn thứ mà lãnh đạo quan tâm: tăng doanh thu, giảm chi phí, giảm rủi ro, hoặc tăng tốc độ. Nếu tầm nhìn của bạn không map được vào một trong bốn cái này, bạn chưa sẵn sàng trình bày.
2. Phép loại suy (analogy). Não người không giỏi xử lý khái niệm trừu tượng, nhưng rất giỏi so sánh với thứ quen thuộc. "Tech debt giống như vay nợ tín dụng — dùng được ngay nhưng lãi mẹ đẻ lãi con" là một câu mà bất kỳ CFO nào cũng hiểu ngay lập tức.
3. Số liệu và câu chuyện (metrics + narrative). Số liệu tạo độ tin cậy, câu chuyện tạo cảm xúc và ghi nhớ. Kết hợp cả hai: "Năm ngoái chúng ta mất 6 tuần chỉ để thêm một cổng thanh toán mới, và trong 6 tuần đó đối thủ đã ra mắt trước — với kiến trúc mới, việc này chỉ còn 3 ngày."
Tình huống thực tế
Tình huống 1: Tiki và bài toán "bán" việc tách monolith
Giả định một Tech Lead tại một sàn thương mại điện tử lớn ở Việt Nam (lấy bối cảnh giống Tiki). Hệ thống checkout là một monolith khổng lồ, mỗi lần deploy mất 2 tiếng và thường xuyên gây downtime trong giờ cao điểm — đặc biệt là các dịp sale lớn như 11/11 hay 12/12.
Lần đầu, Tech Lead trình bày với ban giám đốc bằng một slide đầy sơ đồ kiến trúc, nói về "bounded context", "service mesh", "eventual consistency". Kết quả: CFO hỏi "Cái này tốn bao nhiêu và mang lại gì?" và không ai trả lời được rõ ràng. Dự án bị hoãn.
Ba tháng sau, anh quay lại với một cách kể khác. Một slide duy nhất, với đúng ba con số:
- "Trong đợt sale 11/11 năm ngoái, hệ thống checkout sập 47 phút, ước tính mất 3,2 tỷ đồng doanh thu."
- "Mỗi lần deploy hiện tại, chúng ta phải khóa toàn bộ tính năng thanh toán."
- "Với kiến trúc mới, mỗi team deploy độc lập, downtime dự kiến giảm về gần 0, và thời gian ra tính năng mới nhanh gấp đôi."
Lần này dự án được duyệt trong 20 phút.
Bài học: Con số về tiền mất do downtime nói to hơn ngàn sơ đồ kiến trúc. Lãnh đạo không mua "microservices", họ mua "không mất 3,2 tỷ trong đợt sale tới".
Tình huống 2: Startup fintech và cuộc chiến với Product về "quý refactor"
Một startup fintech ở TP.HCM có 25 engineer. Tech Lead nhận ra codebase đã tích lũy quá nhiều nợ kỹ thuật, tốc độ ship tính năng chậm dần: một tính năng từng mất 1 tuần giờ mất 3 tuần. Anh muốn dành trọn một quý để dọn dẹp nền tảng.
Product Manager phản đối gay gắt: "Cả một quý không có tính năng mới? Khách hàng sẽ bỏ chúng ta." Đây là xung đột kinh điển giữa tech vision và áp lực sản phẩm ngắn hạn.
Thay vì tranh cãi về kỹ thuật, Tech Lead làm một biểu đồ đơn giản mà PM và cả CEO đều hiểu: trục hoành là thời gian, trục tung là "số ngày trung bình để ship một tính năng". Đường biểu diễn đi lên đều đặn trong 12 tháng — từ 5 ngày lên 15 ngày. Anh nói: "Nếu chúng ta không làm gì, đến cuối năm sau mỗi tính năng sẽ mất một tháng. Refactor một quý bây giờ giống như thay dầu và bảo dưỡng xe — nghỉ một ngày để khỏi hỏng máy giữa đường."
Anh cũng không xin trọn một quý. Anh đề xuất phương án "70/30": 70% năng lực vẫn ship tính năng, 30% dành cho nền tảng, kéo dài hai quý. Đây là kỹ thuật giảm rủi ro cảm nhận cho non-tech: đề xuất một bước đi khả nghịch, có kiểm chứng, thay vì một cú nhảy lớn.
Bài học: Với non-tech, hãy biến thứ trừu tượng (tech debt) thành một đường xu hướng họ nhìn thấy được, và luôn đề xuất phương án giảm rủi ro thay vì "được ăn cả ngã về không".
Tình huống 3: Truyền đạt tầm nhìn "AI-first" cho Head of Sales
Một công ty SaaS B2B ở Singapore muốn tái cấu trúc nền tảng dữ liệu để có thể tích hợp AI vào sản phẩm. Tech Lead cần sự ủng hộ của Head of Sales — người kiểm soát một phần lớn ngân sách vì doanh thu đến từ team này.
Head of Sales không quan tâm "vector database" hay "data pipeline". Nên Tech Lead framing hoàn toàn theo góc bán hàng: "Hiện tại mỗi khi khách hàng lớn hỏi 'sản phẩm có tính năng AI không', chúng ta phải trả lời không, và mất deal. Quý vừa rồi chúng ta mất 4 deal lớn vì lý do này, tổng giá trị 800.000 USD. Nền tảng dữ liệu mới cho phép chúng ta ship tính năng AI trong 2 tháng thay vì 8 tháng, và mỗi tính năng đó trở thành một điểm bán mới."
Head of Sales lập tức trở thành người ủng hộ mạnh nhất, thậm chí còn thúc đẩy ban giám đốc duyệt ngân sách.
Bài học: Tìm ra người mà tầm nhìn của bạn giúp họ đạt mục tiêu của họ, rồi biến họ thành đồng minh. Đôi khi người bán tech vision hiệu quả nhất không phải là bạn, mà là một stakeholder non-tech mà bạn đã thuyết phục.
Hướng dẫn từng bước
Đây là quy trình 6 bước để chuẩn bị và truyền đạt một tech vision tới đối tượng non-tech:
Bước 1 — Xác định "so what" kinh doanh. Trước khi mở slide, viết ra một câu: "Nếu chúng ta làm điều này, công ty sẽ [tăng doanh thu / giảm chi phí / giảm rủi ro / tăng tốc độ] bằng cách nào và bao nhiêu?" Nếu không viết được, đừng trình bày vội.
Bước 2 — Lập bản đồ đối tượng. Với mỗi buổi trình bày, liệt kê ai sẽ nghe, họ quan tâm gì, họ có quyền quyết định gì. Dùng bảng audience hierarchy ở trên. Chuẩn bị "phiên bản" khác nhau cho từng nhóm.
Bước 3 — Chọn một thông điệp trung tâm. Một buổi trình bày chỉ nên có MỘT ý chính mà bạn muốn người nghe nhớ. Nếu họ chỉ nhớ một câu sau buổi họp, câu đó là gì?
Bước 4 — Dịch sang analogy + số liệu. Với mỗi khái niệm kỹ thuật, chuẩn bị một phép loại suy đời thường và ít nhất một con số có thật. Tránh mọi thuật ngữ mà một người ngoài ngành không hiểu.
Bước 5 — Cấu trúc theo mô hình "Vấn đề → Chi phí của việc không làm → Tầm nhìn → Bước đi đầu tiên". Đặc biệt nhấn mạnh "chi phí của việc không làm gì" (cost of inaction) — đây là đòn bẩy mạnh nhất với lãnh đạo.
Bước 6 — Kết bằng một "ask" cụ thể. Đừng kết thúc mơ hồ. Nói rõ bạn cần gì: "Tôi xin phê duyệt cho 2 kỹ sư làm việc này trong 8 tuần, với mục tiêu review lại kết quả vào cuối quý." Một ask rõ ràng dễ được đồng ý hơn một tầm nhìn hoành tráng không có điểm khởi đầu.
Lỗi thường gặp & mẹo
Lỗi 1 — Trút hết chi tiết kỹ thuật. Nhiều engineer nghĩ càng nhiều chi tiết càng thuyết phục. Ngược lại: với non-tech, mỗi thuật ngữ khó hiểu là một lần bạn mất họ. Mẹo: nếu bà/mẹ bạn không hiểu câu đó, đừng đưa vào slide cho executive.
Lỗi 2 — Không nói "chi phí của việc không làm gì". Bạn mô tả tương lai tươi đẹp nhưng quên nói điều gì sẽ xảy ra nếu công ty không hành động. Không có sự cấp bách thì không có quyết định. Luôn định lượng cái giá của status quo.
Lỗi 3 — Bán công nghệ thay vì bán kết quả. "Chúng ta cần Kafka" là bán công nghệ. "Chúng ta cần xử lý được 10.000 đơn/giây trong đợt sale mà không sập" là bán kết quả. Non-tech chỉ mua cái sau.
Lỗi 4 — Một slide dùng cho mọi đối tượng. Bộ slide bạn dùng cho team engineering sẽ giết chết buổi họp với board. Luôn tạo phiên bản riêng.
Lỗi 5 — Trình bày như một sự kiện một lần. Tech vision không được "bán" trong một buổi họp. Nó cần được nhắc đi nhắc lại, trong all-hands, trong các cuộc trò chuyện 1:1, cho đến khi nó trở thành ngôn ngữ chung.
Mẹo bonus — "Pre-wire" trước cuộc họp lớn. Đừng để buổi trình bày chính thức là lần đầu lãnh đạo nghe về tầm nhìn của bạn. Hãy gặp riêng từng người quan trọng trước, lắng nghe phản đối, điều chỉnh. Đến buổi họp chính, quyết định gần như đã có sẵn. Đây là bí mật của mọi technical leader lão luyện.
Bài tập thực hành
- Bài tập "một câu". Chọn một tech vision bạn đang ấp ủ (hoặc một cái giả định). Viết nó thành đúng một câu, dưới góc nhìn business outcome, không dùng bất kỳ thuật ngữ kỹ thuật nào. Ví dụ mẫu: "Đầu tư vào X sẽ giúp công ty ra tính năng mới nhanh gấp đôi và giảm 30% chi phí vận hành hạ tầng."
- Bài tập audience hierarchy. Lấy chính tầm nhìn đó, viết ba phiên bản pitch khác nhau — mỗi phiên bản tối đa 3 câu — cho: (a) đội engineering, (b) Product Manager, (c) CEO. So sánh sự khác biệt về ngôn ngữ và trọng tâm.
- Bài tập analogy. Tìm một phép loại suy đời thường cho một khái niệm kỹ thuật (tech debt, latency, scalability, security risk...) mà một người hoàn toàn ngoài ngành hiểu được trong 10 giây. Thử nói nó ra miệng với một người bạn không làm IT và xem họ có "à" ra không.
- Bài tập cost of inaction. Với tầm nhìn của bạn, định lượng cái giá của việc KHÔNG làm gì trong 12 tháng tới — bằng tiền, thời gian, hoặc rủi ro cụ thể. Nếu bạn không định lượng được, hãy tìm dữ liệu để định lượng.
Tóm tắt
Truyền đạt tech vision cho non-tech không phải là làm loãng nội dung kỹ thuật, mà là dịch nó sang ngôn ngữ và mối quan tâm của người nghe. Những điểm cốt lõi cần nhớ:
- Tech vision là về kết quả kinh doanh, không phải công nghệ. Luôn map về tăng doanh thu, giảm chi phí, giảm rủi ro, hoặc tăng tốc độ.
- Áp dụng audience hierarchy: càng lên cao càng bớt chi tiết, thêm business outcome, và rút ngắn thời lượng.
- Ba đòn bẩy: business framing, analogy, và metrics + narrative.
- Luôn nói "chi phí của việc không làm gì" để tạo sự cấp bách.
- Kết thúc bằng một ask cụ thể, và pre-wire các stakeholder quan trọng trước buổi họp chính.