Từ khi nhận quản lý một đội kỹ sư hồi đầu năm, đánh giá hiệu suất với tôi đã chuyển từ chuyện người khác làm với mình thành chuyện mình phải đứng ra tổ chức. Tôi viết bài này một phần để sắp xếp lại suy nghĩ của chính mình, nên bạn hãy xem đây là ghi chép của một người đang mò đường, chứ đừng coi là chân lý.

Rốt cuộc đánh giá hiệu suất để làm gì?

#

Ở cấp nào thì mục đích cũng quy về hai điều: giúp mọi người tiếp tục học hỏi, và đảm bảo những ai đang làm vượt tầm vai trò của mình thực sự được ghi nhận và đền đáp xứng đáng.

Rất nhiều công ty nhỏ nói rằng họ không có thời gian hay nguồn lực để đánh giá hiệu suất, rồi lặng lẽ lấy thâm niên làm căn cứ duy nhất để xét xem ai đã sẵn sàng lên vị trí kỹ sư cấp cao (senior). Đó là một sai lầm, và không chỉ vì thâm niên là một thước đo lười biếng. Bỏ qua đánh giá tức là bỏ luôn kênh trao đổi hai chiều giữa công ty và nhân viên, và mối quan hệ làm việc sẽ vì thế mà đi xuống.

Chuyện này đúng theo cả hai chiều. Một kỹ sư có thể đang làm việc theo cách mà họ thật lòng tin là tốt nhất cho công ty, trong khi thói quen, phương pháp hay cách giao tiếp của họ lại đang dần lệch sang hướng chẳng giúp ích gì. Không có góp ý thì chẳng ai phát hiện ra. Ngược lại, công ty nào không bao giờ lắng nghe nhân viên qua một kênh bài bản thì cứ thế vô tư không biết mọi người thực sự nghĩ gì về công ty.

Mỗi bên nên kỳ vọng gì khi bước vào

#

Về phía nhân viên, danh sách không có gì phức tạp. Họ muốn biết công việc của mình gắn với mục tiêu của đội ra sao, mình đang làm tốt ở đâu, và cần cải thiện ở đâu, nói cụ thể chứ không phải kiểu “cần giao tiếp tốt hơn”. Họ muốn đóng góp của mình được ghi nhận, muốn có một cuộc trao đổi thực chất về lộ trình sự nghiệp và đào tạo, và một quy trình công bằng dựa trên công việc chứ không phải chuyện chính trị văn phòng.

Về phía tôi, tôi mong mọi người mang tới một bản tự đánh giá, tức là góc nhìn của chính họ về những gì đã làm tốt và chưa tốt. Tôi mong họ cởi mở đón nhận góp ý, thay vì mở màn như luật sư bào chữa. Tôi mong có một cuộc thảo luận thật lòng về mục tiêu sắp tới, và những chia sẻ thẳng thắn về việc họ thấy mình hợp với đội đến đâu. Kỳ đánh giá cũng là lúc tôi tự lên kế hoạch cho mình: cơ cấu đội, những ai có thể được thăng chức, ai cần được phát triển theo hướng nào.

Không có một khuôn mẫu chung cho mọi kỹ sư

#

Một đội kỹ sư gồm những người khác nhau về văn hóa, kinh nghiệm và chuyên môn, nên không thể dùng cùng một kịch bản đánh giá cho tất cả. Đối xử như nhau và đối xử công bằng không phải là một. Cách tiếp cận phải linh hoạt theo nhu cầu, giai đoạn sự nghiệp và mức đóng góp của từng người. Tối thiểu, bạn phải đảm bảo vai trò và trách nhiệm của mỗi kỹ sư được định nghĩa rõ ràng và thực sự tương xứng với mức lương của họ.

Chỗ nhạy cảm nhất là chức danh và lương. Khi ai đó còn băn khoăn về chức danh của mình, hoặc thấy mình đã sẵn sàng lên cấp, thì những lời động viên chung chung chẳng khác gì thuốc độc. Cái có tác dụng là những thứ cụ thể: cùng thống nhất một số thử thách hoặc mục tiêu dự án cụ thể làm mốc cho cấp tiếp theo, để chuyện thăng tiến có tiêu chí khách quan chứ không dựa vào cảm tính. Lương cũng vậy. Nếu ai đó thấy mình đang bị trả thấp, hoặc muốn nhận thêm trách nhiệm, hãy đưa vào kế hoạch của họ những mục tiêu đo được, nói rõ cần đạt được gì trước kỳ đánh giá tới thì mới có cơ sở để điều chỉnh. Rồi đến kỳ đánh giá đó, cả hai bên phải giữ đúng lời.

