Vì sao đội ngũ ‘hòa thuận’ của bạn lại thất bại

• An toàn tâm lý không phải là né tránh xung đột, mà xuất hiện trong một môi trường nơi việc thách thức ý tưởng giúp đội ngũ mạnh hơn
• Việc tất cả thành viên đều thể hiện những cuộc họp yên ắng bề ngoài và bầu không khí ôn hòa không có nghĩa đó là một đội ngũ hiệu quả
• Một đội ngũ có bất đồng mang tính xây dựng thường có đặc điểm là báo hiệu vấn đề sớm và cho phép va chạm quan điểm
• Tư duy phản biện cần có ma sát, và đội ngũ thiếu giao tiếp thẳng thắn sẽ bỏ mặc các vấn đề tiềm ẩn
• Lãnh đạo có thể dẫn dắt văn hóa tranh luận lành mạnh bằng cách bộc lộ sự dễ tổn thương, thiết lập quy tắc thảo luận, khuyến khích người thách thức

---

Sự khác biệt giữa bầu không khí mọi người đều hòa hợp và cảm giác an toàn tâm lý

• Cảm giác an toàn tâm lý thường bị hiểu nhầm là trạng thái đội ngũ hòa thuận, không có xung đột
• Nhiều lãnh đạo tự hào về một đội ngũ mà các thành viên không bao giờ lớn tiếng, mọi người đều đồng ý và không có va chạm ý kiến
• Nhưng bản chất của an toàn tâm lý không phải là né tránh xung đột mà là tạo ra môi trường có thể tự do thách thức và thảo luận ý tưởng
• Giáo sư Amy Edmondson của Trường Kinh doanh Harvard định nghĩa an toàn tâm lý là “niềm tin rằng bạn sẽ không bị trừng phạt hay cảm thấy xấu hổ vì các ý tưởng, câu hỏi, mối lo ngại và sai lầm”

Đặc điểm của đội ngũ có mức an toàn tâm lý cao (có xung đột mang tính xây dựng)

• Mọi người phát biểu tự do, tranh luận gay gắt cũng không sao, và nhờ đó đội ngũ trở nên mạnh hơn
• Có một bầu không khí không phải lo bị loại trừ dù nói rằng “Tôi nghĩ cái đó là sai”
• Mọi người có thể thoải mái nói “Ý tôi có thể sai”, nội dung của ý tưởng chứ không phải cá nhân là đối tượng được đánh giá và thảo luận, và có thể bị chất vấn bất kể người đề xuất là ai
• Sai lầm cũng được tận dụng như cơ hội học hỏi, và có văn hóa khuyến khích các góc nhìn đa dạng

Những đặc điểm cụ thể của đội ngũ thực hành thảo luận hiệu quả

• Nhận diện vấn đề sớm: kỹ sư sẽ nêu vấn đề trước khi nó trở nên nghiêm trọng
• Thảo luận tích cực về ý tưởng: dù hai lập trình viên cấp cao tranh luận thiết kế rất căng thẳng, việc hợp tác vào ngày hôm sau vẫn hoàn toàn không bị ảnh hưởng
• Thái độ tập trung vào vấn đề: như câu “Cách tiếp cận này có vẻ sẽ gặp vấn đề về khả năng mở rộng”, tức là tập trung vào chính vấn đề chứ không phải con người
• Sai lầm là cơ hội học hỏi: khi xảy ra sự cố, chính kỹ sư đã mắc lỗi sẽ trực tiếp dẫn dắt buổi postmortem

Cái giá ẩn mà đội ngũ ‘tử tế’ thường bỏ lỡ

• Có những đội ngũ nhìn bề ngoài rất yên bình nhưng trong đa số trường hợp chỉ tạo ra kết quả ở mức trung bình
• Vì tư duy phản biện cần một mức độ ma sát nhất định
• Bên dưới sự đồng thuận bề mặt thường ẩn giấu xung đột thực sự, dẫn đến những trường hợp trong cuộc họp thì đồng ý nhưng khi làm việc thực tế mỗi người lại hành động khác nhau
• Thiếu giao tiếp là vấn đề cốt lõi; thiếu tranh luận mang tính xây dựng khiến kết quả cuối cùng suy giảm

