Dẫn dắt kỹ thuật tại khách hàng khi không ai báo cáo cho bạn

Thử hình dung tuần thứ hai của bạn ở site khách hàng. Bạn phát hiện job ETL của đội dữ liệu bên họ ghi đè bản ghi cũ mỗi đêm, nên agent bạn đang build sẽ không có lịch sử để trả lời câu hỏi của người dùng. Muốn sửa thì đội ấy phải đổi pipeline, mà không ai trong đội báo cáo cho bạn.

Sớm muộn gì FDE cũng gặp tình huống này. Tin tuyển dụng FDE của Palantir nói trước với ứng viên rằng họ sẽ embed cùng khách hàng, chấp nhận mọi sự bề bộn ở đó và cùng chịu hệ quả, đổi lại được giao quyền sở hữu thật. Nhưng sở hữu sản phẩm không có nghĩa là được ra lệnh cho kỹ sư của công ty khác.

Vì thế dẫn dắt kỹ thuật tại khách hàng là một kỹ năng riêng, và bạn luyện được nó. LeadDev tóm lại thế này: dẫn dắt khi không có quyền hạn là chuyện gây ảnh hưởng, không phải chuyện quyền lực. Câu hỏi còn lại là ảnh hưởng ấy được xây từ đâu và dùng thế nào.

Quyền của bạn là quyền đi mượn

Will Larson, khi viết về kỹ sư cấp Staff trở lên, có một nhận xét rất hợp với FDE. Ông cho rằng quyền hạn trong tổ chức mà bạn có là do một cấp cao hơn cho mượn, không phải của bạn. Muốn giữ nó, bạn phải luôn thống nhất chặt chẽ với người bảo trợ, mà thường người đó là quản lý của bạn.

Larson nói về người bảo trợ trong chính công ty bạn, nhưng ý của ông có thể mở rộng sang phía khách hàng. Ở đó, người bảo trợ thường là người bên họ đã đồng ý mang bạn vào: một giám đốc vận hành, một trưởng phòng dữ liệu.

Khi bạn nói “pipeline này cần đổi”, đội dữ liệu nghe theo không phải vì bạn giỏi, mà vì họ tin người bảo trợ của họ muốn điều đó.

Từ đây có một hệ quả thực tế. Nếu bạn đẩy một hướng mà người bảo trợ chưa đồng ý, bạn đang dùng một thứ quyền chưa ai trao cho bạn. Lần đầu có thể suôn sẻ, nhưng đến lần thứ hai, đội kỹ sư sẽ đi hỏi thẳng sếp họ, và khoản quyền mượn kia bị rút lại.

Uy tín đến trước, đề xuất đến sau

Quyền mượn chỉ mở được cửa. Đội kỹ sư có làm theo một cách tận tâm hay không lại phụ thuộc vào uy tín. LeadDev khuyên xây uy tín bằng cách cho người khác thấy kiến thức và kỹ năng của bạn, và với FDE, cách thấy rõ nhất là code chạy được.

Tin tuyển dụng FDE của Harper gọi thẳng tên mục tiêu này: embed với khách hàng để build, deploy và giành được sự tin tưởng về kỹ thuật. Sự tin tưởng ấy có trước, rồi mới đến lúc bạn xin họ đổi kiến trúc. Trong tuần đầu, một bản sửa nhỏ cho đúng vấn đề họ đang đau đầu có giá trị hơn mười slide đề xuất.

Nhưng uy tín kỹ thuật một mình chưa đủ. Một bài phân tích về mô hình echo/delta viết rằng đội chỉ lo quan hệ mà không có đội kỹ thuật giao hàng thì rốt cuộc chẳng ship được gì, còn đội kỹ thuật thiếu nhu cầu và đà từ phía khách hàng thì làm ra phần mềm rất ấn tượng mà không ai bên khách hàng cần.

FDE phải giữ được cả hai đầu.

Ví dụ: đưa quyết định về pipeline cho đội dữ liệu tự chọn

Quay lại job ETL ghi đè dữ liệu. Giả sử bạn đã sửa xong một lỗi nhỏ trong tool nội bộ của đội dữ liệu và đã chốt với người bảo trợ rằng agent cần dữ liệu lịch sử. Lúc này bạn mới mang vấn đề vào phòng họp.