Góp ý về những điểm cần cải thiện cũng phải cụ thể như vậy. Một khóa đào tạo, một buổi workshop hay một dự án cụ thể nhắm vào đúng một điểm yếu cụ thể thì có ích. Còn một câu “tiếp tục nâng cao kỹ năng nhé” thì không.

Đặt mốc ngay từ buổi gặp đầu tiên

#

Buổi đánh giá đầu tiên với một thành viên mới trong đội chủ yếu là để đặt mốc ban đầu. Hai bên cùng xem lại vai trò đó thực sự gồm những việc gì, và nó đóng góp vào mục tiêu của đội, của công ty như thế nào. Thống nhất những kết quả đo được sẽ dùng để đánh giá hiệu suất. Đặt mục tiêu cho ngắn hạn và cho xa hơn. Đây cũng là lúc thích hợp để nói về văn hóa và cách hành xử mà đội kỳ vọng, góp ý sẽ được đưa ra như thế nào và vào lúc nào, người đó có thể dựa vào những nguồn lực và sự kèm cặp nào, và lộ trình sự nghiệp từ vị trí hiện tại của họ trông ra sao. Chẳng có gì trong số này hấp dẫn cả, nhưng nhờ có buổi này mà mọi kỳ đánh giá về sau đều dễ hơn.

Chương trình tôi dùng cho các kỳ sau

#

1. Nói chuyện phiếm. Nghe thì có vẻ vặt vãnh, nhưng nó giúp không khí bớt căng, và nhờ vậy mà phần còn lại của buổi nói chuyện thành thật hơn.
2. Điểm qua chương trình buổi gặp để không ai bị bất ngờ vì một chủ đề nào đó.
3. Những tiến bộ kể từ kỳ đánh giá trước: nói rõ ra họ đã tiến bộ ở đâu, vì hiếm ai tự nhận ra sự tiến bộ của mình.
4. Hiệu suất hiện tại, bắt đầu từ điểm mạnh.
5. Những điểm cần cải thiện, mỗi điểm kèm theo một mục tiêu cụ thể và thực tế.
6. Kế hoạch sự nghiệp, và công việc hiện tại có thực sự đưa họ tới đó không.
7. Chỉ tiêu, mục tiêu và những việc cụ thể cần làm trước kỳ đánh giá tới.

KPI chỉ có tác dụng khi được may đo cho từng người

#

Với kỹ sư trong một đội sản phẩm, KPI phải phù hợp với cả mục tiêu của đội lẫn từng cá nhân. Front-end, back-end và full-stack là những vai trò khác nhau, còn kỹ sư mới vào nghề (junior) và kỹ sư cấp cao thì càng khác nhau hơn nữa. Số lượng commit có thể nói lên điều gì đó về một lập trình viên mới vào nghề, nhưng lại chẳng nói được gì về một kỹ sư cấp cao mà thành quả chính là các quyết định kiến trúc. Vì thế, KPI phải được đặt ra qua trao đổi, chứ không phải chép từ một mẫu có sẵn.

Những mảng tôi thường xem xét:

• Chất lượng mã: tỉ lệ lỗi, mức độ tuân thủ các chuẩn chung, công việc của họ có hay phải sửa lỗi lại không
• Tiến độ dự án: các mốc và hạn chót đã hoàn thành đúng hẹn
• Đổi mới và giải quyết vấn đề: những cải thiện về hiệu quả, những bài toán khó thực sự được giải quyết
• Cộng tác: rà soát mã cho đồng nghiệp, đóng góp vào mục tiêu và các cuộc thảo luận của đội
• Phát triển bản thân: các mục tiêu học tập đã đạt, chứng chỉ, công nghệ mới đã nắm được
• Tác động tới khách hàng: góp ý từ người dùng, mức độ người dùng sử dụng những tính năng mà họ đã phát hành