Cân bằng giữa an toàn tâm lý và xung đột

• Ba cách thực hành cốt lõi để tạo môi trường phù hợp
  • Thái độ thành thật thừa nhận rằng bản thân cũng có điều chưa biết (bộc lộ sự dễ tổn thương)
  • Thiết lập quy tắc rõ ràng cho tranh luận (tập trung vào ý tưởng chứ không phải con người, tách biệt thảo luận và quyết định)
  • Khen ngợi công khai những thành viên nêu vấn đề hoặc đặt ra câu hỏi khó (đóng vai trò như tín hiệu cảnh báo sớm)

Kết luận: Xung đột lành mạnh dẫn tới tăng trưởng và đổi mới thực sự

• Trên thực tế, những đội ngũ tự do bộc lộ xung đột lại có chất lượng xung đột thấp hơn về dài hạn
• Những va chạm quan điểm nhỏ không bị tích tụ mà được giải quyết ngay lập tức, từ đó củng cố niềm tin và sự hợp tác
• Những đội ngũ kỹ thuật xuất sắc nhất không hề yên ắng, mà có đặc điểm là chào đón tranh luận kỹ thuật và các góc nhìn đa dạng
• Một văn hóa có thể tự do thảo luận và tôn trọng lẫn nhau trong đội ngũ mới là an toàn tâm lý thực sự
• Cũng như code và ý tưởng chưa được kiểm chứng có thể gây ra vấn đề, ý tưởng không có tranh luận cũng sẽ dẫn tới thất bại

[chipmunk]

Cảm giác an toàn tâm lý và cả những cuộc tranh luận mang tính xây dựng, rốt cuộc cũng chỉ là nhiên liệu cho việc ‘thực thi’.
Để ý tưởng thực sự sống động, cuối cùng vẫn phải có ai đó thúc đẩy nó tiến lên, và chỉ khi hành động ấy được lặp lại thì niềm tin mới được bồi đắp.
Nếu chỉ lặp đi lặp lại tranh luận mà không có thực thi, thì dù bầu không khí có an toàn đến đâu, đội ngũ vẫn sẽ giậm chân tại chỗ.
Một văn hóa tốt không được chứng minh bằng lời nói, mà bằng hành động.

[chipmunk]

Giữa những người có năng lực thực thi, những cuộc tranh luận mang tính xây dựng tất yếu sẽ xuất hiện.

[mhj5730]

Thường thì... nếu trưởng nhóm là kiểu bảo thủ, né tránh trách nhiệm nhưng lại giao phó hết mọi việc, thì mọi người tự khắc sẽ im lặng và trở nên ngoan ngoãn.

[kaydash]

Lý do đội ngũ 'hòa thuận' của bạn thất bại

[ndrgrd]

Ngưỡng để đưa ra ý kiến càng thấp thì càng tốt. Chỉ là vì khó tìm được tiêu chuẩn và sự cân bằng thôi.

[GN⁺]

Ý kiến Hacker News

