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

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

Sách & khoá học

Influence Without Authority: FDE tìm 'đồng tiền' của người không báo cáo cho mình

Khi DBA của khách hàng chẳng nợ bạn điều gì, code tốt không mở được quyền truy cập, nhưng biết họ coi trọng gì thì có thể.

Bìa sách Influence Without Authority
Influence Without Authority · Allan R. Cohen · Ảnh bìa: Open Library
Chia sẻLinkedInFacebookX

Tóm tắt nhanh

  • Exchange Model: muốn được hợp tác, hãy trao lại thứ đối phương coi trọng.
  • Cùng một yêu cầu, mỗi người ở khách hàng có thể cần một đồng tiền khác nhau.
  • Hãy chọn ấn bản thứ ba, đọc sáu bước theo thứ tự và vừa đọc vừa thử trên một ticket đang kẹt.
Yêu cầu "Cho tôi quyền đọc production" tách thành hai hướng. Với DBA, đồng tiền là giấc ngủ, nên đề nghị là read replica và cảnh báo do bạn nhận. Với trưởng nhóm bảo mật, đồng tiền là kiểm toán, nên đề nghị là tài khoản riêng và nhật ký truy cập.
Ví dụ giả định trong bài: cùng một yêu cầu truy cập, đề nghị đổi theo điều mỗi người coi trọng.

Thử hình dung tuần thứ hai của một deployment: code đã sẵn sàng, còn quyền đọc dữ liệu vẫn nằm trong hàng đợi của một DBA. Người đó không báo cáo cho bạn, cũng không báo cáo cho sếp bạn. Bạn không có quyền ra lệnh, và gửi thêm một lời nhắc cũng khó thay đổi được gì.

Influence Without Authority không viết riêng cho FDE, nhưng hiếm có cuốn sách nào gần tình huống đó đến vậy. Wiley, nhà xuất bản, gọi đây là cuốn hướng dẫn kinh điển để có được điều bạn cần từ những người bạn không kiểm soát.

Với FDE, đó là công việc hằng ngày chứ không phải kỹ năng mềm để dành cho sau này. Dự án của bạn phụ thuộc vào những người không nằm trong tổ chức của bạn, và cuốn sách cho bạn một cách suy nghĩ cụ thể về họ.

Hai tác giả viết cho một thế giới phẳng hơn

Allan R. Cohen là Distinguished Professor về lãnh đạo toàn cầu tại Babson College. David L. Bradford là Senior Lecturer Emeritus về hành vi tổ chức tại Stanford Graduate School of Business, từng điều hành Executive Program in Leadership của trường.

Ấn bản thứ ba ra năm 2017. Wiley đặt cuốn sách vào bối cảnh tổ chức ngày càng phẳng và dựa nhiều vào nhà thầu bên ngoài, nên muốn có kết quả phải hợp tác ngang hàng, thường xuyên qua biên giới, múi giờ và ranh giới tổ chức.

Câu đó gần như mô tả một FDE đang ngồi ở khách hàng. Thông cáo về ấn bản này cũng nói thẳng rằng mô hình dùng được khi tác động tới đồng nghiệp, cấp trên hoặc khách hàng.

Ý đầu tiên: đừng bắt đầu bằng câu hỏi “ai ép được họ?”

Quy trình của sách có sáu bước, và bước đầu là mặc định mọi người đều có thể trở thành đồng minh. Nghe như lời khuyên dễ chịu, nhưng nó đổi hẳn hành động tiếp theo của bạn.

Nếu DBA là vật cản, phản xạ tự nhiên là leo thang lên sponsor. Có thể bạn lấy được quyền, nhưng người sẽ trả lời bạn vào tuần sau vẫn là DBA đó. Nếu DBA là đồng minh tiềm năng, câu hỏi chuyển thành: người này đang cố làm tốt việc gì?

Leo thang đôi khi vẫn cần thiết, nhưng nên là lựa chọn sau cùng, sau khi bạn đã thực sự hiểu đối phương cần gì.

Ý thứ hai: đồng tiền thuộc về người nhận

Lõi của sách là Exchange Model: bạn có được điều mình cần bằng cách trao lại thứ có giá trị. Điều đối phương coi trọng chính là “đồng tiền” của họ, và theo cách Wiley diễn đạt, đó là công cụ trực tiếp để bạn giành được sự hợp tác của họ.

Quay lại ticket đang kẹt. Yêu cầu “cho tôi quyền đọc production để pipeline chạy được” chỉ nói về nhu cầu của bạn. Giả sử sau một buổi cà phê, bạn biết DBA sợ nhất là bị gọi dậy giữa đêm vì một truy vấn lạ làm chậm hệ thống.