LeadDev gợi ý một thang ba màu để sắp xếp các lựa chọn: xanh là làm được ngay, vàng là làm nhưng phải thận trọng, đỏ là dừng lại và nghĩ lại. Thay vì nói “các anh phải đổi pipeline”, bạn viết ba phương án lên bảng:

Phương án	Màu	Rủi ro chính
Thêm bảng snapshot hằng ngày, không đụng job cũ	Xanh	Tốn thêm dung lượng lưu trữ
Đổi job sang ghi thêm thay vì ghi đè	Vàng	Các báo cáo đang đọc bảng cũ có thể vỡ
Agent tự lưu cache lịch sử ở phía agent	Đỏ	Hai nguồn sự thật, lệch dữ liệu về lâu dài

Kịch bản nói chuyện có thể như sau. Bạn: “Agent cần biết giá trị của một bản ghi vào tuần trước. Đây là ba cách có thể làm. Các anh hiểu hệ thống rõ hơn, vậy màu đánh giá thế này đã đúng chưa?”

Trưởng nhóm dữ liệu có thể đáp: “Phương án vàng thật ra là xanh, vì chỉ có hai báo cáo đọc bảng đó.” Đến đó quyết định đã thành của họ.

Cách làm này khớp với điều Palantir yêu cầu ở FDE: cùng các kỹ sư khác ra quyết định kiến trúc và thiết kế, không áp đặt. Bạn mang góc nhìn và dữ liệu, còn họ mang hiểu biết về hệ thống của chính họ.

Năm bước để tự làm

1. Gọi đúng tên người bảo trợ và hỏi thẳng họ ưu tiên điều gì trong quý này. 2. Ship một thứ nhỏ, đúng chỗ đau, trước khi xin ai đổi gì. 3. Viết vấn đề thành các phương án xanh–vàng–đỏ, mỗi phương án kèm một dòng rủi ro. 4. Để đội kỹ thuật bên khách hàng sửa lại màu của từng phương án. 5.

Cập nhật tiến độ đều đặn cho mọi tầng liên quan.

Bước cuối dễ bị xem nhẹ nhất. Palantir mô tả FDE là người giữ quan hệ từ những người dùng trực tiếp làm việc hằng ngày với hệ thống lên tới các lãnh đạo ra quyết định, và LeadDev coi giao tiếp cởi mở, minh bạch, đều đặn là then chốt.

Những lỗi khiến FDE mất ảnh hưởng

Lỗi phổ biến nhất là coi chức danh ở công ty của bạn như quyền hạn. Kỹ sư bên khách hàng không nợ bạn điều gì, và một đề xuất mở đầu bằng tên công ty bạn nghe giống áp đặt nhiều hơn là cộng tác.

Lỗi thứ hai là vượt mặt đội kỹ thuật để đi thẳng lên lãnh đạo. Có thể bạn thắng được một quyết định, nhưng bạn sẽ mất người sẽ phải vận hành quyết định ấy sau khi bạn rời đi.

Lỗi thứ ba là để người bảo trợ trôi khỏi tầm nhìn. Ưu tiên của họ thay đổi, còn bạn vẫn đẩy hướng cũ bằng thứ quyền giờ không còn ai đứng sau. Lỗi cuối cùng là chỉ làm một nửa: hoặc chăm quan hệ mà không ship, hoặc ship giỏi mà không ai cần.

Cách cho nhà tuyển dụng thấy kỹ năng này

Nếu bạn đang nhắm vào vị trí FDE, hãy đọc kỹ các dòng trong JD nhắc tới stakeholder, ownership hay technical trust. Đó là chỗ nhà tuyển dụng đang hỏi bạn về kỹ năng này.

Trong CV, đừng viết “có kỹ năng giao tiếp tốt”. Hãy kể một lần bạn khiến một đội không thuộc quyền bạn đổi thiết kế: bạn đưa những phương án nào, họ chọn phương án nào, và kết quả sau khi deploy ra sao. Một câu chuyện như vậy có sức nặng hơn mọi tính từ.

Cái khó nhất của dẫn dắt mà không có quyền hạn nằm ở việc chấp nhận để người khác ghi tên họ lên quyết định. Bạn càng sẵn lòng nhường phần ghi công đó, hệ thống bạn để lại càng có người chịu nhận về mình.