• Theo kinh nghiệm hơn 20 năm làm việc trong ngành IT của tôi, nhiều người hay nhầm rằng một nhóm có các cuộc "tranh luận gay gắt" thì đồng nghĩa với một nhóm có hiệu suất cao. Kiểu này cũng thường thấy ở các nhóm hiệu suất thấp nhưng đầy xung đột. Có những quản lý công khai đưa ra phản hồi tiêu cực, hoặc các lập trình viên kỳ cựu nói với người mới kiểu không thích thì nghỉ, khiến nội bộ bị chia rẽ nặng nề. Những người được đào tạo bài bản, giỏi lập luận thường mang thái độ "ý kiến mạnh, cố chấp lỏng", rồi vẫn quyết liệt đẩy đến cùng cả những ý tưởng sơ sài, khiến mọi người mệt mỏi và bỏ cuộc. Trên thực tế, gần như không thể phản biện đầy đủ ngay trong thời gian thực, nên cũng có nhiều quản lý nhầm sự tự tin hay nhiệt huyết của họ với năng lực thực sự (tức là đúng). Góc nhìn ở đây là tranh cãi sôi nổi không mặc nhiên bảo đảm hiệu suất cao
  • Theo kinh nghiệm của tôi, vấn đề trong ví dụ trên không phải là không thể chứng minh ngay tại chỗ, mà là những người nói giỏi lại không biết lắng nghe. Năng lực quan trọng là nắm được bản chất của một lập luận dù nó được diễn đạt vụng về; lấy lý do truyền đạt kém để gạt đi là ngạo mạn. Nếu bản thân không chịu lắng nghe thì không thể tự nhận là "ý kiến mạnh, cố chấp lỏng". Chỉ chấp nhận những gì có bằng chứng khó khăn mới xuất hiện thì đó là "ý kiến mạnh, cố chấp chặt". Rốt cuộc, nếu tranh cãi gay gắt xảy ra thường xuyên thì bản thân điều đó lại là tín hiệu cho thấy nhóm đang rối loạn chức năng. Thảo luận trung thực và điềm tĩnh sẽ hiệu quả hơn cho nhóm
  • Trong phần trình bày, tác giả cũng nhấn mạnh thái độ tập trung vào vấn đề. Ví dụ, thay vì định hướng theo kiểu "cách này có giới hạn về khả năng mở rộng", mà lại hạ thấp chính ý tưởng của một cá nhân, thì cuộc thảo luận sẽ lập tức trở nên độc hại
• Tôi có kinh nghiệm dẫn dắt một nhóm phát triển pipeline xử lý hình ảnh C++ hiệu năng cao trong 25 năm. Tôi là thành viên của một đội ngũ lớn, quốc tế và liên ngành, thuộc một công ty imaging nổi tiếng toàn cầu. Vì phải cộng tác với chuyên gia ở nhiều lĩnh vực khác nhau nên việc hòa hợp với tất cả mọi người không hề dễ. Ai cũng nghĩ mình có "đáp án đúng" và đều có nhiệt huyết tạo ra kết quả tốt nhất. Vì thế, các cuộc tranh luận nảy lửa là điều đương nhiên và xảy ra thường xuyên. Phần lớn thời gian, chúng tạo ra kết quả rất tốt, và nguyên nhân vấn đề không nằm ở xung đột nội bộ. Theo kinh nghiệm của tôi, một nhóm giàu năng lực, sáng tạo và đầy nhiệt huyết có thể khá hỗn loạn, và việc quản lý kiểu nhóm này thực sự rất khó
  • Tôi tò mò về những quy tắc, quy trình làm việc và văn hóa nhóm cụ thể đã giúp anh quản lý như vậy suốt 25 năm. Ngoài ra, mức độ thay người trong nhóm là bao nhiêu, và bí quyết quản lý một đội ngũ có những va chạm gay gắt giữa các nhân tài là gì? Chắc không có giải pháp thần kỳ nào, nhưng các ví dụ thực tế hẳn sẽ rất hữu ích
