Đây là đổi nghề, chứ không phải thăng chức
Tôi cũng sắp bước sang vai trò này, nên thời gian gần đây tôi đi hỏi chuyện những người đã từng chuyển, và tìm được gì thì đọc nấy. Bài học rõ nhất cho tới giờ là: từ kỹ sư lên quản lý kỹ thuật (Engineering Manager) không phải là leo thêm một bậc. Thực ra bạn đang bước ngang sang một công việc khác hẳn. Thành quả của bạn không còn là những dòng mã mình viết ra, mà là những gì cả đội làm ra. Ai cũng nói vậy, và theo tôi thấy thì ai cũng vẫn xem nhẹ chuyện này.
Những gì thực sự thay đổi
Bạn không còn trực tiếp giải các bài toán kỹ thuật nữa, mà chuyển sang giải các bài toán về con người. Lịch làm việc kín mít những buổi 1:1, họp lên kế hoạch, họp để các đội thống nhất với nhau. Chuyện tuyển dụng và đánh giá hiệu suất giờ đổ lên đầu bạn. Phần lớn công việc là lo cho đội có đủ những gì họ cần để yên tâm làm việc: đủ bối cảnh, thứ tự ưu tiên rõ ràng, và càng ít chuyện vớ vẩn càng tốt.
Cái khó là bạn vẫn phải giữ đủ trình độ kỹ thuật để không bị lép vế khi bàn về kiến trúc và để đưa ra những quyết định hợp lý, trong khi lại phải chấp nhận rằng mình không còn là người trực tiếp viết mã. Những người quản lý tôi từng thấy cố ôm cả hai việc thường làm dở cả hai.
Kỹ sư và quản lý kỹ thuật, đặt cạnh nhau
| Kỹ sư phần mềm | Quản lý kỹ thuật | |
|---|---|---|
| Thành quả của bạn | Mã nguồn, bản thiết kế, các lượt rà soát mã | Những gì cả đội làm ra, và chính bản thân đội |
| Được đánh giá qua | Chất lượng và tác động của công việc do chính bạn làm | Đội có bàn giao đúng hẹn không, có giữ được người không, và mọi người tiến bộ được bao nhiêu |
| Một ngày điển hình | Thời gian ngồi tập trung viết mã, pull request, thảo luận thiết kế | Các buổi 1:1, lên kế hoạch, tuyển dụng, gỡ vướng cho mọi người |
| Vòng phản hồi | Vài giờ hoặc vài ngày: kiểm thử chạy qua, tính năng được phát hành | Vài tháng: một người mới tuyển tỏ ra phù hợp, một người được thăng chức |
| Công việc kỹ thuật trực tiếp | Chiếm phần lớn thời gian trong tuần | Rà soát mã và chốt các quyết định kiến trúc, hiếm khi tự làm phần việc quyết định tiến độ của cả đội |
Trong bảng này, vòng phản hồi là điều mà những người đi trước hay dặn tôi nhất. Làm kỹ sư thì gần như ngày nào bạn cũng có một chiến thắng nho nhỏ. Làm quản lý thì thành quả vẫn có thật, nhưng đến chậm, và bạn phải quen với việc có khi phải mất một thời gian khá lâu mới biết một quyết định của mình là đúng hay sai.
Những kỹ năng có vẻ quan trọng
Giao tiếp chiếm gần hết công việc. Bạn trở thành người “phiên dịch” giữa đội mình, bộ phận sản phẩm và ban lãnh đạo, và một phần lớn đến bất ngờ của công việc chỉ là đảm bảo ba bên đang nói về cùng một chuyện. Niềm tin quan trọng hơn mọi quy trình: nếu mọi người không thấy yên tâm khi báo với bạn chỗ nào đang hỏng, bạn sẽ là người biết chuyện sau cùng. Lịch làm việc thì sẽ tìm mọi cách nuốt chửng bạn, nên giữ lại thời gian để suy nghĩ, và thời gian cho đội, là một cuộc chiến không có hồi kết. Cuối cùng, bạn phải hiểu công ty thực sự đang muốn đạt được điều gì, không thì bạn chẳng thể chỉ cho ai một hướng đi có ích.
Chuẩn bị từ trước khi có chức danh
Lời khuyên tôi nghe đi nghe lại, và cũng là điều tôi đã tự kiểm chứng được: hãy bắt đầu dẫn dắt trước khi có ai trao chức danh cho bạn. Đứng ra lo một dự án, kèm cặp một đồng nghiệp, hay tổ chức một việc gì đó. Suốt năm qua tôi làm trưởng dự án, và trải nghiệm đó giúp tôi nhiều hơn bất kỳ cuốn sách nào. Dù vậy, sách vẫn có ích. Cuốn “The Manager’s Path” của Camille Fournier thì ai cũng giới thiệu, và đọc xong tôi hiểu vì sao. Đừng để kỹ năng kỹ thuật bị cùn, vì các cuộc tranh luận về kiến trúc sẽ không dừng lại đâu. Và hãy tìm một người cố vấn (mentor) đã từng đi qua con đường này, họ sẽ giúp bạn tránh những sai lầm mà chỉ khi nhìn lại mới thấy hiển nhiên.
Được cái này, mất cái kia
Bạn có nhiều tiếng nói hơn trong chuyện sản phẩm được làm ra như thế nào, nhưng lại hiếm khi tự tay làm. Tôi đoán sẽ có những ngày thấy chuyện đó thật tuyệt, và cũng có những ngày nhớ viết mã đến phát điên. Ai từng chuyển sang vai trò này cũng bảo tôi đó là chuyện bình thường. Sáu tháng nữa hỏi lại tôi nhé.