FDE PulseViệc làm FDE đang mở 632Mới trong 7 ngày 57Công ty đang tuyển 95Nhận làm từ xa 24%Lương trung vị (Mỹ) $205kTuyển nhiều nhất Databricks 114
EN

Tờ báo của nghề Forward Deployed Engineer

Sách & khoá học

An Elegant Puzzle của Will Larson: sách tra cứu cho FDE sắp lên làm lead

Khi bạn chuyển từ người viết code ở site khách hàng sang người chịu trách nhiệm cho cả đội, cuốn sách của Stripe Press này dạy bạn nhìn đội như một hệ thống có dòng chảy chứ không phải danh sách việc cần dập lửa.

Bìa sách An Elegant Puzzle: Systems of Engineering Management
An Elegant Puzzle: Systems of Engineering Management · Will Larson · Ảnh bìa: Open Library
Chia sẻLinkedInFacebookX

Tóm tắt nhanh

  • Sách của Will Larson, Stripe Press xuất bản năm 2019, dành cho người dẫn đội đã có chút kinh nghiệm chứ không phải người mới hoàn toàn.
  • Cốt lõi là tư duy hệ thống: nhìn đội như các stock và flow, kết hợp nguyên tắc có cấu trúc với sự quan tâm đến con người.
  • Nội dung dày, hợp với tổ chức lớn; nên tra theo vấn đề thay vì đọc liền một mạch.
Biểu đồ dốc cho một đội FDE ba người. Trước: mỗi tuần có 6 yêu cầu vào và 5 được đóng, nên sau mười tuần backlog dày thêm 10 việc. Sau khi lọc ở bước discovery: còn 4 yêu cầu vào, vẫn đóng 5, nên backlog vơi đi 1 việc mỗi tuần.
Khi dòng vào giảm từ 6 xuống 4 còn dòng ra giữ ở 5, backlog bắt đầu vơi mà không ai phải tăng ca. Nguồn: ví dụ minh hoạ trong bài, dựa trên tư duy stock và flow của Will Larson trong An Elegant Puzzle.

Một FDE giỏi thường được thưởng bằng một thứ ít ai chuẩn bị: thêm người. Hôm qua bạn còn tự viết pipeline cho khách hàng. Hôm nay bạn có ba kỹ sư, hai engagement song song và một câu hỏi không có trong tài liệu kỹ thuật nào: vì sao đội càng đông, việc càng chậm?

An Elegant Puzzle: Systems of Engineering Management của Will Larson không đưa ra công thức có sẵn cho câu hỏi đó. Thứ nó cho bạn là một cách nghĩ để tự tìm lời giải. Sách do Stripe Press xuất bản năm 2019, và Larson cho biết ông mất khoảng một năm để biên soạn.

Với một FDE sắp thành lead, giá trị của sách không nằm ở mẹo quản lý. Nó nằm ở việc biến những chuyện mơ hồ như “đội đang quá tải” thành một hệ thống bạn có thể vẽ ra, đo và sửa.

Sách thật sự nói về điều gì?

Stripe Press giới thiệu sách là lời giải cho các câu hỏi điển hình của quản lý kỹ thuật: xử lý nợ kỹ thuật ra sao, làm sao để mỗi kỹ sư trong đội phát triển đúng nhịp. Nhà xuất bản mô tả cách tiếp cận của Larson là cân bằng giữa nguyên tắc có cấu trúc và tư duy lấy con người làm trung tâm.

Theo bài review của Gergely Orosz trên The Pragmatic Engineer, sách chia thành sáu phần: Organizations, Tools, Approaches, Culture, Careers và Appendix. Phần Appendix cung cấp công cụ vận hành tổ chức ở ba tầng: line manager, middle manager và manager of managers.

Orosz gọi đây là tài liệu tốt nhất ông từng biết dành cho những người dẫn dắt kỹ thuật đã có chút kinh nghiệm. Vế sau mới là điều đáng để ý. Nếu bạn chưa từng kèm ai hay chịu trách nhiệm cho kết quả của người khác, nhiều chương sẽ đọc như lý thuyết.

Ý thứ nhất: đội là một hệ thống stock và flow

Luca Rossi, tác giả bản tin Refactoring, coi tư duy hệ thống là phần cốt lõi của sách, với cách nhìn mọi hệ thống như các stock và flow. Stock là thứ tích tụ lại; flow là tốc độ thứ đó chảy vào hoặc chảy ra.

Thử hình dung một đội FDE ba người. Stock là danh sách yêu cầu tích hợp từ khách hàng đang chờ. Mỗi tuần có 6 yêu cầu mới chảy vào, đội đóng được 5. Không ai lười, không ai kém, nhưng sau mười tuần backlog đã dày thêm 10 việc và khách hàng bắt đầu phàn nàn.

Phản xạ của một kỹ sư mới lên lead thường là làm thêm giờ cùng đội. Tư duy hệ thống buộc bạn hỏi câu khác: nên giảm dòng vào (lọc yêu cầu ngay từ customer discovery), hay tăng dòng ra (tự động hoá phần tích hợp lặp lại)?

