- Trong môi trường quy tụ các chuyên gia từ nhiều lĩnh vực, người lãnh đạo đảm nhận vai trò kết nối vấn đề và định hướng cách giải quyết hơn là nắm mọi chi tiết kỹ thuật
- Lãnh đạo đòi hỏi khả năng phiên dịch và kỹ năng xã hội quan trọng hơn kiến thức kỹ thuật đơn thuần, đồng thời cần điều phối xung đột và nhấn mạnh mục tiêu chung
- Điều quan trọng không phải là độ sâu chuyên môn của từng người, mà là làm rõ định nghĩa vấn đề thực tế và hướng giải quyết, để thảo luận dẫn đến nhu cầu người dùng và kết quả cụ thể
- Nhà lãnh đạo hiệu quả không giả vờ biết tất cả, mà có can đảm nói “không biết”, đồng thời tạo ra không gian để các chuyên gia chủ động đóng góp
- Giá trị thực sự của người lãnh đạo nằm ở phiên dịch góc nhìn, cung cấp bối cảnh vấn đề, tạo không gian hợp tác, và đó là yếu tố cốt lõi để tạo ra kết quả tốt nhất
Điều tôi gần đây nhận ra
- Tôi đang làm việc trong một phòng họp cùng các lập trình viên chuyên gia và đội ngũ sản phẩm từ nhiều lĩnh vực
- Tôi không có mức độ chuyên môn cao nhất ở một công nghệ cụ thể, nhưng đang đảm nhiệm vai trò lead developer
- Vai trò của tôi với tư cách người dẫn dắt giữa các chuyên gia không phải là biết mọi đáp án, mà là khả năng tìm ra câu trả lời và kết nối chúng lại
Technical Leadership
- Người lãnh đạo thực hiện vai trò người phiên dịch hiệu quả giúp thúc đẩy giao tiếp giữa các nhóm, hơn là chỉ dựa vào độ sâu kiến thức kỹ thuật
- Dù là giải thích tiến độ của đội backend hay yêu cầu từ đội sản phẩm, họ cần diễn giải theo từng góc nhìn để thúc đẩy cộng tác trong nhóm
Dẫn dắt là một kỹ năng xã hội
- Chỉ có độ tin cậy về kỹ thuật là chưa đủ; chính kỹ năng xã hội mới tạo ra năng suất thực sự
- Cần có khả năng đọc được các cuộc thảo luận giữa các lập trình viên và đánh giá đúng khi nào nên hòa giải tranh luận hoặc thúc đẩy cuộc trao đổi tiến lên
- Giao tiếp hiệu quả không chỉ đến từ tài liệu mà còn được hình thành qua đối thoại chủ động
Dẫn dắt là luôn nhớ mục tiêu
- Càng là chuyên gia, con người càng có xu hướng chìm sâu vào chi tiết kỹ thuật; vì vậy người lãnh đạo phải tập trung vào mục tiêu tổng thể
- Vai trò quan trọng là làm rõ không phải tranh luận kỹ thuật, mà là vấn đề cốt lõi của trải nghiệm người dùng và mục tiêu kinh doanh
- Nếu không xác định rõ bản chất của vấn đề, các thành viên trong nhóm có thể bỏ lỡ vấn đề thật sự theo cách phân tích riêng của mình
- Người lãnh đạo có trách nhiệm phiên dịch để cả nhóm hiểu đúng vấn đề và cùng nhìn về một mục tiêu
Dẫn dắt là nói "Tôi không biết"
- Thay vì giả vờ biết mọi đáp án, thái độ "Tôi không biết, hãy cùng tìm hiểu" sẽ tạo ra niềm tin và một văn hóa cởi mở
- Cách tiếp cận này cho phép chuyên gia nêu câu hỏi và tranh luận, đồng thời tạo cơ hội để mỗi người phát huy năng lực
- Người lãnh đạo trao quyền quyết định và quyền lên tiếng cho các chuyên gia theo từng chủ đề, đồng thời đưa ra định hướng để cuộc thảo luận đi theo hướng hiệu quả
- Khi hai chuyên gia bất đồng về cách triển khai, vai trò của lãnh đạo không phải là chọn "đáp án đúng", mà là đưa ra khung nhìn dựa trên trade-off và tác động tới người dùng
Thách thức của việc phiên dịch
- Người lãnh đạo phải có khả năng phiên dịch ngôn ngữ của lập trình viên, đội sản phẩm và ban lãnh đạo theo từng tình huống
- Lập trình viên: "Nếu dịch vụ xác thực không có circuit breaker phù hợp, lỗi dây chuyền có thể xảy ra khi hệ thống chịu tải"
- Đội sản phẩm: "Nếu hệ thống đăng nhập gặp sự cố, toàn bộ ứng dụng có thể bị ảnh hưởng, nên cần bổ sung cơ chế bảo vệ và lịch trình sẽ kéo dài thêm một tuần"
- Ban lãnh đạo: "Trong sprint này, chúng ta ưu tiên độ ổn định hệ thống để giảm rủi ro kinh doanh"
- Không cần bắt các chuyên gia phải học cả ngôn ngữ của bộ phận khác; người lãnh đạo phải là cây cầu lấp đầy khoảng cách đó
Vượt ra ngoài "Vì vậy thôi!"
- Cách ra quyết định kiểu "Tôi là người lead nên cứ làm thế này" sẽ làm tổn hại niềm tin và văn hóa hợp tác, đồng thời làm giảm năng suất của nhóm
- Điều quan trọng là đối xử với cả nhóm như những người trưởng thành và giải thích rõ lý do cùng bối cảnh của quyết định
- "Lý do chúng ta chọn cách tiếp cận thận trọng là vì chi phí nếu sai sẽ rất lớn, và sau đó vẫn có thể cải tiến dần qua nhiều vòng"
- "Điều này có thể trông như phần việc phát sinh thêm, nhưng nó phù hợp với mục tiêu kiến trúc và sẽ giúp ích cho việc phát triển các tính năng tiếp theo"
- "Đây có thể không phải lời giải thanh lịch nhất, nhưng là cách chúng ta có thể tự tin triển khai trong thời hạn đã định"
- Càng bớt bám vào việc thể hiện chuyên môn, bạn càng có thể phát huy năng lực lãnh đạo thực sự
Giá trị người lãnh đạo nên mang lại cho đội ngũ
- Cung cấp định nghĩa vấn đề rõ ràng
- Giải thích đầy đủ bối cảnh của quyết định
- Phiên dịch khác biệt về góc nhìn giữa các nhóm
- Bảo vệ nhóm khỏi sự phức tạp không cần thiết
- Tạo điều kiện cho kết quả tốt nhất
Kết luận
- Lãnh đạo kỹ thuật trong một tổ chức đầy chuyên gia không tập trung vào mệnh lệnh và kiểm soát, mà vào sự kết nối và việc cung cấp bối cảnh
- Người lãnh đạo không phải là nhạc công trực tiếp chơi nhạc cụ, mà giống như nhạc trưởng giúp cả dàn nhạc hoàn thành một bản nhạc
- Đây là một thử thách thú vị hơn nhiều so với việc chỉ trở thành người thông minh nhất trong phòng
4 bình luận
Nghĩ ngược lại thì trong môi trường không có chuyên gia, có lẽ mình buộc phải tự trở thành chuyên gia.
Tất nhiên cũng có lúc mình muốn dẫn dắt theo những cách khác ngoài vai trò lãnh đạo kỹ thuật, nhưng khi gặp các thành viên không chịu chia sẻ thì ngay cả điều đó cũng khó thực hiện, nên có vẻ còn tùy vào từng hoàn cảnh.
Góc nhìn rất hay.
Mình nên làm việc như thế này.
Ý kiến Hacker News
Với vai trò là trưởng nhóm, tôi thường cố tránh những quyết định kiểu “tôi là lead, và chúng ta sẽ làm theo cách này”, nhưng cũng nhấn mạnh rằng khi cần thì phải sẵn sàng làm như vậy không do dự. Tôi dành thời gian lắng nghe ý kiến của mọi người và cân nhắc cẩn thận trước khi quyết định, nhưng khi cả nhóm sa vào tranh cãi bất tận về những chi tiết không mang tính bản chất, tôi nhận ra rằng với tư cách người dẫn dắt, mình phải lập lại trật tự. Tôi nghĩ nhiều về câu nói được cho là của Steve Jobs: “Nếu muốn làm hài lòng tất cả mọi người thì đừng làm lãnh đạo, hãy đi bán kem.” Sau những tình huống như vậy, điều quan trọng là phải xây dựng lại niềm tin và giải thích cho các thành viên vì sao mình buộc phải hành động như thế
Tôi cũng đã học được bài học này theo cách khá đau đớn. Khi mới làm quản lý, tôi ngây thơ nghĩ rằng lúc nào cũng có thể đạt được đồng thuận từ mọi người và rồi cả nhóm sẽ tự nhiên cùng hướng về một phía. Điều đó có hiệu quả với những nhóm rất tốt ban đầu, nhưng sau này khi làm việc với các kỹ sư chỉ khăng khăng bám vào cách làm của đội khác từ 25 năm trước, tôi đã lãng phí quá nhiều thời gian chỉ để chờ đồng thuận. Cuối cùng tôi nhận ra rằng sau khi mọi người đã trình bày đầy đủ quan điểm của mình, sẽ có lúc người dẫn dắt phải chọn hướng đi và đưa ra quyết định
Theo kinh nghiệm của tôi, khi làm nhiều năm ở một công ty F50, tôi đã gặp tình huống tương tự. Trong một domain có 3 nhân sự chủ chốt, chỉ chúng tôi biết rằng phương án A nhìn qua thì có vẻ tốt nhưng thực tế có rất nhiều vấn đề; dù đã giải thích, chúng tôi vẫn không thuyết phục được cả đội, nên cuối cùng phải bỏ qua kết quả bỏ phiếu và trao đổi với cấp trên để đi đến quyết định đúng. Qua chuyện đó, tôi thấm thía rằng nếu đi theo ý kiến số đông (phương án A) thay vì hướng mà người trực tiếp phải gánh kết quả mong muốn (phương án C), thì dự án sẽ liên tục gặp vấn đề và chậm trễ. Điểm quan trọng là những người trực tiếp chịu trách nhiệm và gánh hậu quả nên có “quyền phủ quyết” thay vì để mọi thứ thành một cuộc thi phổ biến; với các dự án lớn, mỗi lead nên quyết định trong domain của mình, còn cấp trên chỉ nên đưa ra quyết định rõ ràng khi bế tắc. Khi người lãnh đạo né tránh quyết đoán, kết quả là ai cũng chỉ biết than phiền, và đó là một trải nghiệm cực kỳ khó chịu làm tinh thần đội ngũ sa sút nghiêm trọng
Tôi cũng nhớ tới giai thoại Steve Jobs nhốt cả đội trong một căn phòng và bắt họ thảo luận cho đến khi tìm ra tầm nhìn chung. Việc kéo mọi người về cùng một hướng là rất khó, nhưng nếu thất bại thì năng lực thực thi sẽ giảm đi đáng kể. Đồng thời, nếu phớt lờ ý kiến của thành viên, họ sẽ cảm thấy mình bị coi thường, nên dù kết quả có quan trọng đến đâu thì đó cũng không phải cách bền vững lâu dài
Tôi thấy rất ấn tượng với điểm rằng “lắng nghe tiếng nói của mọi người” và “trao quyền phủ quyết cho tất cả mọi người” là hai chuyện hoàn toàn khác nhau. Với tư cách người lãnh đạo, cắt đứt thế bế tắc là một vai trò thiết yếu. Tất nhiên, nếu trong mọi vấn đề đều phải để lãnh đạo tự quyết thì đó là dấu hiệu của vấn đề quản lý, động lực làm việc, hoặc việc cả nhóm chưa hiểu chiến lược
Cách tôi thích là nói: “Nếu chính bạn là người trực tiếp phụ trách thì hãy cho tôi biết quyết định của bạn là gì.” Nhiệm vụ của người lead không phải lúc nào cũng là tự mình ra quyết định, mà là bảo đảm rằng sẽ có quyết định được đưa ra
Tôi nghĩ mình có chút chuyên môn trong lĩnh vực này. Trước đây tôi từng được chỉ định dẫn dắt một dự án đã thất bại tới ba lần trước đó, làm việc cùng 6 kỹ sư giỏi nhất từ các nhóm khác nhau. Ai cũng có quan điểm mạnh và lý do chắc chắn, nhưng giống như câu “đừng cản kẻ địch khi hắn đang mắc sai lầm”, tôi cố giữ thái độ “đừng cản bạn mình khi họ đang làm điều gì đó tuyệt vời”. Tinh thần là “nếu đó không phải phần bạn phụ trách thì hãy tạo ra thứ khác mà bạn có thể làm tốt”. Chúng tôi phân vai một cách tự nhiên, tác động qua lại với nhau khá mềm mại, và chấp nhận rằng những phần ít quan trọng hơn không nhất thiết phải hoàn hảo. Kết quả là dự án thành công, và tôi rất tự hào vì đã tạo ra được một cấu trúc nơi nhiều người tài có thể học hỏi lẫn nhau và chỉ tập trung tranh luận ở những chỗ thực sự cần thảo luận
Tôi nghĩ trải nghiệm của bạn khá giống với phong cách lãnh đạo gọi là Servant Leadership(liên kết wiki liên quan). Đó cũng là kiểu lãnh đạo mà tôi thích
Tôi nghĩ để có thể để những kỹ sư xuất sắc chủ động triển khai ý tưởng của họ mà không can thiệp quá mức, người lãnh đạo cần có sự tin tưởng thật sự, tính tự chủ, và sự tự tin
Mỗi khi đội sản phẩm yêu cầu một tính năng “đơn giản”, trong đầu tôi lại hiện ra việc sẽ cần ít nhất 3 đội và phải cập nhật từng microservice của họ. Những lúc như vậy, tôi thật sự ghét web hiện đại
Tôi nghĩ vấn đề ở đây không hẳn là web hiện đại, mà là một kiến trúc nơi chỉ một tính năng “đơn giản” thôi cũng bị chia phụ thuộc ra 3 microservice khác nhau. Xét cho cùng, nguyên nhân lớn hơn là thất bại trong thiết kế hệ thống
Vậy thì sẽ có những phương án thay thế nào?
Theo kinh nghiệm của tôi, nên tránh câu kiểu “tôi là lead” vì nó có thể khiến người khác thấy bạn thiếu tự tin; thay vào đó, khi đã thu thập đủ thông tin và đưa ra quyết định, bạn cần có thể tự tin nói “được rồi, giờ chúng ta sẽ làm theo cách này” hoặc “tôi muốn mọi người làm như thế này”
Cốt lõi của vấn đề không phải là hiểu lầm, mà là thiếu niềm tin lẫn nhau. Nếu một đội nói rằng một việc nào đó mất 2 tuần, đội khác sẽ không tin và nghĩ rằng việc đó chỉ đáng một ngày. Nếu thực sự tin nhau, người ta có thể chấp nhận rằng đội kia có chuyên môn hơn trong lĩnh vực đó; nhưng ngoài đời, người ta lại nghi rằng việc ước lượng thời gian không phải phản ánh khối lượng công việc thật sự mà chỉ là cách để tạo dư địa an toàn. Trong những lúc như vậy, việc chia sẻ đầy đủ giải thích và căn cứ sẽ giúp tăng niềm tin
Tôi mới được thăng chức lên lead developer khoảng 1 năm gần đây. Tôi từng khá bối rối về việc vai trò và trách nhiệm của mình là gì, nhưng thấy mình cũng đã làm việc với suy nghĩ gần giống những điều trong bài gốc nên cảm thấy yên tâm hơn. Vài ngày trước tôi cũng đọc một bài viết về “cách đọc tutorial từ góc nhìn của người không phải lập trình viên” và thấy rất đồng cảm, nên có cảm giác mình đang đi đúng hướng
Tôi cũng đã trải qua 3 trường hợp lead ở các đội phát triển sản phẩm liền kề phần mềm dẫn dắt theo kiểu áp đặt, và lần nào kết quả cũng không tốt. Sau vài lần tự mình làm team lead, tôi nhận ra mình không nên là một “chỉ huy”, mà phải là một “đầu mối và người điều phối”. Khi các thành viên xung đột, tôi giúp tháo gỡ mâu thuẫn; khi có câu hỏi, tôi giúp giảm bớt lo lắng; khi có ý tưởng, tôi đánh giá tính khả thi và giá trị; khi cần tài nguyên, tôi giúp họ tìm đến đúng người cần gặp. Khi có vấn đề, tôi nhận trách nhiệm và khuyến khích cả nhóm cùng giải quyết. Tôi mất hơn 10 năm để học được tất cả những điều đó. Tôi không phải người giỏi nhất, tên tuổi tôi cũng hầu như không được nhiều người biết đến, nhưng khi làm việc như một “thành viên” của đội thì kết quả tốt hơn và tình trạng mất người cũng giảm đi. Và với tư cách lãnh đạo, tôi thấy việc nói “tôi cũng chưa chắc, nhưng chúng ta hãy cùng nhau tìm câu trả lời” là cực kỳ quan trọng. Nó cho phép các chuyên gia được quyền không chắc chắn, giúp họ không rơi vào thế phòng thủ, và khiến họ thấy mình không đơn độc. Với những ai từng cảm thấy bị tách biệt hoặc như một bộ phận có thể thay thế từ các lãnh đạo trước đây, tôi hy vọng họ tìm được sự an ủi; và nếu người lãnh đạo muốn dẫn dắt đội ngũ tốt trong thời gian dài thì nhất định không được xem con người như máy móc, mà phải thực sự có tinh thần quan tâm lẫn nhau
Tôi rất ấn tượng việc chính tác giả đã tự thu âm phần audio cho bài viết
Người viết nói mình thích câu “It's because that's why”, và giới thiệu rằng nếu ai quan tâm tới lĩnh vực này thì sách của Vanessa Van Edwards đã giúp ích rất nhiều trong việc học cách phát đi những tín hiệu về sự ấm áp và tính chuyên nghiệp phù hợp với từng tình huống. Không có một người nào có thể đưa ra hết mọi câu trả lời, nhưng bản thân họ đã có nhiều trải nghiệm tích cực
Về việc ra quyết định, tôi cảm thấy điều đó vừa không hơn cũng không kém chuyện “bảo đảm rằng quyết định nhất định sẽ được đưa ra”. Thứ nhất, nếu có thể thì nên để người khác tự ra quyết định. Có một giai thoại thời Apple rằng Jean-Louis Gassee thường đưa ra một quyết định mà cả hai quản lý đang tranh chấp đều sẽ ghét, và chính vì thế họ lại tự quay về tìm một phương án thay thế mà cả hai có thể đồng thuận. Thứ hai, cần khiến tất cả các bên thực sự đồng lòng với quyết định, và bản thân mình cũng phải làm như vậy trước. Người viết nói điều này cực kỳ khó với những quản lý kiểu thuận theo chiều gió. Họ ví von rằng sinh viên luật luôn suy nghĩ cẩn trọng và thiên về phân tích, nhưng luật sư thì phải lập luận dứt khoát và có thái độ thuyết phục được mọi người. Vì đồng thuận lý tưởng không phải lúc nào cũng đạt được, họ cũng chia sẻ mẹo là hãy đặt ra một điểm tựa cụ thể như khách hàng hoặc mục tiêu kết quả để thúc đẩy quyết định và kéo việc thực thi đi tiếp