WEBSITE ĐANG PHÁT TRIỂN

Ngày đầu làm tech lead - tôi đã làm sai gì

Ngày được gọi vào phòng quản lý và nghe hai chữ "tech lead", tôi cảm thấy như vừa đạt được điểm cuối của một cuộc chạy dài. Sáu năm, mười ba dự án e-commerce, vô số lần rebuild hệ thống search - chắc đó là lý do. Tôi nghĩ: "Ok, bây giờ tôi sẽ vừa tiếp tục code tuyệt vời, vừa dẫn dắt đội. Không có gì khó cả."

Nó khó lắm, các bạn.

Những tuần đầu, tôi nằm mơ thấy mình ngồi bàn phím lúc 2 sáng, vừa fix bug cho feature mới của nhóm vừa phải review PR cho 5-6 người khác. Tôi cố làm tất cả - viết code, lên quyết định kiến trúc, debug lỗi production, đôi khi còn vào Slack kiểm tra xem mấy dev junior có đang giải quyết task đúng cách không. Tôi bao biện rằng "đây là cách tôi chứng tỏ mình xứng đáng là tech lead mà."

Sai. Sai từ câu hỏi đầu tiên.

Sai lầm đầu tiên: Tôi còn cô đơn, và tôi cô đơn một mình

Ba tuần vào vị trí, tôi hoàn toàn cháy hết pin. Chẳng phải vì pressure công việc - vì tôi đã giả vờ rằng job description của tôi chính là "làm hết việc trước khi ai khác kịp."

Bản chất của tôi là người sẽ grab những task khó nhất, những tickets mà "chỉ tôi mới biết cách fix." Và khi làm leader, tôi vẫn làm như thế. Kết quả? Đội tôi bị tắc hàng quanh những task đơn giản hơn, chẳng ai được cơ hội để grow, và tôi - vâng, tôi nằm bàn phím lúc nửa đêm, thói quen cũ.

Một đồng nghiệp kỳ cựu gọi tôi ra ngoài cuối tuần đó. Anh chỉ nói một câu duy nhất: "Nếu anh tiếp tục code như thế, đội anh sẽ luôn cần anh để tồn tại. Đó là một cái bẫy."

Câu nói đó không giết được tôi, nhưng nó làm tôi suy nghĩ.

Sai lầm thứ hai: Tôi cứ quyết định tất cả

Mấy dự án trước, tôi là senior IC - chuyên gia kỹ thuật. Khi có vấn đề kiến trúc, tôi ngồi lại 30 phút, vẽ diagram, rồi nói: "Thế này." Đội tôi chấp nhận vì tôi đúng - hoặc ít nhất, hầu hết lần tôi đều đúng.

Nhưng khi làm tech lead, cách tôi ra quyết định không thay đổi. Nói khác đi, tôi chỉ thay đổi title, chứ không thay đổi hành động. Tôi vẫn ngồi lại, vẽ diagram, rồi nói: "Thế này" - chỉ là lần này, tôi lại còn phải giải thích thêm tại sao "thế này" là đúng cho mấy junior developer mới vào.

Vấn đề? Khi tôi không có mặt, đội tôi lúng túng. Họ chẳng biết cách giải quyết vấn đề, họ chỉ biết cách làm theo chỉ dẫn của tôi.

Tôi thành một bottleneck - không phải vì tôi biết quá nhiều, mà vì tôi không bao giờ dạy cho họ cách tư duy. Tôi không delegation, tôi chỉ ủy quyền execution. Hai cái đó khác nhau, các bạn. Delegation là tôi nói: "Đây là problem, tôi tin bạn giải quyết được, hãy nói cho tôi cách bạn nghĩ." Ủy quyền execution là tôi nói: "Hãy làm đúng như tôi nói."

Sai lầm thứ ba: 1-on-1 của tôi chỉ là status update

"Anh/chị đang làm task nào? Tiến độ như nào? Có blockers không?"

Đó là tất cả những gì tôi hỏi ở những buổi 1-on-1 đầu tiên. Tôi nghĩ rằng - và đây là phần buồn cười nhất - tôi đang "quản lý tốt" vì tôi theo dõi tiến độ. Thực tế, tôi không hỏi cái gì quan trọng: "Anh/chị có happy không? Cái gì khiến anh/chị stress? Anh/chị muốn grow theo hướng nào?"

Một dev junior trong đội từ chối một offer từ một công ty lớn hơn. Tôi bất ngờ - tôi còn tiền đề là anh ta sẽ bỏ đi vì anh ta quá giỏi. Khi hỏi tại sao, anh ta nói: "Anh không bao giờ thấy quan tâm đến tôi như người. Chỉ như một cái máy hoàn thành task." Nó chích tôi, nhưng anh ta nói đúng.

Sai lầm thứ tư: Tôi không lên kế hoạch, tôi chỉ react

Trong vai IC, việc lên kế hoạch không phải bổn phận của tôi - tôi nhận task, tôi làm, xong. Nhưng làm tech lead, mọi thứ lại khác. Có một khái niệm gọi là "technical vision" - tôi phải biết team đang đi đâu, 3 tháng tới sẽ build cái gì, năm sau architecture như thế nào.

