Tháng này tôi bắt đầu quản lý một đội kỹ sư. 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à technical debt đang bị chôn ở đâu. Vì vậy tôi đọc mã, mày mò cái deployment pipeline, 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à cái 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 PR, 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áu tháng nữa hỏi lại tôi xem mọi chuyện thế nào nhé.