• Bài viết này có vẻ đã nhầm lẫn giữa "trạng thái không có tranh cãi gay gắt" với "sự vắng mặt của thảo luận phản biện mang tính xây dựng". Theo kinh nghiệm của tôi, trong các nhóm trưởng thành có mức độ tin cậy cao, tranh cãi quá nhiệt không xảy ra vì không ai lo ý kiến của mình sẽ bị phớt lờ. Mọi người tin rằng ý kiến của mình chắc chắn sẽ được lắng nghe và cân nhắc, nên không có lý do gì để kích động. Tôi không hiểu câu "đoạn code không ai chất vấn thì chắc chắn sẽ gây sự cố trong môi trường production" có ý gì
  • Có lẽ ý là "đoạn code không bị ai phê bình rồi cũng sẽ nổ tung". Nhưng cũng không phải lúc nào cũng vậy
  • Hiện tượng các nhóm có độ tin cậy cao nhưng thảo luận không quá nóng thường dễ thấy hơn khi mức độ rủi ro và bất định khá thấp. Nếu rơi vào tình huống mọi người đều phải đẩy trực giác và lập luận đến giới hạn, thì lượng giao tiếp giữa các nút trong nội bộ nhóm sẽ trở nên mất cân bằng. Trách nhiệm sẽ kéo theo vai trò lãnh đạo, và nhiều góc nhìn sẽ liên tục nổi lên rồi lắng xuống. Nếu nhiệt độ thảo luận lúc nào cũng thấp, thì ngược lại cũng nên tự hỏi liệu nhóm có đang không tự thách thức mình đủ hay không
  • Có vẻ bài viết đang phản bác trực diện chính góc nhìn đó. Một "nhóm trông có vẻ yên ả" thật ra có thể đang né tránh xung đột, nên tránh luôn cả những bất đồng thật sự. Sự đồng thuận chỉ không lộ ra bên ngoài, còn các vấn đề gốc rễ thì vẫn bị chôn vùi
  • Thực tế đúng là có những trường hợp code hoặc kiến trúc không hề bị ai gọi ra vấn đề dù nó rất tệ
• Đọc lại thì tôi hiểu vì sao giọng điệu của bài viết lúc đầu gây hiểu nhầm. Thực ra định nghĩa của tác giả về an toàn tâm lý (PSYCHOLOGICAL SAFETY) là đúng, nhưng họ đang chỉ ra rằng nhiều người hiểu nhầm một "nhóm tử tế (nice team)" là một nhóm có an toàn tâm lý. Không phải cứ ai cũng gật đầu thì sẽ cảm thấy an toàn. Xung đột và an toàn không đối lập nhau. Cốt lõi của an toàn tâm lý thật sự là tạo ra môi trường nơi mọi người sẵn sàng tham gia vào xung đột mang tính xây dựng. Không phải mọi xung đột hay đồng thuận đều có tính xây dựng. An toàn tâm lý là xây dựng văn hóa nhóm nơi mọi người đều có thể thoải mái cả khi đồng ý lẫn khi không đồng ý
  • Một nhóm mà ai cũng đồng ý thực ra là một nhóm nguy hiểm tương ứng. Vì thế mới có hiện tượng sếp vừa nói xong là mọi người đồng loạt hùa theo
• Có ai thật sự bị ấn tượng mạnh bởi điểm "ý tưởng được đánh giá dựa trên chính nó chứ không phải người phát biểu" không? Cả bài này cho tôi cảm giác như Don Quixote đang chiến đấu với cối xay gió. Tức là dường như nó nhắm vào những kỹ sư khó chịu với một cuộc tranh luận kiểu lẽ thường vốn đã quá quen thuộc ngoài thực tế. Hoặc cũng có thể nó nhắm tới các lãnh đạo độc đoán kiểu độc tài, nhưng liệu những người như vậy có nghe bài này không? "Những nhóm tốt nhất của tôi chưa bao giờ im lặng. Những cuộc tranh luận sôi nổi giữa nhiều góc nhìn khác nhau được chào đón, sự bất đồng trong tôn trọng lẫn nhau..." Ai có thể nói rằng mình phản đối việc tôn trọng các góc nhìn đa dạng? Thật ra, tôi thấy cuộc thảo luận trước đó còn gợi mở suy nghĩ nhiều hơn
  • Về câu hỏi "liệu cuộc tranh luận này có mang lại insight đặc biệt nào không", thực tế đây là nội dung rất cơ bản, nhưng trước đây đã có những ví dụ điển hình như một checklist duy nhất có thể cứu mạng người, hay việc nhân viên Toyota được phép dừng dây chuyền sản xuất nếu có bất kỳ nghi ngờ nào. Trong lĩnh vực IT cũng vậy, chuyện xem thường đội ngũ và người khác (đặc biệt là giữa DEV/TEST) cực kỳ phổ biến. Người gây ra vấn đề có thể sẽ không đọc bài này, nhưng một ai đó khác trong nhóm có thể một ngày nào đó nhận ra rằng đây không phải điều bình thường, rồi họ sẽ làm việc theo cách khác hoặc tạo ra thay đổi. Bề ngoài thì không ai nói thẳng rằng họ "phản đối việc tôn trọng góc nhìn khác", nhưng thực tế vẫn có những người trong lòng gọi đội khác là "mấy thằng ngu đó", và với kiểu tư duy ấy thì chính tranh luận mang tính xây dựng cũng bị chặn lại
  • Điều quan trọng là trước tiên phải xác định bạn đang thuộc về kiểu nhóm nào. Những nhóm đề cao "đồng thuận im lặng" thực chất phần lớn là nơi một số ít người đã thỏa thuận trước các quyết định vị kỷ của họ, rồi không muốn ai nêu ý kiến mới trong cuộc họp toàn thể
