Staff Engineer vs Engineering Manager

• Khi nào cần Staff Engineer, và họ khác gì với Engineering Manager?
  • Nhiều kỹ sư và quản lý vẫn đang nhầm lẫn giữa hai vai trò này
• Những EM muốn tránh quản lý con người để tập trung vào kỹ thuật, hay các Senior Engineer muốn đảm nhận vai trò lãnh đạo kỹ thuật, thường trăn trở về điều này
• Điều quan trọng là phải hiểu rõ trách nhiệm và phạm vi của từng vai trò

Những câu hỏi tôi từng nhận được

• EM: "Tôi muốn tập trung vào kỹ thuật thay vì quản lý con người. Staff Engineer có phù hợp với tôi không?"
• Senior EM: "Công việc quản lý quá nhiều. Tôi có nên tuyển một Staff Engineer để giao phần việc kỹ thuật không?"
• Staff Engineer: "Thực tế tôi đang làm vai trò gần như team manager, và tôi thấy thích điều đó. Tôi có nên chuyển sang EM không?"
• Senior Engineer: "Trách nhiệm của Staff Engineer là gì? Trông nó giống như một lập trình viên đã nghỉ hưu vậy."
• New Staff Engineer: "‘Dotted reporting lines’ là gì? Tôi đã có line manager rồi, vậy còn phải để ý đến manager khác nữa sao?"

Khi nào cần Staff Engineer?

• Các kỹ sư xây dựng và duy trì công nghệ, nhưng công nghệ không tồn tại một mình
• Nó là lời giải cho một vấn đề, và vấn đề đó được xác định bởi sản phẩm
• Sản phẩm cung cấp dịch vụ cho người dùng cuối hoặc khách hàng nội bộ
• Sản phẩm là phương tiện để giải quyết vấn đề của người dùng, ví dụ:
  • ứng dụng đo quãng đường chạy và chia sẻ với người dùng khác
  • website đặt phòng khách sạn
  • nền tảng hạ tầng được các đội khác sử dụng
  • hệ thống báo cáo chấm công
• Các kỹ sư phát triển những sản phẩm này thường thuộc về các team do Engineering Manager (EM) dẫn dắt
• EM chịu accountability đối với các thành viên trong team (kỹ sư) và các artifacts kỹ thuật mà họ tạo ra
• Nhưng trong các trường hợp sau, EM sẽ khó hoàn thành trọn vẹn mọi trách nhiệm:
  • quy mô team quá lớn
  • công nghệ quá phức tạp
  • hoặc đồng thời có cả hai yếu tố trên
• Khi đó, thời gian và năng lượng (bandwidth) của EM trở nên thiếu hụt, khiến họ khó thực hiện hoàn hảo trách nhiệm với cả con người lẫn công nghệ
• Nếu EM khó gánh hết trách nhiệm, có thể cân nhắc hai chiến lược ủy quyền:
  • Ủy quyền công việc hành chính:
    • tối ưu hóa quy trình và công cụ HR, hoặc
    • thuê trợ lý để giảm gánh nặng quản lý con người
    • Có thể thấy hơi quá nếu một team có hẳn trợ lý riêng, nhưng cũng có trường hợp nhiều team dùng chung một trợ lý
    • Có thể tận dụng công cụ AI để thay thế một phần các việc lặp lại như điều phối lịch, trả lời câu hỏi quản lý, thu thập phản hồi
    • Một hệ thống HR tốt có thể giảm mạnh gánh nặng quản lý
  • Ủy quyền công việc kỹ thuật:
    • có thể tuyển Staff Engineer để chia sẻ gánh nặng kỹ thuật
• Tuy nhiên, trợ lý hay AI không thể thay thế những công việc lấy con người làm trung tâm vốn là trách nhiệm cốt lõi của EM, như:
  • xây dựng một team tốt
  • mentoring
  • đánh giá hiệu suất
  • tuyển dụng
• Mặt khác, giao toàn bộ công việc kỹ thuật cho Staff Engineer được xem là một anti-pattern
  • Staff Engineer không nên trở thành phiên dịch kỹ thuật cho EM
  • EM vẫn phải duy trì trách nhiệm kỹ thuật ở một mức nhất định
• Vì vậy, Engineering Manager nhất thiết phải giữ được cảm quan kỹ thuật, và
  • về cách các lãnh đạo kỹ thuật duy trì năng lực kỹ thuật, xem How can engineer leaders stay technical?

Những tình huống Staff Engineer hữu ích

