Xung đột với đồng nghiệp

Câu hỏi — "Hãy kể về một lần bạn có xung đột với đồng nghiệp." Các biến thể: "Mô tả một lần bạn bất đồng quan điểm với một đồng nghiệp.", "Kể về một lần bạn phải vượt qua một tình huống khó xử trong quan hệ công việc."

Điều họ đang đánh giá — Bạn xử lý va chạm giữa người với người một cách chín chắn; biết đồng cảm và nhìn nhận từ góc độ của đối phương; giao tiếp rõ ràng, thẳng thắn; đặt mục tiêu và kết quả chung lên trên cái tôi; và thực sự tháo gỡ được vấn đề chứ không né tránh.

Khung STAR-L

Điền câu chuyện của riêng bạn:

• Tình huống — Mô tả bối cảnh của nhóm và xung đột nảy sinh ra sao. Lúc đó có gì đáng để bận tâm, và ai liên quan?
• Nhiệm vụ — Riêng bạn cần đạt được điều gì, và vì sao bất đồng đó lại ảnh hưởng đến kết quả?
• Hành động — Bạn đã chủ động mở lời để nói chuyện thẳng thắn như thế nào? Bạn làm gì để hiểu góc nhìn của người kia? Bạn đề xuất bước tiếp theo ra sao — hãy nói "tôi", đừng nói "chúng tôi", và nêu rõ hành động cụ thể (ví dụ: hẹn một buổi 1:1, lắng nghe mà không ngắt lời, đề xuất một spike giới hạn thời gian để thử cả hai hướng)?
• Kết quả — Kết quả cụ thể ra sao? Xung đột đã được tháo gỡ chưa? Công việc có xong không? Có số liệu thì càng tốt (ví dụ: chốt được quyết định trong 2 ngày, không đụng đến tiến độ).
• Bài học — Chuyện đó thay đổi cách bạn xử lý bất đồng như thế nào? Giờ bạn làm gì khác đi (ví dụ: nêu lo ngại sớm hơn, tách ý tưởng ra khỏi con người)?

Cạm bẫy / dấu hiệu cảnh báo

• Biến người kia thành kẻ xấu còn mình thì hoàn toàn đúng — nhà tuyển dụng nhận ra ngay kiểu chuyện anh hùng đấu phản diện.
• Nói "chúng tôi đã giải quyết được" mà không chỉ ra cụ thể bạn đã làm gì — hãy nói "tôi".
• Kể chuyện né tránh chứ không phải tháo gỡ (ví dụ: "thôi thì bỏ qua rồi làm tiếp").
• Không hề nhắc đến chuyện đồng cảm hay tìm hiểu lý lẽ của phía bên kia.

Ví dụ (ví dụ chung — thay bằng câu chuyện của bạn)

Tình huống: Trong một nhóm backend bốn người, tôi và một đồng nghiệp bất đồng về chuyện có nên áp dụng một pattern event-sourcing mới cho tính năng có deadline hai tuần hay không. Anh ấy muốn dùng nó vì tính linh hoạt về lâu dài; còn tôi lo về thời gian làm quen và rủi ro trễ tiến độ.

Nhiệm vụ: Tôi cần cả hai chốt được một quyết định kỹ thuật thật nhanh mà không làm sứt mẻ quan hệ đồng nghiệp hay kéo lùi sprint.

Hành động: Tôi rủ anh ấy một buổi 1:1 30 phút để nghe cho hết lý lẽ của anh ấy trước khi nói ra lo ngại của mình. Nghe xong, tôi đề xuất một spike nhỏ giới hạn thời gian — hai ngày, cả hai cùng làm — để prototype hướng event-sourcing theo đúng tiêu chí chấp nhận của tính năng. Tôi đặt vấn đề theo hướng "để dữ liệu lên tiếng", nhờ đó không ai phải nhượng bộ chỉ vì quan điểm cá nhân.

Kết quả: Spike cho thấy pattern đó phát sinh thêm ba ngày phức tạp mà chúng tôi không kham nổi. Cả hai cùng đồng ý chọn hướng đơn giản hơn. Tính năng xong đúng hạn, quan hệ vẫn tốt đẹp — thậm chí sang sprint sau chúng tôi còn làm chung khăng khít hơn.

Bài học: Tôi học được cách tách ý tưởng ra khỏi con người ngay từ đầu. Giờ hễ thấy một bất đồng kỹ thuật đang nhen nhóm, tôi chủ động mời người kia trình bày lý lẽ trước — cách này gần như luôn để lộ một lo ngại chính đáng mà tôi chưa nghĩ tới, và biến cuộc trao đổi thành cùng nhau tìm cách thay vì đối đầu.