Bước ngoặt: Hiểu vai trò khác với kỹ năng
Vấn đề của tôi không phải là tôi không biết lead. Vấn đề là tôi không buông bỏ được identity của developer. Cảm giác productive, cảm giác "done", cảm giác output rõ ràng - những thứ đó gắn với việc viết code, không gắn với việc làm tech lead.
Khi làm developer, output rõ ràng: commit, feature done, bug fixed.
Khi làm tech lead, output mơ hồ hơn: team có clarity không? Architecture decision có sound không? Junior dev có grow không? Stakeholders có aligned không?
Tôi mất 6 tháng để thực sự chấp nhận: productivity của tech lead được đo bằng output của team, không phải output của bản thân.
Vậy tech lead cần code bao nhiêu? Framework của tôi
Sau 7 năm - từ tech lead, đến principal engineer, đến CTO, đến CEO - tôi đúc kết ra một framework đơn giản:
Code để giữ credibility (không thể thiếu)
Tech lead mà không code gì cả sẽ mất đi thứ quan trọng nhất: sự tôn trọng của team kỹ thuật.
Credibility không đến từ title. Nó đến từ việc bạn hiểu team đang đối mặt với cái gì. Khi developer than "codebase này legacy quá, khó maintain", bạn phải biết họ đang nói về điều gì. Khi ai đó propose một solution, bạn phải đủ technical để hỏi câu hỏi đúng.
Minimal bar: Review code thực sự (không phải rubber stamp), thỉnh thoảng pair với developer junior, và ít nhất biết codebase đủ để navigate được.
Code để unblock (khi thực sự cần thiết)
Có những lúc tech lead cần code: khi có technical debt quá lớn mà không ai trong team đủ seniority để tackle, khi cần PoC nhanh để validate một idea, khi một critical bug cần người có deep context nhất để fix.
Đây là "heroic coding" - chỉ dùng khi thực sự cần, không phải mặc định.
Rule của tôi: Nếu tôi phải code để team không bị blocked, đó là signal team structure có vấn đề cần address. Không phải solution lâu dài.
Không code để "cảm thấy productive"
Đây là trap. Khi meeting nhiều, khi phần việc mơ hồ, coding cho cảm giác comfortable. Bạn biết mình đang làm gì, biết khi nào done. Rất human.
Nhưng đây là cái giá: Mỗi giờ bạn code là một giờ bạn không lead. Architecture review không được làm. 1:1 với junior không xảy ra. Cross-team alignment bị postpone.
Cái chi phí vô hình đó lớn hơn rất nhiều so với cái feature bạn vừa code.
Sự khác biệt giữa các archetype
Charity Majors, Will Larson và nhiều người khác đã viết về điều này, nhưng tôi muốn share theo kinh nghiệm của mình ở context Việt Nam:
Tech Lead ở startup nhỏ (5-15 người): Cần code 50-60%. Team nhỏ, mọi người phải đa năng. Bạn vừa lead vừa contribute code thực sự.
Tech Lead ở team lớn hơn (15-40 người): Code 20-30%, nhưng strategic code - architecture spikes, PoC, critical path. Còn lại là mentoring, architecture review, cross-team work.
Principal Engineer / Staff Engineer: Code 40-50% nhưng toàn bộ là leverage code - tooling cho team, core library, architecture reference implementation. Không viết feature như regular developer.
CTO / VP Engineering: Code 0-10% khi cần duy trì technical credibility. Focus chủ yếu là people, strategy, và organization.
Ở Việt Nam, tôi thấy nhiều công ty nhỏ và vừa bị confused giữa các vai trò này. Tech lead được expect như CTO nhưng salary như senior dev. Hoặc ngược lại: CTO được expect code daily nhưng không có time để làm strategy.
Clarity về vai trò quan trọng hơn mọi thứ.
Câu hỏi tôi tự hỏi mỗi tuần
Từ năm thứ 3 làm leadership, tôi có một câu hỏi kiểm tra mỗi cuối tuần:
"Tuần này, cái gì chỉ có tôi mới làm được? Cái gì team khác có thể làm tốt hơn tôi?"
Những thứ chỉ tôi làm được (thường): Architecture decision với business context đầy đủ, stakeholder communication, hiring decision, resolving cross-team conflict.
Những thứ team làm tốt hơn tôi: Feature implementation, detailed code review, QA planning, DevOps configuration (sau khi tôi đã dạy họ).
Nếu trong một tuần, tôi code nhiều hơn tôi làm những thứ "chỉ tôi làm được" - đó là tuần tôi fail với vai trò tech lead.
Lời khuyên cho các bạn trẻ đang chuyển lên leadership
1. Đừng sợ "trở nên lỗi thời" về kỹ thuật
Nhiều bạn sợ rằng nếu họ lead nhiều, code ít, sau vài năm họ sẽ không còn technical nữa. Nỗi sợ đó hợp lý. Nhưng solution không phải là giữ nguyên code như developer - solution là học cách học khác (như tôi đã chia sẻ trong bài trước).
2. Credibility đến từ judgement, không chỉ từ code
Khi bạn lead đủ lâu, credibility của bạn đến từ những quyết định đúng, từ team grow được, từ project thành công. Không phải từ số lines of code.
3. Nếu bạn miss coding - đó là thông tin quan trọng
Có những người thực sự không muốn lead. Họ muốn là individual contributor xuất sắc - và đó là path hoàn toàn hợp lệ. Staff Engineer, Principal Engineer là những vai trò vừa technical vừa impactful mà không cần phải manage people.
Biết mình muốn gì còn quan trọng hơn biết mình "phải" làm gì.
4. Buông bỏ ego của developer - và đó là điều khó nhất
Thành thật mà nói: cái khó nhất khi transition lên leadership không phải là học skills mới. Là buông bỏ cái identity "tôi là người code giỏi" mà bạn đã xây trong nhiều năm.
Khi bạn làm được điều đó, bạn sẽ thấy vai trò lead có những niềm vui riêng của nó - xem junior dev grow, xem architecture decision pan out đúng như tính toán, xem team deliver thứ không ai nghĩ làm được.
Và những niềm vui đó, theo tôi, còn thú vị hơn việc code.
Bạn đang ở vai trò tech lead? Bạn đang struggle với balance giữa code và lead? Share với anh - anh muốn biết bạn đang đối mặt với gì.
/Son Do - believe in basic
#1percentbetter #technicalleadership #techlead #engineeringmanagement #careeradvice