• Staff Engineer có thể mang lại giá trị thực chất cho tổ chức trong các trường hợp như sau:
  • khi tồn tại gánh nặng kỹ thuật mà EM khó đảm đương
    • ví dụ: có nhiều công nghệ legacy và cần bảo trì liên tục
    • có các giải pháp phức tạp băng qua nhiều team hoặc đòi hỏi kiến thức kỹ thuật sâu
    • cũng có trường hợp (dù không được khuyến khích) bản thân EM không đủ tính kỹ thuật
  • khi có thể giao accountability rõ ràng cho một phần công việc kỹ thuật
  • khi phạm vi kỹ thuật vượt quá giới hạn mà một EM có thể quản lý
• Staff Engineer phải chịu trách nhiệm với công nghệ, không phải với con người
  • không bao gồm việc quản lý thành viên team hay đánh giá hiệu suất
• Tình huống sẽ khác nhau tùy tổ chức, sản phẩm và con người, nên không thể áp dụng phổ quát cho mọi nơi
• Tham khảo: responsibility và accountability là hai khái niệm hơi khác nhau,
  • xem chi tiết tại Accountable vs Responsible
• Staff Engineer nên có các đặc điểm sau:
  • có hiểu biết sâu về kỹ thuật và trình độ hiểu biết kỹ thuật cao
  • có accountability kỹ thuật rõ ràng
  • vì không có trách nhiệm quản lý con người nên có nhiều thời gian đầu tư cho kỹ thuật hơn
• Ngược lại, EM cũng không được rút hoàn toàn khỏi trách nhiệm kỹ thuật
  • họ vẫn cần tham gia và hiểu kỹ thuật ở một mức nhất định
• Giá trị thực sự của Staff Engineer đến từ lãnh đạo kỹ thuật xuyên nhiều team
• Nếu đặt Staff Engineer chỉ trong một team, có thể phát sinh các vấn đề như:
  • chồng chéo trách nhiệm kỹ thuật
  • vai trò bị nhập nhằng, và cuối cùng dẫn đến sự kém hiệu quả khi chia một vai trò thành nhiều title khác nhau
    • xem thêm tại Breaking a role to multiple titles

Trường hợp ngoại lệ có thể hoạt động ở cấp team

• Thông thường Staff Engineer tập trung vào lãnh đạo kỹ thuật liên team, nhưng trong các tình huống sau họ cũng có thể tạm thời hoạt động ở cấp team:
  • khi EM mới cần nhanh chóng nắm bắt một tech stack legacy
  • khi Staff Engineer mới onboard từ phạm vi nhỏ trước
  • khi nợ kỹ thuật quá nhiều khiến các chỉ số sức khỏe hệ thống xấu đi
  • khi độ phức tạp kỹ thuật khiến việc bảo trì trở nên khó khăn
• Trong những trường hợp này, Staff Engineer ở cấp team chỉ nên là một cấu hình tạm thời

• Giá trị thực sự của Staff Engineer

  • đóng vai trò chất kết dính (glue) giữa các team
  • làm việc cùng các kỹ sư ngay tại thực địa, đồng thời truyền đạt tiếng nói của họ lên ban lãnh đạo
    • thông thường kỹ sư sẽ trò chuyện thẳng thắn hơn với đồng nghiệp kỹ sư so với người nắm quyền về lương, nghỉ phép hay đánh giá
  • thực hiện lãnh đạo có chiều sâu về kỹ thuật
    • khác với EM, do có ít cuộc họp, 1:1 và việc quản lý hơn nên họ có thể tập trung phát triển năng lực engineering và chiều sâu kỹ thuật

• Rủi ro lớn nhất: Ivory Tower Architect

  • trở thành một nhà lý thuyết trừu tượng xa rời vấn đề thực tế và code
  • vấn đề này được bàn chi tiết trong Ivory Tower Architect

Vai trò của Staff Engineer đối với các hệ thống trải rộng qua nhiều team

• Staff Engineer phù hợp nhất với vai trò lãnh đạo kỹ thuật bao quát toàn bộ hệ thống thay vì chỉ một team
• Trong bài luận của Will Larson, có 4 archetype của Staff Engineer:
  • Tech Lead: lãnh đạo kỹ thuật trong team
  • Architect: người thiết kế kiến trúc hệ thống
  • Solver: người giải quyết các bài toán kỹ thuật phức tạp
  • Right Hand: cánh tay phải hỗ trợ lãnh đạo của tổ chức kỹ thuật
