Nói ngắn gọn trước: nếu bạn cũng vừa trở thành quản lý kỹ thuật và chưa biết bắt đầu từ đâu, thì đây là cách tôi đang làm. Tìm hiểu con người, hiểu vì sao mọi thứ lại như bây giờ, rồi đọc mã nguồn, đại khái theo đúng thứ tự đó. Sau đó thì cung cấp đủ bối cảnh và đứng sang một bên để đội tự làm việc.
Tháng này tôi bắt đầu quản lý một đội kỹ sư, chỉ vài tuần sau khi viết bài về những gì thay đổi khi chuyển từ kỹ sư phần mềm lên quản lý kỹ thuật. Có một điều không ai nói trước với tôi: việc gì cũng có vẻ gấp. Đội mới, công ty mới, và một danh sách việc cần làm đã có từ lâu trước khi tôi tới. Tôi không thể làm hết cùng một lúc, nên tôi chọn ra ba việc phải làm cho đúng trước khi đụng tới bất cứ thứ gì khác.
Làm quen với đội#
Tôi đang đặt lịch 1:1 với từng người, và cố giữ cho các buổi này xoay quanh con người, chứ không phải chuyện sprint. Họ muốn gì cho sự nghiệp của mình? Dạo này điều gì làm họ bực mình? Nếu được, ngày mai họ muốn thay đổi gì? Trong mấy buổi này, việc của tôi chủ yếu là im lặng và lắng nghe. Niềm tin không thể xây xong trong tuần đầu tiên, nhưng chắc chắn có thể mất ngay trong tuần đầu tiên.
Mỗi người lại làm việc theo một kiểu rất khác nhau. Có người muốn được hướng dẫn chi tiết, có người thì làm tốt nhất khi bạn để họ yên, và nếu đối xử với người này theo cách dành cho người kia thì chẳng ai vui cả. Cuốn “The Manager’s Path” của Camille Fournier viết về chuyện này rất hay. Hóa ra sự đồng cảm và thật lòng lắng nghe mới là phần lớn công việc.
Hiểu vì sao mọi thứ lại như bây giờ#
Mỗi quy trình, mỗi chỗ kỳ quặc trong kiến trúc đều là dấu vết của một quyết định nào đó trong quá khứ. Trước khi thay đổi gì, tôi muốn biết người ta đã thử những gì, cái gì đã thất bại, và công ty thật sự quan tâm đến điều gì.
Công ty nào cũng có những luật bất thành văn về cách các quyết định thực sự được đưa ra. Tôi nắm được chúng càng nhanh thì càng làm được nhiều việc cho đội. Andrew Grove có nói ý này trong cuốn “High Output Management”: bạn không thể gắn công việc của đội với bức tranh lớn khi chính mình còn chưa hiểu bức tranh đó.
Đọc mã nguồn#
Tôi không cần phải là người lập trình giỏi nhất đội nữa, nhưng tôi cần hiểu kiến trúc, những chỗ đang gây khó chịu, và nợ kỹ thuật (technical debt) đang bị chôn ở đâu. Vì vậy tôi đọc mã, mày mò quy trình triển khai, và hỏi mọi người rằng nếu có một tuần rảnh thì họ sẽ sửa gì. Câu trả lời cho câu hỏi cuối cùng này thường là bản lộ trình (roadmap) thành thật nhất mà bạn có được.
Làm vậy cũng là cách để đội thấy rằng tôi quan tâm đến chính công việc họ làm, chứ không chỉ đến mấy quy trình bọc quanh nó.
Rồi thì đứng sang một bên#
Khi đã có nền móng đó, kế hoạch rất đơn giản: cung cấp bối cảnh, chia sẻ mục tiêu, và để đội tự đưa ra các quyết định kỹ thuật. Việc của tôi không phải là duyệt từng pull request, mà là lo cho mọi người có đủ những gì họ cần và đang đi đúng hướng. Cuốn “The Phoenix Project” của Gene Kim cũng lập luận y như vậy: những đội được tự quyết thì đi nhanh hơn và làm ra phần mềm tốt hơn những đội lúc nào cũng phải chờ cấp trên gật đầu.
Sách cho người mới làm quản lý kỹ thuật#
Gom lại ba cuốn sách tôi đã nhắc tới ở trên:
| Sách | Vì sao hữu ích cho quản lý kỹ thuật mới |
|---|---|
| “The Manager’s Path” của Camille Fournier | Viết riêng cho kỹ sư chuyển sang làm quản lý, đi qua từng nấc, từ người hướng dẫn (mentor), trưởng nhóm kỹ thuật (tech lead) lên đến CTO. Giai đoạn đầu thì những phần về buổi 1:1 và quản lý một đội là hữu ích nhất. |
| “High Output Management” của Andrew Grove | Sách đã cũ và viết từ kinh nghiệm điều hành Intel, nhưng ý cốt lõi vẫn đúng: đầu ra của người quản lý chính là đầu ra của cả đội, nên hãy dành thời gian cho những việc tác động được đến điều đó. |
| “The Phoenix Project” của Gene Kim, Kevin Behr và George Spafford | Một cuốn tiểu thuyết về một người quản lý IT cứu một dự án đang trên đà đổ bể. Dễ đọc hơn sách giáo khoa, và cho thấy rất rõ công việc ùn ứ, tắc lại giữa các đội như thế nào. |
Ngoài ra, mỗi khi có người hỏi quản lý kỹ thuật mới nên đọc gì, còn hai cuốn nữa cũng thường được nhắc tới: “An Elegant Puzzle” của Will Larson, nói về phần hệ thống của công việc quản lý (quy mô đội, lập kế hoạch, thiết kế tổ chức), và “Resilient Management” của Lara Hogan, một cuốn ngắn và thực tế về việc hiểu đội của mình, đặt kỳ vọng rõ ràng và giao tiếp rành mạch.
Sáu tháng nữa hỏi lại tôi xem mọi chuyện thế nào nhé.