Các anti-pattern dành cho lãnh đạo kỹ thuật

• Khi gặp các CTO hoặc lãnh đạo kỹ thuật, chủ đề được nhắc đến thường xuyên nhất là áp lực từ CEO về việc “hãy tăng tốc độ engineering”
• Khác với bán hàng hay tuyển dụng, engineering không có các chỉ số thành quả rõ ràng
• Từ góc nhìn của lãnh đạo kỹ thuật, thật khó để nói với CEO rằng “engineering là nghệ thuật nên rất khó dự đoán kết quả”
• Nguyên nhân của bất đồng giữa lãnh đạo kỹ thuật và ban điều hành
  • Lãnh đạo kỹ thuật có xu hướng làm theo các lời khuyên lãnh đạo mang tính thông lệ một cách quá cứng nhắc
  • Khi khái quát hóa rằng một thông lệ nào đó luôn hữu ích hoặc không hữu ích, sẽ rất khó áp dụng phù hợp với bối cảnh của tổ chức
  • Cốt lõi của lãnh đạo kỹ thuật hiệu quả là biết phán đoán khi nào nên theo thông lệ và khi nào nên thử cách tiếp cận mới tùy tình huống
• Bài viết tổng hợp những chia sẻ của Will Larson, CTO của Carta, trên podcast

3 anti-pattern trong lãnh đạo kỹ thuật

1. Né tránh micromanagement
2. Né đo lường các chỉ số chưa hoàn hảo
3. Lãnh đạo làm “chiếc ô” cho đội ngũ

