# Team Topologies: cuốn sách giúp đội FDE tìm chỗ đứng giữa product và platform

> Cuốn sách không nhắc đến FDE, nhưng khái niệm enabling team trong đó mô tả gần đúng việc bạn làm mỗi ngày: giúp đội khác vượt trở ngại và chỉ ra năng lực còn thiếu.

Bản gốc: https://fdetimes.net/vi/sach-khoa-hoc/sach-team-topologies-skelton-pais/

Docker kể lại chuyện tổ chức lại các đội kỹ sư theo Team Topologies, và trong bài có một câu hiếm gặp trên blog doanh nghiệp: lần thử đầu tiên không giảm được cognitive load. Họ phải làm lại.

Chi tiết đó có sức nặng hơn mọi lời khen. Cuốn sách của Matthew Skelton và Manuel Pais không phải công thức cứ áp vào là chạy. Nó là một bộ từ vựng để nói về chỗ đứng của từng đội và cách các đội chạm vào nhau.

Với FDE, bộ từ vựng ấy là thứ cần nhất. Bạn ngồi giữa khách hàng, sales và đội product, nên mỗi lần một yêu cầu từ hiện trường bị kẹt giữa ba bên, bạn cần nói rõ ai làm gì, làm trong bao lâu, và khi nào thì dừng.

## Bản nào nên đọc, đọc theo thứ tự nào?

Ấn bản đầu mang tên *Team Topologies: Organizing Business and Technology Teams for Fast Flow*, do IT Revolution Press phát hành ngày 7/9/2019, dày 240 trang. Toàn bộ cách tiếp cận xoay quanh bốn kiểu đội cơ bản và ba kiểu tương tác giữa các đội.

Ấn bản 2 ra ngày 23/9/2025, dày 304 trang, phụ đề đổi thành *Organizing Business and Technology for Fast Flow of Value*. Nhà xuất bản coi đội là đơn vị cơ bản để giao giá trị, và vẫn gọi cuốn sách là bước tiến lớn trong thiết kế tổ chức cho IT và công việc tri thức.

Nên đọc theo thứ tự này: trang Key Concepts trên teamtopologies.com trước, vì nó ngắn và có đủ các định nghĩa. Sau đó đọc ấn bản 2. Cuối cùng, đặt sách cạnh handbook FDE công khai của PostHog để xem một công ty thật đặt đội FDE ở đâu.

## Ý thứ nhất: đội quá tải thì quyết định tồi

Lý do chính để tách đội, theo sách, là cognitive load. Trang Key Concepts so sánh rất gọn: CPU quá tải làm máy tính chậm đi, đội quá tải thì ra quyết định kém và đi chậm.

Thử hình dung một đội FDE bốn người phục vụ sáu khách hàng, mỗi khách một stack riêng. Mỗi bản sửa nhanh tại hiện trường lại thành thứ đội phải giữ trong đầu mãi về sau. Đến khách hàng thứ bảy, đội không thiếu kỹ năng. Đội chỉ không còn chỗ trống trong đầu.

Việc nên làm đầu tiên ở khách hàng: liệt kê mọi thứ đội đang phải tự giữ, như connector, script, cấu hình riêng. Danh sách đó cho biết thứ gì cần được đẩy sang đội khác.

## Ý thứ hai: gọi đúng tên kiểu đội

Trong bốn kiểu đội của sách, có ba kiểu chạm trực tiếp vào công việc FDE hằng ngày; kiểu còn lại bạn sẽ gặp khi đọc trang Key Concepts.

Đội stream-aligned bám theo một luồng công việc, thường thuộc một mảng nghiệp vụ, và đội product thường nằm ở đây. Đội platform tạo ra dịch vụ giúp các đội stream-aligned đi nhanh hơn bằng cách gánh bớt độ phức tạp.

Kiểu đáng chú ý nhất với FDE là enabling team: đội giúp stream-aligned vượt trở ngại, đồng thời phát hiện những năng lực còn thiếu. Vai trò ấy rất gần với cách PostHog mô tả đội FDE của họ.

Đội này ngồi giữa khách hàng, sales, CS và product engineering, không nắm quyền định hướng sản phẩm, và mang bài học thật từ khách hàng về product thông qua các đội product engineering.

Rocketlane thì mô tả một mô hình khác: đặt chức năng FDE trong product và R&D thay vì trong khối go-to-market. Không có chỗ đặt nào đúng cho mọi công ty. Việc của bạn là xác định đội mình đang theo mô hình nào, vì từ đó mới biết yêu cầu từ khách hàng sẽ đi về đâu và ai quyết định.

