The Manager's Path của Camille Fournier: cuốn sách cho FDE sắp phải rời bàn phím

Có một con số mà mọi FDE muốn đi lên nên dán lên màn hình: 30%. Trong The Manager’s Path, Camille Fournier dẫn định nghĩa của Patrick Kua: tech lead là người dành ít nhất 30% thời gian viết code cùng đội. Ít nhất, chứ không phải nhiều nhất.

Nếu bạn là developer giỏi nhất đội và vừa được giao dẫn ba người triển khai tại khách hàng, con số này không cấm bạn code nhiều hơn. Nhưng Fournier nói rõ việc thật sự của tech lead là biết lúc nào bước ra khỏi code để lo việc cả đội cần. Vì thế nên đọc cuốn sách này sớm.

Một cuốn sách xếp theo bậc thang

The Manager’s Path, với phụ đề A Guide for Tech Leaders Navigating Growth and Change, do O’Reilly Media xuất bản năm 2017, dài 244 trang (ISBN-13: 9781491973899). Cách tổ chức của nó rất dễ dùng: mỗi chương ứng với một cấp quản lý kỹ thuật, đi từ hình thức mentoring đơn giản nhất lên tới vai trò CTO.

Nhờ cấu trúc đó, bạn có thể dùng cuốn sách như một tấm bản đồ và không cần đọc từ đầu đến cuối. Hãy xác định mình đang đứng ở bậc nào, đọc chương đó, rồi đọc chương ngay phía trên để biết việc tiếp theo sẽ đòi hỏi gì.

Với FDE, tấm bản đồ này đặc biệt hữu ích vì con đường thăng tiến thường không rõ ràng. Hôm nay bạn là người viết integration duy nhất ở một khách hàng; sáu tháng sau bạn có thể dẫn một nhóm nhỏ triển khai cho nhiều khách hàng cùng lúc. Sách không viết riêng cho FDE, nhưng các bậc nó mô tả khớp khá sát với hành trình đó.

Ba mươi phần trăm là sàn, không phải trần

Mốc của Kua giữ tech lead ở lại gần code. Với FDE, điều này còn quan trọng hơn ở nhiều vai trò khác, vì bạn thường là người khách hàng hỏi đầu tiên mỗi khi cần biết một việc kỹ thuật có khả thi hay không.

Một tech lead FDE ngừng code hoàn toàn sẽ rất khó trả lời chắc chắn câu hỏi “cái này có làm được trong hai tuần không?”.

Thử hình dung tuần đầu bạn dẫn ba người tại một khách hàng logistics, 40 giờ.

Một cách chia hợp lý: 12 giờ code cùng đội, nhận phần pipeline dữ liệu khó nhất hoặc pair với người đang vướng; 8 giờ review code và gỡ vướng; 8 giờ ngồi với người vận hành để hiểu quy trình và demo; 6 giờ cho quyết định kiến trúc và kế hoạch; 6 giờ cho 1-1 và mentoring. 12 trên 40 giờ là đúng mốc 30%.

Giờ thử đảo lại: bạn tự viết 30 giờ pipeline. Về con số, bạn vẫn vượt mốc của Kua. Nhưng chỉ còn 10 giờ cho mọi thứ khác, nên review bị dồn, người vận hành không ai hỏi chuyện, và hai đồng đội ngồi chờ.

Đây là thất bại mà Fournier cảnh báo: không chịu bước ra khỏi code để cân bằng cam kết kỹ thuật của mình với việc cả đội cần.

Kỹ năng khó nhất là chịu rời khỏi code

Fournier viết rằng một tech lead hiệu quả phải sẵn lòng bước ra khỏi code và tìm cách cân bằng cam kết kỹ thuật của mình với việc cả đội cần. Đây là bước chuyển tư duy khó nhất, vì kỹ năng đã đưa bạn lên vị trí này chính là kỹ năng bạn phải bớt dùng.

Ở môi trường FDE, cám dỗ này còn mạnh hơn. Khách hàng gấp, deadline sát, và bạn biết mình sửa bug nhanh hơn ai hết.

Nhưng mỗi lần bạn tự lao vào, đồng đội mất một cơ hội học, còn bạn mất một giờ lẽ ra dành cho việc chỉ mình làm được: gỡ vướng cho người đang kẹt và chốt với khách hàng việc nào làm trước, việc nào để sau.

Lời khuyên thực tế: khi viết CV hoặc chuẩn bị phỏng vấn cho vị trí FDE lead, đừng chỉ kể bạn đã build gì. Hãy chuẩn bị sẵn một câu chuyện về lần bạn chủ động giao việc khó cho người khác, bạn hỗ trợ ra sao và kết quả thế nào. Câu chuyện đó cho thấy bạn đã bắt đầu bước chuyển mà Fournier mô tả.

Chương nào đáng đọc kỹ tùy vào chỗ bạn đứng

Một bài review của người làm nghề, viết tháng 8/2017, gọi đây là cuốn sách tốt về những phần của leadership gắn riêng với kỹ thuật phần mềm. Cũng người viết đó cho rằng giá trị lớn nhất nằm ở các phần về quản lý một đội và nhiều đội, và gợi ý đọc lướt các chương đầu.

Lời gợi ý ấy hợp với người đã từng dẫn đội. Nhưng nếu bạn chưa từng chính thức làm tech lead, các chương đầu về mentoring và tech lead lại bàn đúng những việc bạn sắp phải làm, nên đọc kỹ chứ đừng lướt.

Ở bậc quản lý nhiều đội, sách mô tả người quản lý không còn viết code production thường xuyên mà giữ độ nhạy kỹ thuật qua code review. Thử hình dung bạn phụ trách hai nhóm FDE ở hai khách hàng: việc của bạn chuyển sang giúp từng tech lead bên dưới giữ nhịp, và phân biệt việc quan trọng với việc chỉ khẩn cấp.

Bậc CTO ở cuối sách xa hơn nữa, và hợp để đọc lại khi bạn đã tới gần.

Ai nên mở cuốn sách này trước

Cuốn sách hợp nhất với ba nhóm: FDE vừa được giao dẫn một nhóm nhỏ tại khách hàng, senior engineer đang cân nhắc giữa con đường chuyên môn và quản lý, và người đang tuyển hoặc phỏng vấn cho vị trí FDE lead muốn có ngôn ngữ chung để đánh giá ứng viên.

Cách đọc hiệu quả là đọc kèm lịch làm việc thật của mình. Mỗi chương, hãy so điều sách mô tả với tuần vừa qua: bạn code bao nhiêu giờ, giao bao nhiêu việc, có ai trong đội học được điều gì từ bạn không.

Một cuốn sách 244 trang sẽ không biến bạn thành người dẫn dắt. Nhưng nó cho bạn biết trước bậc thang tiếp theo trông thế nào, và rằng muốn bước lên, việc đầu tiên thường là buông bớt thứ bạn đang làm giỏi nhất.