Mở đầu — vì sao bài này quan trọng
Có một sự thật phũ phàng mà mọi Technical PM đều phải đối mặt sớm hay muộn: bạn chịu trách nhiệm cho kết quả của sản phẩm, nhưng bạn gần như không có quyền lực chính thức nào để ra lệnh cho ai cả.
Hãy nghĩ kỹ về điều này. Engineer không phải là "lính" của bạn — họ report cho Engineering Manager, không phải cho bạn. Bạn không quyết định lương, thưởng, hay thăng chức của họ. Bạn không kiểm soát ngân sách, không quyết định headcount (số lượng nhân sự được tuyển), không thể "đuổi việc" ai. Designer, Data team, Security team, Legal — không ai trong số họ phải làm theo lời bạn chỉ vì bạn là PM.
Vậy mà cuối quý, khi sản phẩm chậm tiến độ hoặc ra sai hướng, người đầu tiên bị hỏi "tại sao" lại là bạn.
Đây chính là nghịch lý cốt lõi của nghề PM: trách nhiệm thì cao, nhưng quyền lực chính thức (authority) thì gần như bằng không. Cách duy nhất để bạn drive được outcome (đạt được kết quả) là thông qua ảnh hưởng (influence) — khả năng khiến người khác tự nguyện đi theo hướng bạn đề xuất, vì họ tin đó là hướng đúng, chứ không phải vì bị bắt buộc.
Với Technical PM, kỹ năng này còn khó hơn một bậc. Bạn phải gây ảnh hưởng lên những người thường giỏi kỹ thuật hơn bạn rất nhiều. Một engineer senior có 10 năm kinh nghiệm sẽ không bị thuyết phục bởi slide đẹp hay buzzword. Họ chỉ nghe khi bạn nói có logic, có dữ liệu, và quan trọng nhất — khi họ tin rằng bạn thực sự hiểu vấn đề. Bài này dạy bạn cách xây dựng và sử dụng thứ ảnh hưởng đó một cách có hệ thống.
Khái niệm cốt lõi
Influence là gì và khác gì với Authority
Authority (quyền lực chính thức) là quyền ra lệnh đến từ vị trí trong sơ đồ tổ chức. Sếp bảo nhân viên làm, nhân viên làm — đó là authority. Nó nhanh nhưng giòn: người ta làm vì sợ, không vì tin, và sẽ làm tối thiểu cho xong.
Influence (ảnh hưởng) là khả năng thay đổi hành vi và quyết định của người khác mà không cần ra lệnh. Nó chậm hơn để xây dựng, nhưng bền vững: khi người ta đồng thuận thật sự, họ làm với 120% tâm huyết.
PM sống bằng influence. Và influence không phải là tài năng bẩm sinh — nó là kỹ năng có thể luyện, dựa trên những "nguồn quyền lực" (sources of power) mà bạn chủ động tích lũy.
Các nguồn của Influence (Sources of Influence)
Nhà nghiên cứu French & Raven phân loại quyền lực thành nhiều dạng. Với Technical PM, năm nguồn dưới đây quan trọng nhất:
1. Expertise Power (quyền lực từ chuyên môn). Khi bạn thực sự hiểu kỹ thuật — đọc được pull request, hiểu trade-off giữa các kiến trúc, biết tại sao một API design lại tệ — engineer sẽ lắng nghe bạn. Đây là nguồn quan trọng nhất với Technical PM. Bạn không cần code giỏi bằng họ, nhưng bạn phải đủ hiểu để đối thoại ngang hàng.
2. Information Power (quyền lực từ thông tin). PM thường là người duy nhất nhìn thấy bức tranh toàn cảnh: dữ liệu khách hàng, định hướng kinh doanh, phản hồi từ sales, số liệu thị trường. Khi bạn mang thông tin mà người khác không có, bạn trở thành nguồn giá trị mà họ cần.
3. Relationship Power (quyền lực từ quan hệ). Niềm tin được xây qua thời gian. Một PM mà engineer tin tưởng — vì đã từng bảo vệ team trước áp lực, vì luôn nói thật, vì giữ lời hứa — sẽ được "cho qua" nhiều thứ mà PM lạ không bao giờ có được.
4. Reciprocity (quyền lực từ sự có đi có lại). Khi bạn giúp người khác trước — viết spec rõ ràng để engineer đỡ phải đoán, đứng ra chắn họp để họ tập trung code — họ sẽ có xu hướng giúp lại bạn. Đây là quy luật tâm lý mạnh mẽ.
5. Vision/Conviction Power (quyền lực từ tầm nhìn và niềm tin). Khi bạn vẽ ra được một bức tranh hấp dẫn về "tại sao việc này quan trọng", người ta đi theo vì cảm hứng. Đây là thứ phân biệt một PM bình thường với một PM mà cả team sẵn sàng "đi qua lửa" cùng.
Khung tư duy: Influence = Logic + Cảm xúc + Uy tín
Aristotle gọi ba yếu tố thuyết phục là Logos (logic), Pathos (cảm xúc) và Ethos (uy tín). Áp dụng vào Technical PM:
- Logos: dữ liệu, trade-off, con số ROI, benchmark. Engineer phản ứng mạnh nhất với phần này.
- Pathos: câu chuyện khách hàng đang đau đớn ra sao, hậu quả nếu không làm gì.
- Ethos: bạn là ai, bạn đã đúng bao nhiêu lần trước đó, bạn có trung thực không.
Tình huống thực tế
Tình huống 1 — PM thuyết phục team rời bỏ giải pháp "cây nhà lá vườn"
Mai là Technical PM tại một công ty fintech ở TP.HCM, khoảng 80 kỹ sư. Team Payments của cô đang tự xây một hệ thống chống gian lận (fraud detection) nội bộ, đã đầu tư 4 tháng. Mai nhìn dữ liệu và thấy: tỷ lệ phát hiện gian lận chỉ đạt 62%, trong khi một dịch vụ bên thứ ba như Sift đạt khoảng 91%, với chi phí khoảng 8.000 USD/tháng — rẻ hơn nhiều so với chi phí 3 kỹ sư đang dồn vào dự án.
Vấn đề: team đã đổ tâm huyết 4 tháng, và Tech Lead rất tự hào về hệ thống tự xây. Nếu Mai nói thẳng "bỏ đi, mua ngoài", cô sẽ tạo ra một cuộc chiến phòng thủ.
Cô đã làm gì. Thay vì ra "phán quyết", Mai dùng Information Power. Cô không tự đưa kết luận mà tổ chức một buổi review dữ liệu, để chính các con số tự nói. Cô đặt câu hỏi mở: "Nếu chúng ta giữ hướng hiện tại, mất bao lâu nữa để đạt 90%?" Tech Lead tự ước tính: ít nhất 8 tháng nữa. Mai để khoảng lặng, rồi hỏi tiếp: "8 tháng đó, nếu dồn vào tính năng cho vay trả góp mà sales đang cần, mình mở được bao nhiêu doanh thu?"
Cô không hề chê hệ thống của họ. Cô tái định khung (reframe) vấn đề từ "code của bạn tệ" thành "chi phí cơ hội của thời gian kỹ sư". Cuối buổi, chính Tech Lead là người đề xuất chuyển sang dùng dịch vụ ngoài và giữ lại lớp logic nghiệp vụ riêng của họ.
Bài học: Influence mạnh nhất khi bạn để người khác tự đi đến kết luận. Reframe vấn đề và dùng dữ liệu thay vì ý kiến cá nhân giúp bảo toàn cái tôi (ego) của đối phương.
Tình huống 2 — Gây ảnh hưởng lên một team mình không có chút quyền nào
Hùng là Technical PM cho Platform team tại một công ty thương mại điện tử (giả định kiểu Tiki/Lazada). Anh cần team Search — một team hoàn toàn khác, report cho một director khác — ưu tiên việc nâng cấp API search để Platform của anh tích hợp được. Vấn đề: team Search có backlog riêng dài dằng dặc, và yêu cầu của Hùng đứng thứ 14 trong danh sách ưu tiên của họ.
Hùng không có authority nào lên team Search. Nếu anh "leo thang" (escalate) lên sếp ngay từ đầu, anh sẽ bị xem là kẻ gây rối.
Anh đã làm gì. Đầu tiên, Hùng dùng Reciprocity. Anh hỏi PM của team Search: "Có việc gì Platform team mình giúp được không?" Hóa ra team Search đang khổ sở vì thiếu dữ liệu log chất lượng để cải thiện ranking. Platform của Hùng có sẵn pipeline đó. Anh đề nghị giúp họ trong 2 sprint.
Sau đó, anh dùng Vision Power: anh cho PM Search xem một con số — nếu API được nâng cấp, conversion từ search dự kiến tăng 1.2%, tương đương khoảng 18 tỷ đồng doanh thu/năm. Con số này không chỉ giúp Platform của Hùng, mà chính là OKR của team Search. Anh khéo léo cho họ thấy việc này phục vụ mục tiêu của chính họ, không phải của riêng anh.
Kết quả: yêu cầu nhảy từ vị trí 14 lên vị trí 3, và được làm trong quý sau. Không có một cuộc escalate nào.
Bài học: Khi không có authority, hãy tìm điểm giao thoa giữa mục tiêu của bạn và mục tiêu của họ. Cho trước (give first), rồi gắn yêu cầu của bạn vào thứ họ đã muốn.
Tình huống 3 — Khi influence thất bại và buộc phải escalate đúng cách
Linh là Technical PM tại một startup SaaS ở Singapore. Cô phát hiện một lỗ hổng bảo mật nghiêm trọng cần vá gấp, nhưng Tech Lead của team liên tục trì hoãn vì bận release tính năng. Linh đã thử mọi cách influence: dữ liệu về rủi ro, câu chuyện về các vụ rò rỉ dữ liệu, đề nghị giúp đỡ. Tech Lead vẫn không nhúc nhích.
Cô đã làm gì. Linh hiểu rằng influence có giới hạn, và đôi khi escalate là đúng — nhưng phải làm chuyên nghiệp. Cô không "méc sếp sau lưng". Cô nói thẳng với Tech Lead: "Mình tôn trọng quyết định ưu tiên của bạn, nhưng rủi ro này vượt thẩm quyền cả hai chúng ta. Mình sẽ đưa lên cuộc họp với Engineering Manager để hai bên cùng quyết, và mình muốn bạn có mặt để trình bày quan điểm." Cô escalate một cách minh bạch, có sự hiện diện của người kia, dựa trên rủi ro khách quan chứ không phải cảm tính.
EM sau khi nghe đã ưu tiên việc vá lỗi ngay.
Bài học: Influence không phải là "không bao giờ escalate". Escalate là một công cụ hợp lệ khi rủi ro lớn hơn quan hệ — nhưng phải làm công khai, tôn trọng, và để đối phương giữ thể diện. Escalate lén lút sẽ phá hủy Relationship Power của bạn mãi mãi.
Hướng dẫn từng bước
Khi bạn cần gây ảnh hưởng để đạt một outcome, hãy theo quy trình sau:
Bước 1 — Xác định rõ outcome, không phải output. Bạn muốn điều gì xảy ra? Viết ra một câu cụ thể. "Team đồng ý dùng API gateway thay vì tự build" thay vì mơ hồ "team hợp tác hơn".
Bước 2 — Lập bản đồ stakeholder. Ai là người ra quyết định? Ai là người ảnh hưởng đến người ra quyết định? Ai có thể cản trở? Với mỗi người, ghi rõ: mục tiêu của họ là gì, họ sợ gì, họ đo lường thành công bằng gì.
Bước 3 — Chọn nguồn influence phù hợp. Với người trọng dữ liệu, dùng Expertise và Information Power. Với người trọng quan hệ, đầu tư Relationship trước. Với người bận rộn, dùng Reciprocity.
Bước 4 — Tìm điểm giao thoa lợi ích. Đóng khung đề xuất của bạn theo cách phục vụ mục tiêu của họ. Câu thần chú: "Việc này giúp gì cho điều bạn đang quan tâm?"
Bước 5 — Chuẩn bị bằng chứng. Gom dữ liệu, benchmark, câu chuyện khách hàng. Engineer cần Logos, leadership cần cả Pathos về tác động kinh doanh.
Bước 6 — Influence riêng trước, công khai sau. Trao đổi 1-1 với từng stakeholder quan trọng trước cuộc họp chung. Không bao giờ để ai bị bất ngờ ("no surprises") trong phòng họp. Vào họp khi đa số đã đồng thuận ngầm.
Bước 7 — Để họ tự kết luận. Đặt câu hỏi dẫn dắt thay vì áp đặt. Một quyết định mà người ta tự nghĩ ra sẽ được bảo vệ nhiệt tình hơn nhiều.
Bước 8 — Theo dõi và ghi nhận. Sau khi đạt đồng thuận, công khai ghi công cho những người đã ủng hộ. Điều này nuôi dưỡng Relationship Power cho lần sau.
Lỗi thường gặp & mẹo
Lỗi 1: Dựa vào chức danh. "Tôi là PM nên team phải nghe tôi." Sai. Chức danh PM gần như không mang authority. Càng cố dùng "uy" PM, bạn càng mất influence.
Lỗi 2: Chỉ dùng logic, bỏ qua quan hệ. Nhiều Technical PM nghĩ lập luận đúng là đủ. Nhưng con người không phải máy tính. Nếu họ không tin bạn (thiếu Ethos), lập luận đúng vẫn bị từ chối.
Lỗi 3: Đẩy mọi việc bằng escalate. Mỗi lần bạn "méc sếp" là một lần bạn rút khỏi tài khoản quan hệ. Escalate quá nhiều và bạn sẽ bị cô lập. Để dành nó cho những vấn đề thực sự lớn.
Lỗi 4: Thắng cuộc tranh luận, thua cuộc chiến. Làm đối phương "mất mặt" trong họp có thể giúp bạn thắng lúc đó, nhưng họ sẽ ngầm phá bạn sau này. Luôn để người khác giữ thể diện.
Lỗi 5: Không đầu tư quan hệ khi chưa cần. Đừng đợi đến lúc cần gì mới đi xây quan hệ. Relationship Power phải tích lũy trước, như tiền gửi ngân hàng, để khi khủng hoảng bạn có cái mà rút.
Mẹo hữu ích:
- Học đủ kỹ thuật để đối thoại ngang hàng với engineer — đây là Expertise Power, nền tảng của Technical PM.
- Luôn giữ lời hứa nhỏ. Uy tín được xây từ trăm việc nhỏ, mất trong một lần thất hứa.
- Cho trước rồi nhận sau. Giúp người khác khi họ chưa cần đáp lại.
- Dùng "chúng ta" thay vì "tôi muốn các bạn". Ngôn ngữ đồng đội tạo cảm giác cùng phe.
- Khi bất đồng, hỏi "Mình đang thiếu thông tin gì khiến bạn thấy hướng này không ổn?" — biến tranh cãi thành cùng giải quyết vấn đề.
Bài tập thực hành
Bài tập 1 — Bản đồ nguồn lực của bạn. Liệt kê 5 stakeholder bạn thường làm việc cùng (engineer, EM, designer, data, security...). Với mỗi người, chấm điểm 1–5 cho từng nguồn influence bạn đang có với họ: Expertise, Information, Relationship, Reciprocity, Vision. Nguồn nào bạn yếu nhất? Lập kế hoạch cải thiện trong 30 ngày.
Bài tập 2 — Reframe một xung đột. Nhớ lại một lần gần đây bạn không thuyết phục được ai đó. Viết lại lập luận của bạn dưới góc nhìn mục tiêu của họ: đề xuất của bạn phục vụ điều họ quan tâm như thế nào? So sánh hai cách diễn đạt.
Bài tập 3 — Kịch bản pre-wire. Chọn một quyết định kỹ thuật bạn sắp cần team đồng thuận. Viết ra: bạn sẽ nói chuyện riêng (1-1) với ai trước cuộc họp chung, và sẽ nói gì với từng người để vào họp không ai bị bất ngờ.
Bài tập 4 — Phân tích escalation. Nhớ lại một lần bạn (hoặc đồng nghiệp) escalate. Đánh giá: nó có công khai và tôn trọng không? Đối phương có được giữ thể diện không? Nếu làm lại, bạn sẽ làm khác thế nào?
Tóm tắt
- Technical PM chịu trách nhiệm cho outcome nhưng gần như không có authority chính thức: không phải sếp của engineer, không kiểm soát ngân sách hay headcount.
- Cách duy nhất để drive kết quả là influence — khiến người khác tự nguyện đi theo vì họ tin, không vì bị ép.
- Năm nguồn influence quan trọng: Expertise (chuyên môn — nền tảng của Technical PM), Information (thông tin toàn cảnh), Relationship (niềm tin tích lũy), Reciprocity (cho trước nhận sau), và Vision (tầm nhìn truyền cảm hứng).
- Thuyết phục cần cả ba: Logic (Logos), Cảm xúc (Pathos) và Uy tín (Ethos). Chỉ dùng logic là sai lầm kinh điển của PM kỹ thuật.
- Quy trình: xác định outcome → lập bản đồ stakeholder → chọn nguồn influence → tìm điểm giao thoa lợi ích → chuẩn bị bằng chứng → influence riêng trước công khai sau → để họ tự kết luận.
- Escalate là công cụ hợp lệ nhưng phải dùng tiết kiệm, công khai, tôn trọng và giữ thể diện cho đối phương.
- Trên hết: đầu tư quan hệ và uy tín trước khi bạn cần, như gửi tiết kiệm để dành lúc khủng hoảng.