# FDE và Technical Account Manager: ai sửa hệ thống, ai giữ liên lạc với khách khi có sự cố

> Khi hệ thống của khách hỏng vào đúng đêm quan trọng nhất, bên nhà cung cấp cần hai người làm hai việc khác nhau, và cả hai phải biết trước ai làm việc nào.

Bản gốc: https://fdetimes.net/vi/bach-khoa/fde-vs-technical-account-manager/

Thử hình dung: đêm trước đợt khuyến mãi lớn nhất năm, hệ thống xử lý đơn hàng bạn triển khai cho khách bắt đầu trả lỗi. Kênh chat sự cố có hai người phía nhà cung cấp. Một người mở terminal, người kia mở danh bạ để gọi giám đốc vận hành của khách.

Nếu cả hai cùng mở terminal, không ai báo cho khách biết chuyện gì đang xảy ra. Còn nếu cả hai cùng gọi điện thì chẳng ai sửa lỗi. Ranh giới giữa Forward Deployed Engineer và Technical Account Manager (TAM) nghe như chuyện chức danh, nhưng sự khác biệt lộ ra rõ nhất đúng vào những đêm như thế.

Nếu bạn đang làm FDE, hiểu TAM giúp bạn biết lúc nào nên giao điện thoại cho người khác để quay lại với code. Còn nếu bạn đang làm TAM và muốn chuyển sang FDE, bạn cần biết chính xác mình còn thiếu kỹ năng gì.

## Hai vai trò khác nhau ở đâu?

Bài so sánh vai trò trên fde.academy tóm gọn: FDE xây và giao sản phẩm, TAM điều phối và tư vấn. Cụ thể hơn, TAM đọc được code nhưng hiếm khi viết code production, còn FDE viết code production hằng ngày.

Theo blog này, sức mạnh của TAM đến từ độ sâu của quan hệ với khách và khả năng điều phối nhiều phòng ban, chứ không đến từ việc tự tay giao sản phẩm kỹ thuật.

Nhịp làm việc cũng khác. TAM gắn với khách lâu dài, với các buổi rà soát kinh doanh theo quý. FDE làm theo từng đợt triển khai kéo dài từ vài tuần đến vài tháng.

Christian & Timbers, một công ty săn đầu người, nhấn mạnh rằng trách nhiệm của FDE không kết thúc khi khách ký hợp đồng mà kéo dài tới lúc hệ thống chạy trên production và tạo ra kết quả đo được.

AWS là ví dụ dễ thấy về vai trò TAM. Hãng ghi rõ một TAM chuyên trách là quyền lợi của gói Enterprise Support. Như vậy TAM đi kèm một gói hỗ trợ trả phí, không phải một kỹ sư làm việc ngay trong hệ thống của khách.

**Điểm mấu chốt:** FDE chịu trách nhiệm cho hệ thống. TAM chịu trách nhiệm cho mối quan hệ với khách.

## Ranh giới mờ nhất nằm ở sự cố

Hai vai trò có một điểm chung quan trọng: cả hai đều xử lý escalation từ khách và đưa phản hồi về đội sản phẩm. Vì thế khi có sự cố, rất dễ xảy ra chuyện cả hai cùng lao vào một việc.

AWS mô tả khá rõ TAM làm gì trong một sự kiện kinh doanh quan trọng. Trước sự kiện, TAM cùng khách kiểm tra xem hệ thống đã sẵn sàng chưa và có đủ sức chịu tải dự kiến không. Trong sự kiện, TAM hỗ trợ khách.

Theo trang Enterprise Support, TAM điều phối các chuyên gia của AWS, theo dõi bức tranh tổng thể và dẫn buổi rà soát sau sự kiện để tìm điểm cần cải thiện. Chương trình AWS Countdown gọi cách hỗ trợ này là "TAM-led", tức do TAM dẫn dắt.

Phía FDE có một ví dụ từ Palantir, nơi khai sinh vai trò này. Hãng có một biến thể tên Forward Deployed Enablement Engineer, làm việc trong đội customer success tập trung.

Tin tuyển dụng yêu cầu người này nhận trách nhiệm xử lý đầu tiên khi có sự cố và trực on-call 24/7 cho các sự cố nghiêm trọng của khách. Nói cách khác, việc của họ là giữ cho hệ thống của khách tiếp tục hoạt động.

## Ví dụ: một đợt khuyến mãi, hai danh sách việc

Quay lại đêm khuyến mãi ở đầu bài. Giả sử bạn là FDE đã triển khai một agent tự động xử lý yêu cầu đổi trả cho một chuỗi bán lẻ, còn đồng nghiệp TAM phụ trách khách hàng này từ nhiều năm trước. Bảng dưới đây gợi ý cách hai người chia việc.

| Pha | FDE làm | TAM làm |
|---|---|---|
| Hai tuần trước | Chạy load test với lưu lượng dự kiến, sửa các điểm nghẽn, viết runbook | Cùng khách kiểm tra mức sẵn sàng và sức chịu tải dự kiến, xác nhận ai phía khách có quyền quyết định |
| Trong sự cố | Xử lý đầu tiên: đọc log, rollback hoặc vá lỗi, viết cập nhật kỹ thuật | Kéo chuyên gia nội bộ vào khi FDE cần, báo tin cho lãnh đạo phía khách |
| Sau sự kiện | Viết bản phân tích nguyên nhân, đẩy bản sửa lâu dài lên production | Dẫn buổi rà soát sau sự kiện, gom phản hồi gửi về đội sản phẩm |