Về phần đo lường được, kiểm thử đơn vị (unit test) là một yếu tố mà tôi ngày càng thấy ưng. Bài viết này trên InfoQ bàn về việc đưa kiểm thử đơn vị vào đánh giá hiệu suất, cả cách làm cụ thể lẫn ảnh hưởng của nó tới văn hóa của đội, và cho rằng nên kết hợp cả thước đo định tính lẫn định lượng về độ “khỏe” của mã nguồn. Đáng đọc nếu bạn đang tìm những KPI không biến kỹ sư thành những con số đếm dòng mã.

Chọn KPI nào thì chọn, hãy cùng nhau thống nhất trong buổi đánh giá hoặc buổi 1:1, và xem lại mỗi khi vai trò, dự án hay công nghệ thay đổi. Một KPI mà không ai đồng ý thì chẳng khác gì cây roi.

Mẫu tôi dùng để ghi

#

Mỗi người tôi giữ một tài liệu riêng, và mỗi kỳ đánh giá thì thêm một mục mới vào đó, để toàn bộ lịch sử nằm ở cùng một chỗ. Đây là khung sườn:

## Đánh giá hiệu suất: [Tên], [kỳ đánh giá]

**Vai trò và cấp bậc:** [chức danh, và cấp bậc đó nghĩa là gì trong đội này]
**Mục tiêu từ kỳ trước:** [chép lại từ mục của kỳ trước]

### Tự đánh giá (kỹ sư điền trước buổi gặp)
- Những gì đã làm tốt, kèm một hai ví dụ
- Những gì chưa tốt, và lần sau sẽ làm khác đi thế nào
- Một năm nữa muốn được làm gì

### Tiến độ với các mục tiêu của kỳ trước
- [Mục tiêu]: đạt / đạt một phần / chưa đạt, kèm bằng chứng

### Điểm mạnh (kèm ví dụ cụ thể)
- [Đã làm gì, khi nào, và điều đó thay đổi được gì]

### Điểm cần cải thiện (mỗi điểm kèm một mục tiêu)
- [Hành vi hoặc kỹ năng] → [thế nào thì được coi là "tốt hơn"] trước [ngày]

### Lộ trình sự nghiệp và cấp bậc
- Đang ở đâu so với cấp tiếp theo, và còn thiếu gì

### Mục tiêu đến kỳ đánh giá sau
1. [Mục tiêu đo được]
2. [Mục tiêu đo được]

### Những việc đã thống nhất
- [Ai] sẽ [làm gì] trước [khi nào]

Bản tự đánh giá phải được gửi tới trước buổi gặp một hai ngày, không bao giờ để đến lúc ngồi họp mới làm. Đọc trước bản này khiến cuộc nói chuyện khác hẳn: cứ hai lần thì có một lần chính kỹ sư đã tự nêu ra đúng điều tôi định nói, và hai bên có thể dành cả buổi để bàn xem nên làm gì với nó.

Câu hỏi cho phần tự đánh giá

#

Đây là những câu hỏi gợi ý mà tôi gửi trước cho mọi người. Tôi cố tình để chúng ở dạng câu hỏi mở, để câu trả lời cho tôi biết người đó nhìn nhận công việc của chính mình ra sao, chứ không chỉ liệt kê họ đã làm những gì:

• Kể từ kỳ đánh giá trước, bạn tự hào nhất về điều gì, và vì sao lại là điều đó?
• Bạn đã bị vướng ở đâu, và điều gì có thể giúp bạn gỡ được sớm hơn?
• Có góp ý nào từ đồng đội hay người rà soát mã cho bạn mà bạn vẫn còn nhớ mãi?
• Trong các mục tiêu của kỳ trước, bạn nghĩ mình đã đạt những mục tiêu nào, và muốn bỏ hay thay đổi mục tiêu nào?
• Tiếp theo bạn muốn học gì, và công việc hiện tại có cho bạn cơ hội học điều đó không?
• Với vai trò là quản lý của bạn, tôi nên làm gì khác đi?

Câu cuối cùng là câu khiến người ta im lặng ngượng ngùng lâu nhất, nhưng cũng mang lại những câu trả lời có ích nhất.

Góp ý cụ thể nghe như thế nào

#

Phần lớn những góp ý tồi trong buổi đánh giá không tệ vì gay gắt, mà vì mơ hồ. Dưới đây là sự khác biệt, kèm những ví dụ theo kiểu mà tôi cố gắng viết:

Mỗi góp ý cụ thể đều nêu ra một sự việc, nói rõ sự việc đó đã dẫn tới điều gì, và chỉ ra một việc người đó có thể làm tiếp theo. Viết như vậy tốn thời gian hơn, và đó chính là lý do tôi tự bắt mình ghi lại ví dụ dần dần trong suốt cả quý, thay vì đến tối hôm trước buổi đánh giá mới cố nhớ lại.

Viết ra giấy

#

Sau buổi gặp, hãy viết một bản tóm tắt: những điểm chính đã bàn, các vấn đề được nêu ra, những việc cần làm, và những mục tiêu mà cả hai đã thống nhất. Nghe thì có vẻ quan liêu, nhưng chính bản ghi này giúp tránh được màn “ơ, đâu có thống nhất như vậy” sáu tháng sau. Vấn đề nào đã ghi lại thì sẽ được theo dõi thay vì bốc hơi, danh sách việc cần làm trở thành phần mở đầu cho chương trình kỳ đánh giá sau, và người ta cũng nghiêm túc với mục tiêu hơn khi nó đã nằm trên giấy.

Toàn bộ hệ thống thật ra chỉ có vậy: kỳ vọng rõ ràng ngay từ ngày đầu, KPI may đo cho từng người, mọi thứ đều được ghi lại, và theo sát tới cùng từng việc cần làm. Một buổi đánh giá mà không phải là cuộc trao đổi hai chiều với kết quả đo được thì chỉ là làm cho có, và kỹ sư thì ngửi thấy mùi “làm cho có” ngay từ lúc nhận lời mời họp.

Buổi họp là phần dễ

#

Cấu trúc đơn giản đến mức gần như chẳng có gì để nói. Sau mỗi sprint hoặc mỗi giai đoạn dự án, cả đội ngồi lại với nhau và lần lượt trả lời ba câu hỏi:

1. Điều gì đã làm tốt?
2. Điều gì chưa ổn?
3. Mình có thể cải thiện gì?

Chỉ vậy thôi. Mấu chốt nằm ở vòng lặp phản hồi: đều đặn dừng lại, nhìn vào những gì đã thực sự diễn ra, rồi đưa những điều đó quay lại vào cách mình làm việc. Một đội không bao giờ chịu dừng lại thì sẽ chỉ lặp lại chính mình.

Buổi nhìn lại có ích khác buổi xả bực ở chỗ nào

#

Chủ yếu là ở sự thẳng thắn. Người ta chỉ dám nói ra vấn đề thật khi tin chắc rằng mình sẽ không bị làm khó vì điều đó, nên cảm giác an toàn trong phòng quan trọng hơn bất kỳ hình thức nào bạn chọn. Và những nhận xét sắc sảo nhất thường đến từ những người ít nói. Một buổi nhìn lại mà chỉ có mỗi trưởng nhóm nói thì thực chất là một buổi họp báo cáo tình hình, chỉ là rườm rà hơn.

Nửa còn lại là những gì diễn ra sau buổi thảo luận. Vấn đề nào đáng sửa thì trước khi ra khỏi phòng phải trở thành một đầu việc cần làm (action item), có tên người phụ trách và hạn chót rõ ràng. Rồi đến buổi nhìn lại tiếp theo, hãy mở đầu bằng cách xem lại các đầu việc lần trước. Đây là bước mà hầu hết các đội đều bỏ qua. Không gì giết chết buổi họp nhìn lại nhanh bằng việc mọi người lặng lẽ nhận ra mấy đầu việc đó chỉ để trang trí.

Khi có thể, hãy mang cả số liệu vào. Những ý kiến kiểu “sprint này có vẻ chậm” cứ bàn qua bàn lại mãi không đi đến đâu, trong khi một cái biểu đồ thường chốt được vấn đề ngay.

Những kiểu họp nhìn lại thất bại

#

Có ba kiểu tôi từng tận mắt chứng kiến. Một là buổi nhìn lại biến thành buổi đổ lỗi (hãy sửa quy trình, đừng nhắm vào con người). Hai là buổi nhìn lại dùng y nguyên một hình thức suốt cả năm, đến mức ai cũng tham gia như cái máy (hãy thay đổi cách làm). Ba là họp xong rồi thôi, chẳng ai theo sát việc gì cả. Như đã nói ở trên, kiểu thứ ba mới là kiểu chí mạng.