Giờ tự làm bài tập. Giả sử ở bước discovery bạn gạt được 2 trong 6 yêu cầu mỗi tuần vì chúng không gắn với mục tiêu của khách hàng. Dòng vào còn 4, dòng ra vẫn 5, nên backlog vơi đi 1 việc mỗi tuần, và 10 việc tồn đọng sẽ hết sau mười tuần mà không ai phải tăng ca.

Lỗi hay gặp nhất là chỉ nhìn stock. Người lead báo cáo “backlog đang có 10 việc” nhưng không biết mỗi tuần bao nhiêu việc vào và ra, nên không thể nói khi nào tình hình khá lên. Một con số tồn đọng chỉ cho biết bạn đang đứng ở đâu; hai con số dòng chảy mới cho biết bạn đang đi về đâu.

Việc đầu tiên nên làm tại khách hàng là đếm hai con số đó trong bốn tuần gần nhất, trước khi hứa thêm bất cứ điều gì.

Ý thứ hai: nợ kỹ thuật và nhịp phát triển của con người là cùng một bài toán

Hai câu hỏi Stripe Press chọn để giới thiệu sách, nợ kỹ thuật và tốc độ phát triển của từng kỹ sư, nghe như hai chủ đề tách biệt. Với FDE, chúng dính chặt vào nhau. Code viết vội ở site khách hàng tạo ra nợ; người kỹ sư phải sửa nợ đó mãi sẽ ngừng học.

Từ cách Larson đặt nguyên tắc có cấu trúc cạnh sự quan tâm đến con người, có thể rút ra một thói quen đơn giản cho người mới lên lead. Mỗi khi giao việc, hãy hỏi việc đó trả nợ, tạo giá trị mới cho khách hàng, hay giúp người nhận lớn lên.

Một việc tốt nên làm được ít nhất hai trong ba điều. Nếu một kỹ sư ba tháng liền chỉ nhận việc vá lỗi, bạn đã có câu trả lời cho câu hỏi “họ có phát triển đúng nhịp không”.

Ý thứ ba: tuyển, đánh giá và giữ người là kỹ năng phải học

Phần Careers của sách bàn về tuyển dụng, đánh giá hiệu suất, thăng tiến và giữ người. Với một FDE quen đo mình bằng code đã ship và khách hàng đã hài lòng, đây là những việc hoàn toàn mới, và không việc nào tự giỏi lên chỉ nhờ năng lực kỹ thuật.

Về mặt sự nghiệp, đây cũng là chỗ bạn tạo khác biệt. Khi xem tin tuyển FDE lead hay engagement lead, hãy để ý những dòng như “mentor”, “hiring” hay “grow the team”. Trong CV, một câu như “kèm 2 kỹ sư, cả hai tự dẫn engagement sau sáu tháng” thuyết phục hơn nhiều so với “có kỹ năng lãnh đạo”.

Ai nên đọc, và đọc theo thứ tự nào?

Rossi lưu ý sách hữu ích nhất cho quản lý và tech lead trong tổ chức lớn; đội nhỏ có thể thấy không phải chương nào cũng liên quan. Ông cũng nhận xét nội dung cực kỳ dày và giàu, nên dùng như tài liệu tra cứu hơn là đọc liền từ đầu đến cuối.

Lời khuyên vì thế khá rõ. Nếu bạn ở startup với đội FDE năm người, hãy bắt đầu từ phần Careers và tư duy stock và flow, để Organizations và Appendix cho lúc đội lớn lên. Nếu bạn ở tổ chức lớn, phần Appendix với ba tầng quản lý sẽ giúp bạn hiểu sếp của sếp mình đang lo điều gì.

Còn nếu chưa muốn mua sách, Orosz cho biết Larson từng đăng dần bản nháp các chương trên blog Irrational Exuberance trong lúc viết. Đọc thử một bài về đúng vấn đề bạn đang vướng là cách rẻ nhất để biết cuốn sách có hợp với mình không.

Câu hỏi “vì sao đội càng đông càng chậm” sẽ còn quay lại ở mỗi nấc thăng tiến. Khác biệt giữa người lead mệt mỏi và người lead điềm tĩnh thường nằm ở chỗ ai đã tập vẽ hệ thống trước khi bị nó đè lên.

Bài này có hữu ích không?

Dùng cùng trợ lý AIHỏi Claude ↗Hỏi ChatGPT ↗
4 nguồn
Đọc tiếp trên lộ trình · Chặng 7: Dẫn dắtThe Mythical Man-Month: vì sao thêm kỹ sư vào dự án trễ của khách lại làm nó trễ hơnFred Brooks viết cuốn này từ những năm quản lý OS/360 ở IBM. Trong đó có một phép tính bạn nên mang vào mọi cuộc họp mà có người đề nghị "cử thêm hai kỹ sư sang cho khách".