Mở đầu — vì sao bài này quan trọng
Có một sự thật mà ít PM chịu thừa nhận: hầu hết chúng ta xử lý xung đột theo bản năng, theo "khẩu vị" cá nhân, chứ không phải theo tình huống. Có người cứ gặp tranh cãi là né — họ gật đầu trong họp rồi âm thầm ấm ức. Có người ngược lại, lúc nào cũng "chiến" tới cùng vì sợ mất mặt. Cả hai đều đang dùng một chế độ xử lý cố định cho mọi tình huống, giống như một bác sĩ chỉ biết kê đúng một loại thuốc cho mọi bệnh nhân.
Vấn đề là nghề PM sống bằng xung đột. Bạn đứng giữa engineering muốn refactor, sales muốn tính năng mới, design muốn polish, và sếp muốn ship tuần sau. Mỗi ngày bạn phải quyết định: lúc nào nên nhường, lúc nào nên giữ vững lập trường, lúc nào nên tìm điểm giữa, lúc nào nên ngồi lại đào sâu để cả hai cùng thắng. Nếu bạn chỉ có một "nút bấm" duy nhất, bạn sẽ thắng vài trận và thua rất nhiều trận lẽ ra không cần thua.
Mô hình Thomas-Kilmann (Thomas-Kilmann Conflict Mode Instrument, viết tắt TKI) cho bạn năm "nút bấm" thay vì một. Nó không nói chế độ nào tốt hơn chế độ nào — đây là điểm cốt lõi mà nhiều người hiểu sai. Nó giúp bạn nhìn ra mình đang mặc định dùng chế độ nào, và rèn cho bạn khả năng chọn chế độ phù hợp với từng tình huống một cách có chủ đích. Trong bài này, chúng ta đi sâu vào riêng mô hình TKI: hai trục, năm chế độ, khi nào dùng chế độ nào, và cách chẩn đoán để chọn đúng. Những kỹ thuật hạ nhiệt hay đối thoại khó (Crucial Conversations) sẽ là chuyện của các bài khác — ở đây ta tập trung vào bộ "bản đồ" để bạn biết mình đang đứng ở đâu.
Khái niệm cốt lõi
Kenneth Thomas và Ralph Kilmann phát triển mô hình này năm 1974, dựa trên một ý tưởng đơn giản nhưng sắc bén: mọi hành vi trong xung đột đều có thể đặt trên hai trục.
Hai trục nền tảng
Trục dọc — Assertiveness (Tính quyết đoán): Mức độ bạn theo đuổi và bảo vệ nhu cầu, mục tiêu, mối quan tâm của chính mình. Trục này đi từ thấp (mình bỏ qua nhu cầu của mình) đến cao (mình kiên quyết giành lấy điều mình muốn).
Trục ngang — Cooperativeness (Tính hợp tác): Mức độ bạn quan tâm và đáp ứng nhu cầu, mục tiêu, mối quan tâm của người kia. Trục này đi từ thấp (mặc kệ họ muốn gì) đến cao (mình ưu tiên thoả mãn họ).
Hãy nhớ: hai trục này độc lập với nhau. Quan tâm tới nhu cầu của mình không có nghĩa là phải bỏ qua nhu cầu người khác, và ngược lại. Chính sự giao nhau của hai trục tạo ra năm chế độ.
Năm chế độ xử lý xung đột
1. Competing — Cạnh tranh (Quyết đoán cao, Hợp tác thấp). "Tôi thắng, anh thua." Bạn dùng quyền lực, lập luận, vị thế để đạt điều mình muốn, bất kể bên kia. Nghe có vẻ tiêu cực, nhưng có lúc đây là chế độ đúng: khi cần quyết định nhanh trong khủng hoảng, khi bạn chắc chắn mình đúng về một vấn đề sống còn (ví dụ bảo mật dữ liệu người dùng), hoặc khi cần bảo vệ một nguyên tắc không thể nhân nhượng.
2. Accommodating — Nhường nhịn (Quyết đoán thấp, Hợp tác cao). "Tôi thua, anh thắng." Bạn đặt nhu cầu người kia lên trên nhu cầu của mình. Đây không phải yếu đuối — đó là sự hào phóng có chiến lược. Dùng khi vấn đề quan trọng với họ hơn với bạn, khi bạn nhận ra mình sai, hoặc khi bạn muốn "gửi tiền vào tài khoản quan hệ" để dành cho trận sau.
3. Avoiding — Né tránh (Quyết đoán thấp, Hợp tác thấp). "Không ai thắng, ta gác lại." Bạn không theo đuổi nhu cầu của mình lẫn của người kia, ít nhất là lúc này. Né tránh thường bị mang tiếng xấu, nhưng nó hợp lý khi vấn đề quá nhỏ không đáng tốn năng lượng, khi cảm xúc đang quá nóng cần thời gian nguội, hoặc khi bạn cần thu thập thêm thông tin trước khi vào cuộc.
4. Collaborating — Hợp tác (Quyết đoán cao, Hợp tác cao). "Cả hai cùng thắng." Bạn đào sâu để tìm giải pháp thoả mãn cả hai bên. Đây là chế độ tốn công nhất: phải lắng nghe, phải sáng tạo, phải có thời gian. Dùng khi vấn đề quá quan trọng để thoả hiệp nửa vời, khi cần sự cam kết thực sự của cả hai bên, hoặc khi mối quan hệ dài hạn đáng để đầu tư.
5. Compromising — Thoả hiệp (Quyết đoán trung bình, Hợp tác trung bình). "Mỗi bên nhường một nửa." Nằm chính giữa bản đồ. Cả hai cùng được một phần, cùng mất một phần. Đây là chế độ "vừa đủ tốt" và nhanh: dùng khi hai bên có sức mạnh ngang nhau, khi cần giải pháp tạm thời, hoặc khi Collaborating không đủ thời gian.
Phân biệt Collaborating và Compromising — chỗ hay nhầm nhất
Nhiều PM tưởng chia đôi là hợp tác. Không phải. Compromising là cắt chiếc bánh làm hai: mỗi người được nửa cái bánh. Collaborating là hỏi tại sao mỗi người muốn bánh — biết đâu một người chỉ cần vỏ bánh để làm mứt, người kia chỉ cần ruột để nấu chè, và cả hai cùng có 100% thứ họ cần. Collaborating mở rộng chiếc bánh; Compromising chia chiếc bánh có sẵn. Đó là lý do Collaborating tốn nhiều thời gian hơn nhưng cho kết quả cao hơn khi vấn đề thực sự đáng.
Tình huống thực tế
Ví dụ 1 — Khi "chiến" là đúng: sự cố bảo mật ở một fintech Việt
Linh là Senior PM tại một ví điện tử có khoảng 4 triệu người dùng tại TP.HCM. 9 giờ tối thứ Sáu, đội security phát hiện một lỗ hổng cho phép lộ số dư tài khoản qua API. Trưởng nhóm engineering muốn chờ đến thứ Hai để vá cẩn thận, vì hotfix gấp có thể làm hỏng luồng thanh toán đang chạy. Anh ấy lập luận rất hợp lý về mặt kỹ thuật.
Linh chọn chế độ Competing. Cô nói thẳng: "Tôi nghe ý anh, nhưng đây là dữ liệu tài chính của 4 triệu người. Chúng ta vá ngay tối nay, chấp nhận rủi ro downtime, và tôi chịu trách nhiệm." Cô không tổ chức workshop tìm đồng thuận, không chia đôi kiểu "vá một nửa". Trong tình huống có nguy cơ pháp lý và mất niềm tin người dùng, tốc độ và sự dứt khoát quan trọng hơn sự hài hoà.
Bài học: Competing không phải là độc đoán xấu tính. Khi vấn đề là nguyên tắc sống còn và thời gian là yếu tố quyết định, dùng quyền lực một cách minh bạch và nhận trách nhiệm là chế độ đúng. Cái sai duy nhất là dùng nó cho mọi việc.
Ví dụ 2 — Collaborating cứu một deadline tưởng chừng bế tắc
Tại một công ty SaaS B2B ở Singapore phục vụ thị trường Đông Nam Á, PM tên Hùng đối mặt mâu thuẫn kinh điển. Sales hứa với một khách hàng lớn ở Indonesia rằng tính năng xuất báo cáo đa ngôn ngữ sẽ có trong 3 tuần. Engineering nói cần ít nhất 8 tuần vì phải làm lại toàn bộ hệ thống template.
Phản xạ đầu tiên của nhiều người là Compromising: "Thôi 5-6 tuần nhé, sales xin khách dời lịch." Nhưng Hùng chọn Collaborating. Anh ngồi lại hỏi sâu: Khách thực sự cần gì? Hoá ra khách chỉ cần báo cáo tiếng Indonesia và tiếng Anh cho buổi họp hội đồng quản trị sau 3 tuần — không cần đủ 12 ngôn ngữ như sales tưởng. Còn engineering ngại vì sợ phải làm hệ thống template tổng quát cho mọi ngôn ngữ.
Giải pháp lộ ra: làm cứng (hard-code) hai ngôn ngữ cho riêng khách này trong 2 tuần, đồng thời lên roadmap hệ thống template đầy đủ cho quý sau. Khách hài lòng, engineering không phải gánh nợ kỹ thuật vội vàng, sales giữ được hợp đồng ~180.000 USD/năm.
Bài học: Compromising sẽ cho ra "5-6 tuần ai cũng nửa vui nửa buồn". Collaborating đào tới nhu cầu thật sự đằng sau yêu cầu bề mặt và tìm ra phương án mà cả ba bên đều thắng. Nhưng lưu ý: nó chỉ khả thi vì Hùng có vài tiếng để ngồi đào sâu. Không phải lúc nào cũng có xa xỉ đó.
Ví dụ 3 — Accommodating và Avoiding dùng đúng lúc trong một startup
Mai là PM tại một startup edtech ở Hà Nội, đội 15 người. Trong một sprint, designer kiên quyết muốn đổi màu nút CTA từ cam sang xanh lá vì lý do thẩm mỹ. Mai có dữ liệu cho thấy màu cam đang chuyển đổi tốt, nhưng chênh lệch rất nhỏ và chưa đủ ý nghĩa thống kê.
Mai chọn Accommodating: "Được, mình thử màu xanh của bạn, rồi A/B test xem sao." Vấn đề này không đáng để cô đốt vốn quan hệ với một designer mà cô sẽ làm việc cùng cả năm. Cô "gửi tiền vào tài khoản quan hệ".
Tuần sau, trong một cuộc họp khác, hai engineer tranh cãi gay gắt về việc dùng REST hay GraphQL — và bắt đầu công kích cá nhân vì cả hai đều mệt cuối ngày. Mai chọn Avoiding có chủ đích: "Chủ đề này quan trọng, nhưng giờ ai cũng mệt rồi. Mình hẹn sáng mai 9h, mỗi bạn chuẩn bị 3 luận điểm có số liệu nhé." Cô không né để trốn vấn đề — cô tạm gác để cảm xúc nguội và thông tin đầy đủ hơn.
Bài học: Accommodating đúng lúc bảo vệ quan hệ cho những trận quan trọng hơn. Avoiding đúng lúc là sự khôn ngoan về thời điểm, không phải sự hèn nhát. Sai lầm là Accommodating mọi thứ (bạn thành tấm thảm chùi chân) hay Avoiding mãi mãi (vấn đề mưng mủ rồi nổ tung).
Hướng dẫn từng bước
Đây là quy trình thực dụng để chọn chế độ trong một tình huống xung đột cụ thể.
Bước 1 — Xác định chế độ mặc định của bạn. Trước khi vào trận, hãy thành thật: khi căng thẳng, bản năng bạn kéo về đâu? Phần lớn người Việt làm văn phòng có xu hướng nghiêng về Avoiding hoặc Accommodating vì văn hoá coi trọng hoà khí và giữ thể diện. Biết điểm mù của mình là nửa chặng đường. Nếu bạn luôn nhường, hãy cảnh giác khi thấy mình lại định gật đầu.
Bước 2 — Cân hai câu hỏi. Với mỗi xung đột, hỏi: (a) Vấn đề này quan trọng với mình tới đâu? (đặt điểm trên trục Assertiveness) và (b) Quan hệ với người này / nhu cầu của họ quan trọng tới đâu? (đặt điểm trên trục Cooperativeness). Hai câu trả lời này gần như tự chỉ ra ô bạn nên đứng.
Bước 3 — Cân yếu tố thời gian. Collaborating cần thời gian và năng lượng. Nếu bạn có 5 phút, đừng cố hợp tác toàn diện — Compromising hoặc Competing thực tế hơn. Nếu đây là quyết định kiến trúc ảnh hưởng 2 năm tới, đừng tiếc vài giờ để Collaborating.
Bước 4 — Chọn chế độ một cách có chủ đích và đặt tên cho nó (trong đầu). "Lần này mình chọn Accommodating vì quan hệ quan trọng hơn kết quả này." Việc đặt tên giúp bạn không trôi theo bản năng.
Bước 5 — Thực thi nhất quán với chế độ đã chọn. Đừng nửa Competing nửa Accommodating — kiểu nói cứng rồi lại xuống nước — vì bạn sẽ vừa không đạt mục tiêu vừa mất uy tín.
Bước 6 — Sau xung đột, soi lại. Chế độ mình chọn có cho kết quả tốt không? Lần sau gặp tình huống tương tự sẽ chọn khác chứ? Đây là cách bạn mở rộng "dải tần" của mình, không bị kẹt ở một hai chế độ.
Lỗi thường gặp & mẹo
Lỗi 1 — Tin rằng Collaborating luôn tốt nhất. Đây là cái bẫy phổ biến nhất với PM mới đọc về win-win. Collaborating tốn thời gian khủng khiếp. Nếu bạn cố hợp tác toàn diện về việc chọn font cho một nút bấm, bạn đang lãng phí nguồn lực đắt giá của cả đội. Hãy để dành Collaborating cho các vấn đề thực sự quan trọng và đáng đầu tư.
Lỗi 2 — Kẹt ở một chế độ duy nhất. Người luôn Competing đốt cháy mọi cây cầu quan hệ. Người luôn Accommodating bị xem là không có chính kiến, ý kiến của họ dần bị phớt lờ. Mục tiêu của TKI là linh hoạt, không phải tìm "chế độ thắng".
Lỗi 3 — Nhầm Compromising với Collaborating. Như đã phân tích, chia đôi không phải mở rộng chiếc bánh. Nếu thấy mình hay "chốt giữa cho nhanh", hãy tự hỏi: liệu có giải pháp nào cả hai cùng thắng 100% mà mình chưa đào ra không?
Lỗi 4 — Coi Avoiding luôn là tiêu cực. Tạm gác một cuộc tranh cãi khi mọi người đang nóng giận là kỹ năng, không phải trốn tránh. Cái xấu là né vĩnh viễn một vấn đề cần giải quyết.
Mẹo thực chiến: Hãy làm bài test TKI chính thức (hoặc tự chấm bản đơn giản) để biết phân bố chế độ của mình. Đa số người có một hoặc hai chế độ trội và một hai chế độ gần như không bao giờ dùng. Chế độ bạn ít dùng nhất thường là "cơ bắp" cần tập luyện nhất. Nếu bạn chưa từng Competing, hãy chọn một vấn đề nhỏ tuần này để thực hành giữ vững lập trường.
Mẹo về văn hoá Việt Nam: Trong bối cảnh trọng thể diện và thứ bậc, Competing công khai với sếp dễ bị xem là vô lễ. Nhưng điều đó không có nghĩa bạn phải luôn Accommodating với sếp. Bạn vẫn có thể quyết đoán cao về nội dung trong khi giữ giọng điệu tôn trọng — quyết đoán nằm ở bạn theo đuổi nhu cầu của mình tới đâu, không phải ở bạn nói to tới đâu.
Bài tập thực hành
Bài 1 — Tự chẩn đoán (15 phút). Liệt kê 5 xung đột gần nhất bạn gặp ở công việc. Với mỗi cái, ghi rõ bạn đã dùng chế độ nào trong năm chế độ. Đếm xem chế độ nào lặp lại nhiều nhất — đó là mặc định của bạn. Chế độ nào không xuất hiện lần nào — đó là "cơ bắp teo" cần tập.
Bài 2 — Định vị trên bản đồ (10 phút). Vẽ hai trục Assertiveness và Cooperativeness lên giấy. Lấy một xung đột bạn đang phải xử lý tuần này, chấm điểm hai câu hỏi ở Bước 2, và xác định ô bạn nên đứng. So sánh với ô bạn định đứng theo bản năng. Có khác nhau không?
Bài 3 — Thực hành chế độ yếu (cả tuần). Chọn chế độ bạn ít dùng nhất. Trong tuần tới, tìm một tình huống phù hợp để thực hành nó một cách có chủ đích. Nếu bạn ít Competing, hãy giữ vững lập trường về một quyết định bạn tin là đúng. Nếu bạn ít Collaborating, hãy dành 30 phút đào sâu nhu cầu thật của một bên đối lập. Ghi lại kết quả.
Bài 4 — Phân tích tình huống (20 phút). Lấy lại Ví dụ 2 (deadline ở Singapore). Giả sử Hùng không có thời gian Collaborating — khách cần câu trả lời trong 30 phút. Chế độ nào sẽ hợp lý nhất khi đó, và câu nói cụ thể của Hùng sẽ thế nào? Viết ra để rèn phản xạ chọn chế độ theo ràng buộc thời gian.
Tóm tắt
Thomas-Kilmann cho bạn một bản đồ hai trục — Assertiveness (theo đuổi nhu cầu của mình) và Cooperativeness (đáp ứng nhu cầu người kia) — sinh ra năm chế độ xử lý xung đột: Competing (tôi thắng), Accommodating (anh thắng), Avoiding (gác lại), Collaborating (cùng thắng), và Compromising (chia đôi).
Thông điệp lớn nhất: không có chế độ nào tốt nhất. Có chế độ phù hợp và không phù hợp với từng tình huống cụ thể, tuỳ vào tầm quan trọng của vấn đề, tầm quan trọng của quan hệ, và thời gian bạn có. PM giỏi không phải người luôn win-win, mà là người đọc đúng tình huống và chọn đúng chế độ một cách có chủ đích — biết khi nào cần chiến trong một sự cố bảo mật, khi nào nhường để giữ quan hệ với designer, khi nào tạm gác để cảm xúc nguội, và khi nào đáng bỏ công đào sâu để cả ba bên cùng thắng.
Việc của bạn từ hôm nay: nhận ra chế độ mặc định của mình, và rèn những chế độ "cơ bắp teo" để có đủ năm "nút bấm" thay vì một. Đó là điểm khác biệt giữa một PM xử lý xung đột theo bản năng và một PM xử lý xung đột như một chuyên gia.