Nhân tiện, những điều này không chỉ áp dụng cho phần mềm. Chiến dịch tiếp thị, tổ chức sự kiện, dự án nghiên cứu, sản xuất: bất cứ công việc nào có chu kỳ lặp lại đều hưởng lợi từ cùng một vòng lặp này. Nhưng dù bạn họp nhìn lại ở đâu thì phép thử vẫn vậy: trước buổi tiếp theo, có điều gì thực sự thay đổi không? Nếu không, thì bạn chỉ đang nói suông mà thôi.

Đó là bản ngắn gọn. Bản dài hơn nằm ở bên dưới, vì số lần tôi góp ý rồi hỏng theo đúng một kịch bản nhiều hơn tôi muốn thừa nhận: tôi vừa nêu ra một chuyện, người kia lập tức gồng lên, và từ giây phút đó cả hai chẳng ai thật sự nghe ai nữa.

Vì sao người ta lại phản ứng phòng thủ

#

Phòng thủ không phải là cứng đầu, hay ít ra thì hiếm khi nó bắt đầu từ sự cứng đầu. Đó là phản ứng tự nhiên khi con người cảm thấy bị đe dọa, và một lời góp ý đe dọa người nghe nhiều hơn ta thường nghĩ. Ngoài mặt, bạn đang nói về một pull request hay một hạn chót bị trễ. Nhưng điều người kia nghe thấy lại là những câu hỏi khác hẳn: mình có làm tốt công việc này không, mình có còn chỗ đứng trong đội không, có phải người này đã âm thầm nghĩ như vậy về mình suốt mấy tháng nay rồi không.

Một khi đã có cảm giác đó, người ta sẽ dồn sự chú ý vào việc tự bảo vệ mình, chứ không còn để tâm đến điều bạn đang muốn nói. Bạn càng tranh luận gay gắt thì càng xác nhận rằng mối đe dọa là có thật. Vì vậy, phần lớn những cách làm hiệu quả dưới đây đều xoay quanh việc hạ bớt mức độ căng thẳng trước, rồi mới đi vào nội dung chính.

Cũng nên nhớ rằng có những người bước vào cuộc nói chuyện kiểu này khi trong lòng đã sẵn vết thương cũ. Có thể là một người quản lý trước đây chỉ mở miệng ra là để chê, hay một môi trường mà ai mắc lỗi là bị gạt ra rìa. Bạn không thể chữa lành quá khứ đó trong một buổi nói chuyện, nhưng nó giải thích vì sao đôi khi chỉ một nhận xét nhẹ nhàng lại nhận về phản ứng lớn hơn hẳn mức cần thiết.

Trước khi nói chuyện

#

Phần lớn các cuộc góp ý đã được định đoạt từ trước khi bắt đầu. Có vài việc bây giờ tôi làm mà trước đây thì không:

Tôi chỉ chọn một chuyện. Nếu tôi tích lại năm vấn đề rồi nói một lần, người kia sẽ nghe như đang bị buộc tội chứ không phải đang được góp ý. Bốn chuyện còn lại có thể đợi, và nhiều khi hóa ra chúng chỉ là hệ quả của chuyện đầu tiên.

Tôi nói sớm. Góp ý về một chuyện xảy ra từ sáu tuần trước sẽ bị nghe thành “Sao giờ mới nói?”, một câu hỏi hoàn toàn chính đáng mà tôi chẳng có câu trả lời nào ổn. Một hai ngày sau sự việc là vừa: đủ sớm để mọi thứ còn mới, đủ muộn để cả hai đã nguôi.

Tôi nói riêng, và tránh góp ý qua tin nhắn chat nếu có thể. Lời góp ý viết ra thì mất đi giọng điệu, và một người đang phòng thủ sẽ tự lấp chỗ trống đó bằng phiên bản tệ nhất có thể. Nếu buộc phải viết vì đội làm việc từ xa hoặc lệch múi giờ, tôi viết thật ngắn và đề nghị gọi điện nói chuyện trực tiếp.

Và tôi kiểm tra lại tâm trạng của chính mình. Nếu tôi đang bực, người kia sẽ nhận ra ngay từ câu đầu tiên, dù tôi có chọn lời thế nào đi nữa. Có những lần góp ý lẽ ra đã suôn sẻ hơn nhiều nếu tôi chịu đợi đến lúc hết bực.