[Anti-pattern #1: Né tránh micromanagement]

Ba vai trò mâu thuẫn mà một lãnh đạo kỹ thuật xuất sắc phải đảm nhiệm

• Lãnh đạo kỹ thuật cấp điều hành phải thực hiện ba vai trò trái ngược nhau, và những người giỏi nhất có thể linh hoạt chuyển đổi giữa các vai trò đó
  • Vai trò là một thành viên ban điều hành: tìm cách thúc đẩy doanh nghiệp phát triển
    • Đôi khi có thể phải đưa ra các quyết định “có hại cho toàn bộ engineering”, chẳng hạn như cắt giảm ngân sách engineering
    • Cũng có thể bao gồm việc chuyển sang mô hình business unit, nơi tiếng nói của engineering trong một số chủ đề cụ thể giảm đi
  • Vai trò là quản lý engineering
    • Nắm bắt cấu trúc chính sách cần thiết để vận hành tổ chức engineering và tìm cách trở thành người dẫn dắt nhân sự hiệu quả
  • Vai trò là kỹ sư
    • Chịu trách nhiệm về sự xuất sắc kỹ thuật và năng lực thực thi engineering bất chấp các áp lực từ bên ngoài
    • Phải duy trì tiêu chuẩn cao về chất lượng kỹ thuật
• Nhiều lãnh đạo cấp cao có xu hướng lệch quá nhiều về một trong ba vai trò này
• Dù đang ở vai trò nào, lãnh đạo cũng dễ mắc sai lầm khi bám chặt vào các thực hành quản lý đã không còn hữu ích
• Khi đột nhiên trở thành quản lý của một đội, bạn là người có nhiều ngữ cảnh nhất về mọi việc đội đang làm về mặt kỹ thuật, nhưng đồng thời cũng trở thành quản lý con người
• Từ thời điểm đó, người ta liên tục được khuyên phải lùi khỏi các chi tiết
• Các engineering manager mới thường được nghe lời khuyên “hãy rời khỏi code”
• Tác giả thừa nhận lời khuyên này có thể hữu ích với một số người
• Nhưng những lãnh đạo rất giỏi vẫn có mức độ hiểu biết chi tiết nhất định về domain mà họ đang vận hành
• Nếu đi quá xa khỏi chi tiết, bạn chỉ trở thành một quan chức bàn giấy, và đó là lý do vì sao quá nhiều engineering manager cuối cùng lại rơi vào tình trạng này

Nuôi dưỡng phong cách lãnh đạo

• Larson khuyên các lãnh đạo kỹ thuật hãy quên hẳn thuật ngữ micromanagement đi, và thay vào đó tập trung xây dựng nhiều phong cách lãnh đạo có thể lựa chọn
• Khi chưa có con đường rõ ràng phía trước, hoặc khi những người có ngữ cảnh về hướng đi lại bất đồng gay gắt, việc đi sâu vào chi tiết và tự đưa ra quyết định sẽ rất hữu ích
• Điều này giúp hiểu được các đòn bẩy có thể thực sự thay đổi doanh nghiệp, kết quả đội ngũ cần đạt được, khung thời gian để làm điều đó và cách phục vụ người dùng tốt hơn
• Việc phát triển sự tự tin mạnh mẽ hơn trong ra quyết định là điều phải rèn luyện suốt đời, và chính Larson cũng vẫn đang tiếp tục nỗ lực
• Đặt các câu hỏi như “Chúng ta đang làm gì? Tại sao làm như vậy? Dữ liệu là gì? Nguồn dữ liệu thực sự ở đâu?” theo chu kỳ hàng tháng hoặc hàng quý sẽ giúp đào sâu hơn vào chi tiết

Hai chiến thuật để tiến gần hơn đến chi tiết

1. Nắm bắt ngữ cảnh thông qua “khai thác xung đột”

   • Trong môi trường mới, chỉ cần bỏ lỡ một khác biệt nhỏ về ngữ cảnh cũng có thể làm tổn hại đến thành công trong vận hành
   • Dù tốn nhiều thời gian để trò chuyện với những người có góc nhìn đối lập, quá trình tìm ra “mầm mống xung đột” vẫn rất quan trọng
   • Lãnh đạo thành công sẽ hỏi “Tôi cần thay đổi thế nào để phù hợp với tổ chức?”, chứ không hỏi “Tôi phải thay đổi tổ chức thế nào để phù hợp với cách của mình?”

2. Ghi chép tài liệu về chi tiết

   • Strategy ở khắp mọi nơi nhưng hiếm khi được tài liệu hóa
   • Cơ sở của các quyết định quan trọng thường không được ghi chép lại
   • Xây dựng văn hóa documentation là chìa khóa cho một tổ chức engineering vận hành nhanh
   • Lãnh đạo mới nên khảo sát mọi thứ đang tồn tại và lấy các trường hợp thành công của công ty khác làm benchmark trước khi tự xây dựng strategy
   • Khi viết tài liệu strategy, tác giả khuyến nghị dùng framework “Good Strategy, Bad Strategy” của Richard Rumelt
   • Dù strategy được viết tệ đến đâu, chỉ riêng việc tài liệu hóa nó thôi cũng có thể giúp strategy cải thiện chỉ sau một đêm

[Anti-pattern #2: Né đo lường các chỉ số chưa hoàn hảo]

• Trong việc đo lường có rất nhiều anti-pattern
• Lý tưởng thì có thể đơn giản nói rằng “chúng ta không nên đo cái đó”, nhưng làm vậy chỉ khiến việc học hỏi của tổ chức xung quanh chậm lại
• Một trong những việc có giá trị nhất mà lãnh đạo kỹ thuật cấp điều hành có thể làm là giúp các lãnh đạo khác hiểu engineering vận hành như thế nào

Tập trung cải thiện mental model

• Ta muốn các chỉ số phản ánh thực tế, nhưng chỉ số không chỉ để cho thấy sự thật mà còn để giáo dục con người
• Bạn nên lo việc khai sáng mental model của CEO hoặc hội đồng quản trị hơn là khó chịu vì mental model của họ “xúc phạm” cách bạn nhìn nhận vấn đề

Kéo CEO vào chi tiết

• Thay vì nói “đây là cách đo lường rất tệ”, nên nói “hãy bắt đầu từ đây và cùng đào sâu cho đến khi hiểu được giới hạn của cách đo này”
• Ép người khác rời xa chi tiết chưa bao giờ là cách hay. Hãy kéo họ vào chi tiết và giáo dục họ từ đó

[Anti-pattern #3: Trở thành chiếc ô cho đội ngũ]

• Trước đây, tác giả từng tin vào việc manager hành xử như một “chiếc ô” để bảo vệ đội ngũ
• Nhưng việc che chắn đội khỏi thực tế về lâu dài sẽ gây hại cho chính đội ngũ
• Cần để cả manager lẫn kỹ sư đều có thể tham gia vào các cuộc trao đổi quan trọng

Cần góc nhìn mới cho các quyết định chiến lược

1. Strategy Bottom-Up
   • Ưu điểm: giúp đội ngũ di chuyển nhanh và kiểm soát được công cụ của mình
   • Nhược điểm: không có khả năng đầu tư kỹ thuật tập trung và thường biết thông tin chậm hơn một chút
2. Strategy Top-Down
   • Nhược điểm: để CTO hoặc nhóm kiến trúc đưa ra mọi quyết định là không hiệu quả
   • Ủy ban hiếm khi đưa ra được quyết định tốt nhất

Tăng tốc ra quyết định bằng “navigator”

• Tăng tốc độ ra quyết định bằng cách đặt các “navigator” đóng vai trò “mini CTO” theo từng business unit
• Giúp những người có nhiều ngữ cảnh nhất tại hiện trường có thể đưa ra quyết định phù hợp nhất về tech stack
• Bài học để thành công:
  1. Đừng bỏ qua documentation
  2. Hãy làm postmortem
  3. Hãy cực kỳ cẩn trọng trong việc chọn người để trao niềm tin
• Tổ chức là sự tích lũy năng lực phán đoán của một số ít cá nhân, và không thể thoát khỏi thực tế đó

Kết luận

• Sự nguy hiểm của việc tuân thủ quy tắc quá cứng nhắc
  • Khi đội ngũ engineering bắt đầu phát triển cùng công ty, các lãnh đạo không được quên những điều từng đẩy nhiều lãnh đạo cấp cao đầy thiện chí vào thế khó trước đây
  • Mục tiêu cuối cùng là tạo ra cơ chế chất lượng cao để mọi người giữ được sự tò mò và tìm ra các ngoại lệ
• Learning Circle
  • Trong 3 năm rưỡi qua, Larson đã tổ chức “Learning Circle” hai tuần một lần
    • 6 đến 10 CTO, VP of Engineering hoặc các lãnh đạo kỹ thuật cấp cao khác trong các công ty công nghệ cùng gặp nhau để cập nhật tình hình, trao đổi về chiến thuật và các vấn đề quy trình
    • Mỗi buổi họp bắt đầu bằng việc lần lượt mỗi người nói trong 1 phút về điều họ đang tập trung trong tuần này và chủ đề họ muốn thảo luận
    • Sau khi nói về các chủ đề trong khoảng 5 phút, cả nhóm chọn một chủ đề rồi đào sâu vào đó trong khoảng 20 phút tiếp theo
    • Chủ đề rất đa dạng, từ “tôi đang gặp rắc rối vì dự án này” đến “chúng tôi vừa tuyển được một người thật sự xuất sắc và rất háo hức”
• Học thông qua thực hành
  • Những người học qua thực hành có thể dựa vào các hoạt động phản tư thường xuyên như learning circle hay tự suy ngẫm cá nhân để buộc bản thân có đủ khả năng tự soi xét cần thiết nhằm tinh chỉnh các quy tắc một cách tinh tế
  • Larson nói: “Tôi đã trở thành một lãnh đạo tốt hơn nhờ học từ bài học của những người khác đã mắc các sai lầm tương tự tôi”

[geniuskey]

Đoạn cuối kiểu “Larson nói rằng ‘tôi đã trở thành một nhà lãnh đạo tốt hơn...’” khiến tôi hơi ngại. Thà rằng viết theo kiểu “người lãnh đạo phải liên tục nỗ lực để... Tôi cũng vẫn còn thiếu sót và đang cố gắng để trở nên tốt hơn” thì có lẽ sẽ dễ đọc hơn. Có phải đây là một góc nhìn quá kiểu Hàn Quốc không? ^^;;

[savvykang]

Nhìn việc bạn hỏi liệu đây có phải là góc nhìn kiểu Hàn Quốc hay không thì có vẻ bạn hiểu khá rõ vấn đề rồi; theo tôi, người nói cũng không hề thể hiện sự tự luyến, nên phản ứng như thế này có phần khá khó hiểu.

[tofumaker]

Việc tập trung vào thái độ của người nói thay vì bản chất hay nội dung bài viết của bạn đúng là rất kiểu Hàn Quốc.

[savvykang]

"Mẫu phản tác dụng #1: tránh micro-management" nhưng lại bảo hãy quên micro-management đi, nên cách triển khai nội dung có vẻ kỳ lạ.

[frog08]

Xem micromanagement là điều xấu và cần phải tránh bằng mọi giá mới chính là một anti-pattern. Thay vì phán xét đó có phải là micromanagement hay không, ý ở đây là cần chú ý đến các chi tiết khi cần thiết.

[savvykang]

Ít nhất nếu viết là “Phản mẫu: coi micromanage là một lựa chọn” hoặc “cho rằng quan tâm đến chi tiết cũng giống như micromanaging” thì mạch văn đã tự nhiên hơn đôi chút. Tôi hiểu ý đồ của bài viết, nhưng rốt cuộc thông điệp mà bài muốn truyền tải có lẽ là hãy quản lý theo kiểu chú ý đến chi tiết thay vì quản lý kiểu “micro”.

[kandk]

Khi gặp các CTO hoặc lãnh đạo kỹ thuật, chủ đề trò chuyện xuất hiện thường xuyên nhất là áp lực từ CEO về việc "hãy tăng tốc độ kỹ thuật"
Không giống như bán hàng hay tuyển dụng, kỹ thuật không có các chỉ số hiệu suất rõ ràng
Từ góc nhìn của lãnh đạo kỹ thuật, thật khó để nói với CEO rằng "kỹ thuật là nghệ thuật nên rất khó dự đoán kết quả"

[xguru]

Hãy tham khảo cả ý kiến trên Hacker News về bài viết này.

• Có ý kiến cho rằng phương pháp của Will Larson, đã được áp dụng ở nhiều tổ chức, không thực sự hiệu quả. Cách tiếp cận của ông gây ra xung đột giữa kỹ sư và phía kinh doanh.
• Gợi ý sách của Ron Jeffries: khuyến nghị cuốn "The Nature of Software Development", nhấn mạnh giá trị tăng dần, sự dẫn dắt từ phía kỹ sư, phản hồi liên tục và tính linh hoạt.
• Điểm tích cực là Larson có khả năng tự nhìn lại và chấp nhận phê bình. Bài viết của ông không phải lúc nào cũng đúng hay sai hoàn toàn, nhưng cho thấy ông đào sâu vào việc giải quyết vấn đề.
• Do đặc tính của sản phẩm web, lỗi không mang tính chí mạng và các thay đổi thường xuyên thường được thực hiện vì lý do marketing. Vì vậy hình thành một văn hóa di chuyển nhanh và chấp nhận sai sót.
• Mặt tích cực của micromanagement: một lãnh đạo kỹ thuật giỏi hiểu rõ chi tiết và có khả năng giao tiếp với đội ngũ. Điều này khác với micromanagement.
• Có quá nhiều nhân sự kỹ thuật nên phát sinh vấn đề. Khi công cụ tốt hơn được phát triển, các nhóm nhỏ cũng sẽ có thể hoàn thành công việc một cách đầy đủ.
• Vấn đề không nằm ở việc đo lường, mà ở chỗ đưa ra phán đoán sai từ kết quả đo lường đó. Chỉ số nên được dùng như một công cụ để đặt câu hỏi.
• Trong phát triển phần mềm quy mô lớn, hợp tác là yếu tố cốt lõi. Sự tan rã của cộng đồng là nguyên nhân chính làm chậm tiến độ dự án.
• Nếu vai trò và kỳ vọng của mỗi người trong pipeline phát triển không rõ ràng thì sẽ phát sinh vấn đề. Nhà quản lý cần giải quyết tình huống này.
• Có ý kiến cho rằng đây là một bài viết hay, nhưng sẽ tốt hơn nếu rút ngắn độ dài khoảng 25%.