Lúc này đề nghị đổi hẳn: dùng read replica thay vì bản chính, giới hạn 5 truy vấn đồng thời, chạy ngoài giờ cao điểm, cảnh báo từ các truy vấn này do bạn nhận, và quyền tự hết hạn sau 30 ngày. Bạn vẫn đọc được dữ liệu, còn DBA được đúng thứ họ cần: giấc ngủ.

Giờ thử gửi đúng đề nghị đó cho trưởng nhóm bảo mật. Giả sử người này coi trọng khả năng trả lời kiểm toán, thì giới hạn truy vấn chẳng nói lên nhiều. Thứ cần thêm là tài khoản riêng, nhật ký truy cập và danh sách bảng được phép đọc.

Vì thế, hành động đầu tiên tại khách hàng không phải là soạn yêu cầu. Hãy hỏi người đó điều gì khiến họ khó chịu nhất trong tuần, rồi chỉ viết đề nghị sau khi đã nghe câu trả lời.

Ý thứ ba: có đi có lại là chuyện của cả dự án

Mô hình dựa trên nguyên tắc mà giới khoa học xã hội gọi là Law of Reciprocity, luật có đi có lại. Trong quy trình sáu bước, nhận diện đồng tiền chỉ là bước thứ tư. Sau đó còn hai việc: lo cho mối quan hệ với người đó, rồi thuyết phục họ bằng những lần có đi có lại.

Thứ tự ấy đáng chú ý, vì đồng tiền không phải mẹo dùng một lần. Một FDE từng sửa giúp DBA một script sao lưu hay gặp lỗi sẽ không phải bắt đầu từ con số không khi cần xin quyền ở tuần thứ sáu.

Ở đây có một cái bẫy mà FDE nên tự cảnh giác: đừng trả bằng đồng tiền không phải của mình. Hứa một tính năng trên roadmap để đổi lấy quyền truy cập thì việc được mở khóa hôm nay, nhưng khoản nợ rơi vào đội product. Hãy trao những gì bạn tự làm được.

Đọc ấn bản nào, đọc thế nào?

Sách hợp nhất với kỹ sư đang làm FDE hoặc sắp chuyển từ vị trí SWE, nơi quyền lực trước nay đến từ việc code của bạn đúng. Ai đã nhiều năm dẫn dắt các dự án liên phòng ban có lẽ sẽ thấy nó quen, nhưng vẫn có ích như một bộ từ vựng để dạy lại cho đồng đội.

Hãy chọn ấn bản thứ ba. Ấn bản thứ hai cũng của Wiley, nhưng ấn bản mới có thêm ví dụ và nội dung về các nhóm làm việc từ xa, phân tán về địa lý. Nếu bạn làm với khách hàng khác múi giờ, chừng đó đã đủ lý do.

Cách đọc chỉ cần nhớ một việc: đi qua sáu bước theo đúng thứ tự của tác giả, vừa đọc vừa thử trên một ticket đang kẹt. Ở bước đầu, hãy viết tên người đang giữ ticket và coi họ là đồng minh tiềm năng trước khi đọc tiếp.

Tới bước thứ tư, dừng lại và viết ra đồng tiền của người đó. Hai bước cuối về mối quan hệ và chuyện có đi có lại sẽ dùng ngay câu trả lời ấy. Đọc xong mà chưa đổi được một email nào thì xem như chưa đọc.

Về sự nghiệp, kỹ năng này chỉ có giá trị khi bạn chứng minh được. Khi đọc JD, hãy để ý những dòng nói về làm việc với stakeholder hoặc tác động mà không có quyền quản lý trực tiếp. Trong CV, thay “giao tiếp tốt” bằng một câu cụ thể: bạn đã đề xuất gì với nhóm nào, để mở khóa bước nào của deployment.

Hãy chuẩn bị sẵn câu chuyện đó cho những câu hỏi phỏng vấn về xung đột với khách hàng. Lần tới khi một ticket nằm im, hãy khoan viết lời nhắc thứ tư và tự hỏi người ở đầu bên kia đang tiêu bằng đồng tiền nào.

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

Dùng cùng trợ lý AIHỏi Claude ↗Hỏi ChatGPT ↗
3 nguồn
Đọc tiếp trên lộ trình · Chặng 7: Dẫn dắtThe Product-Minded Engineer: cuốn sách của Drew Hoskins dạy FDE thiết kế cho người dùng thật của kháchMột kỹ sư đã chuyển sang làm product manager cho rằng thông báo lỗi có thể là giao diện quan trọng nhất của sản phẩm, và FDE nào từng trực sự cố ở chỗ khách cũng hiểu vì sao.