Trong lĩnh vực công nghệ thông tin, vai trò và trách nhiệm của quản lý kỹ thuật (engineering manager) và trưởng nhóm kỹ thuật (technical lead) thường bị nhầm lẫn. Tuy nhiên, việc phân định rõ ràng các vai trò này rất quan trọng để đảm bảo một nhóm hoạt động hiệu quả và năng suất. 

Trong bài viết này, VietnamWorks inTECH sẽ đi sâu vào những khác biệt giữa vai trò của Technical Lead và Engineering Manager, thông qua sự phức tạp trong giao tiếp với các nhóm kỹ thuật và lý do tại sao các quản lý kỹ thuật nên tránh thực hiện review code.

1. Sự khác biệt giữa Technical Lead và Engineering Manager

Thoạt nhìn, vai trò của Engineering Manager (EM) và Technical Lead (Tech Lead) có vẻ giống nhau, nhưng trách nhiệm cốt lõi của họ lại khác nhau khá nhiều:

• Vai trò chính của một EM là quản lý nhân sự, triển khai dự án và tối ưu hóa quy trình. Họ chịu trách nhiệm về việc phát triển sự nghiệp của các thành viên trong nhóm, thực hiện đánh giá hiệu quả, tuyển dụng và đảm bảo các dự án được hoàn thành đúng thời hạn và trong phạm vi đề ra. EM cũng đóng vai trò then chốt trong việc liên kết các mục tiêu của nhóm với các mục tiêu chiến lược của công ty, quản lý kỳ vọng của các bên liên quan và thúc đẩy môi trường làm việc hiệu quả.

• Ngược lại, Tech lead tham gia sâu vào các khía cạnh kỹ thuật của dự án. Họ thường là người hướng dẫn kỹ thuật, dẫn dắt các kỹ sư junior và đảm bảo chất lượng của codebase. Trưởng nhóm kỹ thuật thường chịu trách nhiệm về các quyết định liên quan đến  kiến trúc, thực hiện review code và luôn cập nhật những xu hướng công nghệ mới để áp dụng vào các dự án một cách hiệu quả. Họ cũng xử lý các vấn đề liên quan đến bug, tối ưu hóa hiệu suất và duy trì tài liệu kỹ thuật.

Việc nhận biết vai trò của từng bị trí vô cùng quan trọng: EM tập trung vào "nhóm đang hoạt động như thế nào", trong khi Tech Lead tập trung vào "dự án đang hoạt động như thế nào". Sự tách biệt này cho phép mỗi vai trò chuyên môn hóa và xuất sắc trong lĩnh vực tương ứng của họ.

2. Độ phức tạp trong giao tiếp O(n²)

Khi các nhóm phát triển, độ phức tạp của giao tiếp tăng theo cấp số nhân, thường được mô tả bằng công thức O(n²), trong đó 'n' là số thành viên trong nhóm. Khái niệm này nhấn mạnh sự gia tăng phi tuyến tính của việc giao tiếp với mỗi thành viên gia nhập nhóm.

• Trong một nhóm nhỏ, mọi người có thể giao tiếp trực tiếp với nhau, giúp việc phối hợp trở nên tương đối đơn giản. Các kênh giao tiếp ít hơn và dễ quản lý hơn, tạo điều kiện cho việc ra quyết định nhanh chóng và sự gắn kết nhóm mạnh mẽ.

• Khi các nhóm mở rộng, số lượng kênh giao tiếp tăng lên đáng kể. Ví dụ, một nhóm gồm 5 người có 10 đường giao tiếp, nhưng một nhóm gồm 10 người có 45 đường giao tiếp. Sự gia tăng theo cấp số nhân này có thể dẫn đến quá tải thông tin, giao tiếp sai sót và trì hoãn trong việc ra quyết định.

Để giải quyết sự phức tạp này, các EM phải triển khai các cấu trúc giao tiếp hiệu quả, chẳng hạn như:

• Phân chia thành các nhóm nhỏ: Chia các nhóm lớn thành các nhóm nhỏ hơn, việc tập trung vào từng nhóm nhỏ như vậy có thể giúp quản lý sự phức tạp của giao tiếp. Mỗi nhóm có thể đảm nhận một trách nhiệm, tính năng cụ thể, giúp giảm số lượng kênh giao tiếp cần thiết để phối hợp làm việc dễ dàng hơn.

• Họp định kỳ: Thiết lập các cuộc họp stand-up thường xuyên, lập kế hoạch sprint và các cuộc họp cải tiến (retrospective meeting) để đảm bảo mọi người đều được thông tin và kết nối. Những cuộc họp này giúp đồng bộ công việc và giải quyết các vấn đề ngay lập tức.

• Sử dụng các công cụ giao tiếp hiệu quả: Sử dụng các công cụ như Slack để nhắn tin tức thời, Jira để theo dõi vấn đề hay Confluence để ghi chú. Điều này có thể giúp đơn giản hóa luồng thông tin và đảm bảo các thành viên trong nhóm có quyền truy cập vào thông tin họ cần khi cần.

