The version of the job I was trained for

Phiên bản công việc tôi được đào tạo để làm

For most of my career, the CTO job description was clear. You hire good engineers. You set technical direction. You protect the team from bad product decisions and protect the product from bad technical decisions. You review architecture. You make the hard tradeoffs. You scale the organization as the company scales.

Trong phần lớn sự nghiệp, mô tả công việc CTO của tôi khá rõ ràng. Bạn tuyển kỹ sư giỏi. Bạn định hướng kỹ thuật. Bạn bảo vệ team khỏi các quyết định sản phẩm tệ và bảo vệ sản phẩm khỏi các quyết định kỹ thuật tệ. Bạn review kiến trúc. Bạn đưa ra những đánh đổi khó. Bạn scale tổ chức khi công ty scale.

That model made sense when building anything meaningful required a team. One person could not ship a production booking engine, an API layer, a frontend, a CI/CD pipeline, documentation and SEO in a reasonable timeframe. You needed engineers, and engineers needed managing.

Mô hình đó có lý khi xây dựng bất cứ thứ gì có giá trị đều cần một team. Một người không thể ship booking engine production, API layer, frontend, pipeline CI/CD, tài liệu và SEO trong thời gian hợp lý. Bạn cần kỹ sư, và kỹ sư cần quản lý.

What changed

Điều đã thay đổi

This month I shipped a full blog section — bilingual, with structured data schema for AI search, custom CSS, performance optimizations, and proper SEO — in a few evenings. Not a prototype. Production code on a live site.

Tháng này tôi ship một phần blog hoàn chỉnh — song ngữ, có structured data schema cho AI search, CSS tùy chỉnh, tối ưu hiệu suất và SEO đúng chuẩn — trong vài buổi tối. Không phải prototype. Code production trên site thực tế.

I also fixed CLS issues that were tanking Lighthouse scores, converted images to WebP, set up Cloudflare caching headers, and wrote the first piece of content designed to be cited by Perplexity. All of it, working alongside Claude Code.

Tôi cũng sửa các vấn đề CLS đang kéo điểm Lighthouse xuống, chuyển đổi ảnh sang WebP, cài đặt Cloudflare caching headers, và viết nội dung đầu tiên được thiết kế để Perplexity trích dẫn. Tất cả, khi làm việc cùng Claude Code.

The work that used to take a team of three for a sprint now fits in the margin of a founder's week. That is not a small change. That changes the unit economics of building software.

Công việc từng mất một team ba người trong một sprint giờ vừa vặn trong khoảng trống của một tuần làm việc của founder. Đó không phải là thay đổi nhỏ. Điều đó thay đổi kinh tế học đơn vị của việc xây dựng phần mềm.

The uncomfortable question

Câu hỏi khó chịu

If I can build more by building directly — with AI as a multiplier — what exactly is the CTO job for?

Nếu tôi có thể build được nhiều hơn bằng cách tự build trực tiếp — với AI như một bộ nhân — thì chính xác công việc CTO dùng để làm gì?

I am not suggesting the answer is "nothing." Coordination, judgment, stakeholder trust, hiring — these are not things AI replaces. A team still needs direction. A product still needs someone whose job is to see around corners.

Tôi không nói câu trả lời là "không có gì". Phối hợp, phán đoán, niềm tin từ các bên liên quan, tuyển dụng — đây không phải là những thứ AI thay thế. Một team vẫn cần định hướng. Một sản phẩm vẫn cần người có nhiệm vụ nhìn xa hơn những gì đang xảy ra.

But I keep noticing a pattern: the weeks when I am deep in product decisions and alignment meetings, I feel useful but not productive. The weeks when I am building — actually writing code, shipping things, solving real problems — I feel like something is moving.

Nhưng tôi tiếp tục nhận ra một kiểu mẫu: những tuần tôi chìm sâu vào các quyết định sản phẩm và cuộc họp alignment, tôi cảm thấy hữu ích nhưng không hiệu quả. Những tuần tôi đang build — thực sự viết code, ship thứ gì đó, giải quyết vấn đề thực tế — tôi cảm thấy như có gì đó đang di chuyển.

That tension is not new. But AI has made it sharper. Because now the option of doing both — being a builder and operating at CTO altitude — is more plausible than it has ever been.

Sự căng thẳng đó không mới. Nhưng AI đã làm nó sắc nét hơn. Bởi vì giờ đây lựa chọn làm cả hai — vừa là builder vừa hoạt động ở tầm cao CTO — khả thi hơn bao giờ hết.

What I'm actually doing

Điều tôi thực sự đang làm

I have not resolved this. I am not sure it resolves — I think it just gets managed differently at different phases of the company.

Tôi chưa giải quyết được điều này. Tôi không chắc nó sẽ được giải quyết — tôi nghĩ nó chỉ được quản lý khác nhau ở các giai đoạn khác nhau của công ty.

Right now, at this stage of 247 Technical, I am making a deliberate choice to stay closer to the building. Not because the CTO work doesn't matter, but because the leverage is higher when I am shipping than when I am coordinating. A small team with high output beats a larger team with high coordination overhead — and AI has shifted where that inflection point sits.

Ngay bây giờ, ở giai đoạn này của 247 Technical, tôi đang đưa ra lựa chọn có chủ đích là ở gần hơn với việc build. Không phải vì công việc CTO không quan trọng, mà vì đòn bẩy cao hơn khi tôi đang ship hơn là khi tôi đang phối hợp. Một team nhỏ với output cao đánh bại một team lớn hơn với chi phí phối hợp cao — và AI đã dịch chuyển điểm uốn đó.

What I have not fully figured out is whether this is a temporary phase — something that shifts when the company is bigger and the coordination cost is unavoidable — or whether AI fundamentally changes what senior technical leadership looks like for the next decade.

Điều tôi chưa hoàn toàn hiểu ra là liệu đây có phải là giai đoạn tạm thời — thứ gì đó thay đổi khi công ty lớn hơn và chi phí phối hợp không thể tránh khỏi — hay liệu AI có cơ bản thay đổi lãnh đạo kỹ thuật cấp cao trông như thế nào trong thập kỷ tới.

I genuinely do not know. But I think it is worth naming the question clearly rather than pretending there is an obvious answer.

Tôi thực sự không biết. Nhưng tôi nghĩ đáng để đặt rõ câu hỏi hơn là giả vờ có câu trả lời rõ ràng.