- Nhiều CTO chuyển dần sang trọng tâm quản lý, nhưng vẫn duy trì cách làm tự tay viết code và phát triển sản phẩm
- Tạo ra đòn bẩy lớn trong tổ chức thông qua ba loại công việc phát triển: dự án thử nghiệm, yêu cầu khẩn cấp từ khách hàng và sửa lỗi
- Bằng cách tiếp tục code, có thể trực tiếp cảm nhận giá trị thực tế và giới hạn của các công cụ AI, đồng thời bảo đảm tính thực tế trong các quyết định kỹ thuật
- Thay vì quản lý, đặt thế mạnh và đam mê vào giải quyết vấn đề và xây dựng sản phẩm, rồi thiết kế cấu trúc tổ chức để điều đó khả thi
- Không có một khuôn mẫu cố định cho vai trò CTO; điều cốt lõi là tìm ra phong cách lãnh đạo phù hợp với thế mạnh cá nhân và bối cảnh công ty
Vì sao tôi tiếp tục viết code với vai trò CTO
- Nhiều CTO dần ngừng code theo thời gian, nhưng tôi vẫn duy trì cách làm tự phát triển và triển khai tính năng
- Trong 12 tháng qua, đã phát hành nhiều tính năng quan trọng mà không có thành viên nào báo cáo trực tiếp cho tôi
- Không chỉ là sở thích cá nhân, mà tôi thực sự đảm nhận vai trò nhà phát triển các tính năng cốt lõi được đưa vào sản phẩm
- Tôi xem đây là “một trong những hoạt động có đòn bẩy cao nhất đối với một lãnh đạo kỹ thuật”
Ba loại dự án tôi thực sự xây dựng
1. Dự án thử nghiệm dài hạn (Long-horizon experimental projects)
- Trong tổ chức, số người có thể thực sự xây dựng sản phẩm mới là rất hạn chế
- Vì phần lớn tổ chức tập trung vào việc duy trì và mở rộng sản phẩm hiện có
- Chỉ có nhà sáng lập, một số lãnh đạo cấp cao và các cá nhân đóng góp hiệu suất cao (IC) mới có dư địa để thử sản phẩm mới
- Do cấu trúc tổ chức, động lực từ roadmap và ngân sách rủi ro hạn chế, đa số kỹ sư không thể theo đuổi một dự án bất định trong vài tháng
- CTO ở vị trí đặc biệt có thể đẩy nhanh các dự án thử nghiệm nhiều bất định, nhờ hiểu sâu về pain point của khách hàng và kiến trúc hệ thống
- Dù có những thất bại, cũng đã đạt được những thành công lớn
- Ví dụ sản phẩm chat AI: đó là dự án mà cả nhóm đều thấy có giá trị nhưng cứ bị hoãn vì không có thời gian và dư địa, nên tôi đã làm prototype trong kỳ nghỉ Lễ Tạ ơn
- Sau đó phối hợp với cả nhóm để thương mại hóa thành công một sản phẩm ARR trị giá hàng triệu đô la
2. Xử lý yêu cầu khẩn cấp từ khách hàng (Critical customer asks)
- Có những lúc tính năng mà khách hàng lớn cần gấp trở thành điểm chặn cho một hợp đồng lớn hoặc việc gia hạn
- Thay vì điều động kỹ sư đang bận sprint hiện tại, CTO trực tiếp xử lý dựa trên khả năng ra quyết định nhanh và hiểu biết toàn cục về hệ thống
- Trường hợp thực tế: khách hàng trị giá một triệu đô mỗi năm yêu cầu tính năng rút gọn dữ liệu để đáp ứng tuân thủ
- Ở bước xem xét ban đầu, nhóm dự đoán khách hàng sẽ phải tự xây dựng tích hợp API, hoặc cần nhiều cuộc họp giữa product, pháp lý và engineering
- Nhưng CTO đã xây dựng và triển khai một phiên bản hoạt động chỉ trong một ngày, từ đó giữ vững quan hệ với khách hàng
3. Sửa lỗi (Bugfixes)
- Nhiều người thấy bất ngờ, nhưng sửa lỗi là một trong những cách tôi thích nhất để duy trì bản đồ tinh thần về codebase
- Khi lần theo nguyên nhân vì sao phân trang bị lỗi ở trang 3 của kết quả tìm kiếm, hoặc vì sao kết nối WebSocket bị ngắt đúng sau 60 giây, bạn sẽ phải đi qua toàn bộ hệ thống
- Từ đó có được hiểu biết trực quan về technical debt mà rất khó có được chỉ qua code review hay thảo luận kiến trúc
- Chính những trải nghiệm này giúp duy trì trực giác cần thiết để quyết định hướng và mức độ ưu tiên của các khoản đầu tư kỹ thuật
Vì sao tôi tiếp tục code
1. Để biết công nghệ nào thực sự hiệu quả
- Nhờ sử dụng hằng ngày các công cụ AI như Claude Code, Codex, Cursor, tôi có thể phân biệt đâu là thực tế và đâu là hype khi đưa ra quyết định về công cụ hay chiến lược tuyển dụng
- Ví dụ gần đây: tôi thử vibe-coding cho một tính năng đụng đến tích hợp phức tạp nhưng không tiến triển, còn khi tự viết tay thì lại đi nhanh hơn nhiều
- Lượng code không nhiều, nhưng cần logic cực kỳ chính xác (đây là điểm yếu của LLM)
- Trong khi đó, một tính năng lớn khác thì gần như được phát triển toàn bộ bằng Claude Code
- Việc hiểu rõ AI làm rất tốt ở đâu (CRUD, test, boilerplate) và thất bại ở đâu (độ chính xác, sắc thái hệ thống) tốt hơn hẳn so với ra quyết định dựa trên hype trên Twitter
- Khi ở bên trong code, bạn có thể cảm nhận được lúc nào cần siết và lúc nào có thể nới
- Có thể nhận ra khi kiến trúc đang trở nên quá phức tạp hoặc khi technical debt thực sự bắt đầu thành vấn đề
- Người quản lý chỉ dựa vào báo cáo có thể bỏ lỡ rất nhiều thứ
2. Để tập trung vào điều mình giỏi và yêu thích
- Tôi không đặc biệt hứng thú với việc xây dựng tổ chức hay quản lý nhân sự
- Quản lý kỹ thuật đòi hỏi xử lý động lực quan hệ con người, đánh giá hiệu suất và thiết kế tổ chức
- Đó là chức năng quan trọng, nhưng không phải lĩnh vực tôi mạnh nhất
- Vì vậy, tôi tuyển những engineering manager và lãnh đạo xuất sắc
- Họ làm tốt hơn và cũng thích việc đó hơn
- Nhờ vậy, CTO có thể tập trung vào xây dựng sản phẩm, giải quyết vấn đề kỹ thuật và viết code
- Startup giống như một “cuộc marathon kiểu nước rút”, nên tôi thiết kế vai trò của mình xoay quanh những công việc giúp duy trì hứng thú và chạy nhanh trong thời gian dài
- Đó là cách làm bền vững suốt nhiều năm và cũng rất quan trọng với công ty
3. Vì công cụ AI đã mở rộng đòn bẩy
- Vài năm trước, tôi từng khó tìm được thời gian để code trong khi vẫn phải xử lý công việc chiến lược
- Khi công ty lớn dần, tôi bị mắc kẹt trong các cuộc họp cả ngày và phải làm nhiều việc ngoài vùng thế mạnh
- Đó là một trong những giai đoạn khó khăn nhất trong sự nghiệp
- Các công cụ AI hiện đại đã thay đổi căn bản phương trình này (đặc biệt là trong vài tháng gần đây)
- Năng suất tăng gấp 2~3 lần so với trước
- Chúng không thay thế năng lực phán đoán hay kiến thức kỹ thuật, mà ngược lại còn khiến những kỹ năng đó trở nên giá trị hơn
- Nếu chỉ dẫn cho công cụ AI rằng “hãy xây dựng chức năng xuất dữ liệu khớp với định dạng xuất CSV hiện có, nhưng bổ sung thêm ba trường từ bảng hồ sơ người dùng”, nó sẽ tạo ra phần lớn mã nguồn một cách chính xác
- Điều này khả thi vì tôi có ngữ cảnh sâu về chính xác thứ cần làm và nơi cần tìm
- Một kỹ sư không quen với phần codebase đó sẽ mất khá nhiều thời gian chỉ để nắm được chi tiết
- Công việc đã chuyển từ việc “tự viết mọi dòng code” sang “cung cấp ngữ cảnh, ra quyết định và đánh giá giải pháp”
- Và may mắn là tôi có rất nhiều ngữ cảnh đó
Tìm ra cách phù hợp với chính mình
- Khi định nghĩa vai trò CTO, tôi tham khảo bài blog của Greg Brockman về việc định hình vai trò CTO tại Stripe
- Sau khi trò chuyện với nhiều CTO, tôi nhận ra có sự khác biệt cực lớn về hình thái của vai trò này
- Có CTO là người vạch tầm nhìn công nghệ, có người là builder tổ chức, có người lại tập trung vào hạ tầng
- Điểm chung là các CTO giỏi đều xác định được nơi họ có thể tạo ra nhiều giá trị nhất, dựa trên kỹ năng riêng, mối quan tâm và bối cảnh công ty
- Với tôi, điều đó đồng nghĩa với việc viết rất nhiều code
- Tôi thích xây dựng phần mềm hơn là thiết kế tổ chức
- Tôi đặc biệt hiệu quả nhờ hiểu biết sâu về khách hàng và codebase
- Và tôi tuyển những engineering manager mạnh
- Nhưng đây là con đường cá nhân, không phải đơn thuốc chung
- Vai trò CTO rất linh hoạt
- Từ xây dựng tổ chức đến phát triển chiến lược sản phẩm — lãnh đạo kỹ thuật có thể rất đa dạng tùy theo thế mạnh, nguồn năng lượng và nhu cầu của công ty
- Với những kỹ sư lo rằng bước vào vị trí lãnh đạo đồng nghĩa phải từ bỏ công việc kỹ thuật: vẫn có rất nhiều con đường
- Điều cốt lõi là xác định lĩnh vực mà bạn giỏi một cách khác biệt
5 bình luận
Tôi hiện là CTO và hoàn toàn không đồng ý với bài viết này.
Tôi đồng ý 100% rằng không nên bỏ coding, nhưng chỉ cần làm open source không liên quan đến sản phẩm của công ty là được. Tôi nghĩ đây chỉ là lập luận có giá trị khi nhìn từ góc độ một technical founder ở startup giai đoạn đầu phải làm việc như một người đa năng.
Bản thân người đó thì thích đấy… nhưng còn công ty thì sao?
Phải làm công việc tương xứng với mức lương mình nhận chứ…
Thật khó hiểu khi CTO trực tiếp làm một dự án mang tính thử nghiệm. Nếu dành đủ thời gian cho đội ngũ thực thi, họ hẳn cũng có thể làm tốt. Điều khó hiểu nhất là việc một dự án thử nghiệm dài hạn lại chỉ do mỗi CTO tiến hành. Nếu bản thân có quyền phân bổ nguồn lực, thì chỉ cần tự bố trí riêng nguồn lực cho dự án thử nghiệm và dành đủ thời gian cho đội ngũ thực thi là được mà.
Con đường cá nhân thôi.. nhưng có lẽ phải quản lý cho tốt để phần việc quản trị tổ chức không ngày càng tăng lên.
Ý kiến Hacker News
Nếu đang cân nhắc ứng tuyển vào một công ty mà tôi thấy bài blog khoe CTO commit code vào mỗi cuối tuần, tôi sẽ chuẩn bị bỏ chạy
Vai trò của lãnh đạo là xây dựng văn hóa tổ chức lành mạnh, còn việc khoe làm cuối tuần thì đi ngược lại điều đó
Hơn nữa, công khai nói rằng đã bỏ qua khâu pháp lý hay rà soát kỹ thuật để giải quyết vấn đề của khách hàng chỉ trong một ngày là một tín hiệu nguy hiểm
Ở startup giai đoạn đầu, văn hóa hoàn toàn khác và kiểu bài viết này ngược lại còn đóng vai trò như một bộ lọc để loại ra những người không phù hợp
Phần lớn code tôi viết là để cải thiện DevEx nội bộ hoặc xử lý nợ kỹ thuật
Tôi không bao giờ bỏ qua rà soát pháp lý, và nếu làm thì cũng chỉ ở mức PoC chứ không phải code production
Với CTO là nhà sáng lập, việc luôn ở gần code là quan trọng, nhưng điều cốt lõi là không được mất cân bằng
Vai trò của CTO khác nhau ở mỗi công ty
Như trường hợp Greg Brockman tại Stripe, có CTO là người định hình tầm nhìn kỹ thuật, có CTO là kiến trúc sư tổ chức, và cũng có CTO thiên về hạ tầng
Với tôi, tôi thích coding và tham gia rất sâu vào khách hàng cũng như codebase, nên đó là cách tạo ra giá trị lớn nhất
Chức danh “CTO” vốn có định nghĩa khá mơ hồ
Có CTO xuất thân là nhà sáng lập nên có thể tự do code, cũng có CTO làm việc theo định hướng khách hàng đến mức mất luôn quyền truy cập code
Mặt khác, cũng tồn tại những CTO độc đoán
Cuối cùng thì phải làm rõ đó là kiểu CTO nào thì câu hỏi ‘vì sao lại coding’ mới có ý nghĩa
Trong trường hợp này, tên gọi CTO chỉ đơn thuần là cách phân chia vai trò
CTO tập trung vào chiến lược và định hướng, còn VP tập trung vào quản lý kỹ thuật hằng ngày
Cách làm là xây dựng tổ chức hay trực tiếp code thì không quan trọng
Khi người quản lý trực tiếp viết code, quá trình review code có thể bị bóp méo và đội ngũ có thể trở nên rối loạn
Cuối cùng thì người đó có lẽ không phải CTO mà trong lòng vẫn là một developer
Tôi không hoàn toàn phản đối việc CTO coding, nhưng trong trường hợp này có vẻ chưa làm tròn vai trò CTO
Người đảm nhiệm vai trò lãnh đạo kỹ thuật thực chất lại là kỹ sư sáng lập, nhưng cơ chế đãi ngộ thì thấp hơn rất nhiều, đó mới là vấn đề
Một CTO không có hệ thống báo cáo và chỉ đi code thì tôi nghĩ gần với vai trò senior developer hơn là chiến lược
Tôi cũng từng nhận được đề nghị như vậy nhưng rốt cuộc nó chỉ là một chức danh mang tính hình thức
Khi tổ chức lớn lên thì vai trò có lẽ sẽ thay đổi
Ở startup nhỏ, công việc của tôi là cùng team chạy sprint, nếu tiến độ chậm thì tìm cách giải quyết nguyên nhân, và quan tâm những người đang kiệt sức
Nhưng nhìn vào bài viết, nếu team ở trong một cấu trúc không có cả dư địa để thử những dự án AI đang hot, thì đó là vấn đề tổ chức
CTO không nên trực tiếp code mà phải giải quyết những điểm nghẽn mang tính hệ thống như vậy
Ở mỗi công ty, vai trò của “senior” hay “head” đều hoàn toàn khác nhau
Những vấn đề phát sinh khi CTO quá sa đà vào coding là rất rõ ràng
Bao gồm bóp méo review PR, lơ là công việc chính, gây nhầm lẫn vai trò và xâm phạm tính tự chủ của đội ngũ
Quan điểm “CTO không nên code mà chỉ làm chiến lược” là một kiểu tư duy máy móc
Bản chất của công ty công nghệ là chuyển giao giá trị, và đôi khi việc CTO trực tiếp triển khai một tính năng lớn chỉ trong một ngày lại có thể là việc tạo ra giá trị nhất
Đó có thể còn là một ngày hiệu quả hơn rất nhiều so với họp KPI
Đôi khi lãnh đạo C-level cũng cần trực tiếp lấy lại cảm giác thực chiến
Có người trở thành CTO chỉ đơn giản vì họ là đồng sáng lập
Nếu mang cách tiếp cận đó sang công ty khác, họ có thể còn chưa đạt tới trình độ staff engineer
Cuối cùng, việc trang giá trên website công ty không có giá thực tế có thể gây nhầm lẫn, nên cần được chỉnh sửa