Presales - Khi kỹ sư không chỉ viết code
Một hướng đi khác cho những ai không muốn code mãi, cũng chưa chắc muốn làm quản lý.
Intro
Làm kỹ sư phần mềm được vài năm, mình bắt đầu nhận ra công việc không chỉ xoay quanh việc code nữa.
Ban đầu là review kiến trúc, rồi được nhờ hỗ trợ viết proposal, giải thích solution cho bên non-tech, tham gia họp với khách hàng cùng team sales. Lúc đó mình nghĩ đơn giản: "À chắc tại mình hiểu hệ thống, nên đi cùng cho tiện."
Mình tưởng đó chỉ là phần việc phát sinh, tạm thời. Nhưng càng làm, mình càng thấy... cũng ổn (ít nhất là 70%😅). Và rồi một hôm, mình mới biết đến khái niệm Presales — và hoá ra mình đã làm nó từ lúc nào không hay.
Vai trò này không nằm trong career path ban đầu của mình. Không ai dạy bạn cách làm nó trong trường, hay thậm chí trong các buổi đào tạo nội bộ.
Bài viết này là để chia sẻ một chút về hiểu biết và trải nghiệm trên hành trình đó – một hướng đi thứ ba ít được nhắc đến: Presales / Sales Engineer.
📦 Bài viết gồm 3 phần chính (thực ra là bạn có thể skip tới phần bạn cần nếu lười, I’m fine 🫠):
Career Paths – những hướng đi phổ biến dành cho kỹ sư phần mềm.
Giới thiệu về Presales – vai trò, kỹ năng, trải nghiệm thực tế.
Ai cũng phải học cách “bán” một điều gì đó – không riêng gì dân Sales.
Bắt đầu nhé! 🚀
👨🏻💻 Trước khi đi vào chi tiết...
Nếu đây là lần đầu bạn đọc newsletter này, thì xin tự giới thiệu:
Mình là Bryant (Dũng) 👨🏻💻 host của Growth Engineering Journal - nơi mình chia sẻ mỗi tuần về tư duy phát triển bản thân, kỹ năng làm việc, và những thứ hay ho dành cho kỹ sư phần mềm. 😜.
Nếu bạn chưa subscribe thì đây là 4 bài viết gần nhất bạn đã bỏ lỡ:
📩 Đừng để lỡ những bài viết thú vị tiếp theo – subscribe ngay để nhận những chia sẻ mới nhất mỗi tuần nhé!
I. The Career Paths 🛣️
Khi làm kỹ sư phần mềm đủ lâu, bạn sẽ thấy mình không còn chỉ ngồi fix bug hay code task nữa. Bạn bắt đầu tham gia thiết kế hệ thống, phối hợp với product, hỗ trợ các bạn junior… và rồi một câu hỏi sẽ bắt đầu xuất hiện trong đầu:
🧐 “What's next?”Thành thật mà nói, không ai có thể đưa ra câu trả lời chắc chắn cho bạn cả.
Sự nghiệp trong ngành tech không hề tuyến tính.
Không phải ai cũng đi theo lộ trình chuẩn: junior → senior → tech lead → manager → director.
Nhiều người rẽ ngang, có người vòng lại, thậm chí có người bỏ hẳn để làm thứ hoàn toàn khác (vài đứa bạn mình chuyển sang làm KOL, bán đất, streamer hoặc…tốt nghiệp đại học rồi đi tu 🧘♂️. Cuộc đời mà 🥲).
Dựa trên những gì mình từng trải qua và cả những buổi trà đá nghe anh em tâm sự thất nghiệp 🤐 thì có ba hướng đi phổ biến mà mình thấy kỹ sư phần mềm thường cân nhắc khi đến ngã ba (hoặc ngã tư, năm, sáu gì đó của sự nghiệp 🤡):
1. 🔧 Đi sâu vào kĩ thuật
📌 Senior → Staff → Principal Engineer, hoặc System Architect.
Đây là hướng dành cho những người thực sự mê kỹ thuật – thích hiểu sâu, tối ưu từng chi tiết, và giải những bài toán hóc búa mà không phải ai cũng dám đụng vào.
Bạn sẽ làm gì?
Đào sâu vào kiến trúc hệ thống, performance, security, availability — tất tần tật những thứ liên quan tới technical.
Giải các bài toán khó và ảnh hưởng qua thiết kế hệ thống, tư vấn kiến trúc, mentorship kỹ thuật.
✅ Cái được:
Giữ được "chất kỹ sư" thuần túy — được làm thứ mình giỏi và yêu thích.
Gần với tech mới, problem thú vị, và tầm ảnh hưởng kỹ thuật rất cao.
Có thể trở thành “core member” trong một số domain nhất định.
⚠️ Cái mất:
Ảnh hưởng đến business đôi khi bị gián tiếp. Khó được nhìn nhận đúng và đủ khi tới kì performance review.
Học, học nữa, học mãi…nếu không muốn bị lỗi thời nhanh chóng.
Nếu không chủ động mở rộng mối quan hệ, dễ bị bó hẹp trong vùng an toàn kỹ thuật.
2. Chuyển sang quản lý (Engineering Management)
📌 Tech Lead → Engineering Manager → Director of Engineering/Delivery Manager
Nếu bạn quan tâm đến việc xây dựng team, phát triển con người, tối ưu quy trình và giúp đội ngũ vận hành trơn tru — đây có thể là lựa chọn dành cho bạn.
Bạn sẽ làm gì?
Tuyển người, build team, giao việc, mentoring, coaching…bạn làm đủ.
Gỡ rối vấn đề team gặp phải – cả kỹ thuật lẫn con người.
Làm việc nhiều với leadership, PM, khách hàng, để định hướng sản phẩm và tổ chức.
✅ Cái được:
Tác động rõ ràng đến team, văn hoá, kết quả sản phẩm.
Học được kỹ năng lãnh đạo, quản trị, giao tiếp – cần thiết nếu muốn lên cấp cao (VP, CTO...).
Mở rộng góc nhìn chiến lược, giúp bạn hiểu công ty hoạt động như thế nào.
⚠️ Cái mất:
Cần chấp nhận mất đi “niềm vui viết code”.
Lịch họp dày đặt, kèm theo áp lực xử lý vấn đề con người (vốn phức tạp hơn bug).
Nhiều quyết định phải đưa ra trong vùng xám – nơi không có câu trả lời đúng tuyệt đối.
3. Trở thành cầu nối - Presales / Solution Architect / Customer Engineer
Đây là hướng đi ít được nhắc tới, nhưng lại cực kỳ tiềm năng cho những ai có khả năng giao tiếp tốt, hiểu hệ thống và thích nhìn thấy ảnh hưởng thực sự của giải pháp mình đề xuất.
Bạn sẽ làm gì?
Là cầu nối giữa kỹ thuật và khách hàng – nơi kỹ năng giải thích và trình bày có giá trị ngang với kiến thức kỹ thuật.
Thiết kế và trình bày giải pháp kỹ thuật phù hợp.
Đảm bảo thứ bạn “hứa” có thể được dev team thực hiện được.
✅ Cái được:
Vẫn giữ được nền tảng kỹ thuật, đồng thời phát triển mạnh kỹ năng giao tiếp và ảnh hưởng tới kết quả kinh doanh của công ty.
Hiểu sâu hơn về nhu cầu thực tế của thị trường.
Dễ mở ra nhiều hướng đi mới: product, business strategy, customer success, thậm chí là tự khởi nghiệp.
⚠️ Cái mất:
Mất dần tính "hands-on" nếu không chủ động duy trì kỹ thuật.
Làm việc giữa nhiều nhóm lợi ích: khách hàng – sales – kỹ thuật – legal…, áp lực điều phối rất cao.
Có ảnh hưởng, nhưng không phải lúc nào cũng có quyền quyết định cuối cùng.
Mình không đặt mục tiêu làm Presales. Chỉ đơn giản là một hôm, sếp nhắn:
“Bryant, tuần sau đi họp với anh vụ abc… với khách hàng xyz…”
“Ok sếp” 🤪 (trong đầu lúc đó đã bật chế độ overthinking...)
Và thế là cũng từ hôm đó, mình bắt đầu “đi khách” nhiều hơn, rồi trở thành “phiên dịch viên” cho hai thế giới: tech và client. Nói cả tiếng Dev và tiếng người.
Không giống như technical hay management — là những hướng đi bạn có thể chủ động theo đuổi, học và chuẩn bị sẵn từ trước, thì Presales nhiều khi là con đường… chọn bạn (nghề chọn người chứ người đâu chọn…đi làm 😵💫)
II. So what is Presales anyway? 🧩
Presales không bán hàng – mà bán niềm tin vào giải pháp kỹ thuật.
Và hi vọng khách hàng không hỏi về thứ bạn chưa kịp hiểu. 🫣
Lúc mới biết đến vai trò này, mình cũng thấy hơi... mơ hồ. Làm kỹ sư thì mình hiểu, làm sales thì nghe rõ. Nhưng "presales" là gì? Nếu bạn chưa từng làm việc trực tiếp với team Presales, rất dễ hiểu lầm họ là... một nhánh con của sales. Nhưng thực tế thì không phải.
Presales (có nơi gọi là Sales Engineer, Solution Engineer...) là những người hiểu rõ giải pháp kỹ thuật và biết cách giải thích nó sao cho khách hàng hiểu – và tin.
👥 Presales và Sales phối hợp thế nào?
Nếu ví quá trình bán hàng là một vở kịch, thì Sales là người dẫn chuyện, còn Presales là người lo phần kỹ thuật sân khấu: ánh sáng, âm thanh, hậu đài. Cả hai phối hợp để tạo nên một buổi diễn trơn tru.
Sales là người kết nối với khách hàng, tìm hiểu nhu cầu ở tầng chiến lược, xây dựng mối quan hệ, đàm phán, và chốt deal.
Presales bước vào để hiện thực hoá ý tưởng thành giải pháp kỹ thuật cụ thể. Nhiệm vụ của họ là:
Phân tích nhu cầu thực sự (không chỉ cái khách hàng nói).
Đề xuất giải pháp kỹ thuật phù hợp, khả thi.
Trình bày rõ ràng, dễ hiểu, logic — sao cho cả khách hàng và sales đều cảm thấy yên tâm.
Đảm bảo rằng những gì công ty cam kết là thứ team kỹ thuật có thể thực sự làm được.
Trong một số dự án thì bạn là pre-sales và cả post-sales (chăm sóc khách hàng - về mặt technical sau khi delivery)
Thường thì, nếu deal lớn, team sales sẽ không bao giờ đi một mình. Họ cần một Presales ngồi cạnh, gật đầu đúng lúc, giải thích đúng chỗ, và... cảnh báo khi có gì đó “nghe thì hay nhưng không nên hứa”.
🛠️ Kỹ năng nào khiến một Presales giỏi?
Presales giỏi không phải là người chém gió giỏi, mà là phải nói đúng người, đúng lúc, đúng cách.
Những kỹ năng dưới đây là thứ mình đã quan sát, đúc kết từ đồng nghiệp giỏi hơn, và cũng là những thứ mình đang rèn luyện mỗi ngày — vì thật lòng mà nói, xuất phát điểm của mình là kỹ thuật và phần nào cũng khá hướng nội. Không phải kiểu “con nhà người ta”, nói gì người ta cũng gật ngay từ đầu đâu 😅
Giao tiếp rõ ràng: không dùng từ viết tắt, không jargon1 lung tung. Biết khi nào nên nói kỹ, khi nào nên đơn giản hoá.
Lắng nghe và đặt câu hỏi: khách hàng đôi khi nói "tôi cần A", nhưng khi hỏi kỹ lại thì hoá ra họ đang cố giải quyết vấn đề B.
Giải thích kỹ thuật cho người không chuyên: đây là kỹ năng rất “đắt giá”. Biết cách dùng ví dụ, ví von, hình ảnh để làm cho người nghe “à, tôi hiểu rồi”. Vì tới cuối ngày, khách hàng không care bạn dùng công nghệ gì, họ chỉ quan tâm là công nghệ đó có giúp họ có thêm doanh thu và…ngủ ngon không 😜
Tư duy hệ thống: không chỉ đưa ra giải pháp đúng, mà còn nghĩ đến rủi ro, chi phí, thời gian triển khai, và khả năng mở rộng.
Tư duy kinh doanh: hiểu rằng không phải cái gì làm được cũng nên làm. Phải làm cái hợp lý — về mặt thời gian, tiền bạc, và giá trị thực tế.
EQ tốt để vừa nắm bắt tâm lý khách hàng vừa hiểu struggle của team mình để hỗ trợ.
⚙️ Vậy kỹ thuật có còn quan trọng không?
Short answer: Yes! Rất nhiều người nghĩ Presales là “kỹ sư bị sales hoá”, và sẽ dần xa rời kỹ thuật. Mình cá là phần lớn họ chưa thực sự trải nghiệm và dấn thân vào công việc này.
Bạn không cần viết code mỗi ngày, nhưng bạn vẫn phải:
Hiểu hệ thống đủ sâu để tự tin đứng trước khách hàng và trình bày kiến trúc.
Biết rõ giới hạn kỹ thuật – để không hứa hão.
Dịch các yêu cầu kinh doanh thành giải pháp kỹ thuật – và ngược lại, dịch giải pháp kỹ thuật thành giá trị cho khách hàng.
Làm việc với team kỹ thuật, đảm bảo mọi thứ được bàn giao chính xác – đúng cái đã hứa, đúng kỳ vọng.
Presales là kỹ sư nói chuyện được với người ngoài ngành. Và điều đó không làm bạn kém "technical" đi. Ngược lại, nó khiến bạn trở nên hiếm – vì không phải ai cũng làm được.
💬 Một lần đi chào hàng…
Có lần mình đi cùng team sales để chào mời giải pháp cho một công ty tài chính lớn. Họ đang cân nhắc chuyển đổi hệ thống cũ sang nền tảng mới. Bên mình tới để giới thiệu năng lực và mở đầu mối quan hệ.
Dù chỉ là buổi gặp đầu, khách vẫn đặt một vài câu hỏi kỹ thuật ở mức high level:
“Triển khai hạ tầng như thế nào? Có mở rộng linh hoạt không? DR và backup thì xử lý ra sao?”
Lúc đó, mình tới lượt trình bày — không phải show ra kiến trúc chi tiết, mà để trả lời vừa đủ để xây niềm tin.
Mình giải thích rằng hệ thống có thể triển khai linh hoạt (cloud, on-prem2, hybrid3), khả năng mở rộng đã được kiểm chứng, và các yếu tố như DR4 hay HA5 luôn là phần mặc định trong mọi thiết kế cho ngành tài chính.
Buổi gặp kết thúc trong tâm trạng thoải mái. Tuy không có deal được chốt (mới initial meeting mà), nhưng khách có vẻ hào hứng muốn tìm hiểu sâu hơn với công ty mình và hẹn thêm một buổi meeting để có phần Q&A chi tiết.
Với Presales, đó là bước đầu tiên – không phải để “trả lời tất cả”, mà để khách tin rằng bạn là người có thể cùng họ tìm ra câu trả lời.
III. Ai cũng đang bán một điều gì đó 💡
Kể cả khi bạn không có ý định theo đuổi vai trò Presales, thì vẫn có một sự thật là:
Mỗi chúng ta, mỗi ngày, đều đang “bán” một thứ gì đó.
Khi bạn đề xuất refactor một đoạn code — bạn đang bán ý tưởng cải tiến.
Khi bạn bảo vệ một kiến trúc trong buổi thiết kế — bạn đang bán niềm tin rằng nó đúng và cần thiết.
Khi bạn viết một PR và gửi đi code review — bạn đang bán sự cẩn trọng và tư duy của mình.
Khi bạn nói chuyện với PM hay khách hàng — bạn đang bán giải pháp phù hợp nhất trong bối cảnh ràng buộc.
Bạn không bán bằng hợp đồng. Bạn bán bằng cách trình bày, bằng logic, bằng việc bạn hiểu người nghe đang quan tâm điều gì.
🧠 Vậy kỹ năng “bán hàng” có giúp gì cho kỹ sư phần mềm?
Nhiều kỹ sư nghĩ “bán hàng” là kỹ năng của dân sales — nói chuyện giỏi, hoạt ngôn, chốt deal.
Nhưng thật ra, nó là kỹ năng giao tiếp + thuyết phục, và đó là thứ giúp bạn sống khoẻ hơn trong bất kỳ team nào, nhất là trong thời đại AI.
Dưới đây là vài thay đổi mình cảm nhận rõ sau khi “học bán hàng” theo cách của kỹ sư:
Trình bày dễ hiểu hơn: không còn nói toàn thuật ngữ cao siêu mà biết nói sao cho đúng người nghe hiểu.
Hiểu tâm lý người nghe: biết ai cần chi tiết, ai chỉ cần big picture, ai đang nghi ngờ, ai cần thêm niềm tin.
Tự tin hơn trong code review, demo, hay họp với stakeholders. Hay còn gọi là chém gió có cơ sở.
Thuyết phục hiệu quả hơn: không cần to tiếng hay gồng lên – chỉ cần nêu được logic rõ ràng và lý do sau quyết định.
Làm việc với non-tech tốt hơn: đặc biệt là với những vai trò không thuộc team kỹ thuật – PM, QA, business, khách hàng...
🔌 Còn kỹ năng kỹ thuật thì sao? Có bị “mất chất” dần không?
Short answer: probably yes.Khi làm Presales hoặc các vai trò tương tự, bạn sẽ:
Viết ít code hơn.
Dành nhiều thời gian họp, làm slide, demo, viết proposal.
Giao tiếp với nhiều nhóm khác nhau thay vì ngồi “deep work” cả ngày.
Lúc đầu, mình cũng thấy... thiếu thiếu như khi chuyển từ role IC lên làm tech lead. Như thể mất đi một phần “chất kỹ sư” trong người. Nhưng dần dần mình nhận ra:
Mình không mất đi năng lực kỹ thuật – mình chỉ dùng nó theo một cách khác.
Mình tập trung vào cái WHY và WHAT nhiều hơn trong khi các kĩ sư thì tập trung đi vào cái HOW.
Mình không còn code từng dòng, nhưng mình:
Đọc kiến trúc kỹ thuật nhiều hơn.
Phải hiểu hệ thống ở tầng tổng thể.
Trả lời được câu hỏi “vì sao chọn giải pháp này?” thay vì chỉ “nó chạy thế nào?”.
Mình từng fail để trả lời câu hỏi của khách hàng trong một buổi demo. Mình hiểu kiến trúc tổng thể. Mình nắm business use case. Nhưng mình không hiểu đủ sâu vào hệ thống để trả lời chắc chắn về vấn đề testing, và thế là mình múa vài đường – múa xong mới biết... múa sai 🥲. Câu trả lời của mình khi ấy thành ra... mơ hồ. Về sau mình mới biết khách hàng hơi “lăn tăn” vì không phải giải pháp dở mà vì mình không cho họ cảm giác chắc chắn về mặt kĩ thuật. Nên kinh nghiệm xương máu là phải rehearsal với team thật kĩ để chuẩn bị hết tất cả tình huống mà khách hàng có thể hỏi. Vì bạn không biết khách sẽ hỏi gì — nhưng bạn biết bạn sẽ quê ra sao nếu không trả lời được 🥶. Well, ít nhất là từ phía mình phải sẵn sàng.
Và nếu bạn vẫn muốn giữ “cảm giác kỹ sư”, đây là một vài cách mình thấy hữu ích:
Làm side project nhỏ — không cần hoành tráng, để giữ “technical muscle memory”.
Mentor hoặc review giải pháp cho team — vừa giúp người khác, vừa giúp mình có skin in the game.
Theo dõi công nghệ mới để ít nhất biết thị trường đang đi đâu.
Tự học và cập nhật – có thể bạn không dùng ngay, nhưng vẫn hiểu để còn nói chuyện với kỹ sư khác.
🎯 Kỹ năng kỹ thuật không mất đi – nó thay đổi hình thức sử dụng. Bạn không còn là người trực tiếp code, mà là người biết rõ code đó giải quyết vấn đề gì – và thuyết phục người khác rằng nó xứng đáng được triển khai.
🔚 Kết
Không phải kỹ sư nào cũng cần (hay nên) làm Presales. Và cũng không phải ai làm rồi cũng sẽ gắn bó mãi.
Nhưng việc hiểu vai trò này, và rèn luyện những kỹ năng liên quan, sẽ giúp bạn trở thành một kỹ sư toàn diện hơn:
Hiểu sản phẩm tốt hơn. Giao tiếp rõ ràng hơn. Ảnh hưởng rộng hơn..
Presales không phải ngã rẽ – mà là phần mở rộng con đường kỹ thuật.
Bạn vẫn là kỹ sư — chỉ là thay vì chỉ nói chuyện với máy, bạn bắt đầu nói chuyện với người.
Và biết đâu, lần tới khi sếp rủ đi họp khách, bạn sẽ không chỉ gật đầu — mà còn thật sự thấy hào hứng (nhưng nhớ kiểm tra xem có ai đi cùng không, kẻo lại solo lên thớt nhé 🤣).
✌🏻 Hẹn gặp lại bạn trong bài viết sau!
Bạn có suy nghĩ gì về bài viết này? Để lại comment cho mình biết nhé! Mình rất mong nhận được ý kiến từ độc giả của mình (và nếu bạn đã đọc được đến đây mà không scroll ào ào, thì bạn đúng là một người kiên trì và có sự tập trung cao độ đó 😁, và thật lòng... mình quý bạn lắm á! ❤️. Cũng chứng tỏ bài viết này bạn rất quan tâm nữa). Đừng ngần ngại để lại comment vì chắc chắn mình sẽ phản hồi!
See ya 🤖!
Bryant!
thuật ngữ chuyên ngành khó hiểu
viết tắt của “on-premise”, nôm na là tự dựng server
kết hợp giữa cloud và on-prem
Disaster Recovery - phòng khi hệ thống “đi bụi”
High Availability - để chạy cả ngày lẫn đêm như cái cách bạn săn sale Shopee
Em tò mò nếu bay giờ anh phải phỏng vấn 1 bạn presales engineer thì quy trình sẽ ntn? Khác gì với phỏng vấn 1 engineer bình thường, và KPI của role này sẽ được đánh giá ra sao