• Sẽ hơi gượng nếu gọi Tech Lead trong team xuất hiện trên sơ đồ là Staff Engineer
  • giá trị của một Staff Engineer đúng nghĩa đến từ điều phối liên team và tích hợp kỹ thuật
  • xem Introduction to Staff Engineering
    • Staff Engineer không chỉ là một chức danh, mà là một tư thế lãnh đạo kỹ thuật
    • vai trò này phụ trách điều phối kỹ thuật và giải quyết vấn đề trên phạm vi nhiều team và nhiều sản phẩm
    • họ tạo ảnh hưởng ngay cả khi không có quyền lực chính thức với con người hay sản phẩm, và dẫn dắt chiến lược cùng định hướng kỹ thuật của toàn tổ chức
    • khác với engineering manager, họ tạo giá trị thông qua chuyên môn kỹ thuật sâu và hợp tác xuyên tổ chức hơn là quản lý
    • họ xắn tay tham gia thực tế, đồng thời làm mentor hỗ trợ sự phát triển của các kỹ sư khác
• Trong các tổ chức thực tế, hệ thống kỹ thuật không bị giới hạn trong một team mà thường phân tán qua nhiều team hoặc gắn kết chặt chẽ với nhau
  • trong những trường hợp như vậy, cần có Staff Engineer chuyên trách chịu trách nhiệm cho toàn bộ hệ thống
  • bất kể mỗi team đang phụ trách phần nào, vẫn cần góc nhìn toàn hệ thống và tinh thần trách nhiệm

Staff Engineer không chỉ đi qua kỹ thuật mà còn phải đi qua con người và sản phẩm

• Điểm cốt lõi: công nghệ (tech) không tự nói hay tự lắng nghe phía còn lại
  • công nghệ không thể tồn tại một mình; nó chỉ có ý nghĩa thông qua con người (kỹ sư) và sản phẩm (vấn đề)
• Để Staff Engineer tạo ra giá trị thực sự, họ bắt buộc phải đi qua những kênh sau:
  • hợp tác với các kỹ sư
  • trao đổi với team sản phẩm
• Vì vậy Staff Engineer có cấu trúc báo cáo dạng dotted line
  • đây là mối nối không chính thức nhưng quan trọng cho hợp tác liên tổ chức và các cam kết
• Một số người tinh ý đôi khi hỏi tại sao trong sơ đồ, mũi tên từ Staff lại hướng xuống các vị trí thấp hơn
  • Lý do 1: lãnh đạo tốt dựa trên hợp tác chứ không phải quyền uy
    • Staff Engineer truyền đạt các đề xuất cải thiện kỹ thuật tới EM hoặc PM ở cấp team theo cách hợp tác
    • đó không phải mệnh lệnh áp đặt, mà là cách phối hợp có tính đến kỹ sư và roadmap sản phẩm
  • Lý do 2: Staff Engineer là IC (Individual Contributor) nên không có cấp dưới trực tiếp chính thức
    • nếu có kênh trao đổi định kỳ với EM/PM, thì mục tiêu không chỉ là báo cáo, mà là:
      • hiện trạng của công nghệ (status quo)
      • tầm nhìn kỹ thuật (vision) để giải quyết vấn đề sản phẩm
      • chiến lược kỹ thuật của tổ chức (strategy) để thực hiện điều đó
      • lý tưởng nhất là có đối thoại hai chiều về cả ba điểm này
• Để sắp xếp cấu trúc báo cáo chồng chéo này và giúp căn chỉnh kỹ thuật/sản phẩm giữa các team,
  • strategy document ở cấp toàn công ty rất hữu ích
  • có thể xem nền tảng tại Strategy basics

    • Chẩn đoán (Diagnosis)

      • sau khi khảo sát không gian vấn đề, xác định vấn đề cốt lõi cần giải quyết và lý do của nó
      • giải thích vì sao chiến lược là cần thiết
      • nhận diện triệu chứng và nguyên nhân gốc rễ, rồi phân tích vì sao chúng quan trọng ngay lúc này
      • trong chiến lược tệ, phần này thường bị bỏ qua hoặc chỉ mô tả hiện trạng
      • một chẩn đoán tốt đòi hỏi điều tra khách quan và tư duy như thám tử

    • Chính sách định hướng (Guiding Policy)

      • đây là cách tiếp cận cấp cao để giải quyết các vấn đề đã xác định
      • nó tập trung vào lời giải và giúp toàn tổ chức đi cùng một hướng
      • nó cung cấp phương hướng mà không cần phải nghĩ lại từ đầu ở từng chi tiết chiến thuật
      • chiến lược tệ thường thiếu sự kết nối giữa chính sách này (HOW) và phần chẩn đoán (WHY)

    • Hành động nhất quán (Coherent Actions)

      • đây là kế hoạch hành động cụ thể để giải quyết các vấn đề được chẩn đoán theo đúng chính sách đã đề ra
      • làm rõ ai (WHO), làm gì (WHAT), khi nào (WHEN)
      • cốt lõi là “tính nhất quán”, để nhiều team khác nhau cùng phối hợp và tiến về một hướng