Thực sự nên nói gì

#

Cấu trúc tôi hay quay lại là cấu trúc thường được gọi là tình huống – hành vi – tác động (situation, behaviour, impact – SBI): chuyện xảy ra lúc nào, người đó đã làm gì, và việc đó gây ra hậu quả gì. Điểm mấu chốt là phần nào cũng quan sát được. Trong đó không có gì nói về con người họ, chỉ có chuyện đã xảy ra.

Thử xem khác biệt khi áp dụng vào thực tế. Giả sử một lập trình viên merge một thay đổi vào chiều thứ Sáu mà không đợi ai review, và thay đổi đó làm hỏng chức năng thanh toán suốt cuối tuần.

Cách nói khiến người ta dựng tường ngay lập tức: “Lúc nào bạn cũng làm ẩu cho nhanh. Bạn cần cẩn thận hơn.”

Cách nói còn có cơ hội: “Hôm thứ Sáu, thay đổi ở phần thanh toán được merge mà không qua review, và chức năng thanh toán bị sập mấy tiếng vào thứ Bảy. Mình muốn hiểu chuyện gì đã xảy ra, vì mình không nghĩ là do bạn cẩu thả.”

Câu thứ hai chỉ nêu đúng một sự việc, nói rõ ràng nó đã gây thiệt hại gì, và kết thúc bằng việc mặc định rằng người kia có ý tốt. “Lúc nào cũng” và “không bao giờ” là những từ gây hại nhiều nhất. Chúng biến một sự cố đơn lẻ thành lời phán xét về tính cách, và người kia sẽ lập tức nghĩ ra ngay một ví dụ ngược lại để chứng minh bạn sai.

Tôi cũng cố nhận đó là quan sát của riêng mình. Những câu như “mình để ý thấy” hay “mình hơi lo” thành thật thừa nhận rằng đây là góc nhìn của tôi, nói từ phía tôi, và vẫn chừa chỗ cho khả năng tôi đã bỏ sót điều gì đó. Mà nhiều khi đúng là tôi bỏ sót thật.

Rồi tôi ngừng nói và đặt câu hỏi: “Từ phía bạn thì chuyện này thế nào?” Thường sẽ có bối cảnh mà tôi không biết, chẳng hạn một hạn chót do người khác đặt ra, hay người lẽ ra review hôm đó lại nghỉ ốm. Ngay cả khi không có bối cảnh nào như vậy, câu hỏi đó cũng cho người kia thấy đây là một cuộc trò chuyện, chứ không phải một bản án.

Lời góp ý cũng dễ tiếp nhận hơn nhiều khi đi kèm một hướng đi tiếp. Không phải một danh sách vấn đề, mà là “Lần sau mình thử… được không?”. Còn tốt hơn nữa nếu hướng đi đó do chính người kia đưa ra.

Khi người kia vẫn phản bác

#

Bạn có thể làm đúng mọi thứ mà vẫn gặp phản kháng. Sự phản kháng thường xuất hiện dưới vài dạng dễ nhận ra, và mỗi dạng cần một cách phản hồi hơi khác nhau.

Phổ biến nhất là phủ nhận: “Không phải như vậy đâu.” Đừng tranh cãi chuyện đó. Hãy quay về những thứ cả hai cùng nhìn thấy được, như commit, tin nhắn hay ngày tháng, rồi hỏi xem mình đang bỏ sót điều gì. Nếu bản thân sự việc thật sự còn chỗ chưa rõ, cứ nói “Mình với bạn cùng xem lại rồi mai nói tiếp nhé” là được.

Kế đến là lái sang chuyện khác, kiểu “Thì tại yêu cầu cứ thay đổi liên tục” hay “Người kia cũng làm vậy mà”. Trong những câu này thường có phần đúng, nên hãy ghi nhận thay vì gạt đi: “Cũng đúng, và mình cũng nên xử lý luôn chuyện yêu cầu thay đổi liên tục.” Rồi nhẹ nhàng kéo câu chuyện về: “Còn tách riêng chuyện đó ra, mình muốn nói về bước review.”

Phản công, như “Chính bạn cũng merge mà không review suốt đấy thôi”, là kiểu khó kìm mình nhất để không đáp trả lại. Hãy hít một hơi. Nếu họ nói đúng, cứ thừa nhận, vì đó là cách nhanh nhất để hạ nhiệt, và bạn vừa thể hiện đúng sự cởi mở mà bạn đang mong ở họ. Rồi quay lại vấn đề ban đầu.