3. Đường Cong Quy Mô Nhóm

Hiểu được quy mô nhóm tối ưu là rất quan trọng để duy trì năng suất và tinh thần làm việc. Nghiên cứu và các thông lệ của ngành cho thấy các nhóm hiệu quả nhất bao gồm 5-9 thành viên.

• Nhóm nhỏ (5-9 thành viên): Hoạt động linh hoạt, với các kênh giao tiếp rõ ràng và mối quan hệ cá nhân gắn kết. Họ có thể thích nghi nhanh chóng với những thay đổi và duy trì mức độ gắn kết cao. Các nhóm nhỏ thường thể hiện mức độ tin tưởng và hợp tác cao, điều này quan trọng cho việc giải quyết vấn đề sáng tạo.

• Nhóm lớn (>9 thành viên): Các nhóm lớn thường gặp phải những thách thức trong việc phối hợp, ra quyết định và duy trì văn hóa đồng nhất. Chia nhỏ các nhóm lớn thành các đơn vị nhỏ hơn, giúp giảm thiểu những vấn đề đã kể trên, cho phép hợp tác tập trung trong khi vẫn duy trì sự phù hợp với mục tiêu lớn hơn. Mỗi nhóm nhỏ có thể có Tech Lead riêng, báo cáo với một EM, đảm bảo định hướng kỹ thuật và giám sát dự án thống nhất.

Đường cong quy mô nhóm nhấn mạnh tầm quan trọng của việc duy trì sự cân bằng giữa tính linh hoạt của nhóm và nguồn lực sẵn có, đảm bảo các nhóm luôn hiệu quả và có động lực.

4. Tại sao Engineering Manager không nên review code?

Lý do chính khiến các EM không nên thực hiện code review bắt nguồn từ nguyên tắc phân chuyên môn hóa vai trò và tập trung.

• Chuyên môn hóa về vai trò: EM nên tập trung vào việc quản lý nhóm ở cấp độ cao, lập kế hoạch chiến lược và loại bỏ những trở ngại cản trở hiệu suất của nhóm. Việc tham gia review code sẽ làm họ mất tập trung khỏi những trách nhiệm quan trọng này. Bằng cách tập trung vào các khía cạnh chiến lược và vận hành, các EM có thể hỗ trợ tốt hơn cho nhóm của mình trong việc đạt được mục tiêu.

• Tin Tưởng và Trao Quyền: Ủy quyền review code cho các Tech Lead và các lập trình viên có level cao khác sẽ thúc đẩy lòng tin và trao quyền cho nhóm. Nó khuyến khích một văn hóa có trách nhiệm, nơi các thành viên trong nhóm duy trì chất lượng code cao. Các nhóm được trao quyền có nhiều khả năng đổi mới và chủ động hơn, thúc đẩy thành công của dự án.

Ngoài ra, nếu EM thực hiện review code sẽ gây ra những cản trở trong nội bộ:

• Tránh Tình Trạng tắt nghẽn: Khi các EM thực hiện review code, họ có thể trở thành bottleneck (điểm nghẽn), gây ra sự chậm trễ trong quá trình phát triển. Các Tech Lead có vị trí tốt hơn để xử lý nhiệm vụ này một cách nhanh chóng, do chuyên môn kỹ thuật của họ và sự thấu hiệu chặt chẽ với codebase (phần code nền tảng). Bằng cách ủy quyền, các EM có thể đảm bảo rằng chu kỳ phát triển sản phẩm không bị cản trở và tiến độ dự án được đáp ứng.

• Duy trì Tính Khách Quan: Các EM phải duy trì một mức độ tách biệt để đánh giá khách quan về hiệu suất và năng động của nhóm. Việc tham gia review code có thể làm mờ ranh giới giữa đánh giá kỹ thuật và quản lý, có khả năng ảnh hưởng đến tính công bằng và khách quan. Bằng cách tập trung vào quản lý nhóm, các EM có thể cung cấp các đánh giá và hỗ trợ không thiên vị.

Tuy nhiên, cần lưu ý rằng những lý do này không phải là tuyệt đối và có thể thay đổi tùy theo bối cảnh và cấu trúc tổ chức cụ thể. Trong một số trường hợp, EM vẫn có thể tham gia vào việc review code nhưng ở mức độ hạn chế hơn, chẳng hạn như cung cấp phản hồi chung về cấu trúc code hoặc chọn phương pháp hay nhất.

Lời kết

Như vậy, việc Engineering Manager không nên tham gia review code xuất phát từ nhu cầu tập trung vào các nhiệm vụ chiến lược quan trọng hơn như quản lý dự án, phát triển nhân sự, và cải thiện quy trình làm việc. Bằng cách ủy thác công việc này cho các thành viên trong nhóm, Engineering Manager không chỉ giúp tối ưu hóa hiệu suất của đội ngũ mà còn tạo điều kiện cho sự phát triển và học hỏi lẫn nhau. Điều này đảm bảo rằng cả nhóm có thể hoạt động hiệu quả hơn và hướng tới những mục tiêu lớn hơn.

VietnamWorks inTECH