Questions behind questions: cách giao tiếp hiệu quả để nâng tầm sự nghiệp (phần 1)

Trong giao tiếp, truyền tải thông điệp hiệu quả là thách thức lớn với người làm kỹ thuật. Đặc biệt khi xử lý vấn đề phức tạp hoặc mâu thuẫn, các câu hỏi thường mang trong mình nhiều ý nghĩa và mục đích sâu xa hơn. Kỹ năng hỏi-trả lời để lấy thông tin chỉ trở nên cần thiết khi bạn thực sự trải qua tình huống này. Một bí kíp để tăng sự hiệu quả là áp dụng tư duy "Questions behind questions" (QbQ)¹.

⭐️ Trong bài viết này, bạn sẽ học được:

1. Questions behind Questions trong thực tế ra làm sao

2. Cách thăm dò để có thêm thông tin

3. Kĩ thuật phân tích sâu về nguyên nhân cho câu hỏi

Ví dụ, khi một developer hỏi: "Hi team, mình có nên sử dụng framework mới này không?" thì câu hỏi đằng sau có thể là: "Framework hiện tại có vấn đề gì không?" hoặc "Framework mới này có thể giải quyết vấn đề gì hiện tại của chúng ta".

Chúng ta sẽ quay lại ví dụ này vào cuối bài.

Bắt đầu nào! 💪🏻

---

👋 Hey, mình là Bryant (Dũng), chào mừng bạn đến Growth Engineering Journal newsletter hàng tuần của mình, nơi mình chia sẻ về Engineering Growth, phát triển bản thân và những thứ hay ho mình học được qua quá trình bán mình cho tư bản.😜

---

Photo by Pavan Trikutam on Unsplash

I. Questions behind questions trong thực tế

1. Nếu bạn là người được hỏi

Sếp: “hey Bryant, feature ABC này sao rồi? Có cần anh support gì không?”

Nếu là bạn thì bạn sẽ trả lời câu hỏi này như thế nào?

Bạn có nên trả lời thẳng theo nghĩa đen, ngắn gọn và chung chung không? Thay vào đó hãy thử lùi lại một chút và suy nghĩ sâu hơn, câu trả lời của bạn sẽ phụ thuộc vào một số yếu tố sau:

• Điều gì có thể khiến sếp cảm thấy rủi ro?

• Điều gì làm cho sếp cảm thấy yên tâm và an toàn?

• Điều gì khiến sếp tin rằng bạn có thể làm được điều này?

❌ Câu trả lời tệ:

“Mọi thứ vẫn ổn trong tầm kiểm soát của em sếp à!”

Câu này chỉ nên dùng khi bạn tự tin rằng mối quan hệ của bạn và sếp có sự tin tưởng rất cao, task không quan trọng (nhưng vẫn phải ăn chửi nếu bạn làm sai), sếp nắm được phần lớn thông tin, số liệu. Ngược lại, đây là câu trả lời rất chung chung, và nếu gặp sếp khó tính, họ sẽ xoay bạn cho tới khi bạn cung cấp đủ cái họ cần để họ tin là bạn không gây ra rắc rối cho họ.

✅ Câu trả lời hiệu quả:

“Mọi thứ vẫn ổn. Em mới clarify lại với BA lại về phần logic abc sáng nay, đã break task ra cho Frontend và Backend và hiện tại đang implement theo đúng timeline. Estimation tới thứ 5 này done và sẽ có call với team để test trên local trước khi tạo PR merge vào dev, rồi sau đó sẽ smoke test thêm lần nữa. Có gì concern e sẽ raise tiếp.”

Câu này tuy dài nhưng nó cung cấp đủ thông tin cần thiết, tạo sự an tâm, đồng thời bạn cũng cho sếp thấy mình thực sự theo sát công việc.

Photo by Tingey Injury Law Firm on Unsplash

2. Nếu bạn là người đặt câu hỏi

Lật ngược lại góc nhìn, khi bạn là tech lead và hỏi team member:

Tụi mình có đang đi đúng plan cho sprint này không mọi người?

Đây là câu hỏi dạng yes-no. Việc trả lời có hoặc không khiến cho bạn không có đủ thông tin cần thiết và sau đó chính bạn phải đặt thêm nhiều câu hỏi cho team member nhằm tìm ra được rủi ro tiềm ẩn ảnh hưởng tới delivery của sprint này.

Thay vào đó thì bạn có thể hỏi:

Hi team, tụi mình có đang đi đúng plan cho sprint này không? Vì sprint này có feature abc, estimate ban đầu là x ngày nhưng khi implement thì gặp vài issue phát sinh. Mình muốn tránh tình trạng delivery low quality, nên có thể xem xét cần rút gọn lại code phần quan trọng nhất của feature, để cuối sprint có cái show cho user/PO. Đồng thời lấy feedback cho toàn bộ workflow của phần này.

Câu hỏi đầu tiên không hẳn là tệ, nhưng câu hỏi thứ hai mình nêu lên được tính quan trọng cần thiết và tập trung sự chú ý của mọi người lên vấn đề trọng tâm hơn. Từ đó nhận được câu trả lời nhiều thông tin hơn. Nói tóm lại, mình thêm ngữ cảnh vào câu hỏi để nhận được câu trả lời hiệu quả.

Khi bạn ở vai trò là người trả lời, bạn thầm nghĩ "Tại sao người ta không thể đặt những câu hỏi hay hơn để mình trả lời cho đầy đủ?".🧐 Và tới khi bạn ở vài trò người đặt câu hỏi, thì bạn lại cũng hành xử như vậy.😂

Nên bạn chỉ có thể kiểm soát hành vi và suy nghĩ của chính mình.

Để giao tiếp được hiệu quả, việc tư duy theo hướng QbQ là một phương pháp giúp bạn tìm ra được thông tin đầy đủ và mong muốn thực sự ẩn đằng sau câu hỏi đơn giản.

II. Cách thăm dò để có thêm thông tin

Có một vấn đề là đôi khi, ngay cả người đặt câu hỏi cũng thậm chí không biết là mình thực sự muốn cái gì, nên việc bạn trả lời ngay chẳng khác nào nhắm bắn một mục tiêu đang di động. Và thậm chí là cuộc hỏi-đáp có khi đi xa hơn và dường như bạn đang sa vào vũng lầy. Dưới đây là một số cách để có thể giúp bạn có thêm nhiều thông tin hơn:

Photo by mari lezhava on Unsplash

1. 💬 Xác nhận và hỏi thêm thông tin

Khi nhận được câu hỏi, hãy xác nhận lại với người hỏi để đảm bảo bạn hiểu đúng.

Người đặt câu hỏi của bạn có thể không biết cách diễn đạt rõ ràng điều họ muốn. Dưới đây là vài câu bạn có thể sử dụng để bắt đầu:

• Excellent question! Bạn có thể nói thêm chút về context về việc này không? Vì có thể mình có thể biết mà share thêm những gì liên quan.

• Trả lời 1-2 câu rồi hỏi. Điều gì làm bạn hỏi vậy?

Một số lưu ý:

Nên chú ý hỏi “Why-Tại sao” vừa đủ, mặc dù why là ngắn gọn cần thiết nhưng nếu hỏi liên tục why, why, why có thể gây ra tác dụng ngược khiến người được hỏi cảm giác bị thẩm tra và trong tâm thế đề phòng. Thay vào đó có thể thay bằng “What makes you-Điều gì khiến cho bạn”. Theo kinh nghiệm của bản thân, câu hỏi What khả năng đem lại câu trả lời chính xách nhiều hơn.

2. 📋 Đưa ra giả định và kiểm chứng

Đôi khi, bạn cần đưa ra giả định dựa trên câu hỏi và kiểm tra lại với người hỏi.

Một ví dụ gần đây, trong quá trình chuẩn bị proposal, mình đã để vào đó toàn bộ chi tiết cho phần technical, cost, để mấy sếp có thể đem đi trình bày với khách hàng. Đứng ở góc độ technical mà nói, proposal đã trình bày đầy đủ thông tin cần thiết, nhưng điều bất ngờ là sếp yêu cầu họp gấp, bổ sung thêm vài ý nữa, và yêu cầu cả team phải mô tả thế này thế kia. Sau 5’ được sếp giải thích, mình nhận ra vấn đề đó là proposal làm quá thiên về phần technical nhưng khách hàng lại là dân non-tech. Và thế là mình hỏi lại sếp:

Mình: Vậy e cần thêm tóm tắt ngắn gọn cho dân non-tech đọc cũng hiểu phải hông sếp?

Sếp: Đúng rồi, chính xác!

Easy money, thế là cả team hiểu ra vấn đề cốt lõi.

3. 🗣️Paraphrasing (diễn giải lại)

Diễn giải lại câu hỏi bằng lời của bạn để xác nhận sự hiểu biết của bạn là đúng. Ví dụ:

"Vậy ý bạn muốn là cần check lại phần này để đảm bảo không có lỗi, đúng không?"

---