Một cách khác để thu hẹp phạm vi kỹ thuật vào một team: mô hình Kebab vs Cake

• Cũng có thể thiết kế cấu trúc tổ chức sao cho công nghệ không trải rộng qua nhiều team mà được giải quyết ngay trong một team
• Một cách tiêu biểu là mô hình Kebab vs Cake
  • cấu trúc team dựa trên hành trình người dùng, tức một cách tiếp cận ở cấp tổ chức để thu hẹp phạm vi trách nhiệm kỹ thuật
  • xem chi tiết tại Kebab vs Cake organization

  • Kiến trúc Kebab

    • team được tổ chức xoay quanh các chức năng cung cấp
    • hành trình người dùng đi xuyên qua các artifacts của nhiều team
    • Ưu điểm: tính tự chủ và liên kết lỏng
    • Nhược điểm: rủi ro phát sinh handoff

  • Kiến trúc Cake

    • team được tổ chức xoay quanh hành trình người dùng
    • quản lý cognitive load thông qua các lớp trừu tượng hóa
    • Ưu điểm: quyền sở hữu end-to-end và giảm handoff
    • Nhược điểm: rủi ro tăng cognitive load
• Staff Engineer không chỉ là một vai trò kỹ thuật đơn thuần, mà phải là owner chịu trách nhiệm với toàn hệ thống, và cần có 3 yếu tố sau:
  • Kiến thức (Knowledge):
    • hiểu sâu về tech stack và vấn đề sản phẩm
    • khi cần phải có thể giải thích và trực tiếp triển khai chúng
  • Thẩm quyền (Mandate):
    • có vị thế để đưa ra ý kiến về cách công nghệ sẽ được phát triển và duy trì
  • Trách nhiệm (Responsibility):
    • chịu trách nhiệm về sức khỏe của hệ thống (sự cố, nợ kỹ thuật, tài liệu hóa, đứt gãy kỹ thuật, v.v.)
• Staff Engineer không phải vai trò thuần kỹ thuật, và soft skills là bắt buộc để dẫn dắt tổ chức về mặt kỹ thuật
  • cần có giao tiếp có sức ảnh hưởng, khả năng hợp tác, năng lực lãnh đạo, v.v.
• Tuy nhiên, nếu chỉ thiên về soft skills thì có thể phát sinh các vấn đề như sau:
  • chỉ đưa ra các lý tưởng xa rời thực tế mà không tham gia coding hay giải quyết vấn đề thực tế
  • có nguy cơ biến thành Ivory Tower Architect

Kết luận

• Không phải tổ chức nào cũng cần Staff Engineer. Trong các trường hợp sau, có thể không cần vai trò này:
  • khi EM có đủ năng lực kỹ thuật và có thể trực tiếp dẫn dắt kỹ thuật của team
  • khi tech stack đang khỏe mạnh và dễ bảo trì
  • khi công nghệ được khép kín trong một team, gần như không có phụ thuộc liên team (mô hình tổ chức Cake là một ví dụ)
  • khi tổ chức đủ trưởng thành để vận hành tốt toàn hệ thống ngay cả khi không có một owner cụ thể
• Ngược lại, nếu tổ chức có Staff Engineer thì cần làm rõ các điểm sau:
  • xác lập rõ technical ownership
  • và trao cho Staff Engineer accountability rõ ràng đối với phần trách nhiệm đó
• Tóm tắt cốt lõi:
  • cần tránh Ivory Tower Architect (thiếu tính thực tế)
  • chia một vai trò thành nhiều title là kém hiệu quả
  • EM không mang tính kỹ thuật cũng là một mô hình kém hiệu quả
• Cuối cùng, bài viết này không phải là luật tuyệt đối mà là một bài luận để tham khảo
  • tổ chức, công nghệ, sản phẩm, vận hành và con người đều khác nhau, nên điều quan trọng là phán đoán linh hoạt theo bối cảnh
  • tránh sao chép mù quáng (cargo culting) → xem bài liên quan

[kuthia]

Có cảm giác họ là cánh tay phải của CTO.

[bus710]

Staff Engineer: người sẽ đến làm phiền khi đã thử đủ mọi cách mà vẫn không được.

[bobross0]

Haha, chuẩn luôn

[ethanhur]

Không liên quan nhiều đến nội dung bài viết, nhưng vì lúc đó tôi cũng đang suy nghĩ về sự khác biệt giữa accountability và responsibility nên liên kết sau đã giúp ích cho tôi rất nhiều.

https://blog.alexewerlof.com/p/accountable-vs-responsible