Mở đầu — vì sao bài này quan trọng
Có một sự thật khiến nhiều PM mới vào nghề bị sốc: bạn chịu trách nhiệm cho thành công của sản phẩm, nhưng bạn không có quyền ra lệnh cho bất kỳ ai trong nhóm xây dựng sản phẩm đó. Engineer report cho Engineering Manager. Designer report cho Design Lead. QA report cho QA Lead. Còn bạn — PM — đứng ở giữa, với một bản roadmap, một danh sách yêu cầu, và đúng… zero người báo cáo trực tiếp cho mình.
Đây chính là nghịch lý "managing down without authority" (quản lý xuống dưới mà không có thẩm quyền). Trong sơ đồ tổ chức, PM thường nằm ngang hàng — hoặc thậm chí thấp hơn — so với những người mà họ cần dẫn dắt. Khi engineer nói "việc này tôi không làm kịp sprint này", bạn không thể đáp "Tôi là sếp anh, anh phải làm". Bởi vì bạn không phải sếp họ. Và đó mới là điều thú vị: những PM giỏi nhất mà tôi từng làm việc cùng đều không cần đến chiếc gậy quyền lực đó. Họ khiến cả nhóm đi theo mình vì nhóm muốn đi theo, chứ không phải vì sơ đồ tổ chức bắt buộc.
Bài này tập trung hẹp vào một câu hỏi: làm sao để một PM tạo ảnh hưởng và dẫn dắt nhóm thực thi (engineer, designer, QA, data) khi những người đó không report cho mình? Đây không phải bài về quản lý sếp (đó là Bài 33), không phải về làm việc với PM ngang hàng (Bài 35), cũng không phải về kỹ thuật thuyết phục stakeholder cấp cao (Bài 02, 17). Đây là chuyện hằng ngày, trong standup, trong sprint planning, trong những tin nhắn Slack lúc 9 giờ tối khi deadline cận kề.
Khái niệm cốt lõi
Responsibility without authority — gốc rễ của vấn đề
PM sống trong trạng thái "trách nhiệm không đi kèm thẩm quyền". Bạn bị đánh giá dựa trên việc sản phẩm có ra đúng hạn, đúng chất lượng, đạt mục tiêu kinh doanh hay không. Nhưng những đòn bẩy trực tiếp để tạo ra điều đó — phân bổ thời gian của engineer, quyết định ưu tiên kỹ thuật, duyệt nghỉ phép — lại nằm trong tay functional manager. Bạn chỉ có "dotted-line" (đường nét đứt) tới nhóm, trong khi functional manager có "solid-line" (đường nét liền).
Hệ quả là nếu bạn cố quản lý nhóm bằng tư duy "command and control" (ra lệnh và kiểm soát), bạn sẽ thất bại nhanh chóng. Engineer sẽ ngầm kháng cự, làm đúng chữ nhưng không đúng tinh thần, và bạn mất đi thứ quý giá nhất: sự tự nguyện cống hiến của họ.
Bốn nguồn ảnh hưởng thay thế cho quyền lực
Khi không có quyền lực vị trí (positional power), PM phải xây dựng ảnh hưởng từ những nguồn khác. Tôi gom thành bốn loại:
- Expertise power (quyền lực từ chuyên môn): Nhóm tin tưởng vì bạn thực sự hiểu thị trường, hiểu khách hàng, hiểu vấn đề sâu hơn họ. Khi bạn nói "khách hàng cần cái này", họ không cãi vì bạn có data và insight để chứng minh.
- Information power (quyền lực từ thông tin): PM thường là người duy nhất nhìn được bức tranh toàn cảnh — vì sao công ty đầu tư vào tính năng này, đối thủ đang làm gì, doanh thu phụ thuộc ra sao. Chia sẻ context này biến bạn thành nguồn "why" mà nhóm cần.
- Relationship power (quyền lực từ quan hệ): Người ta giúp người mà họ quý mến và tin tưởng. Một PM xây được quan hệ thật với engineer sẽ nhận được sự nỗ lực vượt mức trong những lúc khó khăn.
- Reciprocity power (quyền lực từ có đi có lại): Khi bạn gỡ rào cản, che chắn cho nhóm khỏi yêu cầu vớ vẩn từ bên ngoài, đấu tranh để họ có thời gian trả nợ kỹ thuật — bạn tạo ra "tài khoản tín dụng" mà sau này nhóm sẽ trả lại bằng sự hợp tác.
Từ "cái gì" và "khi nào" sang "tại sao"
Sai lầm lớn nhất của PM yếu là chỉ giao "cái gì làm" và "khi nào xong". Engineer giỏi ghét bị đối xử như cái máy nhận lệnh. Vũ khí ảnh hưởng mạnh nhất của PM là làm chủ phần "tại sao". Khi nhóm hiểu rõ vì sao một việc quan trọng — nó giải quyết nỗi đau gì của khách hàng, gắn với mục tiêu kinh doanh nào — họ sẽ tự tìm ra cách làm tốt nhất, thường tốt hơn cả những gì bạn nghĩ ra. Bạn quản lý "outcome" (kết quả mong muốn), để nhóm tự chủ "output" (cách thực hiện).
Đồng minh quan trọng nhất: functional manager
Một sai lầm tinh tế là PM cố gắng "đi vòng" qua functional manager để gây ảnh hưởng trực tiếp lên engineer. Điều này phá vỡ lòng tin. PM khôn ngoan coi Engineering Manager, Design Lead là đối tác đồng minh, không phải đối thủ tranh giành ảnh hưởng. Bạn cùng họ căn chỉnh ưu tiên; họ lo "ai làm, làm thế nào về mặt kỹ thuật", bạn lo "làm gì, vì sao". Khi hai người này đồng thuận, nhóm sẽ đi theo rất tự nhiên.
Tình huống thực tế
Ví dụ 1 — PM mới ở một fintech tại TP.HCM và bài học "gánh việc trước"
Minh, một PM vừa chuyển từ công ty khác sang một startup fintech khoảng 60 người ở Quận 1, được giao tính năng "thanh toán hóa đơn điện nước" trong app ví điện tử. Nhóm của Minh có 4 engineer và 1 designer, tất cả đều report cho Trưởng phòng Kỹ thuật, không ai report cho Minh.
Tuần đầu, Minh đưa một bản spec dày 12 trang vào sprint planning và nói "Mình cần xong cái này trong 2 sprint". Tech Lead tên Tuấn nhìn lướt qua rồi đáp gọn: "Spec này có nhiều chỗ không khả thi với hạ tầng hiện tại. Để bọn mình xem đã." Hai sprint sau, tính năng vẫn nằm im. Minh bực bội, nhưng nhận ra mình đã sai cách tiếp cận.
Minh đổi chiến lược. Anh dành một tuần ngồi cạnh nhóm, hỏi Tuấn "Hệ thống thanh toán hiện tại vướng ở đâu? Mình muốn hiểu để spec sát thực tế hơn". Anh phát hiện nhóm đang khổ vì một đoạn code tích hợp với nhà cung cấp cổng thanh toán cũ kỹ, hay lỗi timeout. Thay vì ép tiến độ, Minh đi đấu tranh với CEO để dời một tính năng marketing ít quan trọng, giải phóng thời gian cho nhóm xử lý nợ kỹ thuật đó trước.
Khi Minh "gánh việc" giúp nhóm — bảo vệ họ khỏi áp lực bên ngoài, ưu tiên thứ họ thực sự cần — thái độ của Tuấn thay đổi hẳn. Đến sprint sau, chính Tuấn chủ động đề xuất cách rút gọn phạm vi để ra mắt sớm phiên bản thử nghiệm cho 500 người dùng. Tính năng lên sóng sau 5 tuần.
Bài học: Ảnh hưởng đến từ reciprocity. Minh không có quyền ra lệnh, nhưng khi anh chứng minh mình đứng về phía nhóm và gỡ rào cản cho họ, nhóm trả lại bằng sự hợp tác tự nguyện. "Tài khoản tín dụng quan hệ" được nạp trước, rồi mới rút ra sau.
Ví dụ 2 — Designer "biến mất" và sức mạnh của phần "tại sao"
Tại một công ty thương mại điện tử ở Singapore phục vụ thị trường Đông Nam Á, PM tên Hoa làm việc với một product designer tên Raj. Raj giỏi nhưng hay tự ý thiết kế theo ý mình, bỏ qua yêu cầu của Hoa, dẫn đến nhiều vòng làm lại tốn thời gian. Hoa từng nghĩ vấn đề là Raj "khó bảo".
Trong một buổi 1-on-1 không chính thức bên ly cà phê, Hoa hỏi thẳng: "Em thấy mình giao việc kiểu gì khiến anh thấy khó chịu?" Raj thành thật: "Em toàn đưa anh giải pháp đã chốt sẵn — 'làm cái nút ở đây, màn hình kiểu này'. Anh không hiểu vì sao, nên anh thấy nhàm và muốn làm theo cách của anh."
Hoa thay đổi cách giao việc. Thay vì nói "thiết kế màn hình checkout có 3 bước", cô kể: "Data cho thấy 38% người dùng bỏ giỏ hàng ở bước nhập địa chỉ, và phần lớn là người dùng ở Indonesia điền địa chỉ rất dài. Vấn đề cần giải là giảm ma sát ở bước này. Anh nghĩ sao?" Raj lập tức hào hứng, đưa ra ba phương án mà Hoa chưa từng nghĩ tới, trong đó có ý tưởng dùng định vị bản đồ để tự điền địa chỉ. Tỷ lệ bỏ giỏ hàng giảm 11% sau khi ra mắt.
Bài học: Khi PM làm chủ phần "tại sao" và trao quyền tự chủ về "cách làm", người không report cho bạn vẫn dồn hết năng lực sáng tạo vào bài toán. Quản lý outcome, đừng quản lý từng pixel.
Ví dụ 3 — Đi vòng qua manager và cái giá phải trả
Một PM tên Khanh tại một công ty SaaS ở Hà Nội gặp deadline gấp. Một engineer tên Phong đang bận task khác, nên Khanh nhắn riêng Phong qua Slack: "Anh ưu tiên giúp em cái này trước nhé, gấp lắm" — mà không hề trao đổi với Engineering Manager là chị Lan, người đã sắp xếp công việc cho Phong. Phong nể nên làm, nhưng task gốc bị trễ. Chị Lan phát hiện, và từ đó mất lòng tin vào Khanh, bắt đầu kiểm soát chặt mọi yêu cầu của Khanh tới nhóm, khiến mọi thứ chậm lại gấp đôi.
Khanh học được bài học đắt giá. Lần sau, khi cần Phong ưu tiên việc gấp, Khanh đến gặp chị Lan trước: "Em có một việc khá gấp liên quan khách hàng lớn. Chị xem có thể sắp xếp ai đó, hay đổi thứ tự ưu tiên trong tuần này không?" Chị Lan, được tôn trọng vai trò, lập tức hỗ trợ và còn chủ động đề xuất giải pháp.
Bài học: Functional manager là đồng minh, không phải vật cản. Đi vòng qua họ có thể được việc một lần, nhưng phá hủy lòng tin dài hạn — thứ đắt hơn nhiều so với một deadline.
Hướng dẫn từng bước
Đây là quy trình để xây dựng và vận hành ảnh hưởng "xuống dưới" mà không cần quyền lực vị trí:
Bước 1 — Lập bản đồ "ai báo cáo cho ai". Ngay khi join nhóm, vẽ rõ: engineer/designer/QA report cho functional manager nào. Xác định ai là đồng minh chiến lược (thường là Engineering Manager, Tech Lead, Design Lead). Đây là những người bạn cần kết đôi cùng, không phải vượt mặt.
Bước 2 — Đầu tư xây quan hệ trước khi cần đến nó. Đừng đợi đến lúc khủng hoảng mới làm quen. Dành thời gian hiểu từng người: họ quan tâm điều gì trong sự nghiệp, họ ghét kiểu làm việc nào, điều gì khiến họ tự hào. Quan hệ là tài khoản phải nạp trước khi rút.
Bước 3 — Trở thành nguồn "tại sao" đáng tin. Trong mọi yêu cầu, luôn giải thích context: vấn đề khách hàng, mục tiêu kinh doanh, dữ liệu hỗ trợ. Đừng bao giờ giao việc kiểu "vì sếp muốn". Làm chủ phần "tại sao" tốt đến mức nhóm tìm đến bạn để hiểu bức tranh lớn.
Bước 4 — Giao outcome, không giao giải pháp. Mô tả vấn đề cần giải và tiêu chí thành công, rồi để nhóm tự chọn cách. Điều này vừa tôn trọng chuyên môn của họ, vừa thường cho ra giải pháp tốt hơn.
Bước 5 — Gỡ rào cản chủ động (servant leadership). Vai trò lớn nhất của bạn là làm "lá chắn": chặn những yêu cầu vô lý từ bên ngoài, đấu tranh để nhóm có thời gian, giải quyết blocker trước khi nhóm phải hỏi. Khi nhóm thấy bạn liên tục làm cuộc sống họ dễ hơn, họ sẽ theo bạn.
Bước 6 — Đồng bộ ưu tiên với functional manager đều đặn. Họp định kỳ với Engineering Manager / Design Lead để căn chỉnh roadmap với năng lực thực tế của nhóm. Khi cần điều phối con người hay đổi ưu tiên, luôn đi qua họ, không đi vòng.
Bước 7 — Ghi nhận công khai, sửa lỗi riêng tư. Khen nhóm trước mặt lãnh đạo, nhận trách nhiệm khi mọi thứ hỏng. PM giành công về mình sẽ mất nhóm chỉ sau một lần.
Lỗi thường gặp & mẹo
Lỗi 1 — Dùng quyền lực không tồn tại. Câu "Tôi là PM nên việc này phải làm" lập tức biến bạn thành kẻ thù. Bạn không có thẩm quyền đó, và việc giả vờ có chỉ bộc lộ sự non nớt. Mẹo: thay "phải làm" bằng "đây là vì sao việc này quan trọng — mình cùng tìm cách nhé".
Lỗi 2 — Đi vòng qua functional manager. Như ví dụ của Khanh — được việc trước mắt, mất lòng tin lâu dài. Mẹo: coi functional manager là đối tác đồng cấp; mọi điều phối con người đều thông qua họ.
Lỗi 3 — Giao "cái gì" mà quên "tại sao". Đối xử với engineer như công nhân dây chuyền giết chết động lực. Mẹo: mỗi yêu cầu kèm một câu "vấn đề khách hàng đằng sau là…".
Lỗi 4 — Chỉ xuất hiện khi cần việc. PM chỉ ló mặt lúc deadline để giục giã sẽ bị nhóm xem là "kẻ chuyên lấy". Mẹo: xây dựng quan hệ và gỡ rào cản trong những lúc bình thường, không chỉ lúc khủng hoảng.
Lỗi 5 — Micromanage cách làm. Săm soi từng dòng code, từng pixel khiến chuyên gia thấy bị xúc phạm. Mẹo: định nghĩa rõ "thế nào là thành công", rồi lùi lại.
Lỗi 6 — Nhận công, đổ lỗi. Mẹo: công khai khen nhóm, riêng tư nhận lỗi. Đây là cách rẻ nhất để mua lòng trung thành.
Mẹo nâng cao: Khi nhóm phản đối một yêu cầu, đừng coi đó là chống đối. Thường engineer thấy một rủi ro kỹ thuật mà bạn không thấy. Hỏi "Anh lo ngại điều gì?" thay vì "Sao không làm được?". Sự phản đối có chất lượng là dấu hiệu của một nhóm khỏe mạnh, và lắng nghe nó chính là cách bạn xây expertise của họ thành sức mạnh chung.
Bài tập thực hành
- Vẽ bản đồ báo cáo của nhóm bạn. Liệt kê mọi người trong nhóm thực thi sản phẩm của bạn và functional manager của họ. Khoanh tròn 2–3 người là "đồng minh chiến lược" mà bạn cần đầu tư quan hệ nhất. Viết một câu cho mỗi người: "Điều người này quan tâm nhất trong công việc là gì?" Nếu chưa trả lời được, đó là việc cần làm tuần tới.
- Viết lại một yêu cầu theo kiểu "outcome + tại sao". Lấy một task gần đây bạn đã giao kiểu "làm X". Viết lại thành: vấn đề khách hàng/kinh doanh là gì, tiêu chí thành công là gì, và bỏ ngỏ phần cách làm cho nhóm. So sánh hai phiên bản.
- Kiểm toán "tài khoản quan hệ". Trong 4 tuần qua, bạn đã lấy bao nhiêu lần (giục việc, yêu cầu gấp) so với cho bao nhiêu lần (gỡ blocker, che chắn, đấu tranh giành thời gian cho nhóm)? Nếu tỷ lệ lệch về phía "lấy", lên kế hoạch ít nhất 2 hành động "cho" trong tuần tới.
- Diễn tập tình huống đi vòng. Tưởng tượng bạn cần một engineer ưu tiên việc gấp nhưng họ đang bận. Viết ra hai kịch bản: (a) nhắn thẳng engineer, (b) trao đổi với functional manager trước. Ghi ra hậu quả ngắn hạn và dài hạn của mỗi cách.
Tóm tắt
Managing down without authority là kỹ năng sống còn của PM, bởi bạn chịu trách nhiệm cho sản phẩm nhưng không ai trong nhóm xây dựng nó report cho bạn. Quyền lực vị trí không có, nên bạn phải xây ảnh hưởng từ bốn nguồn khác: chuyên môn, thông tin, quan hệ và có-đi-có-lại. Vũ khí mạnh nhất là làm chủ phần "tại sao" — giao outcome thay vì áp đặt giải pháp, để chuyên gia tự do phát huy. Functional manager (Engineering Manager, Design Lead) là đồng minh quan trọng nhất, không bao giờ được đi vòng qua họ. Và nguyên tắc nền tảng: nạp đầy "tài khoản quan hệ" bằng cách phục vụ và gỡ rào cản cho nhóm trước, rồi mới rút ra khi cần. PM giỏi không khiến nhóm đi theo vì sơ đồ tổ chức — họ khiến nhóm muốn đi theo.