• Tôi đã ngộ ra rằng phản hồi từ một người bạn phản biện nhưng tử tế đem lại nhiều điều để học hơn là từ một người bạn luôn đồng tình không phê phán
• Cũng như trong mọi mối quan hệ, mục tiêu không phải là "chiến thắng", mà là tạo ra một môi trường nơi nhu cầu của tất cả mọi người đều được đáp ứng
• Tôi băn khoăn không biết một người duy nhất có góc nhìn đúng đắn phải trụ thế nào khi phần lớn thành viên trong nhóm đều nói rất to nhưng lần nào cũng chỉ khăng khăng những ý kiến sai
  • Cách giải quyết nhanh nhất là ngừng can dự hoàn toàn. Nếu họ thực sự cứ sai mãi như vậy, thì tình hình sẽ tự xấu đi nhanh hơn ngay cả khi không có sự can thiệp của bạn. Hoặc cũng có thể lợi dụng chính sức mạnh của đối phương để khiến ý tưởng sai lầm tự hủy
  • Nếu bạn không phải là lãnh đạo thì đúng cũng không có ý nghĩa gì, và việc "tôi đã đúng" cũng không được tưởng thưởng. Có những dự án chỉ quan tâm đến bề ngoài chứ năng suất không quan trọng. Nếu bạn đã hiểu sai mục đích ngay từ đầu thì hành động "đúng" cũng không còn là đúng nữa. Khi đó bạn chỉ có thể quyết định hoặc tiếp tục làm vì tiền, hoặc rời đi
  • Nếu ngoài đường mà ai cũng chạy ngược chiều, thì đôi khi cũng cần nghi ngờ xem có phải chính mình mới là người đi ngược hay không
• Đã từng có lúc CTO (đồng sáng lập) là một nhân vật cực kỳ độc hại, đến mức tạo ra một bong bóng hạnh phúc trong nội bộ nhóm. Khi đó tôi từng cảm thấy đó là đội ngũ tuyệt vời nhất, nhưng rồi bong bóng ấy vỡ tan đột ngột, và một tình cảnh thực sự khủng khiếp lộ ra

[techiemann]

"Vẫn có những trường hợp trong lòng gọi đội khác là ‘bọn ngốc đó’, và với kiểu tư duy như vậy thì ngay cả tranh luận mang tính xây dựng cũng bị chặn lại.

Điều quan trọng là trước hết phải xác định xem bạn đang thuộc kiểu đội nào. Những đội cho rằng ‘đồng thuận trong im lặng’ là giá trị thực ra phần lớn là nơi quyết định ích kỷ của chỉ một số ít người đã được dàn xếp từ trước, và họ không muốn ý kiến mới được đưa ra trong các cuộc họp toàn thể."

Chắc chắn không nên tổ chức những cuộc họp kiểu Đại bản doanh như quân đội Nhật trong Thế chiến II. Văn hóa thiếu hợp tác, ngấm ngầm thù địch cả trong lẫn ngoài phe của mình vì sợ người khác có thể cô lập mình, ghi điểm, được thăng chức hoặc thành công cũng có lẽ là một vấn đề.