Photo by Belinda Fewings on Unsplash

III. Phân tích sâu hơn về nguyên nhân của câu hỏi

• Tìm kiếm động cơ đằng sau câu hỏi: Đặt câu hỏi về mục đích cuối cùng của người hỏi. Ví dụ: "Bạn muốn đảm bảo rằng tính năng này thân thiện với người dùng, đúng không?"

• Đánh giá tác động của câu trả lời: Hiểu rằng câu trả lời của bạn có thể ảnh hưởng đến các quyết định tiếp theo. Hãy cân nhắc kỹ trước khi trả lời để đảm bảo rằng bạn đang giúp giải quyết vấn đề thực sự.

Trở lại ví dụ ban đầu

Tình huống: Một developer hỏi:

"Mình có nên sử dụng framework mới này không?"

Câu hỏi đằng sau câu hỏi:

• "Bạn có lo ngại gì về framework hiện tại không?"

• "Bạn nghĩ framework mới này có thể giải quyết được vấn đề nào hiện tại của team?"

• "Có yếu tố nào khác bạn đang cân nhắc khi đề xuất sử dụng framework mới này không?"

Phân tích và xử lý:

1. Lắng nghe và xác nhận: "Mình hiểu rằng bạn đang cân nhắc sử dụng framework mới này vì bạn thấy có vấn đề với framework hiện tại. Đúng không?"

2. Đặt câu hỏi ngược để làm rõ: "Framework hiện tại có điểm nào bạn thấy không ổn?" hoặc "Bạn đã thử nghiệm framework mới này trong môi trường nào chưa?"

3. Phân tích nguyên nhân: "Bạn có nghĩ rằng framework mới này sẽ giúp cải thiện hiệu suất hoặc dễ bảo trì hơn không?"

Kết quả mong đợi:

• ✅ Xác định rõ ràng lý do đằng sau đề xuất sử dụng framework mới.

• ✅ Đưa ra quyết định dựa trên thông tin đầy đủ và hiểu biết sâu sắc về vấn đề.

• ✅ Đảm bảo sự hợp tác và đồng thuận trong team về quyết định cuối cùng.

---

Tóm tắt

• Đừng vội nhảy vào cuộc trao đổi. Người đặt câu hỏi cho bạn có thể cũng không biết tại sao họ lại có thắc mắc đó, hãy là rõ vẫn đề để không biến cuộc trao đổi thành “mục tiêu di động”.

• Xác định mối quan tâm thực sự của họ có thể là gì. Điều gì có thể khiến họ cảm thấy rủi ro? Điều gì sẽ khiến họ tin tưởng rằng bạn có được điều này?

• Dùng các kĩ thuật như: xác nhận và hỏi thêm thông tin, đưa ra giả định và kiểm chứng, paraphrasing (diễn giải lại) để thăm dò và thu thập thêm thông tin

• Việc tư duy Questions behind questions đòi hỏi phải luyện tập có chủ đích, và cần thời gian. Nhưng đừng lo, vì theo thời gian bạn sẽ thoải mái và thực hành nhuần nhuyễn hơn. 💪🏻

Update: bạn có thể xem phần 2 của series Giao tiếp hiệu quả trong công việc tại đây:

Bottom Line Up Front: cách giao tiếp hiệu quả để nâng tầm sự nghiệp (phần 2)

---

📢 Weekly Shoutouts:

• From stagnation to being the most valuable company in the world bởi Orel Zilberman.

• The Secret to a Healthy Relationship with Work của Kevin Naughton Jr.

• Những sai lầm trong lãnh đạo và quản lý cho người mới bắt đầu từ Quang Nguyen.

• Can you please stop telling me to live my best life please của Tom Cox.

Như thường lệ, đừng ngần ngại thả ❤️ hay để lại comment cho newsletter tuần này nếu như bạn đã học được một điều gì đó mới mẻ, hay có một suy nghĩ nào đó từ lá thư này. Mình rất mong nhận được ý kiến từ độc giả của mình (và nếu bạn đã làm được đến mức này thì mình rất trân trọng)🙏🏻

Hẹn gặp mọi người trong bài viết tiếp theo 🤖!

Bryant!

1. "Questions behind questions" là khái niệm chỉ các câu hỏi ẩn sau câu hỏi ban đầu, nhằm tìm hiểu sâu hơn, làm rõ vấn đề hoặc khám phá động cơ của người hỏi. Tư duy theo QbQ giúp chúng ta tiếp cận hiệu quả hơn và kích thích sự chủ động để tìm ra câu trả lời sâu sắc hơn.