Phần dễ hỏng nhất là chỗ hai bên trao tin cho nhau trong lúc có sự cố. Một cách làm hiệu quả là FDE gửi cho TAM một bản cập nhật ba dòng sau mỗi khoảng thời gian cố định, chẳng hạn:

```
Đang hỏng: 30% yêu cầu đổi trả bị timeout ở bước gọi API kho.
Đang làm: đã rollback bản deploy chiều nay, đang theo dõi tỉ lệ lỗi.
Cập nhật tiếp: 23h30.
```

TAM chuyển ba dòng đó thành ngôn ngữ mà lãnh đạo phía khách cần nghe, gồm ảnh hưởng tới khách mua hàng và thời điểm có tin tiếp theo. Nhờ vậy FDE không phải rời terminal để vào các cuộc gọi, còn TAM không phải hứa một mốc thời gian khi chưa hỏi người đang sửa lỗi.

## Tự làm: chia vai trước khi có chuyện

Hãy bắt đầu khi mọi thứ còn yên ổn. Viết ra ai chịu trách nhiệm hệ thống, ai chịu trách nhiệm liên lạc với từng người phía khách, rồi gửi cho cả hai đội. Nếu công ty bạn không có TAM, người giữ liên lạc có thể là account executive hoặc trưởng nhóm của bạn. Điều quan trọng là có người đứng tên cụ thể.

Tiếp theo, thống nhất nhịp cập nhật và mẫu tin nhắn trước sự kiện, đừng đợi lúc đang có sự cố mới bàn. Trước mỗi đợt cao điểm của khách, đặt một buổi rà soát mức sẵn sàng. FDE mang số liệu load test đến, còn TAM mang danh sách các bên phía khách cần được thông báo.

Sau sự kiện, cả hai ngồi lại trước khi gửi gì cho đội sản phẩm. Vì cả hai vai trò đều đưa phản hồi về sản phẩm, một bản phân tích chung sẽ có sức nặng hơn hai email rời rạc mô tả cùng một lỗi theo hai cách khác nhau.

## Những lỗi hay gặp

Một cái bẫy dễ rơi vào với FDE là đóng luôn vai TAM: ngồi họp với lãnh đạo phía khách trong lúc lỗi vẫn chưa được sửa. Lỗi ngược lại của TAM là hứa với khách thời điểm khắc phục khi chưa hỏi người đang đọc log. Cả hai lỗi đều xuất phát từ việc chưa phân vai trước.

Lỗi thứ ba là coi TAM như một phiên bản FDE nhẹ hơn. Hai vai trò dựa trên hai thế mạnh khác nhau, một bên là quan hệ và khả năng điều phối, một bên là code production. Người giỏi việc này chưa chắc giỏi việc kia.

## Đọc job description và viết CV thế nào?

Khi đọc tin tuyển dụng, để ý các cụm từ. Những cụm như "quarterly business review", "designated" hay "relationship" cho thấy vị trí nghiêng về TAM. Còn "production code", "on-call" hay "first responder" cho thấy vị trí nghiêng về FDE, kể cả khi vị trí nằm trong đội customer success như trường hợp của Palantir.

Trên CV, đừng chỉ ghi "phối hợp với khách hàng". Hãy kể một sự cố bạn trực tiếp xử lý: bạn sửa gì, hệ thống phục hồi sau bao lâu, bản sửa lâu dài nào đã lên production.

Nếu bạn đang làm TAM và muốn chuyển sang FDE, phần còn thiếu thường là bằng chứng bạn đã tự tay đưa code lên production, nên hãy nhận một bản vá nhỏ trong lần escalation tới thay vì chuyển hết cho đội kỹ sư.

Một nhà cung cấp tốt cần cả hai vai trò trong đêm có sự cố. Chỉ cần mỗi người biết trước việc của mình, khách sẽ thấy hệ thống được khôi phục và được báo tin đúng hẹn.

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

- Với một khách bạn đang phụ trách, viết một trang gồm hai cột: ai chịu trách nhiệm hệ thống, ai chịu trách nhiệm liên lạc với từng người phía khách.
- Soạn sẵn mẫu cập nhật sự cố ba dòng (đang hỏng gì, đang làm gì, mấy giờ cập nhật tiếp) và gửi cho người phụ trách liên lạc với khách.
- Mở 3 job description có chữ 'customer' trong tên vị trí và đánh dấu các cụm từ cho thấy vị trí đó nghiêng về FDE hay TAM.

## Nguồn

- [Forward Deployed Engineer vs Technical Account Manager: Role Comparison Guide](https://fde.academy/blog/forward-deployed-engineer-vs-technical-account-manager)

- [Forward Deployed Engineer vs. Sales Engineer: The Difference Is Production Ownership](https://www.christianandtimbers.com/insights/forward-deployed-engineer-vs-sales-engineer)

- [AWS Support Plans - AWS Support](https://docs.aws.amazon.com/awssupport/latest/user/aws-support-plans.html)

- [AWS Enterprise Support plan – AWS](https://aws.amazon.com/premiumsupport/plans/enterprise/)

- [Forward Deployed Enablement Engineer - Customer Success (Palantir)](https://jobs.lever.co/palantir/a90eb029-19cc-413c-bd51-b8411053d7d4)