Mở đầu — vì sao bài này quan trọng
Có một khoảnh khắc trong sự nghiệp kỹ sư mà gần như ai cũng gặp: bạn nhìn thấy rất rõ đội đang đi sai hướng — chọn sai công nghệ, ôm một khoản technical debt sẽ trở thành thảm họa sau sáu tháng, hoặc bỏ qua một rủi ro bảo mật — nhưng bạn không có quyền ra lệnh cho ai làm gì. Bạn không phải Engineering Manager, không phải Tech Lead chính thức. Bạn chỉ là một IC (Individual Contributor — người đóng góp cá nhân, không quản lý con người). Và bạn bất lực nhìn quyết định tồi trôi qua vì "mình đâu có quyền quyết".
Đây chính là bài toán của "influencing without authority" — gây ảnh hưởng mà không cần quyền lực chính thức. Nó quan trọng vì một sự thật ít ai nói thẳng: trong hầu hết tổ chức tech, phần lớn quyết định quan trọng KHÔNG được đưa ra bằng mệnh lệnh từ trên xuống. Chúng được định hình bởi những người mà đồng nghiệp tin tưởng, lắng nghe và tự nguyện đi theo. Một Senior/Staff Engineer giỏi có thể thay đổi cách cả một org viết code, thiết kế hệ thống, hay ra quyết định — mà chưa từng có ai báo cáo cho họ.
Nếu bạn muốn phát triển từ mid-level lên senior, rồi staff/principal, kỹ năng này không phải "nice to have" — nó là ranh giới. Người ta thăng chức bạn lên Staff không phải vì bạn code nhanh hơn, mà vì bạn khiến người khác code tốt hơn, khiến những quyết định xung quanh bạn trở nên đúng đắn hơn. Đó hoàn toàn là câu chuyện về ảnh hưởng. Và tin tốt: ảnh hưởng không phải năng khiếu bẩm sinh — nó là một tập kỹ năng giao tiếp có thể học được, luyện được.
Khái niệm cốt lõi
Authority vs. Influence: hai loại "quyền" khác nhau
Authority (quyền lực chính thức) đến từ chức danh: manager có quyền giao việc, đánh giá, quyết định lương thưởng. Người ta làm theo vì cấu trúc tổ chức buộc họ phải thế.
Influence (ảnh hưởng) đến từ việc người khác tự nguyện thay đổi suy nghĩ và hành vi vì họ tin bạn. Không ai bị ép. Đây là loại quyền bền vững hơn và, nghịch lý thay, mạnh hơn — vì nó không mất đi khi bạn đổi team hay công ty.
Với một Tech IC, bạn gần như không có authority với đồng nghiệp ngang cấp hay với Product/Design. Toàn bộ sức mạnh của bạn đến từ influence. Hiểu điều này giúp bạn ngừng phàn nàn "sao chẳng ai nghe mình" và bắt đầu xây dựng nền tảng thực sự khiến người ta nghe.
Ba trụ cột của ảnh hưởng: Credibility, Trust, Reciprocity
Ảnh hưởng không tự nhiên có. Nó đứng trên ba trụ cột:
1. Credibility (độ tín nhiệm chuyên môn). Người ta nghe bạn về kiến trúc hệ thống vì bạn đã từng thiết kế hệ thống chạy ổn định. Credibility được xây bằng track record — những lần bạn dự đoán đúng, những đề xuất của bạn về sau chứng minh là hợp lý. Đây là lý do senior IC có ảnh hưởng: họ đã "trả tiền" bằng nhiều năm quyết định đúng.
2. Trust (sự tin cậy về ý định). Credibility là "người này giỏi", trust là "người này không có ý đồ xấu". Đồng nghiệp cần tin rằng bạn đề xuất điều gì đó vì tốt cho sản phẩm/đội, chứ không phải để đánh bóng bản thân hay ghi điểm chính trị. Trust xây chậm, mất nhanh.
3. Reciprocity (sự có qua có lại). Người ta ủng hộ đề xuất của người từng giúp họ. Nếu bạn thường xuyên review PR cho người khác một cách tận tâm, giúp họ debug lúc kẹt, thì khi bạn cần ủng hộ cho một RFC, họ sẽ ở đó.
Ảnh hưởng qua "cách viết ra" chứ không qua "cách nói to"
Đây là điểm đặc thù của tech mà nhiều người bỏ lỡ. Trong tech team hiện đại — nhất là môi trường remote, async — ảnh hưởng của một IC lan tỏa chủ yếu qua văn bản và artifact: một RFC được viết chặt chẽ, một ADR (Architecture Decision Record) rõ ràng, một comment code review mang tính khai sáng, một tài liệu chuẩn hóa được cả team dùng làm tham chiếu. Người viết ra "nguồn chân lý" mà cả team trích dẫn chính là người đang định hình tổ chức.
Nói cách khác: ảnh hưởng của tech IC thường bất đồng bộ và có thể mở rộng (scalable). Một tài liệu tốt tiếp tục thuyết phục người khác cả khi bạn đang ngủ.
Bốn "chiến trường" ảnh hưởng của một IC
Ghi nhớ để nhận diện nơi mình có thể tạo tác động: (1) Thiết kế hệ thống — qua RFC/design doc, bạn hình thành hướng kỹ thuật. (2) Chuẩn mực kỹ thuật — qua linter config, style guide, template, bạn quyết định "cách đúng" để làm việc. (3) Mentoring xuyên team — bạn nâng năng lực người khác và họ mang tư duy của bạn đi khắp org. (4) Quyết định liên phòng ban — bạn giúp Product/Design hiểu ràng buộc kỹ thuật và cùng ra quyết định tốt hơn.
Tình huống thực tế
Ví dụ 1: Kỹ sư backend tại một fintech ở TP.HCM và cuộc chiến "microservices"
Minh là Senior Backend Engineer tại một công ty fintech khoảng 80 người ở Quận 1. Một VP Engineering mới về, đầy nhiệt huyết, muốn tách monolith thành 15 microservices trong 6 tháng — vì "công ty lớn nào cũng làm microservices". Minh nhìn thấy thảm họa: đội chỉ có 12 engineer, chưa có hạ tầng observability, chưa có ai vận hành Kubernetes thành thạo. Nhưng VP là sếp của sếp anh — làm sao cãi?
Thay vì phản đối trong meeting (điều gần như chắc chắn thất bại và khiến anh mang tiếng "khó tính"), Minh làm điều khác. Anh viết một RFC dài 6 trang, không tiêu đề "Đừng làm microservices" mà là "Lộ trình tách dịch vụ theo giai đoạn dựa trên rủi ro". Trong đó anh: (1) đồng ý với mục tiêu của VP — hệ thống cần mở rộng được; (2) đưa ra dữ liệu — deploy hiện tại mất 20 phút, đúng, nhưng downtime do phối hợp service phân tán ở các công ty cùng quy mô cao gấp 3 lần; (3) đề xuất tách 2 service rủi ro cao nhất trước (payment và notification), đo lường, rồi mới quyết định phần còn lại.
Minh chia sẻ bản nháp riêng cho VP trước cuộc họp, xin góp ý — chứ không phục kích công khai. VP cảm thấy được tôn trọng, thấy Minh đứng cùng phe mình chứ không chống lại. Kết quả: công ty tách 2 service trong quý đầu, phát hiện đúng những vấn đề observability mà Minh cảnh báo, và lộ trình "15 service trong 6 tháng" lặng lẽ được thay bằng cách tiếp cận thực tế của Minh.
Bài học: Ảnh hưởng lên cấp cao hơn không đến từ đối đầu, mà từ việc tái định khung (reframe) — biến đề xuất của bạn thành phiên bản tốt hơn của mục tiêu mà họ đã có. Cho họ giữ thể diện, giữ mục tiêu, chỉ đổi phương pháp. Và luôn "socialize" (chia sẻ trước, xin ý kiến riêng) trước khi lên sân khấu chung.
Ví dụ 2: Chuẩn hóa testing tại một startup e-commerce Đông Nam Á
Lan là một mid-level engineer tại một startup thương mại điện tử hoạt động ở Việt Nam, Thái Lan và Indonesia. Codebase gần như không có test tự động; mỗi lần release là một lần cầu nguyện. Lan không phải lead, không được giao nhiệm vụ "cải thiện testing". Nếu cô gửi một tin nhắn Slack "mọi người ơi viết test đi" — chắc chắn rơi vào hư không.
Cô làm ba việc. Thứ nhất, cô tự làm gương ở quy mô nhỏ: trong feature tiếp theo cô phụ trách, cô viết test đầy đủ và trong PR description giải thích ngắn gọn hai bug mà test đã bắt được trước khi lên production. Con số cụ thể, hậu quả cụ thể. Thứ hai, cô biến việc đúng thành việc dễ: cô tạo một template test và một helper setup để đồng nghiệp chỉ cần copy, giảm ma sát từ "phải học cả framework" xuống "điền vào chỗ trống". Thứ ba, cô tìm một ally (đồng minh) — cô rủ một senior được cả team nể trọng cùng dùng cách này trong một PR, để ý tưởng không chỉ đến từ một mid-level.
Sau 6 tuần, ba engineer khác bắt đầu bắt chước vì thấy nó thực sự giúp họ. Đến lúc đó Lan mới đề xuất chính thức đưa test coverage tối thiểu vào CI — và đề xuất được duyệt gần như không tranh cãi, vì team đã sống với thực hành đó rồi.
Bài học: Với ảnh hưởng ngang cấp (peer influence), thứ tự đúng là demonstrate → reduce friction → recruit allies → formalize. Đừng bắt đầu bằng việc yêu cầu một chính sách; hãy bắt đầu bằng việc chứng minh giá trị và khiến việc làm đúng trở nên dễ hơn việc làm sai. Chính sách chỉ nên là bước cuối, đóng dấu cho một thứ đã thắng trên thực tế.
Ví dụ 3: Khi ảnh hưởng thất bại vì thiếu trust
Đối chiếu ngược. Tại một công ty SaaS, một kỹ sư rất giỏi tên Phong liên tục đề xuất chuyển toàn bộ frontend sang một framework mới. Đề xuất của anh về mặt kỹ thuật đôi khi hợp lý, nhưng gần như luôn bị bác. Vì sao? Vì mỗi lần công nghệ anh từng cổ vũ gặp vấn đề, anh lặng lẽ biến mất khỏi việc dọn dẹp; anh phát biểu để trông "thông minh" trong meeting hơn là để giúp team. Credibility kỹ thuật của Phong cao, nhưng trust thì thấp — người ta không tin ý định của anh.
Đồng nghiệp của anh, Trang, kỹ thuật ngang hoặc kém hơn một chút, lại có ảnh hưởng lớn hơn nhiều. Vì Trang luôn là người ở lại lúc sự cố, luôn ghi công người khác, và khi đề xuất gì đó, cô nói rõ cả nhược điểm. Người ta tin cô.
Bài học: Credibility mà thiếu trust thì ảnh hưởng bị "chiết khấu" nặng. Bạn có thể là người giỏi nhất phòng mà vẫn không lay chuyển được ai, nếu người ta nghi ngờ động cơ của bạn. Đầu tư vào trust — chủ động ghi công, thừa nhận điểm yếu trong đề xuất của mình, ở lại dọn dẹp khi thứ mình cổ vũ gặp vấn đề — quan trọng ngang với việc giỏi chuyên môn.
Hướng dẫn từng bước
Đây là quy trình thực chiến để đẩy một thay đổi khi bạn không có quyền ra lệnh:
Bước 1 — Xác định "currency" của người bạn cần thuyết phục. Mỗi bên quan tâm một thứ khác nhau. Manager quan tâm rủi ro và tốc độ giao hàng; PM quan tâm tác động lên người dùng và deadline; một engineer khác quan tâm việc code của họ có dễ bảo trì hơn không. Trước khi mở miệng, hỏi: "Điều này giúp họ thế nào, theo ngôn ngữ của họ?" Đừng bán một giải pháp kỹ thuật; hãy bán kết quả mà bên kia coi trọng.
Bước 2 — Xây nền credibility trước khi cần. Ảnh hưởng không thể "vay nóng" đúng lúc bạn cần. Hãy tích lũy trước: review PR tận tâm, viết tài liệu người khác thực sự dùng, giúp người khác lúc họ kẹt. Khi đến lúc bạn cần ủng hộ, tài khoản của bạn đã có số dư.
Bước 3 — Viết ra, đừng chỉ nói. Chuyển ý tưởng thành artifact: một RFC, một design doc, một đoạn benchmark có số liệu. Văn bản buộc bạn suy nghĩ chặt hơn, cho người khác thời gian tiêu hóa (quan trọng với người hướng nội và với môi trường async), và có thể lan xa mà không cần bạn có mặt.
Bước 4 — Socialize trước, quyết định sau. Đừng bao giờ để đề xuất lớn của bạn xuất hiện lần đầu trong một cuộc họp quyết định. Chia sẻ bản nháp cho vài người chủ chốt trước, xin phản hồi, hấp thụ ý kiến của họ. Khi họ thấy dấu vân tay của mình trong đề xuất, họ trở thành người ủng hộ chứ không phải người phản biện.
Bước 5 — Đóng khung theo mục tiêu chung, không phải sở thích cá nhân. Thay "Tôi nghĩ cách này hay hơn" bằng "Cách này giảm rủi ro downtime cho mục tiêu uptime 99.9% mà đội đang cam kết". Gắn đề xuất vào mục tiêu mà mọi người đã đồng thuận.
Bước 6 — Tuyển đồng minh và cho phép người khác ghi công. Tìm một hoặc hai người có tín nhiệm cùng đứng tên/ủng hộ. Và sẵn lòng để ý tưởng "thuộc về cả nhóm" — mục tiêu là thay đổi xảy ra, không phải bạn được vinh danh.
Bước 7 — Thu nhỏ bước đầu tiên. Đề xuất một thử nghiệm giới hạn ("làm cho 1 service, đo 2 tuần") thay vì một cú nhảy toàn diện. Người ta dễ nói "có" với một thử nghiệm nhỏ, có thể đảo ngược, hơn là với một cam kết lớn.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm "đúng về kỹ thuật" với "sẽ được chấp nhận". Rất nhiều engineer tin rằng chỉ cần mình đúng thì người ta phải nghe. Sai. Con người ra quyết định bằng cảm xúc, quan hệ và bối cảnh, rồi mới hợp lý hóa bằng logic. Đúng là cần thiết nhưng chưa đủ.
Lỗi 2 — Phục kích trong meeting. Tung ra một phản đối lớn lần đầu tiên ngay giữa cuộc họp khiến người khác phòng thủ và mất mặt. Luôn socialize trước.
Lỗi 3 — Bán giải pháp thay vì vấn đề. Nếu bạn nhảy thẳng vào "ta nên dùng công nghệ X", người ta tranh cãi về X. Nếu bạn xây đồng thuận về vấn đề trước ("deploy của ta chậm và rủi ro, đồng ý không?"), giải pháp trở nên dễ chấp nhận hơn nhiều.
Lỗi 4 — Ép quá mạnh, quá thường xuyên. Ảnh hưởng có "ngân sách". Nếu bạn biến mọi thứ thành trận đánh sinh tử, bạn cạn vốn thiện chí. Chọn trận để đánh; nhượng bộ những thứ nhỏ để dành sức cho thứ thật sự quan trọng.
Mẹo 1 — Dùng câu hỏi thay vì khẳng định. "Chuyện gì xảy ra nếu service payment down giữa lúc tách?" khiến người khác tự đi đến kết luận — mạnh hơn nhiều so với việc bạn phán "cách này sẽ hỏng".
Mẹo 2 — Ghi công công khai, phản hồi riêng tư. Khen người khác trước đám đông xây trust và reciprocity cực nhanh. Phê bình thì làm riêng.
Mẹo 3 — "Disagree and commit". Khi bạn đã trình bày hết mà quyết định đi hướng khác, hãy cam kết thực thi tử tế. Nghịch lý: chính sự trưởng thành này khiến lần sau người ta nghe bạn nhiều hơn.
Bài tập thực hành
Bài 1 — Bản đồ ảnh hưởng. Chọn một thay đổi bạn thực sự muốn đẩy trong đội (kỹ thuật hoặc quy trình). Liệt kê 3–5 người liên quan. Với mỗi người, viết ra: họ quan tâm điều gì (currency của họ), họ có thể phản đối vì lý do gì, và một câu bạn sẽ dùng để đóng khung đề xuất theo ngôn ngữ của họ.
Bài 2 — Viết một mini-RFC. Lấy ý tưởng ở Bài 1, viết một tài liệu 1 trang gồm: vấn đề (kèm ít nhất một số liệu), mục tiêu chung mà nó phục vụ, đề xuất, các phương án đã cân nhắc, và một "bước thử nghiệm nhỏ nhất". Gửi riêng cho một đồng nghiệp xin góp ý trước khi công khai.
Bài 3 — Kiểm toán reciprocity. Trong 2 tuần tới, mỗi ngày làm một việc giúp đồng nghiệp mà không được yêu cầu: một review PR kỹ lưỡng, một câu trả lời rõ ràng khi họ kẹt, một tài liệu nhỏ. Ghi lại. Cuối 2 tuần, quan sát xem thái độ của team với đề xuất của bạn có khác đi không.
Bài 4 — Luyện "disagree and commit". Nhớ lại lần gần nhất một quyết định đi ngược ý bạn. Viết lại bạn đã phản ứng thế nào, và bạn nên phản ứng thế nào để vừa nêu được quan điểm vừa giữ được trust khi cam kết thực thi.
Tóm tắt
Là một Tech IC, quyền lực thật sự của bạn không nằm ở chức danh mà ở ảnh hưởng — khả năng khiến người khác tự nguyện thay đổi suy nghĩ và hành vi. Ảnh hưởng đứng trên ba trụ cột: credibility (giỏi và có track record), trust (ý định trong sáng, ghi công người khác, thừa nhận điểm yếu) và reciprocity (cho đi trước khi cần nhận). Trong tech, ảnh hưởng lan tỏa mạnh nhất qua văn bản và artifact — RFC, ADR, tài liệu, code review — những thứ tiếp tục thuyết phục cả khi bạn vắng mặt.
Quy trình cốt lõi: hiểu currency của người bạn cần thuyết phục, tích lũy credibility từ trước, viết ra thay vì chỉ nói, socialize trước khi lên bàn quyết định, đóng khung theo mục tiêu chung, tuyển đồng minh, và thu nhỏ bước đầu tiên. Tránh nhầm "đúng" với "được chấp nhận", đừng phục kích trong meeting, và biết chọn trận để tiêu ngân sách ảnh hưởng của mình cho khôn ngoan. Đây chính là kỹ năng phân biệt một engineer giỏi với một Staff/Principal engineer thật sự — và nó hoàn toàn học được.