Làm chủ khía cạnh con người trong kỹ thuật: Bài học lãnh đạo từ Apple, Palantir và Slack

• Michael Lopp, lãnh đạo kỹ thuật tại Apple, nhấn mạnh rằng trong thời đại có thể tạo ra sản phẩm rất nhanh, vận hành lấy con người làm trung tâm và năng lực phán đoán lại càng quan trọng
  • “Ai là người đưa ra quyết định, và quyết định đó được thực thi như thế nào?” mới là bản chất thực sự của kỹ thuật
  • Hơn cả năng lực viết mã, tổ chức lấy con người làm trung tâm và năng lực lãnh đạo mới là yếu tố quyết định hiệu quả của tổ chức
• Dựa trên kinh nghiệm tích lũy trong nhiều môi trường như Borland, Netscape, Palantir và Slack, ông đưa ra những gợi ý cụ thể về cấu trúc tổ chức, văn hóa hợp tác và các năng lực cốt lõi của lãnh đạo
• Trọng tâm không phải là lãnh đạo công nghệ, mà là vận hành tổ chức, hợp tác giữa con người với con người và sự thấu hiểu con người
• Cuộc phỏng vấn này không chỉ là một cuộc thảo luận về công nghệ, mà tập trung vào thiết kế tổ chức kỹ thuật bền vững và hiệu quả, đồng thời đưa ra lời khuyên thực tế cho nhà sáng lập và lãnh đạo kỹ thuật về quan hệ với đội ngũ sản phẩm, năng lực lấy con người làm trung tâm và điều kiện để trở thành một nhà lãnh đạo giỏi

Nên thiết kế cấu trúc tổ chức kỹ sư như thế nào

• Ngay cả trong các ngành khác nhau, ông vẫn chỉ ra những yếu tố thành công chung là niềm tin vào kỹ thuật, tăng trưởng nhanh và thu hút được nhân tài thông minh
• Từ đó, ông đề xuất ba mẹo thực hành để thiết kế một tổ chức kỹ thuật thành công

Tip #1: Hãy khuyến khích “Wolf Time”

• Chia thời gian của kỹ sư thành 71% công việc thực chất / 29% thời gian sáng tạo tự do
• 29% này là “khoảng thời gian không thể đo lường và không cần giải thích”, là không gian để sự sáng tạo và tính chủ động phát triển
• Nỗ lực chính thức hóa tại Palantir đã thất bại → khuyến khích và giao tiếp một cách không chính thức hiệu quả hơn việc hình thức hóa
• Ví dụ: đề xuất thời gian chia sẻ ý tưởng không chính thức vào mỗi thứ Sáu
  > “Nếu các thành viên trong nhóm không nhận thức rằng khoảng thời gian này được cho phép, họ sẽ phải lén làm giữa các cuộc họp và sẽ chẳng có gì phát triển được.”

Tip #2: Tranh luận càng đều đặn càng tốt

• Sản phẩm xuất sắc được tạo ra từ sự hợp tác của ba lĩnh vực: kỹ thuật, thiết kế và sản phẩm
• Sự hợp tác này thường đi kèm xung đột, nhưng chính những tranh luận đó mới là chìa khóa nâng cao chất lượng sản phẩm
• Cần có tranh luận sôi nổi trong nhóm về việc “đây là vấn đề thiết kế, vấn đề sản phẩm hay vấn đề hiểu tính năng”
• Lãnh đạo cần khuyến khích việc thách thức ý kiến không chỉ từ dưới lên mà cả từ trên xuống
• Thường có những khoảnh khắc tranh luận giữa nhà sáng lập và nhân viên làm thay đổi hướng đi của công ty

Tip #3: Xây dựng hệ thống vận hành có thể mở rộng

• Phán đoán tốt + năng lực vận hành là nền tảng của sản phẩm có khả năng mở rộng
• Phán đoán không chỉ là kết quả đơn thuần, mà là khả năng giải thích “vì sao lại đưa ra quyết định đó”
• Ý nghĩa của trách nhiệm giải trình (Accountability) là có một “câu chuyện có thể báo cáo lại”
• Để năng lực phán đoán của một số ít người mở rộng ra toàn bộ hệ thống, cần có quy trình rõ ràng
• Chỉ nhìn vào quy trình tuyển dụng cũng có thể thấy chất lượng vận hành (tốc độ phản hồi, độ rõ ràng của lịch trình, v.v.)
• Đừng lấy lý do là startup để bỏ qua quy trình → xây dựng công ty cũng chính là xây dựng vận hành

Làm thế nào để củng cố mối quan hệ giữa kỹ thuật và đội ngũ sản phẩm

