18 tháng trước, tôi được thăng chức làm Technical Lead của team nơi tôi đang làm việc với vai trò Senior Fullstack Engineer.
Mặc dù các hoạt động hàng ngày không thay đổi nhiều – tôi vẫn review code, phân công nhiệm vụ và hướng dẫn đồng nghiệp như trước – nhưng có một sự thay đổi lớn trong cách người khác nhìn nhận vai trò của tôi và những kỳ vọng đi kèm với vị trí Tech Lead.
Với tính cách mạnh mẽ và đôi khi hơi thẳng thắn, tôi nhận ra rằng điều có thể chấp nhận được ở vị trí đồng nghiệp ngang hàng không còn phù hợp khi là người lãnh đạo. Tôi cần phải cải thiện kỹ năng giao tiếp và làm việc với con người. Việc chính thức phụ trách một team cũng buộc tôi phải xem xét lại vai trò cá nhân của mình và những kỳ vọng đặt lên các thành viên khác.
Tôi mới chỉ ở giai đoạn đầu của hành trình lãnh đạo, nhưng 18 tháng vừa qua đã chứa đầy những thách thức, nghi ngờ và bài học. Tôi chia sẻ chúng ở đây, để đưa ra một số lời khuyên cho bất kỳ ai muốn trở thành Technical Lead và để nhận được phản hồi, gợi ý từ các Lead và Manager có nhiều kinh nghiệm hơn.
Mục lục
Output vs Outcome
Sự khác biệt cốt lõi giữa một người với vai trò cá nhân và Technical Lead nằm ở sự khác biệt giữa Output và Outcome. Dù từng là những ninja coder hay 10x developer xuất sắc, khi trở thành người lãnh đạo kỹ thuật, chúng ta sẽ code ít đi và có thể cảm thấy kém hiệu quả hơn. Tuy nhiên, tác động của việc giúp 10 kỹ sư giỏi hơn 10% sẽ lớn hơn nhiều so với năng suất tối đa của một cá nhân.
Trách nhiệm giải trình và Trách nhiệm thực hiện
Là một developer, tôi luôn cam kết đáp ứng deadline, tạo code chất lượng và đề xuất giải pháp cho các vấn đề. Khi trở thành Tech Lead, tôi ban đầu cảm thấy mình phải chịu trách nhiệm với mọi thứ team làm.
Nhưng đó là một sai lầm.
Mỗi thành viên trong team phải chịu trách nhiệm về những gì họ làm và cách họ làm điều đó. Họ sở hữu tính năng mà họ đang triển khai.
Nếu bạn không tin tưởng các thành viên trong team và cảm thấy có trách nhiệm với từng dòng code họ viết, bạn sẽ kết thúc bằng việc quản lý vi mô. Điều này không tốt cho bạn và không tốt cho team của bạn.
Không tốt cho bạn vì bạn sẽ bị sa lầy vào chi tiết thay vì tập trung vào mục tiêu lớn, trong khi team mất đi cơ hội học hỏi và phát triển. Tất nhiên, nếu có điều gì xấu xảy ra, bạn có thể phải chịu trách nhiệm giải trình về điều đó (và bạn không nên chỉ đổ lỗi xuống team của mình), nhưng có sự khác biệt lớn giữa việc chịu trách nhiệm giải trình và chịu trách nhiệm thực hiện.
Hiệu suất và Tốc độ của Team
Trong một team, khoảng cách về năng lực giữa các thành viên có thể rất lớn. Thay vì cố gắng đưa mọi người lên cùng một tiêu chuẩn cao, chúng ta cần chấp nhận rằng mỗi người có những kỹ năng, đường cong học tập và động lực khác nhau. Như Yan Cui từng nói:
Bạn phải chậm lại nếu muốn đi nhanh hơn
Nguyên tắc này đúng với cả cá nhân lẫn leader. Là tư cách cá nhân, bạn phải dành thời gian học hỏi để nâng cao tốc độ. Là leader, bạn cần thời gian để hiểu team, lắng nghe nhu cầu và tôn trọng nhịp độ của từng người.
Đừng vội vàng truyền đạt tất cả kiến thức cùng lúc. Giống như trong thể thao, việc tập luyện quá sức mà không có thời gian nghỉ ngơi sẽ dẫn đến chấn thương thay vì cải thiện sức mạnh. Hãy cho phép mọi người có thời gian tiếp thu kiến thức và thể hiện sự tiến bộ.
Kết quả của hành động của bạn
Một ngày nọ, khi tôi đang trao đổi về những trăn trở của mình với Giám đốc Kỹ thuật, anh ấy đã nhắc đến một câu trong Bhagavad Gita:
“Bạn có quyền với hành động của mình, nhưng không bao giờ có quyền với kết quả của hành động.”
Ban đầu tôi không thực sự hiểu, nên sau cuộc trò chuyện, tôi đã tìm hiểu thêm.
“Điều quan trọng là hành động, không phải kết quả của hành động. Bạn phải làm điều đúng đắn. Có thể không phải trong khả năng của bạn, có thể không phải trong thời điểm của bạn, để có được kết quả. Nhưng điều đó không có nghĩa là bạn ngừng làm điều đúng đắn. Bạn có thể không bao giờ biết hành động của mình sẽ mang lại kết quả gì. Nhưng nếu không làm gì cả, chắc chắn sẽ không có kết quả nào.”
Tôi phải nói rằng tôi không hoàn toàn đồng ý với trích dẫn này khi áp dụng vào việc lãnh đạo (hay dạy dỗ) người khác. Bởi theo tôi, “kết quả của hành động” ở đây nói đến phần thưởng nhiều hơn là hiệu quả, nhưng tôi hoàn toàn đồng ý rằng chúng ta nên làm điều đúng đắn, bất kể kết quả ra sao.
Và tôi nghĩ điều mà Giám đốc của tôi muốn nói là:
Chúng ta nên tập trung vào những gì chúng ta có thể kiểm soát – đó là đầu vào. Hãy để đầu ra tự định hình.
Hãy làm những gì bạn có thể. Cho đi sự hướng dẫn, kiến thức và sự hỗ trợ của bạn. Đừng trách móc bản thân quá nhiều nếu họ không tiếp nhận được.
Bạn có thể nóng vội với số lượng và chất lượng hành động của bạn, nhưng hãy kiên nhẫn với kết quả của chúng.
Sự thay đổi phải đến từ bên trong
Bạn không thể ép buộc người khác thay đổi.
Dĩ nhiên bạn có quyền hạn và sức mạnh trong team, nhưng việc dựa vào điều đó hiếm khi mang lại hiệu quả. Chắc chắn, trong một số trường hợp bạn có thể áp dụng biện pháp kỷ luật – khiển trách hay thậm chí sa thải… nhưng đó hiếm khi là cách mà một leader/manager giỏi xử lý thách thức hay xung đột.
Nhiệm vụ của chúng ta là chỉ cho họ thấy con đường, không phải nắm tay dắt họ đi. Hãy cố vấn, hỗ trợ, trao quyền và lắng nghe.
Học cách ủy quyền
Tech lead thường vẫn tham gia coding và review code. Khi có vấn đề quan trọng, việc trực tiếp xử lý là điều dễ hiểu.
Là người có kinh nghiệm nhất trong team, bạn cảm thấy mình phải lo hết mọi việc. Nhưng đa nhiệm không bao giờ tốt, hãy học cách ủy thác. Giao những nhiệm vụ ưu tiên cao cho các thành viên trong team, hướng dẫn và cho họ lời khuyên nhưng đừng tự mình làm tất cả mọi thứ.
Hãy kìm nén việc muốn tiếp quản công việc.
Đúng, có thể bạn sẽ làm nhanh hơn, thậm chí code tốt hơn, nhưng bạn đang tước đi cơ hội học hỏi, cải thiện, trở nên độc lập và tăng cảm giác làm chủ công việc của các thành viên trong team.
Và đây có lẽ là một trong những điều khó khăn nhất đối với những kỹ sư senior có kinh nghiệm khi chuyển sang vị trí Tech Lead
Cho phép các thành viên trong team tự do làm việc theo cách của họ, dù có thể không tốt bằng cách của bạn
Tôi biết, điều này thật khó khăn, nhưng đó là sự thật.
Điều này không có nghĩa là hạ thấp tiêu chuẩn và từ bỏ chất lượng, mà chỉ là chấp nhận thực tế rằng vì lợi ích lớn hơn, vì dự án, để giữ động lực cao và duy trì sức khỏe tinh thần, bạn phải chấp nhận rằng các developer khác, dù có kinh nghiệm hay ít kinh nghiệm hơn, có thể làm việc đủ tốt.