Thu mình lại, dù là im lặng hay buông một câu “Ừ, sao cũng được”, trông thì giống đồng ý nhưng thực ra không phải. Tôi sẽ nhẹ nhàng gọi tên điều đó, kiểu như “Có vẻ chuyện này nghe hơi khó chịu, không sao đâu”, rồi đề nghị để lúc khác nói tiếp. Cố ép một người đã thu mình phải lên tiếng thì bạn chỉ nhận về một câu trả lời cho có.

Xin lỗi rối rít (“Mình tệ quá, mình xin lỗi nhiều lắm”) cũng là phòng thủ, chỉ là hướng vào bên trong. Người đó đang tự bảo vệ mình bằng cách tự chê mình trước khi bị người khác chê. Hãy trấn an họ rằng đây chỉ là một chuyện cụ thể chứ không phải đánh giá toàn bộ năng lực của họ, rồi chuyển sang bàn xem tiếp theo sẽ làm gì.

Với tất cả những trường hợp trên, có một nguyên tắc tôi luôn cố giữ: không để mình bị cuốn theo cảm xúc của người kia. Khi ai đó bắt đầu phòng thủ, phản xạ của tôi là phòng thủ lại, và đó chính là nước đi chắc chắn nhất để nhấn chìm cuộc nói chuyện. Chỉ cần tôi giữ được giọng điềm tĩnh, không khí thường sẽ tự hạ nhiệt. Cũng nên nói thẳng ra cảm xúc đang có, kiểu như “Mình hiểu là nghe chuyện này chắc bực lắm”, thay vì giả vờ như không hề có chút căng thẳng nào.

Biết lúc nào nên dừng

#

Có những lúc chẳng cách nào ở trên có tác dụng, bức tường vẫn sừng sững ở đó. Lúc ấy càng cố ép thì càng vô ích. Bạn hoàn toàn có thể tạm gác cuộc nói chuyện lại, đợi một hai ngày cho mọi thứ lắng xuống rồi hẵng quay lại. Lời góp ý thì để đến mai vẫn còn đúng, và sau khi đã ngủ một đêm, người ta thường biết nhìn lại mình hơn nhiều. Vài cuộc nói chuyện tiếp nối tốt nhất mà tôi từng có lại bắt đầu bằng câu của chính người kia: “Mình đã nghĩ lại về điều bạn nói hôm trước.”

Điều này là điều tôi mất nhiều thời gian nhất mới học được.

Sau cuộc nói chuyện

#

Những gì diễn ra trong tuần tiếp theo cũng quan trọng không kém chính cuộc nói chuyện. Nếu người kia thay đổi hành vi, hãy nói ra là bạn đã để ý, nói rõ ràng và nói sớm. Đó là cách để họ biết góp ý từ bạn không phải lúc nào cũng là tin xấu, và nó giúp lần nói chuyện sau dễ dàng hơn.

Và khi thấy phù hợp, hãy hỏi lại xem người kia cảm thấy thế nào về lời góp ý. Một câu “Mình nói vậy có công bằng không?” giúp mọi thứ cân bằng trở lại, và cho thấy sự cởi mở mà bạn cũng mong nhận lại từ họ. Từ khi chuyển sang làm quản lý, tôi bắt đầu hỏi câu này thường xuyên, và nhờ vậy đã phát hiện ra vài lần điều tôi nghĩ trong đầu thì rất rõ ràng, nhưng nói ra miệng lại không rõ được như thế.

Tóm lại

#

Hạ bớt cảm giác bị đe dọa trước, rồi mới nêu vấn đề. Chọn một chuyện, nói riêng và nói sớm, mô tả hành vi cùng tác động của nó thay vì nhận xét con người, và hỏi xem người kia nhìn nhận thế nào trước khi đề xuất cách sửa. Khi họ phản bác, đừng đáp trả lại. Hãy ghi nhận cảm xúc, quay về với sự việc, và sẵn sàng dừng lại để hôm khác nói tiếp. Sau đó nhớ theo dõi tiếp, vì niềm tin được xây dựng chính ở những lần nói chuyện sau cuộc nói chuyện ấy.