• Căng thẳng và hiểu lầm giữa đội sản phẩm và đội kỹ thuật là câu chuyện lâu năm, nhưng
  để tạo ra sản phẩm chất lượng cao có thể mở rộng, việc mài giũa mối quan hệ này là điều bắt buộc
  • PM tệ khiến kỹ sư chỉ làm theo sản phẩm mà không có tinh thần sở hữu,
  • PM giỏi giúp kỹ sư hiểu đầy đủ “vì sao chúng ta xây cái này”
• Lopp định nghĩa kỹ sư là người của “how”, còn PM là người của “why”
  • Đội sản phẩm cần truyền đạt câu chuyện của khách hàng, và ủy quyền cách xây dựng cho kỹ sư và nhà thiết kế
• Cốt lõi là chia sẻ “why”
  > Hãy trực tiếp hỏi kỹ sư chứ không phải PM rằng “Vì sao chúng ta làm tính năng này?”
  • Nếu câu trả lời là “Vì PM bảo vậy” thì thật đáng giận
  • Vấn đề thực sự thường không phải là phán đoán của đội sản phẩm sai, mà là kỹ sư không hiểu bối cảnh
    > “Kỹ sư là người tạo ra sản phẩm bằng đôi tay của mình. Một tổ chức nơi họ làm việc mà không hiểu ‘vì sao mình làm điều này’ thì sẽ thất bại.”
  • Khi được hỏi vì sao Slack không có tính năng chặn, Stewart đã giải thích rất rõ triết lý rằng “điều quan trọng là thông tin phải hiển thị cho mọi người”
    • Chia sẻ góc nhìn rằng đây là vấn đề của tầm nhìn chứ không phải của tính năng
• Một quản lý sản phẩm giỏi phải có khả năng đặt từng tính năng hoặc ý tưởng vào đúng ngữ cảnh trong tầm nhìn tổng thể của sản phẩm khi truyền đạt
  • Đó chính là một phần của ‘why’ mà mọi người cần tập trung vào

Một nhà lãnh đạo xuất sắc là người như thế nào?

• Lãnh đạo kỹ thuật thực sự không chỉ dừng ở năng lực kỹ thuật đơn thuần
• “Rốt cuộc, lãnh đạo là kỹ năng làm việc với con người”

• Đặc điểm lãnh đạo #1: Có tính linh hoạt (Malleability)

  • Lãnh đạo làm việc với những người có tính cách khác nhau, nên cần có khả năng điều chỉnh phong cách của bản thân cho phù hợp
  • Ông nhấn mạnh điều này bằng chính trải nghiệm dẫn dắt đội ngũ theo những cách hoàn toàn khác nhau tại Pinterest và Slack
  • Với quản lý mới, ông luôn đặt cùng một câu hỏi: “Sau khi nhận phản hồi, bạn đã thay đổi điều gì?”
  • Việc tổ chức đội ngũ cũng không dựa vào tiêu chí cố định, mà được tái cấu trúc dựa trên điểm mạnh và điểm yếu bộc lộ trong quá trình cùng làm việc thực tế
  • Vì vậy, ông tái tổ chức cứ mỗi 6 tháng một lần

• Đặc điểm lãnh đạo #2: Xuất sắc trong storytelling

  • Ông thể hiện sự phản đối mạnh với micromanagement: "Không có gì khó chịu bằng việc chỉ đạo kỹ sư phải làm gì."
  • Thay vào đó, lãnh đạo cần cung cấp “Box” và “Soup”
    • Box: không gian được lấp đầy bởi ý tưởng và bối cảnh
    • Soup: nền thông tin để các thành viên tự do tiếp nhận hoặc kết hợp
  • Thay vì ra lệnh, nếu cung cấp những câu chuyện truyền cảm hứng, các thành viên sẽ tự phán đoán và phát triển
  • Một số người có thể nói “Cứ bảo tôi phải làm gì là được”, nhưng ngay cả như vậy cuối cùng họ vẫn diễn giải theo cách của riêng mình
    > Vai trò của lãnh đạo là đưa ra bát súp. Uống hay cho thêm gì vào đó là lựa chọn của họ.

• Đặc điểm lãnh đạo #3: Hiểu động lực và mục tiêu của từng thành viên

  • Lãnh đạo cần biết từng thành viên trong nhóm trưởng thành và được tạo động lực bởi điều gì
  • Một ví dụ: với kỹ sư lấy thử thách kỹ thuật làm động lực sống, hãy trao cho họ những cơ hội giải quyết vấn đề liên tục
  • Một ví dụ khác: trợ lý tại Palantir đã bày tỏ rõ động lực lấy phần thưởng làm trung tâm → có thể quản lý rất rõ ràng
  • Cốt lõi là nắm được “một động lực cốt lõi duy nhất” của mỗi người và liên tục đầu tư vào đó
  • Để làm được điều này, sự tò mò (curiosity) và việc liên tục hỏi “Vì sao?” là điều thiết yếu
    > Lãnh đạo phải khám phá cả những động lực mà chính thành viên cũng chưa nhận ra và tạo ra cơ hội phát triển cho họ.

