Trong thế giới lãnh đạo công nghệ, một câu hỏi cốt lõi đã trỗi dậy với cường độ mới: một Giám đốc Công nghệ (CTO) có thực sự nên viết code? Một bài đăng blog gần đây của một CTO đang hành nghề, người tuyên bố vẫn triển khai các tính năng quan trọng trong khi không quản lý nhân sự trực tiếp nào, đã châm ngòi cho những cuộc thảo luận sôi nổi khắp các cộng đồng công nghệ về điều gì cấu thành nên một nhà lãnh đạo kỹ thuật hiệu quả trong bối cảnh phát triển nhanh chóng như hiện nay.
 |
|---|
| "Một bài đăng blog thảo luận về các sắc thái trong vai trò của CTO giữa việc viết code và lãnh đạo" |
Cách tiếp cận CTO không theo lối mòn
Cuộc tranh luận tập trung vào một CTO vẫn duy trì hoạt động lập trình tích cực, đóng góp hàng nghìn commit mỗi năm trong khi từ bỏ các trách nhiệm quản lý truyền thống. Nhà lãnh đạo này mô tả việc tập trung vào ba danh mục lập trình chính: các dự án thử nghiệm tầm xa, các yêu cầu khách hàng quan trọng cần được xử lý ngay lập tức, và đáng ngạc nhiên là, cả việc sửa lỗi thông thường. Cách tiếp cận này thách thức quan điểm thông thường rằng các nhà lãnh đạo kỹ thuật cấp cao nên dần dần tách rời khỏi công việc lập trình thực tế khi họ thăng tiến trên nấc thang sự nghiệp.
Điều khiến trường hợp này đặc biệt thú vị là việc vị giám đốc điều hành này thừa nhận không có ai báo cáo trực tiếp, thay vào đó dựa vào các quản lý kỹ thuật được thuê để xử lý việc quản lý con người. Cơ cấu này cho phép CTO tận dụng hiểu biết sâu rộng về cả codebase lẫn nhu cầu khách hàng để nhanh chóng tạo mẫu giải pháp và giải quyết các vấn đề cấp bách mà nếu không thì có thể bị sa lầy trong các quy trình tổ chức.
Nếu bạn đang làm việc trên nền tảng SaaS về bảo hiểm, tôi đồng ý. Nhưng nếu bạn đang xây dựng công nghệ lõi (hard tech), tôi sẽ hoàn toàn không đồng ý.
Các biến thể vai trò CTO phổ biến:
- Nhà tầm nhìn công nghệ: Tập trung vào chiến lược công nghệ dài hạn và đổi mới sáng tạo
- Người xây dựng tổ chức: Chú trọng vào cấu trúc nhóm, tuyển dụng và quy trình quản lý
- Tập trung vào hạ tầng: Chuyên về kiến trúc kỹ thuật và các quyết định về nền tảng
- Lập trình viên thực hành: Duy trì hoạt động viết code trong khi vẫn đảm nhiệm vai trò lãnh đạo
Phản ứng dữ dội từ cộng đồng và Lo ngại về Quy trình
Phản ứng từ cộng đồng công nghệ bị chia rẽ sâu sắc, với nhiều người bày tỏ quan ngại nghiêm trọng về hệ quả của phong cách lãnh đạo này. Những người chỉ trích lập luận rằng một CTO viết code quá nhiều có thể đang bỏ bê các trách nhiệm có đòn bẩy cao hơn như phát triển tổ chức, chiến lược kỹ thuật và cải tiến quy trình. Sự chỉ trích gay gắt nhất tập trung vào tác động văn hóa tiềm ẩn khi một giám đốc điều hành làm việc cuối tuần và bỏ qua các thủ tục đã được thiết lập.
Một số người bình luận chỉ ra các ví dụ cụ thể từ bài viết gốc như những dấu hiệu cảnh báo, đặc biệt là câu chuyện xây dựng một tính năng liên quan đến tuân thủ chỉ trong một ngày mà thông thường sẽ đòi hỏi các đánh giá xuyên bộ phận. Những người chỉ trích cho rằng điều này chứng tỏ một quy trình bị hỏng cần được sửa chữa, hoặc các thói quen phát triển phần mềm kiểu cao bồi nguy hiểm có thể gây ra lỗ hổng bảo mật hoặc nợ kỹ thuật.
Cuộc thảo luận tiết lộ những lo ngại sâu xa hơn về kỳ vọng cân bằng giữa công việc và cuộc sống khi các giám đốc điều hành làm gương cho thói quen lập trình cường độ cao. Nhiều người bày tỏ quan ngại rằng hành vi như vậy có thể tạo ra áp lực ngầm buộc các kỹ sư khác phải làm việc với thời gian tương tự, có khả năng dẫn đến kiệt sức và các thực hành công việc không bền vững trên toàn bộ tổ chức.
Những lo ngại của cộng đồng về việc CTO viết code:
- Có thể bỏ bê các trách nhiệm chiến lược
- Tác động văn hóa khi lãnh đạo cấp cao làm việc vào cuối tuần
- Bỏ qua các quy trình và đánh giá đã được thiết lập
- Hạn chế cơ hội phát triển cho các kỹ sư khác
- Lạm phát chức danh và nhầm lẫn vai trò
- Khó khăn trong việc nhận được đánh giá code trung thực
Tranh luận về Chức danh và Thực tế
Một phần đáng kể của cuộc trò chuyện đặt câu hỏi liệu một người không có ai báo cáo trực tiếp và có trách nhiệm lập trình đáng kể có thực sự đủ tiêu chuẩn là CTO hay không. Những người bình luận đề xuất các chức danh thay thế như Kỹ sư Chính (Principal Engineer), Kỹ sư Cấp cao (Staff Engineer), hoặc Kỹ sư Xuất sắc (Distinguished Engineer) có thể phản ánh chính xác hơn công việc thực tế đang được thực hiện, đồng thời tránh gây nhầm lẫn về trách nhiệm lãnh đạo.
Cuộc tranh luận làm nổi bật bản chất mơ hồ của vai trò CTO trong các tổ chức khác nhau. Như một người bình luận nhận xét, Không có một định nghĩa rõ ràng nào cho chức danh 'CTO'. Trong các startup nhỏ, CTO thường đảm nhận nhiều vai trò và vẫn duy trì tính kỹ thuật sâu, trong khi tại các doanh nghiệp lớn hơn, vai trò này thường tập trung vào tầm nhìn chiến lược, lập ngân sách và lãnh đạo tổ chức hơn là triển khai thực tế.
Cuộc thảo luận về lạm phát chức danh này vượt ra ngoài phạm vi ngữ nghĩa, chạm đến sự tiến bộ trong sự nghiệp, kỳ vọng về thu nhập và câu hỏi cốt lõi về việc lãnh đạo kỹ thuật nên bao gồm những gì ở các giai đoạn và quy mô công ty khác nhau.
Công cụ AI đang Thay đổi Cán cân
Một tình tiết thú vị trong cuộc thảo luận này liên quan đến vai trò của các trợ lý lập trình AI trong việc cho phép cách tiếp cận lãnh đạo này. Vị CTO này ghi nhận các công cụ như Claude Code và Cursor đã giúp tăng năng suất lên 2-3 lần, về cơ bản thay đổi cách tính toán về việc các giám đốc điều hành có thể tương tác với code như thế nào. Sự thay đổi công nghệ này có thể đang định nghĩa lại những gì khả thi đối với các nhà lãnh đạo kỹ thuật muốn duy trì kỹ năng lập trình trong khi vẫn xử lý các trách nhiệm điều hành.
Phản ứng của cộng đồng đối với khía cạnh này rất trái chiều. Một số coi đó là sự tiến hóa tự nhiên của lãnh đạo kỹ thuật, trong khi những người khác tỏ ra hoài nghi về việc liệu code được tạo bởi AI có thể sánh được với chất lượng và độ chính xác cần thiết cho các hệ thống sản xuất hay không. Cuộc thảo luận phản ánh các cuộc trò chuyện rộng hơn trong ngành về cách công cụ AI đang chuyển đổi các phương pháp phát triển phần mềm ở mọi cấp độ.
Các Tuyên Bố Về Năng Suất Được Báo Cáo:
- 3.738 đóng góp trong năm qua
- Tăng năng suất gấp 2-3 lần khi sử dụng các công cụ lập trình AI
- Khả năng triển khai các tính năng đáng kể chỉ trong một ngày
- Nhiều tính năng chính được triển khai mỗi quý
Mô hình Lãnh đạo Startup so với Doanh nghiệp
Cuộc trao đổi nảy lửa tiết lộ một sự căng thẳng cơ bản giữa triết lý lãnh đạo startup và doanh nghiệp. Trong các công ty giai đoạn đầu, những người sáng lập kỹ thuật thường vẫn tham gia sâu vào việc lập trình vì nhu cầu thiết yếu, và cách tiếp cận thực hành này có thể mang lại những lợi thế đáng kể về tốc độ và tính linh hoạt. Tuy nhiên, khi các tổ chức mở rộng quy mô, những yêu cầu về quản lý con người, lập kế hoạch chiến lược và phối hợp liên chức năng thường đòi hỏi các nhà lãnh đạo phải lùi lại khỏi việc lập trình hàng ngày.
Những người bình luận có kinh nghiệm tại các công ty lớn hơn nhấn mạnh rằng các CTO hiệu quả ở quy mô lớn tập trung vào việc tạo điều kiện cho tổ chức của họ hoạt động hơn là đóng góp cá nhân. Họ tạo ra môi trường nơi nhiều thành viên trong nhóm có thể theo đuổi các dự án đổi mới thay vì dành riêng những thách thức kỹ thuật thú vị nhất cho bản thân. Quan điểm này gợi ý rằng những gì hiệu quả với một startup 50 người có thể trở nên có vấn đề ở quy mô 500 hoặc 5.000 nhân viên.
Cuộc thảo luận cũng chạm đến tầm quan trọng của việc ủy quyền và cố vấn trong việc xây dựng các tổ chức kỹ thuật bền vững. Những người chỉ trích lập luận rằng bằng cách tự mình đảm nhận các dự án lập trình có tác động lớn, các CTO có thể vô tình hạn chế cơ hội phát triển cho các kỹ sư khác, những người có thể được hưởng lợi từ việc giải quyết các vấn đề khó khăn.
Kết luận
Phản ứng đầy nhiệt huyết đối với triết lý lập trình của vị CTO này nhấn mạnh sự không chắc chắn đang diễn ra về vai trò đang phát triển của lãnh đạo kỹ thuật trong kỷ nguyên AI. Mặc dù không có câu trả lời chung cho tất cả, nhưng cuộc thảo luận làm nổi bật những cân nhắc quan trọng về thiết kế tổ chức, tín hiệu văn hóa và phát triển sự nghiệp. Khi công cụ AI tiếp tục định hình lại sự phát triển phần mềm, ranh giới giữa đóng góp cá nhân và lãnh đạo có thể bị xóa nhòa hơn nữa, đòi hỏi cả tổ chức và các chuyên gia phải suy nghĩ lại về các định nghĩa vai trò truyền thống và các chỉ số thành công trong lãnh đạo kỹ thuật.
Tham khảo: Why I code as a CTO