Crucial Conversations: cuốn sách 2002 dạy FDE nói chuyện khi cuộc họp sắp hỏng

Cuốn sách này ra năm 2002. Nó đã bán được hơn hai triệu bản, được dịch sang 28 thứ tiếng, và vẫn đáng đọc với một engineer muốn làm FDE hơn phần lớn tài liệu về agent ra mắt năm nay.

Lý do nằm ở bản chất công việc. Người làm FDE ngồi sát khách hàng, nên một buổi họp hỏng có thể kéo dự án chậm lại chẳng kém một con bug trên production: khách hàng thấy bị coi thường, kỹ sư thấy bị đổ lỗi, và từ lúc đó không ai còn nói thật.

Crucial Conversations: Tools for Talking When Stakes Are High viết riêng về đúng những khoảnh khắc như vậy.

Ai viết, và có những bản nào?

Các tác giả là Joseph Grenny, Kerry Patterson, Ron McMillan và Al Switzler. Ấn bản mới hơn có thêm Emily Gregory. Crucial Learning, công ty của chính các tác giả, giới thiệu họ là những nhà tư vấn doanh nghiệp làm việc ở nhiều nước. Sách được McGraw-Hill in lần đầu năm 2002, bản thứ hai ra năm 2012.

Cuốn sách không đứng một mình. Crucial Learning xây một khóa học dựa trên chính các nguyên tắc trong sách, tên là Crucial Conversations for Mastering Dialogue. Mục tiêu khóa học là giúp người học nêu ra mối lo, vượt qua bất đồng và đi đến thống nhất vào lúc quan trọng nhất.

Bài học đầu tiên: chọn đúng cuộc trò chuyện

Bài đầu của khóa học không dạy cách nói. Nó dạy bạn nhận ra những cuộc trò chuyện đang chặn đường bạn tới thứ mình muốn. Bước này nghe đơn giản, nhưng với FDE, một cuộc trò chuyện bị né có thể giữ dự án đứng yên mà không ai gọi tên.

Thử hình dung bạn đang deploy một hệ thống cho một ngân hàng. Dữ liệu khách hàng đưa sai định dạng suốt ba tuần, và cả đội lặng lẽ viết code vá thay vì nói thẳng với trưởng phòng dữ liệu bên họ. Cuộc trò chuyện đang chặn dự án không nằm ở pipeline. Nó là cuộc trò chuyện chưa ai dám mở ra.

Ý thứ nhất: an toàn trước, nội dung sau

Đây là ý đáng giữ nhất. Theo Crucial Learning, khi đứng trước một Crucial Conversation, mục tiêu đầu tiên của bạn là tạo cảm giác an toàn. Phản xạ quen của nhiều kỹ sư là đưa thêm dữ liệu, thêm log, thêm bằng chứng. Nhưng nếu bên kia chưa thấy an toàn, thêm bằng chứng dễ bị nghe thành thêm lời buộc tội.

Ý thứ hai: an toàn có hai chân

Crucial Learning chia an toàn thành hai điều kiện, và cách chia này rất hợp với tư duy debug của dân kỹ thuật. Mutual Purpose nghĩa là bên kia tin bạn quan tâm đến mối lo của họ. Mutual Respect nghĩa là bên kia tin bạn quan tâm đến chính họ, với tư cách một con người.

Hai điều kiện này hỏng theo hai kiểu khác nhau. Khách hàng nghĩ bạn chỉ muốn đóng ticket cho xong là hỏng Mutual Purpose. Họ nghĩ bạn chê đội IT của họ kém là hỏng Mutual Respect. Muốn sửa đúng thì phải chẩn đoán đúng chân nào đang gãy, cũng giống như phải đọc đúng stack trace thì mới vá đúng chỗ.

Bài 8 của khóa học, Seek Mutual Purpose, đi thêm một bước: tìm điểm chung ngay cả khi tưởng như không có. Trong một deployment, điểm chung đó thường đã có sẵn. Cả hai bên đều muốn hệ thống chạy được trên production, chỉ là chưa ai nói ra câu ấy.

Ý thứ ba: Contrasting, công cụ dùng được ngay ngày mai

Crucial Learning định nghĩa Contrasting là một câu dạng không/có (don’t/do), và xếp nó vào nhóm kỹ thuật khôi phục an toàn. Đầu tiên bạn nói rõ điều mình không có ý, sau đó nói điều mình thật sự muốn.

Lấy lại ví dụ ngân hàng. Trưởng phòng dữ liệu nghe bạn nhắc chuyện định dạng sai và lập tức phòng thủ. Một câu Contrasting có thể là: “Tôi không có ý nói đội anh làm sai. Tôi muốn hai bên cùng chốt một định dạng để tuần sau go-live đúng hạn.” Câu đầu sửa Mutual Respect, câu sau nhắc lại mục tiêu mà cả hai bên cùng muốn.

Contrasting hỏng ở đâu khi mới tập?

Lỗi hay gặp nhất là biến Contrasting thành lời xin lỗi cho có. “Tôi không có ý chê đội anh, nhưng mà…” rồi tiếp theo là đúng lời chê đó. Chữ “nhưng mà” xóa sạch nửa câu đầu, và bên kia sẽ nghe ra ngay.

Lỗi thứ hai là nói nửa “không” mà quên nửa “có”. Chỉ phủ nhận thì bên kia biết bạn không muốn gì, nhưng vẫn chưa biết bạn muốn gì, nên Mutual Purpose vẫn treo lơ lửng.

Lỗi thứ ba là dùng Contrasting khi câu “không” không thật: nếu bạn thực sự nghĩ đội họ làm sai, hãy tìm cách nói điều đó một cách tôn trọng thay vì phủ nhận nó.

Ai nên đọc, và đọc theo thứ tự nào?

Nếu bạn là developer có 2 đến 8 năm kinh nghiệm, chủ yếu làm việc qua ticket và Slack, cuốn sách sẽ lấp đúng chỗ trống lớn khi chuyển sang FDE. Hãy đọc sách trước, rồi để ý ba ý ở trên. Khóa học là bước sau, dành cho người muốn được luyện có hướng dẫn, và bản tự học online là lựa chọn dễ bắt đầu nhất.

Khi đọc JD, hãy để ý những dòng nói về làm việc với stakeholder hay xử lý tình huống mơ hồ cùng khách hàng: đó là chỗ bạn có thể đem kỹ năng trong sách ra chứng minh.

Trong CV và khi phỏng vấn, đừng viết “giao tiếp tốt”. Hãy kể một lần cụ thể bạn mở ra một cuộc trò chuyện khó, bạn đã làm gì để giữ an toàn, và kết quả ra sao.

Code tốt giúp bạn được mời vào phòng họp với khách hàng. Còn được giữ lại trong phòng hay không thì phụ thuộc vào việc khách hàng có còn dám nói thật với bạn hay không.