Thay vì làm điều đó, tôi chỉ hốt hoảng chạy theo từng sprint, từng ticket. Một lần, chúng tôi phát hiện ra tech stack của mình cổ lỗi chỉ sau khi team đã phụ thuộc vào nó. Khi đó, cost của việc chuyển đổi lên tới mấy tháng, thay vì nếu tôi đã có "map" từ đầu, chúng tôi có thể refactor dần.

Bài học: Chuyển từ "Làm" sang "Enable"

Sau mấy tháng chạy theo kiểu đó, tôi buộc phải dừng lại và xem lại. Một mentor của tôi nói: "Thành công của anh, bây giờ, không phải là anh code đẹp. Thành công là đội anh code đẹp hơn hôm qua, và anh hỗ trợ họ làm điều đó."

Từ đó, tôi bắt đầu thay đổi:

Delegate tasks thay vì grab chúng. Tôi vẫn code, nhưng tôi chọn kỹ những gì tôi code. Thay vì "lấy task khó nhất", tôi đặt câu hỏi: "Task nào sẽ giúp dev junior này grow nhất?" Rồi tôi mentorship họ qua nó.

Mở ra decision-making process thay vì announce decisions. Khi có problem kiến trúc, tôi thay đổi từ "Nghe tôi, hãy làm thế" sang "Tôi nghĩ chúng ta nên làm thế, nhưng tôi muốn nghe suy nghĩ của mọi người trước." Và tôi lắng nghe thật - không phải nghe để chỉnh sửa, mà để học.

1-on-1 từ "status check" thành "mentoring & growth." Tôi hỏi: "Anh/chị cảm thấy như thế nào? Tôi có thể giúp anh/chị grow cái gì?" Tôi hỏi về dream role, về khó khăn. Tôi lắng nghe nhiều hơn nói.

Lên technical roadmap và share vision. Mỗi quý, tôi dành thời gian viết ra "team technical roadmap" - không phải sơ đồ phức tạp, chỉ là 5-10 điều chúng tôi muốn refactor hoặc improve. Tôi share nó với đội, hỏi feedback, rồi commit vào nó.

Gửi các bạn trẻ đang transition

Nếu các bạn là senior dev và vừa được promote lên tech lead, nghe lời tôi: Đừng cố code như lúc trước. Tôi biết nó khó. Tôi biết bạn muốn chứng tỏ mình xứng đáng. Nhưng thứ duy nhất bạn sẽ chứng tỏ là bạn không thể scale.

Thành công của bạn, bây giờ, không phải là output của bạn. Nó là output của đội bạn. Và nếu bạn cứ cố làm tất cả, đội bạn sẽ không bao giờ output được gì.

Hai tuần đầu, hãy listen. Hỏi từ từ. Không cần quyết định gì. Một tháng sau, hãy bắt đầu delegate những task nhỏ với support mạnh. Ba tháng, nếu bạn có thể nhìn lại và thấy team bạn giải quyết problem mà không cần bạn, đó là dấu hiệu bạn đang làm đúng.

Và nhớ: Delegation không phải "tôi bỏ cho bạn," nó là "tôi tin bạn, tôi support bạn." Hai cái đó khác nhau nhiều lắm.

Hôm nay, 7 năm sau ngày đầu tiên đó, tôi vẫn code - nhưng ít hơn. Tôi vẫn ra quyết định - nhưng không phải một mình. Và thứ mà tôi tự hào nhất không phải là những lines of code tôi viết, mà là những engineer tôi mentorship grow thành tech lead sau tôi.

Đó là thứ khác biệt.

Và tôi có một câu hỏi cho các bạn:

Nếu bạn là senior developer sắp transition sang tech lead, hay thậm chí đã ở position đó: Bạn đang làm gì không cần phải bạn làm? Hôm nay, hãy tìm một task, ghi vào list, rồi delegation cho ai đó với frame là "đây là cơ hội để bạn grow." Rồi step back. Chỉ support, không overtake.

Nói cho tôi biết điều gì xảy ra.

/ Son Do - believe in basic

#1percentbetter #techleadership #engineeringculture #leaddev #careerpath


Bài viết liên quan

Xem thêm
Technical Leadership & Engineering Culture

Khi AI làm được mọi thứ, thứ còn lại chính là bạn

Trong thời đại AI viết code, dự đoán bug, và generate bất kỳ tài liệu kỹ thuật nào, thứ không thể tự động hóa lại là điều đơn giản nhất: cuộc trò chuyện thật sự giữa người với người. Và chính điều đó đang trở thành lợi thế cạnh tranh lớn nhất của bạn.

Technical Leadership & Engineering Culture

Antigravity và nghệ thuật chống lại trọng lực tổ chức

Trọng lực tổ chức là cái lực vô hình kéo team về phía "những gì đã quen rồi". Để bay lên (antigravity), bạn phải hiểu rõ nó, đo lường nó, rồi mới có thể chống lại nó.

Technical Leadership & Engineering Culture

Mentoring junior developer không phải là dạy code

Sau 20 năm trong ngành và 7+ năm làm tech lead, tôi nhận ra: mentoring junior developers không phải là dạy code, mà là dạy cách suy nghĩ. Nếu bạn chỉ giải quyết các vấn đề cho họ, bạn đang cướp đi cơ hội để họ trở thành independent engineer. Thực ra cách lớn nhất để giúp junior phát triển là cùng học cách giải quyết vấn đề, chứ không phải đưa câu trả lời sẵn.