Kết luận: Bản chất của kỹ thuật thành công là thấu hiểu con người

• Một tổ chức kỹ thuật thành công phụ thuộc vào động lực con người (Human Dynamics) vận hành trơn tru
  • Sản phẩm xuất sắc không được tạo ra bởi những cá nhân xuất chúng riêng lẻ, mà bởi một tập thể những con người biết hợp tác tốt
  • Vai trò của lãnh đạo bắt đầu từ việc trao quyền cho những con người tạo nên tổ chức
• “Đội ngũ kỹ thuật là một tấm thảm dệt khổng lồ của những con người phức tạp nhưng tuyệt vời”
  • Nỗ lực để hiểu cấu trúc và dòng chảy của tấm thảm đó chính là chìa khóa giúp giá trị của sản phẩm được truyền tải hiệu quả trên quy mô toàn tổ chức
    > "Khi bạn có động lực để hiểu cách con người tương tác với nhau, công ty của bạn sẽ sẵn sàng truyền tải giá trị của sản phẩm ở quy mô lớn."

[xguru]

Có một Slack dành cho các lãnh đạo kỹ thuật do Michael Lopp vận hành.
RLS - Rands Leadership Slack
Nếu bạn quan tâm thì hãy thử tham gia. Hiện đây là một Slack khổng lồ với hơn 36.000 thành viên.
Để đăng ký, hãy đọc kỹ nội dung ở liên kết trên và gửi email cho Lopp.
Tên/nghề nghiệp/lý do bạn muốn tham gia/bạn đã biết đến RLS từ đâu/tài khoản LinkedIn hoặc Twitter của bạn

[techiemann]

Nếu đã tuyển một kỹ sư đắt giá về thì đừng coi kỹ sư như LLM chỉ vì cầm bút, rồi sai vặt từ những thứ nhỏ nhặt như thể đang ra lệnh cho Doraemon lắp đồ trong chớp mắt; chỉ cần chia sẻ tầm nhìn của mình, còn cách tiếp cận kỹ thuật để hiện thực hóa nó chính là lĩnh vực chuyên môn của người đó, nên hãy để họ tự làm.

Nghe kỹ thì không hiểu sao trong đầu tôi lại hiện lên cảnh những người ở nước mình muốn xây nhà vườn ở quê hoặc cải tạo căn hộ cũ rồi cãi qua cãi lại với nhà thầu, đơn vị thi công hay kiến trúc sư.

[nemorize]

Có phải trường hợp sau này có bối cảnh hơi khác một chút không?

Cải tạo nhà ở vùng ven hoặc chung cư cũ trước hết là lĩnh vực gần với việc hiện thực hóa mơ ước hơn là kinh doanh,
hơn nữa cũng lạ là có rất nhiều chuyện giao phó cho công ty xây dựng/cải tạo với niềm tin rồi lại bị họ chơi sau lưng...

[groge]

Nếu chủ đầu tư không tự làm mà giao cho người khác thì có lẽ cũng sẽ rơi vào tình huống y hệt.
Dù giải thích kỹ đến đâu vẫn có chỗ bị hiểu sai, và dù chuẩn bị cẩn thận đến mấy thì vẫn luôn có những phần nằm ngoài dự liệu.
Nếu cứ phải hỏi từng chút một về những phần chủ đầu tư chưa nói ra rồi mới làm thì sẽ rất mất thời gian và gây bức bối, nên có khá nhiều phần chuyên gia sẽ tự xử lý, mà có vẻ chính những phần đó lại trở thành nguồn cơn của mọi cuộc đôi co.
Mà thôi, tôi cũng thấy ghen tị vì có vẻ bạn chưa bị các công ty SI đâm sau lưng quá nhiều.

[nicewook]

Tôi cũng nhớ đến cuốn Modern Software Engineering mà tôi đọc gần đây. Cuốn sách đó cũng nói về đội ngũ và tổ chức, chứ không chỉ riêng việc phát triển.

[haejuk99]

Dù có nhiều quan điểm và phương pháp khác nhau về lãnh đạo kỹ thuật, có lẽ điểm cốt lõi đều giống nhau ở chỗ dựa trên sự thấu hiểu đối với các thành viên trong nhóm. Nghe thì có vẻ dễ khi nói rằng phải hiểu các thành viên, nhưng dường như đó là phần đòi hỏi phải xây dựng niềm tin dựa trên sự đồng cảm giữa người lãnh đạo và thành viên thông qua phản hồi qua lại. Có lẽ đây không phải là điều có thể tạo ra chỉ trong một lần. Cảm ơn vì nội dung rất hay và đáng để suy ngẫm.