## Ý thứ ba: chọn đúng kiểu tương tác, và đặt ngày kết thúc

Sách đưa ra ba kiểu tương tác: collaboration, X-as-a-Service và facilitation. Collaboration được định nghĩa là hai đội làm cùng nhau *trong một khoảng thời gian xác định* để khám phá điều mới, chẳng hạn API, cách làm hay công nghệ. X-as-a-Service là khi một đội cung cấp và đội kia dùng một thứ dưới dạng dịch vụ.

Với FDE, đó là lúc bạn giúp đội product hiểu một vấn đề từ hiện trường để họ tự xây, chứ không viết tính năng thay họ.

Thử hình dung một khách hàng ngân hàng cần SSO qua một identity provider lạ. Trong ba tuần đầu, FDE và đội platform cộng tác để tìm ra API phù hợp. Sau đó platform cung cấp nó như một dịch vụ, còn FDE chỉ việc dùng.

Nếu đợt cộng tác ấy không có ngày kết thúc, platform sẽ bị kéo vào từng khách hàng, và tải nhận thức lan sang cả hai đội.

**Điểm mấu chốt:** Mỗi lần hai đội cộng tác nên có ngày kết thúc ghi sẵn từ đầu.

Để biết khi nào một việc nên chuyển thành dịch vụ, hãy dùng phép thử Rocketlane nêu ra. Giải pháp chỉ giúp một khách hàng là customization. Giải pháp giúp mọi khách hàng sau này là product development.

Áp vào ví dụ trên, một connector viết riêng cho identity provider của ngân hàng vẫn là customization; nó chỉ thành product development khi được làm thành thứ mà mọi khách hàng sau này đều dùng được.

## Docker dạy gì về việc vẽ lại sơ đồ đội?

Sơ đồ đúng trên giấy chưa chắc giảm được tải trong thực tế, và Docker là ví dụ rõ nhất. Họ dùng Reverse Conway Maneuver để cân chỉnh đội với kiến trúc, nhằm giảm tải nhận thức, giảm phụ thuộc và khớp với hướng đi của sản phẩm.

Lần đầu họ làm hỏng. Đó là lời nhắc rằng đặt một đội mới, như đội FDE, cạnh các đội cũ thì phải kiểm tra xem tải nhận thức có thật sự giảm, chứ vẽ sơ đồ thôi là chưa đủ.

## Ai nên đọc, và dùng nó thế nào cho sự nghiệp?

Nếu bạn là kỹ sư có 2-8 năm kinh nghiệm, đang làm FDE hoặc muốn chuyển sang, đây là cuốn sách về tổ chức hiếm hoi mà bạn dùng được ngay tuần sau. Người đang dẫn một đội FDE mới thành lập càng nên đọc.

Khi phỏng vấn, hãy hỏi thẳng: đội FDE báo cáo về product hay về sales, và yêu cầu từ khách hàng đến đội platform bằng đường nào. Câu trả lời mơ hồ là tín hiệu của nhiều vướng víu phía trước. Trên CV, thay vì ghi "tích hợp cho khách hàng", hãy kể bạn đã biến một bản customization thành tính năng mà nhiều khách hàng dùng chung.

Sơ đồ tổ chức nào cũng có hộp FDE. Sách giúp bạn vẽ được những mũi tên nối hộp đó với các đội khác, và ghi ngày hết hạn lên từng mũi tên.

**Thử ngay tuần này:**

- Đọc trang Key Concepts trên teamtopologies.com rồi xếp từng đội bạn hay làm việc cùng vào một kiểu đội
- Lấy ba yêu cầu gần nhất từ khách hàng và áp phép thử của Rocketlane: chỉ giúp một khách hàng hay giúp mọi khách hàng sau này?
- Với đợt cộng tác đang mở với đội platform, ghi ra ngày kết thúc và đầu ra mong muốn

## Nguồn

- [Team Topologies book (teamtopologies.com)](https://teamtopologies.com/book)

- [Team Topologies, 2nd Edition (IT Revolution)](https://itrevolution.com/product/team-topologies/)

- [Key Concepts (Team Topologies)](https://teamtopologies.com/key-concepts)

- [Building Stronger, Happier Engineering Teams with Team Topologies (Docker)](https://www.docker.com/blog/building-stronger-happier-engineering-teams-with-team-topologies/)

- [Forward deployed engineering overview - Handbook (PostHog)](https://posthog.com/handbook/forward-deployed-engineering/overview)

- [Forward Deployed Engineering: Finding the Model That Fits (Rocketlane)](https://rocketlane.com/blogs/forward-deployed-engineering-models)