Mở đầu — vì sao bài này quan trọng
Có một sự thật phũ phàng mà nhiều Tech Lead (TL) mất vài tháng đầu mới thấm: bạn phải chịu trách nhiệm cho kết quả kỹ thuật của cả team, nhưng bạn gần như không có quyền ra lệnh cho ai cả. Không giống Engineering Manager (EM) — người nắm quyền đánh giá lương thưởng, thăng tiến, thậm chí quyết định giữ hay cho ai đó nghỉ — TL đứng ở một vị trí lạ lùng: trách nhiệm cao, quyền lực chính thức (positional authority) thấp.
Ngay cả những người trong team mà bạn nghĩ là "cấp dưới" của mình, trên thực tế thường dual-report: họ báo cáo về mặt con người, sự nghiệp, lương thưởng cho EM, còn TL chỉ dẫn dắt họ về mặt kỹ thuật. Chưa kể những người bạn cần tác động lại chẳng nằm trong team bạn tí nào: một kỹ sư ở team hạ tầng đang chặn API bạn cần, một Product Manager (PM) muốn nhồi thêm feature vào sprint, một kiến trúc sư nền tảng ở tổng công ty không chịu duyệt thiết kế của bạn.
Vì thế, kỹ năng sống còn của TL không phải là "ra lệnh" mà là influence without authority — gây ảnh hưởng mà không cần quyền lực chính thức. Đây chính là thứ phân biệt một TL được cả tổ chức tin tưởng đi theo với một TL suốt ngày phải "leo thang" (escalate) lên sếp để nhờ ép người khác. Bài này sẽ mổ xẻ cơ chế của ảnh hưởng, và cho bạn một bộ công cụ thực tế để áp dụng ngay từ tuần sau.
Khái niệm cốt lõi
Authority vs Influence — hai loại "sức mạnh" khác nhau
Authority (quyền lực chính thức) đến từ vị trí trong sơ đồ tổ chức. Nó cho phép bạn nói "hãy làm việc này" và người ta làm vì họ phải làm — nếu không sẽ có hậu quả về lương, đánh giá, công việc. Authority có giới hạn cứng: nó chỉ tác động được xuống những người báo cáo trực tiếp cho bạn.
Influence (ảnh hưởng) khiến người khác làm theo vì họ muốn — họ tin bạn đúng, tin điều đó tốt cho họ, hoặc tin tưởng con người bạn. Influence không có ranh giới sơ đồ tổ chức: bạn có thể tác động lên người ngang cấp, người ở team khác, thậm chí cả sếp của sếp bạn.
TL vận hành gần như hoàn toàn bằng influence. Điều nghịch lý là: influence bền vững hơn authority. Người làm vì bị ép sẽ làm mức tối thiểu; người làm vì được thuyết phục sẽ chủ động, sáng tạo, và đi xa hơn yêu cầu.
Ba nguồn gốc của ảnh hưởng
Ảnh hưởng của một TL thường đến từ ba nguồn, và bạn nên đầu tư cả ba:
1. Uy tín kỹ thuật (technical credibility). Người ta nghe bạn vì họ tin bạn giỏi và phán đoán kỹ thuật của bạn đáng tin. Đây là nền móng. Một TL viết code cẩu thả, đưa ra quyết định kiến trúc sai vài lần sẽ mất sạch tiếng nói. Nhưng lưu ý: uy tín kỹ thuật là điều kiện cần, không phải điều kiện đủ. Rất nhiều kỹ sư giỏi nhất phòng vẫn không influence được ai vì họ thiếu hai nguồn còn lại.
2. Quan hệ và niềm tin (relational trust). Người ta nghe bạn vì họ tin con người bạn — bạn công bằng, bạn giữ lời, bạn quan tâm đến lợi ích của họ chứ không chỉ của bạn. Niềm tin được xây từ hàng trăm tương tác nhỏ: bạn có giúp họ khi họ kẹt không, bạn có ghi công cho họ không, bạn có thừa nhận khi bạn sai không.
3. Hiểu bối cảnh và động lực của người khác (empathy & context). Người ta nghe bạn vì bạn hiểu họ đang cần gì. Một đề xuất được đóng gói theo góc nhìn "điều này giúp bạn đạt mục tiêu của bạn" luôn mạnh hơn "điều này tốt cho hệ thống của tôi".
Nguyên tắc "trao đổi" (currency) của Cohen & Bradford
Một khung tư duy kinh điển về influence without authority là mô hình "reciprocity" (có đi có lại) của Allan Cohen và David Bradford. Ý tưởng: mọi tổ chức vận hành trên một nền kinh tế ngầm của các "đồng tiền" (currencies) — những thứ có giá trị mà người ta trao đổi cho nhau. Bạn không thể ép người khác, nhưng bạn có thể trao cho họ thứ họ cần, và nhờ đó tạo ra "món nợ" thiện chí.
Các loại "currency" phổ biến trong môi trường kỹ thuật:
- Inspiration currency: cho người ta thấy công việc của họ có ý nghĩa lớn hơn, gắn với một tầm nhìn.
- Task currency: giúp họ hoàn thành việc, chia sẻ nguồn lực, gỡ blocker cho họ.
- Position currency: giúp họ được nhìn nhận, được lộ diện trước lãnh đạo, được ghi công.
- Relationship currency: sự thấu hiểu, ủng hộ, tình đồng đội.
- Personal currency: giúp họ học được kỹ năng mới, phát triển sự nghiệp.
Tình huống thực tế
Ví dụ 1: TL và team hạ tầng đang chặn dự án (bối cảnh một fintech tại TP.HCM)
Minh là TL của team Payments ở một công ty fintech khoảng 150 người tại Sài Gòn. Sprint của team Minh phụ thuộc vào một API mới từ team Platform. Team Platform không báo cáo cho Minh, sếp của họ ngang cấp với sếp Minh, và họ đang bận với ưu tiên riêng. API bị hoãn ba tuần liền.
Phản ứng đầu tiên (sai) của nhiều TL là leo thang: "Anh ơi, team Platform đang chặn tụi em, anh nói với sếp bên đó giúp em." Cách này đôi khi hiệu quả một lần, nhưng nó đốt cháy quan hệ và biến bạn thành người "hay mách sếp".
Minh làm khác. Anh hẹn cà phê với Tuấn — TL bên Platform. Thay vì đòi hỏi, Minh hỏi: "Ưu tiên của team anh quý này là gì? Đâu là thứ đang làm anh đau đầu nhất?" Hóa ra Platform đang bị áp lực giảm số lượng incident on-call. Minh nhận ra API mà anh cần thực ra sẽ thay thế một endpoint cũ đang gây phần lớn incident cho Platform. Anh đóng gói lại đề xuất: "Nếu tụi em cùng anh ưu tiên API này lên, nó sẽ dọn luôn cái endpoint cũ đang khiến team anh bị gọi dậy lúc 2h sáng." Minh còn đề nghị team mình gánh việc migration cho các consumer cũ.
Kết quả: API được ưu tiên trong sprint kế tiếp. Bài học: ảnh hưởng bắt đầu bằng việc hiểu currency của phía bên kia. Minh không ép Tuấn — anh chỉ ra rằng việc anh cần cũng chính là thứ giải quyết nỗi đau của Tuấn. Đề xuất được đóng khung theo lợi ích của họ, không phải của mình.
Ví dụ 2: Thuyết phục một senior engineer bảo thủ (bối cảnh một startup e-commerce)
Lan là TL mới được đề bạt trong một startup thương mại điện tử ở Hà Nội. Trong team có anh Đức — senior engineer kỳ cựu, viết phần lớn hệ thống cũ, và cực kỳ phản đối việc chuyển sang kiến trúc mới mà Lan đề xuất. Đức không báo cáo cho Lan; cả hai đều báo cáo cho cùng một EM. Nếu Lan dùng "quyền" ép Đức, cô sẽ thua ngay — vì cô còn không có quyền đó, và vì cô sẽ mất một trong những người quan trọng nhất team.
Lan chọn cách xây niềm tin trước. Trong hai tuần, cô ngồi cạnh Đức, thật sự lắng nghe những lo ngại của anh — phần lớn là hợp lý: rủi ro downtime khi migrate, chi phí đào tạo team, những edge case mà chỉ Đức biết vì anh đã sống với hệ thống ba năm. Thay vì bác bỏ, Lan ghi nhận và mời Đức đồng thiết kế bản kế hoạch migration. Cô để Đức làm người phản biện chính (devil's advocate) và ghi công công khai cho những rủi ro mà anh phát hiện.
Đến buổi trình bày với ban lãnh đạo, chính Đức là người đứng lên bảo vệ kiến trúc mới — vì lúc này nó đã có dấu ấn của anh trong đó. Bài học: người ta ủng hộ thứ họ tham gia xây dựng (people support what they help create). Đối kháng thường không phải vì người ta ngu, mà vì họ nắm bối cảnh bạn chưa thấy, hoặc vì họ sợ mất vị thế. Biến người phản đối mạnh nhất thành đồng tác giả là đòn influence mạnh nhất.
Ví dụ 3: Nói "không" với PM mà vẫn giữ quan hệ
Trong một team ở công ty giao đồ ăn tại Đông Nam Á, TL tên Hùng liên tục bị PM đẩy thêm feature vào mỗi sprint, khiến tech debt chồng chất và team kiệt sức. Hùng không có quyền phủ quyết PM — họ ngang cấp, cùng nhắm một mục tiêu chung là sản phẩm thành công.
Thay vì nói "không, tụi em không làm kịp" (tạo thế đối đầu), Hùng đổi ngôn ngữ sang thế đánh đổi (trade-off): "Em làm được feature này trong sprint tới. Nhưng để làm, mình phải hoãn việc dọn hệ thống thanh toán, và rủi ro là tỷ lệ lỗi checkout sẽ giữ ở mức 2% thay vì giảm về 0.5% như mục tiêu quý. Anh muốn ưu tiên cái nào?" Anh còn chuẩn bị dữ liệu: mỗi 0.1% lỗi checkout tương đương khoảng bao nhiêu đơn hàng thất bại mỗi ngày.
PM, khi thấy con số và được trao quyền quyết định, đã tự chọn lùi feature lại. Bài học: influence không phải là luôn nói "có", cũng không phải là nói "không" cứng nhắc. Nó là làm cho cái giá của mỗi lựa chọn trở nên rõ ràng, rồi để người kia sở hữu quyết định. Dữ liệu là một loại currency cực mạnh với các stakeholder không rành kỹ thuật.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng mỗi khi cần tác động lên một người/nhóm mà bạn không có quyền chỉ đạo:
Bước 1 — Xác định rõ bạn cần gì và của ai. Viết ra một câu: "Tôi cần [ai] làm [gì] trước [khi nào]." Càng cụ thể càng tốt. Mơ hồ về mục tiêu là lý do số một khiến các nỗ lực influence thất bại.
Bước 2 — Tìm hiểu currency và động lực của người đó. Họ đang bị đo lường bằng chỉ số gì? Điều gì làm họ được thăng tiến? Nỗi đau lớn nhất của họ hiện tại là gì? Nếu không biết, hãy hỏi trực tiếp — một buổi 1:1 hoặc cà phê thường tiết lộ nhiều hơn mười email.
Bước 3 — Xây "tài khoản niềm tin" trước khi rút. Trước khi nhờ vả, hãy trao đi trước: gỡ blocker cho họ, chia sẻ thông tin, ghi công cho họ trước mặt lãnh đạo. Niềm tin không thể vay nóng lúc bạn cần.
Bước 4 — Đóng khung đề xuất theo lợi ích của họ. Chuyển từ "điều này tốt cho tôi" sang "điều này giúp bạn đạt được X". Cùng một yêu cầu, cách đóng gói quyết định 80% kết quả.
Bước 5 — Dùng dữ liệu và câu chuyện, không dùng ý kiến. "Tôi nghĩ nên làm thế này" yếu hơn nhiều so với "Dữ liệu cho thấy điều này, và đây là hệ quả nếu không làm." Kết hợp con số (cho lý trí) với câu chuyện cụ thể (cho cảm xúc).
Bước 6 — Trao quyền quyết định, đừng ép. Trình bày các lựa chọn và đánh đổi, rồi để họ chọn. Người ta bảo vệ quyết định của chính mình mạnh hơn quyết định bị áp đặt.
Bước 7 — Chỉ escalate như phương án cuối, và làm cho minh bạch. Đôi khi bạn phải nhờ tới authority của EM. Khi buộc phải làm, hãy báo trước cho người liên quan ("Mình nghĩ việc này cần đưa lên để hai sếp cùng ưu tiên, anh thấy sao?"), đừng đâm sau lưng. Escalate minh bạch giữ được quan hệ; escalate lén lút phá hủy nó.
Lỗi thường gặp & mẹo
Lỗi 1: Nghĩ rằng giỏi kỹ thuật là đủ. Nhiều TL tin "tôi đúng thì người ta phải nghe". Đúng về kỹ thuật nhưng thất bại trong việc thuyết phục vẫn là thất bại. Uy tín kỹ thuật mở cửa, nhưng quan hệ và cách trình bày mới đưa bạn qua cửa.
Lỗi 2: Chỉ "rút tiền" mà không "gửi tiền". TL suốt ngày đi nhờ vả nhưng không bao giờ giúp lại người khác sẽ nhanh chóng cạn kiệt thiện chí. Hãy chủ động tìm cơ hội giúp người khác trước khi bạn cần họ.
Lỗi 3: Lạm dụng escalation. Mỗi lần bạn nhờ sếp ép người khác, bạn tự chứng minh mình không influence nổi. Escalate là con dao hai lưỡi — dùng nhiều sẽ cùn và làm bạn mất uy tín ngang cấp.
Lỗi 4: Đóng khung mọi thứ theo góc nhìn của mình. "Hệ thống của tôi cần cái này" là cách chắc chắn nhất để bị phớt lờ. Luôn dịch sang ngôn ngữ lợi ích của người nghe.
Lỗi 5: Nhầm influence với thao túng (manipulation). Influence tử tế là minh bạch và win-win: cả hai bên đều hiểu rõ và cùng có lợi. Thao túng là che giấu ý đồ thật và khai thác người khác. Thao túng có thể thắng một trận, nhưng sẽ hủy hoại niềm tin — tài sản quý nhất của TL — về lâu dài.
Mẹo hữu ích:
- Xây quan hệ khi chưa cần gì. Mạng lưới quan hệ giống như quỹ hưu trí: đóng góp đều đặn từ sớm.
- Học cách "disagree and commit": bạn có thể phản đối trong lúc bàn, nhưng một khi nhóm đã chốt, hãy cam kết thực thi hết mình. Điều này khiến người khác tin tưởng giao cho bạn những quyết định lớn.
- Ghi công hào phóng, nhận lỗi sẵn sàng. Đây là hai hành vi xây niềm tin nhanh nhất.
- Với stakeholder không rành kỹ thuật, luôn quy đổi vấn đề kỹ thuật ra ngôn ngữ kinh doanh: tiền, rủi ro, thời gian, trải nghiệm khách hàng.
Bài tập thực hành
- Bản đồ influence. Vẽ ra một sơ đồ gồm 5–7 người/nhóm mà bạn phụ thuộc để hoàn thành công việc nhưng không có quyền chỉ đạo. Với mỗi người, ghi: (a) currency của họ là gì — họ đang được đo bằng chỉ số nào, nỗi đau lớn nhất của họ là gì; (b) hiện tại "tài khoản niềm tin" giữa bạn và họ đang dương hay âm.
- Đóng khung lại một yêu cầu. Lấy một việc bạn đang cần nhờ ai đó làm. Viết đề xuất theo hai cách: một theo góc nhìn lợi ích của bạn, một theo góc nhìn lợi ích của họ. So sánh và nhận ra khác biệt.
- Gửi tiền trước. Trong tuần này, tìm một cách cụ thể giúp một đồng nghiệp ở team khác — gỡ blocker, chia sẻ tài liệu, ghi công cho họ công khai — mà không kèm bất kỳ yêu cầu nào. Quan sát quan hệ thay đổi thế nào trong vài tuần sau.
- Tình huống nói không. Viết kịch bản bạn từ chối một yêu cầu của PM/stakeholder bằng ngôn ngữ đánh đổi (trade-off) thay vì từ chối thẳng. Chuẩn bị ít nhất một con số hỗ trợ cho lập luận.
Tóm tắt
Tech Lead là vai trò có trách nhiệm lớn nhưng quyền lực chính thức nhỏ — thậm chí những người trong team cũng dual-report với EM. Vì thế công cụ vận hành chính của bạn không phải là authority mà là influence. Ảnh hưởng bền vững đến từ ba nguồn: uy tín kỹ thuật, quan hệ và niềm tin, và sự thấu hiểu động lực của người khác.
Cơ chế cốt lõi là nền kinh tế "có đi có lại": hiểu currency của người khác, gửi giá trị trước khi rút, và đóng khung mọi đề xuất theo lợi ích của người nghe. Thay vì ra lệnh, hãy làm rõ các đánh đổi và trao quyền quyết định — vì người ta bảo vệ quyết định của chính mình mạnh hơn quyết định bị áp đặt. Escalation là phương án cuối cùng và phải luôn minh bạch. Và tuyệt đối phân biệt influence (minh bạch, win-win) với manipulation (che giấu, khai thác) — chỉ influence tử tế mới xây được thứ tài sản quý nhất của một TL: niềm tin mà cả tổ chức sẵn sàng đi theo.