Tôi là người New Zealand sống ở Seoul. Bài này kể lại môi trường phát triển phần mềm ở Hàn nhìn từ bên trong, từ cả hai phía của bàn tuyển dụng, và những gì tôi muốn nói với ai đang tính chuyện sang đây làm việc.

Tôi đến đây bằng cách nào

#

Con đường của tôi bắt đầu từ bậc thạc sĩ. Sau khi học cử nhân ở Đại học Waikato và làm vận hành mạng một năm ở một công ty viễn thông tại New Zealand, tôi học thạc sĩ khoa học máy tính ở Đại học Kyung Hee từ tháng 3/2017 đến tháng 2/2019. Mỗi học kỳ, phòng lab của chúng tôi đều đi dự KSC và KCC, hai hội nghị tin học trong nước. Ở KSC 2018 tại PyeongChang, nhà tài trợ có nhiều công ty công nghệ lớn nhất Hàn Quốc, lại có cả gian hàng tuyển dụng cho ai đang tìm việc. Nếu bạn là sinh viên cao học nước ngoài ở Hàn thì điều này đáng để biết.

Từ đó đến nay:

Phần kỹ thuật là nửa quen thuộc. Startup hỗ trợ khách hàng là nơi tôi học được rằng một phần lớn việc phát hành phần mềm thực ra là vận hành, còn backend của nền tảng cho nhà sáng tạo chạy trên nhiều bộ công nghệ hơn mức tôi sẽ chọn bây giờ. Khác biệt riêng của Hàn Quốc nằm ở rìa. Naver là công cụ tìm kiếm bạn buộc phải để ý: khi ra mắt website mới cho Kiwi Alumni, tôi làm SEO cho cả Google lẫn Naver. Các nền tảng Hàn Quốc thu thập dữ liệu (crawl) bằng những cái tên bạn khó đoán ra (crawler của Naver tên là Yeti, còn bản xem trước link trong KakaoTalk là do một thứ tên kakaotalk-scrap lấy về). Và ngân hàng trực tuyến ở Hàn đến giờ vẫn đòi cài phần mềm bảo mật riêng của họ lên máy tính của bạn.

Nhưng chẳng cái nào trong số đó là phần khó.

Nunchi là gì, và vì sao nó không phải là “optics”

#

눈치 là cảm giác về việc người khác đang nghĩ gì, muốn gì, mong đợi gì, nắm bắt từ tình huống chứ không phải từ lời họ nói ra. 눈 nghĩa là “mắt”, và Euny Hong, tác giả cuốn The Power of Nunchi (2019), cuốn sách giới thiệu nunchi bằng tiếng Anh được biết đến nhiều nhất, dịch cả từ này là “eye-measure”, tức là “đo bằng mắt”. Nó xuất hiện trong mấy cách nói hằng ngày. Người “눈치가 빠르다” (nunchi nhanh) là người đọc tình huống rất nhanh, kiểu người mình gọi là tinh ý. Người “눈치가 없다” (không có nunchi) thì không đọc được gì cả, và đó chẳng phải lời khen. Còn “눈치를 보다” (nhìn nunchi) là liên tục để ý phản ứng của người khác, thường là cấp trên, rồi điều chỉnh để mình luôn ở phía an toàn, rất giống chuyện “nhìn sắc mặt” mà dân văn phòng Việt Nam hay nói.

Từ tiếng Anh mà người ta hay chọn ở đây là “optics”, và tôi nghĩ nó sai. Optics là chuyện một việc trông như thế nào từ bên ngoài, bất kể thực chất ra sao, kiểu “công bố thưởng ngay trong tuần cắt giảm nhân sự thì optics rất tệ”. Nó là chuyện hình thức, và người quản lý nó là người đang bị nhìn. Nunchi phần lớn lại chỉ theo hướng ngược lại: vấn đề không phải là bạn trông thế nào trong mắt người khác, mà là bạn nhìn người khác rõ đến đâu. Hai thứ chỉ gặp nhau ở “눈치를 보다”, khi bạn quan sát mọi người để quản lý hình ảnh của mình trong mắt họ, và đó chính là phiên bản xuất hiện trong các bài báo nước ngoài viết về văn phòng Hàn Quốc.

Ví dụ trong những bài báo đó lần nào cũng na ná nhau: không về trước trưởng nhóm, cái nunchi người ta phải để ý khi thật sự xin nghỉ phép năm (연차), biết lúc nào thì được phép rời một buổi 회식 (bữa ăn tối cùng đội), và quyết định nếu phản bác cấp trên thì nói ngay trong cuộc họp hay lặng lẽ nói sau. Dù bạn nghĩ gì về từng ví dụ, chúng đều có chung một hình dạng: mỗi cái là một quy tắc ai cũng theo mà không ai nói ra.

Và nó là một vấn đề tách biệt với ngôn ngữ. Tiếng Hàn nằm trong lời nói. Nunchi nằm trong mọi thứ xung quanh lời nói.

Nunchi lộ ra ở đâu trong một đội phát triển

#

Các đội phát triển vận hành đúng theo hình dạng đó. Vài tháng sau khi lần đầu làm quản lý, tôi viết một bài về quy ước của đội mở đầu thế này: phần lớn xích mích tôi phải xử lý không phải chuyện kỹ thuật, mà là mỗi người ngầm mặc định một kiểu về việc review code (đánh giá mã) nên được phản hồi nhanh đến đâu, “xong” thực ra nghĩa là gì, và nhắc ai đó lần thứ hai có bị coi là bất lịch sự không. Hồi đó tôi chưa dùng từ này, nhưng danh sách ấy dòng nào cũng là thứ mà nunchi phải đọc ra. Mỗi dòng là một quy tắc cả đội ngầm đồng ý mà không nói ra, và người mới chỉ có thể học bằng cách quan sát.

Cũng trong bài đó, tôi phàn nàn chuyện người mới học quy ước “như truyền miệng dân gian” thay vì được nói rõ khi nhận việc (onboarding), và chuyện các đội đa quốc gia cứ tưởng chuẩn của mình là chuẩn của tất cả mọi người. “Folklore”, truyện truyền miệng, là từ tiếng Anh hay nhất tôi tìm được để mô tả thứ mà nunchi dựa vào. Khi bạn là người nước ngoài duy nhất trong đội, chuẩn bị lệch chính là của bạn, và những “truyện truyền miệng” kia chẳng được ghi lại ở đâu để bạn đọc.

Chỗ tốn kém nhất là buổi họp đứng (standup) hằng ngày. Năm 2023 tôi có viết về một dự án tôi phụ trách bị chậm tiến độ trong khi tôi cứ chờ có ai hỏi đến. Ba tuần sau mới có người hỏi, và lúc đó mọi thứ đã thành thảm họa. Nunchi tốt không cứu được chuyện này. Đọc được không khí thì bạn biết điều gì không ai muốn nghe, nhưng nó không bảo bạn phải nói ra bất chấp. Thói quen tôi rút ra thì ngược hẳn với việc chờ đợi: nói trước, bằng văn bản, trước khi có ai hỏi. “Việc này đang lâu hơn tôi nghĩ. Giờ tôi ước tính khoảng 8 đến 10 ngày chứ không phải 5. Mình cắt bớt phạm vi hay lùi hạn chót?”

Khi bạn là người bị “đọc”

#

Tháng 2/2024, tôi bắt đầu quản lý một đội kỹ sư ở một công ty phần mềm tại Seoul, và nunchi đảo chiều. Khi còn là lập trình viên, tôi là người đọc không khí. Khi làm quản lý, tôi chính là không khí. Những gì tôi nói trong cuộc họp, những gì tôi không nói, tôi trả lời tin nhắn nhanh hay chậm, mấy giờ tôi về, tất cả đều trở thành thứ người khác có thể đọc.

Nhiều điều tôi từng viết khi còn làm trưởng dự án lại càng đúng hơn khi đã là quản lý. Nếu mọi người không thấy an toàn để nói với bạn chỗ nào đang hỏng, bạn sẽ là người biết sau cùng. Giữ thông tin quá lâu thì mọi người cảm nhận được, và tin đồn sẽ lấp đầy khoảng im lặng bạn để lại. Câu “tôi không biết” nghe như thất bại khi năm người trong phòng họp đang chờ câu trả lời của bạn, và chính vì thế mà nó đáng để nói ra. Còn câu mà tôi cứ quay lại mãi: người khác không đọc được ý định của bạn, họ chỉ đọc được lời bạn nói. Trong một đội vận hành bằng nunchi, họ vẫn sẽ cố đọc: từ nét mặt bạn, từ những gì bạn bỏ qua, từ giờ bạn ra về. Đó là lý do chính đáng để bạn chừa cho họ ít chỗ phải đoán hơn.

Những thứ tôi dựa vào đều chẳng có gì hào nhoáng. Họp 1:1 với từng người, nói về chính người đó chứ không phải về sprint, cùng một câu hỏi giản dị làm được phần lớn việc: “Có điều gì bạn cần tôi hoặc cả đội hỗ trợ để làm việc thuận hơn không?”

Một danh sách quy ước ngắn của đội, từ ba đến năm điều, ghi ở chỗ ai cũng thấy, kể cả chuyện sẽ ra sao nếu chính người quản lý vi phạm. Chủ động đi hỏi những người sẽ chẳng bao giờ lên tiếng trong một phòng tám người, thay vì chờ họ tự nói. Và một câu thẳng thắn “không được, lý do là thế này” thay cho câu “để xem đã” rồi chẳng bao giờ được nhắc lại, vì một câu trả lời mơ hồ chỉ thêm một thứ nữa khiến người ta phải nhìn sắc mặt. Khoảng một tháng sau khi tôi vào, buổi dã ngoại của đội sản phẩm bắt đầu ở một quán cà phê với một buổi workshop về giá trị của từng người và quy ước của đội. Một công ty khó có câu trả lời nào cho nunchi trực diện hơn thế: dành nguyên một buổi sáng để nói to những điều thường chẳng ai nói ra.

Được tuyển với tư cách người nước ngoài

#

Tôi không có bí kíp tìm việc nào cho Hàn Quốc. Thứ tôi có là góc nhìn của người quản lý tuyển dụng, và lời khuyên rút ra từ đó là: hãy dùng nunchi với chính công ty trước khi bạn ký hợp đồng.

Hồi còn làm quản lý và tuyển người, những lập trình viên tôi muốn tuyển nhất chẳng bao giờ có mặt trên các trang tuyển dụng, và như tôi từng viết, các nhà sáng lập thích tuyển người mình đã từng làm cùng hơn nhiều. Vậy nên cửa vào tốt nhất là bất cứ thứ gì giúp người ta thấy bạn làm việc trước khi tuyển bạn. Một kỳ thực tập ở công ty nhỏ hay lặng lẽ biến thành lời mời làm chính thức. Một cuộc thi hackathon cho người ta xem bạn làm việc suốt cả cuối tuần: năm 2023, tôi cùng ba người nữa trong một đội bốn người đã thắng Seoul Tech Impact Hackathon do Lunit Global tổ chức, với một ứng dụng giúp tìm các xe bán đồ ăn đường phố, vốn ở Hàn chẳng có địa chỉ.

Rồi còn buổi cà phê trò chuyện (coffee chat). Tôi từng viết rằng cách một người cư xử trong một cuộc nói chuyện thoải mái cho bạn biết làm việc cùng họ sẽ ra sao nhiều hơn hẳn một buổi phỏng vấn đã tập dượt, và điều đó đúng cho cả hai phía. Với ứng viên, đó là cơ hội duy nhất để đọc một đội trước khi bước vào. Nếu ngồi ở ghế ứng viên, tôi sẽ hỏi: thách thức lớn nhất đội đang gặp lúc này là gì, vì sao anh chị vào đây và điều gì giữ anh chị ở lại, và có điều gì về việc làm ở đây có thể khiến tôi bất ngờ. Câu cuối là một cách lịch sự để xin người ta nói trước cho mình phần nunchi. Câu trả lời né tránh về chuyện nghỉ việc hay định hướng công ty tự nó đã nói lên khá nhiều.

Nếu bạn đang tuyển lập trình viên nước ngoài

#

Nếu bạn điều hành một đội ở Hàn và đang tuyển một lập trình viên đến từ nơi khác, điều hữu ích nhất bạn có thể làm chính là câu trong bài viết về quy ước của đội: biến những điều ngầm hiểu thành điều nói rõ. Đừng để họ học quy tắc của bạn như truyện truyền miệng. Hãy nói với họ ngay tuần đầu: review thường được phản hồi trong bao lâu, “xong” nghĩa là gì, nhắc lần hai có bị coi là bất lịch sự không, mọi người thực tế mấy giờ thì về, và xin nghỉ phép thì ngoài cái đơn ra còn phải để ý gì nữa không. Hai câu cuối là những câu hỏi nunchi kinh điển, những điều mà người trong đội chẳng ai nghĩ đến chuyện phải nói ra.

Sau đó là những thói quen nhàm chán giúp người ta bớt phải đoán. Nói trước khi bị hỏi; một email ba gạch đầu dòng gửi các bên liên quan vào thứ Sáu (đã phát hành gì, tiếp theo làm gì, có điều gì đáng lo) chỉ mất mười phút. Hỏi thẳng những người trầm tính thay vì chờ họ lên tiếng trong cuộc họp. Đưa ra câu trả lời thật, kể cả “không”, kèm theo lý do. Và phỏng vấn mọi ứng viên bằng cùng một bộ câu hỏi, theo cùng một thang đánh giá. Điều này tôi mất một thời gian mới học được, nhưng đó là cách công bằng duy nhất để so sánh mọi người; nếu không, bạn sẽ thiên vị người mình nói chuyện gần đây nhất. Nó cũng có nghĩa là ứng viên không biết các quy tắc ngầm của đội bạn sẽ được hỏi đúng những câu mà ứng viên đã biết được hỏi.

Cộng đồng người New Zealand ở đây

#

Năm 2018, khi vẫn còn là sinh viên, tôi chụp ảnh cho một buổi ăn sáng về lãnh đạo của Kiwi Chamber, và sau đó viết rằng tôi thật sự thích làm tình nguyện cho những sự kiện thúc đẩy quan hệ giữa hai nước. Từ tháng 1/2020, tôi làm chủ tịch Kiwi Alumni, một cộng đồng dành cho người New Zealand ở Hàn Quốc và cho những ai từng học ở New Zealand nay đang sống và làm việc ở đây. Đây là vai trò tình nguyện, và phần lớn là việc với con người: tổ chức sự kiện, xây dựng quan hệ với Đại sứ quán New Zealand và các cơ sở giáo dục, cộng thêm những việc chẳng ai thấy như làm logo mới hay một website mà thành viên thật sự tìm được thứ mình cần. Năm 2023, chúng tôi cùng Đại sứ quán tổ chức Kiwi Alumni Night, và sự kiện còn lên cả KTV.

Câu tôi viết sau đêm đó là thứ gần nhất với luận điểm chính của bài này. Những người từng sống ở cả Hàn Quốc lẫn New Zealand hiểu cách nối những khác biệt, vì họ đã trải qua cả hai nền văn hóa. Nếu bạn sang đây làm việc, dù bạn đến từ đâu, hãy tìm những người như thế. Họ là người sẽ nói với bạn bằng lời lẽ rõ ràng rằng căn phòng lúc đó đã muốn nói gì.

Làm tự do từ Seoul

#

Tôi chuyển sang làm tự do vào tháng 10/2025, sau khi nghỉ việc quản lý. Thực tế đó là các hợp đồng DevOps và MLOps, phần lớn là hạ tầng tại chỗ: một cụm PostgreSQL độ sẵn sàng cao, rồi hạ tầng phục vụ LLM trên chính phần cứng đó. Làm rồi mới thấy phần kiểm soát chất lượng còn nhiều hơn phần “đi ống nước”: theo dõi trace và các cuộc hội thoại nhiều lượt để tìm xem đầu ra của mô hình bắt đầu lệch từ đâu. Từ tháng 2/2026, tôi còn làm thêm một ứng dụng chợ và cộng đồng của riêng mình.

Làm tự do không giúp bạn thoát khỏi nunchi; nó chỉ đổi thứ bạn phải đọc. Đến bất kỳ đâu, thứ đầu tiên tôi xem là hệ thống giám sát (monitoring), vì nó cho biết về một đội nhiều hơn file README. Đó là nunchi dành cho hệ thống: đọc những gì một đội thật sự làm, chứ không phải những gì họ nói là mình làm.

Điều tôi muốn nói với ai đang cân nhắc

#

1. Hãy vào bằng một cánh cửa nơi người ta thấy bạn làm việc trước khi tuyển bạn. Của tôi là bậc thạc sĩ. Một cuộc thi hackathon, một kỳ thực tập ở công ty nhỏ, hay cộng đồng người cùng nước với bạn ở đây cũng có tác dụng y như vậy, và chính trong cộng đồng bạn sẽ gặp những người từng sống ở cả hai bên.
2. Đừng gạt bỏ các công ty nhỏ; phần lớn sự nghiệp của tôi là ở đó. Ở một công ty mười người thì chẳng có ai để bạn đẩy việc nhàm chán sang, và thứ bạn làm ra thật sự được đưa vào sử dụng.
3. Đọc đội trước khi vào. Tận dụng buổi coffee chat, hỏi xem làm ở đây có gì khiến bạn bất ngờ, và đừng xem nhẹ những câu trả lời né tránh về chuyện nghỉ việc.
4. Đừng chờ bị hỏi. Một ước tính đang trễ, một thay đổi rủi ro, một quyết định người khác đang chờ: hãy nói trước, bằng văn bản.
5. Hỏi thành tiếng những quy tắc chưa được viết ra: review được phản hồi nhanh đến đâu, “xong” nghĩa là gì, nhắc lần hai có bất lịch sự không. Nếu chưa ai viết lại, hãy xung phong viết.
6. Học cả hệ sinh thái xung quanh bộ công nghệ của bạn. Ở đây, Naver và Kakao quan trọng theo những cách mà thói quen dùng Google của bạn không bao quát được.

Phần kỹ thuật là nửa bạn có thể chuẩn bị trước khi đến. Nunchi là nửa bạn học trong lúc làm, và cách nhanh nhất tôi biết để học nó là nhờ mọi người nói to phần thường không được nói ra, và tự mình nói phần của mình trước.

Dạo này tôi hay nghĩ về chuyện đó, vì chính tôi cũng đang dẫn dắt dự án, và tôi hiểu cảm giác muốn chém gió là có thật. Khi có người hỏi bạn một câu giữa cuộc họp và năm người khác đang chờ bạn trả lời, nói “Tôi không biết” nghe cứ như mình thất bại. Nhưng không phải vậy. Phần lớn thời gian, đó lại là câu trả lời có sức nặng nhất mà bạn có thể đưa ra, miễn là bạn nói tiếp xem sau đó sẽ làm gì: sẽ hỏi ai, hoặc khi nào sẽ quay lại với câu trả lời.

Chém gió sớm muộn cũng lộ

#

Công nghệ phần mềm thay đổi quá nhanh, không ai nhớ hết được mọi thứ, còn kỹ sư thì đứng tận cuối phòng cũng nhận ra ai đang chém gió. Lần đầu tiên cả đội bắt gặp bạn giả vờ biết một điều gì đó, họ sẽ lặng lẽ bớt tin mọi điều khác bạn nói. Ngược lại, một người quản lý dám thừa nhận chỗ mình còn hổng rồi đi tìm hiểu cho ra thì lại được điều ngược lại: mọi người tin những câu trả lời thật của họ, vì ai cũng nhận ra đâu là câu trả lời thật khi nghe thấy.

Đó là điểm khởi đầu, chứ chưa phải câu trả lời

#

Mấu chốt nằm ở những gì bạn làm sau đó. Nói “Tôi không biết” rồi thôi thì cũng chỉ là nhún vai cho qua. Những người quản lý giỏi sẽ làm tiếp một bước: đặt những câu hỏi tốt hơn, kiểu “cái này so với thứ mình đang dùng thì thế nào?”, “nếu mình nhận định sai chỗ này thì cái gì sẽ hỏng?”, rồi mang những câu hỏi đó đến đúng người. Đội nào cũng có một người gần như sống luôn trong cơ sở dữ liệu, một người thuộc lòng mọi trường hợp biên (edge case) khó chịu ở phía giao diện. Bạn không cần biết mọi thứ; bạn chỉ cần biết ai là người biết, và chịu khó đi hỏi họ.

Nói “tôi không biết” ở chỗ làm sao cho khéo, không bị coi là thiếu chuẩn bị

#

Nguyên tắc tôi cố giữ là: đừng bao giờ để “tôi không biết” là chữ cuối cùng trong câu. Dưới đây là vài cách nói mà bạn có thể dùng ngay:

• “Cái này hiện mình chưa nắm được. Để mình tìm hiểu rồi báo lại trước thứ Năm nhé.”
• “Phần này anh Minh rành hơn mình nhiều, mình hỏi anh ấy luôn đi.”
• “Mình chưa chắc lắm. Mình nghĩ nhiều khả năng là X, nhưng trước khi chốt thì mình muốn kiểm tra lại Y đã.”
• “Số liệu đó giờ mình không có sẵn, họp xong mình gửi vào nhóm chat nhé.”
• “Phần này em chưa nắm rõ, em xin phép kiểm tra lại rồi phản hồi anh chị sau ạ.” (khi nói với cấp trên hoặc khách hàng)

Nói “tôi không biết” có bất lịch sự không? Không, nếu đi kèm một bước tiếp theo. Điều thực sự khiến người khác khó chịu là một câu “không biết nữa” bỏ lửng, chẳng giúp ai tiến thêm bước nào, hoặc một câu trả lời đầy tự tin mà sau đó hóa ra là bịa. Đi phỏng vấn cũng vậy: không biết thì cứ nói là không biết, rồi trình bày bạn sẽ tìm hiểu như thế nào. Như vậy nhà tuyển dụng thấy được về bạn nhiều hơn hẳn một câu đoán mò.

Quyết định tốt hơn

#

Trong phần mềm, một quyết định đã đưa ra thường sẽ tồn tại khá lâu, nên cần thành thật xem phần nào mình chắc chắn và phần nào mình chỉ đang đoán. Thừa nhận chỗ hổng ngay từ đầu thì bạn sẽ đi tìm thêm thông tin còn thiếu trước khi quyết định, chứ không phải sau đó. Nó cũng cho những người không đồng tình với bạn cơ hội lên tiếng, đúng vào lúc bạn cần nghe họ nhất. Khi đã quyết rồi, hãy giải thích lý do. Và nếu hóa ra bạn sai, cũng hãy nói luôn. Không gì làm một đội mất đi sự thẳng thắn nhanh bằng một người quản lý không chịu nhận là mình đã quyết định sai.

Chẳng có gì phức tạp ở đây cả. Hãy đặt câu hỏi, lắng nghe những người biết nhiều hơn mình (lúc nào cũng có người biết nhiều hơn bạn), và nói rõ khi mình đang đoán. Câu “Tôi không biết, nhưng để mình tìm hiểu xem” đã giúp tôi có uy tín hơn bất kỳ câu trả lời chém gió cho qua chuyện nào tôi từng đưa ra.

Vì sao tôi vẫn mặc định cởi mở

#

Những lý lẽ quen thuộc ủng hộ minh bạch đều đúng cả, và tôi đã tận mắt thấy từng điều một. Khi hiểu lý do đằng sau một quyết định, người ta sẽ tin vào nó, kể cả khi không mấy thích. Khi nắm cùng thông tin với tôi, họ tự quyết đúng mà chẳng cần chờ tôi. Và chẳng ai vui khi phát hiện ra mình bị gạt ra ngoài một chuyện ảnh hưởng trực tiếp đến mình.

Minh bạch kiểu “thô” dễ hỏng ở đâu

#

Chủ yếu là ba chỗ.

Khối lượng. Cập nhật nào còn dở dang cũng chuyển tiếp hết thì những thứ thật sự quan trọng sẽ bị chôn vùi, và dần dần mọi người chẳng buồn để ý nữa.

Bối cảnh. Thông tin trần trụi mà thiếu câu chuyện đi kèm thì chỉ khiến người ta hoang mang. Cùng một câu “Mình đang xem lại lộ trình sản phẩm” (roadmap), có kèm lời giải thích thì nghe rất bình thường, còn không thì đáng sợ hơn nhiều.

Thời điểm. Chuyện còn chưa chốt mà đã nói ra thì cả đội sẽ mất cả tuần đoán già đoán non về những kịch bản vốn chưa bao giờ được tính đến. Một tin mới quyết được một nửa có khi còn ngốn nhiều năng lượng hơn chính quyết định cuối cùng.

Chờ không có nghĩa là giấu

#

Chọn thời điểm để chia sẻ nghe thì có vẻ như thao túng. Nhưng nếu làm thật lòng thì lại ngược hẳn: mục đích là để tin tức đến tay mọi người cùng với đủ bối cảnh để hiểu. Tin xấu dễ nghe hơn khi đi kèm một kế hoạch. Tin tốt cũng được đón nhận hơn khi không bị lẫn trong mớ thông báo dồn hết vào chiều thứ Sáu.

Nhưng chờ cũng có cái giá của nó, và cái giá ấy cứ thế cộng dồn. Ôm thông tin quá lâu thì người ta sẽ cảm nhận được. Bạn để trống chỗ nào, tin đồn sẽ lấp vào chỗ đó, mà tin đồn thì lúc nào cũng tệ hơn sự thật. Còn nếu một người lúc nào cũng là người biết sau cùng, họ sẽ hiểu đó là thông điệp về giá trị của mình trong đội. Mà cũng phải thôi — thường thì đúng là vậy thật.

Giờ tôi quyết định thế nào

#

Trước khi chia sẻ (hay giữ lại) một chuyện nhạy cảm, tôi tự hỏi mình vài câu. Cả đội có cần thông tin này để làm việc không, hay chỉ là tôi muốn nói ra cho nhẹ lòng? Tôi đã giải thích được bối cảnh cho đàng hoàng chưa, hay mới chỉ đưa ra được mấy mảnh rời rạc? Và mọi người có khả năng sẽ đón nhận thế nào — tôi đã chuẩn bị sẵn câu trả lời cho những câu hỏi chắc chắn sẽ được hỏi chưa?

Rồi dù chọn hướng nào, tôi cũng cố làm ba việc: đưa bối cảnh đi kèm thông tin, để mọi người dễ hỏi lại sau đó, và để ý xem mọi chuyện diễn ra thế nào để lần sau căn chỉnh tốt hơn. Mỗi người muốn nghe chi tiết ở một mức khác nhau, và cách duy nhất để biết là quan sát và hỏi.

Mặc định là cởi mở, thêm bối cảnh, và dành một phút nghĩ xem người ta sẽ đón nhận thế nào trước khi bấm gửi. Đến giờ, chừng đó đã đủ cho hầu hết những tình huống tôi gặp.

Tôi đã phải tự tìm ra giới hạn đó theo cách khá vất vả. Tôi là một lập trình viên rồi tình cờ thành người dẫn dắt một đội dự án, chứ chưa từng được đào tạo bài bản cho vai trò này, nên hầu hết những gì dưới đây đều là bài học rút ra sau khi đã làm sai một chút.

Thấu cảm trong lãnh đạo nghĩa là gì

#

Thấu cảm trong lãnh đạo là hiểu được các thành viên trong đội thực sự đang ra sao, rồi để điều đó được cân nhắc nghiêm túc khi bạn ra quyết định, khi góp ý, hay khi quyết định cách đội làm việc. Thấu cảm không có nghĩa là ai nói gì cũng chiều, cũng không phải là tỏ ra dễ chịu trong các buổi họp: bạn hoàn toàn có thể hiểu rõ hoàn cảnh của một người mà vẫn nói “không” với họ. Khi mọi người cảm nhận được hoàn cảnh của mình được tính đến, họ thấy thoải mái hơn, dám lên tiếng sớm hơn, và công việc cũng thực sự tốt lên. Phần này của lời khuyên quen thuộc thì đúng.

Quá ít thì hại. Quá nhiều cũng hại.

#

Kiểu thất bại mà ai cũng cảnh báo là người quản lý lạnh lùng, coi nhân viên như nguồn lực để phân bổ. Kiểu này có thật: nếu bạn phớt lờ những gì đang diễn ra trong cuộc sống của một người, họ sẽ thu mình lại, tinh thần cả đội đi xuống, và vấn đề nào bạn cũng biết muộn hàng tháng trời.

Còn kiểu thất bại không ai cảnh báo thì ngược lại. Nếu chuyện gì bạn cũng chiều theo, ranh giới sẽ dần mờ đi. Hạn chót chỉ còn là lời gợi ý. Và những người vẫn âm thầm giữ chuẩn bắt đầu bực bội vì phải gánh thay cho những người không bị yêu cầu như vậy. Có những lúc tôi nhận ra mình đã chiều quá tay, vì lúc đó thấy làm vậy là tử tế. Nhưng với những người còn lại trong đội thì chẳng tử tế chút nào.

Ví dụ về thấu cảm trong lãnh đạo: đúng mức và quá đà

#

Đặt cạnh nhau thì dễ thấy sự khác biệt hơn. Đây không phải quy tắc gì, chỉ là hình mẫu mà tôi muốn hướng tới:

Những cách làm quá đà có một điểm chung: lúc đó thì thấy tử tế, nhưng thực ra là đẩy cái giá phải trả sang sau này, hoặc sang vai người khác.

Trao đổi định kỳ (check-in) gánh phần lớn công việc

#

Thứ giúp tôi giữ được mức cân bằng tương đối không phải là triết lý gì cao siêu. Mà là một khung giờ cố định lặp lại trên lịch. Các buổi 1:1 đều đặn giúp những vấn đề nhỏ lộ ra khi vẫn còn nhỏ, thay vì dồn lại rồi ập đến một lúc dưới dạng lá đơn xin nghỉ việc.

Buổi 1:1 của tôi thường xoay quanh vài chủ đề quen thuộc: điều gì đang cản trở bạn, gần đây có việc gì suôn sẻ, đội đang phối hợp với nhau thế nào, bạn muốn phát triển theo hướng nào, và tôi có thể làm gì khác đi.

Câu hỏi hữu ích nhất mà tôi tìm được lại là một câu rất bình thường: “Bạn có cần gì từ mình hay từ đội để làm việc thuận lợi hơn không?” Nghe thì tầm thường, nhưng không hề tầm thường. Câu hỏi đó cho thấy tôi coi mình là một phần của giải pháp, và câu trả lời gần như lúc nào cũng là những thứ cụ thể mà tôi thực sự giải quyết được: kết nối với một người nào đó, chốt một quyết định đang bị treo, hay dành một tiếng ngồi lập trình cặp (pair programming) cùng nhau.

Thẳng thắn khi câu trả lời là không

#

Các buổi trao đổi định kỳ sẽ phát sinh đề xuất, và bạn không thể đáp ứng hết. Cách bạn xử lý những đề xuất không thể đáp ứng mới là chỗ niềm tin được vun đắp hoặc mất đi.

Cách tôi thấy hiệu quả là: nghiêm túc cân nhắc đề xuất và cho người kia biết là mình nghiêm túc, giải thích vì sao lúc này chưa làm được, đưa ra phương án thay thế một phần nếu có, hẹn khi nào sẽ xem xét lại, và rồi thực sự quay lại với nó, kể cả khi câu trả lời vẫn chưa đổi.

Làm vậy cũng chẳng khiến việc nói “không” dễ chịu hơn. Nhưng người ta đón nhận một câu “không, và đây là lý do” thành thật tốt hơn nhiều so với một câu “để xem đã” mơ hồ rồi chẳng bao giờ nhắc lại.

Công thức gần đúng nhất tôi có được là thế này: quan tâm đến chuyện mọi người đang thế nào, thành thật về những gì công việc đòi hỏi, và trao đổi đủ thường xuyên để nhận ra khi mình đã lệch quá xa về một phía.

Trong hầu hết các dự án tôi từng tham gia, khâu chậm nhất không phải là viết mã. Mà là xếp hàng chờ: các quyết định chất đống sau lịch làm việc của một người quản lý, chờ một cái gật đầu mất ba ngày mới tới. Giao tiếp bất đồng bộ và đội tự chủ là cách chữa quen thuộc, và tôi tin vào nó. Nhưng về bản chất, cuộc chuyển đổi này là bài toán niềm tin khoác áo bài toán công cụ.

Vì sao việc gì cũng phải chờ duyệt

#

Công bằng mà nói, văn hóa xin duyệt cũng có gốc gác của nó. Kiểm soát cho người ta cảm giác mọi thứ được chính xác: nếu quyết định nào cũng phải qua bàn quản lý thì chẳng có gì đi chệch hướng được. Một quyết định sai không chỉ làm hỏng dự án mà còn làm sứt mẻ uy tín của người quản lý, nên nỗi sợ chiếm phần rất lớn. Đôi khi người quản lý thật sự nghi ngờ đội chưa đủ kinh nghiệm để tự quyết cho tốt. Và đôi khi chỉ là thói quen còn sót lại: sơ đồ tổ chức xưa nay vẫn vận hành như vậy, thì cứ thế vận hành tiếp.

Để ý mà xem, trong bốn lý do đó chỉ có một lý do thực sự nằm ở phía đội. Ba lý do còn lại đều là chuyện của người quản lý.

Để tự chủ thì cần những gì

#

Tự chủ mà không cùng nhìn về một hướng thì chỉ là hỗn loạn, có điều tinh thần mọi người phấn chấn hơn. Khi ai cũng thực sự hiểu mục tiêu chung, những quyết định họ tự đưa ra phần lớn sẽ tự khắc cùng hướng. Bí quyết chỉ có vậy. Đào tạo cũng quan trọng, vì tin một người được trang bị đầy đủ thì dễ hơn tin một người chỉ có nhiệt huyết. Nên giữ lại vài ranh giới: có những quyết định thực sự nên để quản lý đưa ra, và nói rõ đó là những quyết định nào sẽ giúp tránh được những bất ngờ tệ nhất. Sau đó cứ để vòng lặp phản hồi vận hành, và coi những sai lầm không tránh khỏi là học phí chứ không phải bằng chứng để quy lỗi.

Nếu niềm tin đã sứt mẻ (mà ở những đội đang cố thoát khỏi văn hóa xin duyệt thì thường là đã sứt mẻ, từ cả hai phía) thì không có đường tắt nào cả. Hãy gọi tên vấn đề trong một buổi nói chuyện cởi mở, để phía quản lý nhận phần lỗi của mình trước, rồi kiên trì nhất quán đến nhàm chán trong nhiều tháng. Vai trò rõ ràng và những buổi trao đổi định kỳ (check-in) hàn gắn được nhiều hơn mọi cử chỉ hoành tráng.

Phần bất đồng bộ mới là phần dễ

#

Nói qua về công cụ trước: Slack hay Microsoft Teams đều ổn cả. Việc thật sự cần làm là tài liệu. Khi không ai ngồi chung phòng hay chung múi giờ, những quyết định được viết ra chính là trí nhớ của cả đội. Hãy đặt quy ước về thời gian phản hồi để bất đồng bộ không lặng lẽ biến thành “không ai trả lời”; “trong vòng một ngày” tốt hơn nhiều so với “lúc nào rảnh”, và quy ước này nên được ghi vào kế hoạch truyền thông của đội, ngay cạnh phần ai nhận bản cập nhật nào. Và hãy thực sự dạy mọi người cách viết một tin cập nhật cho người khác đọc sau sao cho tử tế, vì kỹ năng này không tự nhiên mà có: đủ bối cảnh để người đọc ra quyết định, nói rõ cần quyết định điều gì, và hạn chót là khi nào. Chẳng hạn như thế này:

Cần chốt trước thứ Năm: thử lại thanh toán
Hiện tại, khi thanh toán bằng thẻ thất bại, hệ thống chỉ thử lại (retry) một lần sau 24 giờ, và câu hỏi “Đơn hàng của tôi đâu rồi?” đang là loại yêu cầu hỗ trợ nhiều nhất.
Phương án A: thử lại ba lần trong vòng 24 giờ (mất khoảng nửa ngày làm). Phương án B: giữ nguyên, thay vào đó gửi email báo cho khách.
Tôi đề xuất chọn A. Chi tiết và số liệu có trong tài liệu tôi gửi kèm.
Nếu đến 17 giờ thứ Năm không ai phản đối, tôi sẽ bắt đầu làm theo phương án A.

Một tin như vậy thì ai đọc lúc 7 giờ sáng hay 11 giờ đêm, ở múi giờ nào, cũng có thể trả lời được mà không cần họp.

Bạn có thể triển khai Slack trong một buổi chiều. Còn niềm tin thì phải mất hàng tháng, và chính nó quyết định mọi thứ ở đây có thành hay không. Hãy làm rõ mục tiêu, và để một sai lầm chỉ tốn một bài học chứ không tốn cả sự nghiệp của ai. Làm được vậy thì phần bất đồng bộ gần như tự vận hành.

Phần lớn những dự án rối như canh hẹ mà tôi từng bị kéo vào đều không phải do mã nguồn tệ. Nguyên nhân là thông tin cần thiết không đến được đúng người, cho tới khi đã quá muộn. Từ khi nhận vai trò trưởng dự án (project lead) ở công ty, tôi bắt đầu ghi lại cách mình muốn điều phối giao tiếp, nếu có ngày ngồi vào ghế CTO. Đây là những ghi chép đó.

Xác định ai cần biết gì

#

Nền móng thì chẳng có gì hào nhoáng: một kế hoạch giao tiếp ghi rõ ai cần được báo, họ cần biết gì, bao lâu báo một lần và qua kênh nào. Tôi sẽ đòi có kế hoạch này ngay từ đầu mỗi dự án, kèm tên người phụ trách cụ thể, vì việc gì cũng giao cho “cả đội” thì rốt cuộc chẳng ai làm. Với các bên liên quan (stakeholder) cũng vậy: tìm ra ai thực sự quan tâm đến dự án, hiểu mỗi người thích được cập nhật theo cách nào, và đừng gửi cho CEO nguyên cái tin cập nhật bạn vừa đăng trong kênh của đội lập trình. Cuối cùng là đặt ra vài quy ước rõ ràng: bao lâu thì nên phản hồi, thế nào mới tính là gấp, kênh nào dùng cho việc gì. Phần lớn cái gọi là “vấn đề giao tiếp” thật ra chỉ là những kỳ vọng chưa ai nói ra thành lời.

Ví dụ về kế hoạch truyền thông cho một dự án phần mềm

#

Đây là kế hoạch tôi sẽ dùng làm điểm xuất phát rồi điều chỉnh dần. Mỗi dòng là một nhóm đối tượng cần được báo, chứ không phải một cuộc họp:

Bên dưới bảng là các quy ước, viết càng đơn giản càng tốt: gấp nghĩa là việc đó đang chặn một lần phát hành hoặc khiến khách hàng bị kẹt, nên hãy gọi điện thay vì nhắn tin; câu hỏi thì đưa vào chat, quyết định thì ghi vào công cụ quản lý công việc; phản hồi trong vòng một ngày làm việc. Với nhật ký quyết định, tôi dùng tài liệu ra quyết định, lưu dưới dạng GitHub Issues để chúng nằm ngay cạnh công việc.

Có hai điều giúp một kế hoạch như thế này thực sự vận hành. Dòng nào cũng có tên một người cụ thể ở cột cuối, và bản cập nhật cho ban lãnh đạo được viết ra chứ không chỉ nói miệng, nên có thể chuyển tiếp cho người khác mà không rơi rớt thông tin nào.

Công cụ và nhịp làm việc

#

Công cụ không quan trọng bằng mức người ta hay cãi nhau về nó. Slack để nhắn tin, Trello để quản lý công việc, Zoom khi cần nhìn mặt nhau mà nói chuyện. Chọn cái hợp với đội mình rồi đi tiếp. Nhịp làm việc mới quan trọng hơn: họp nhanh hằng ngày (daily stand-up) nếu đội làm theo Agile, cập nhật hằng tuần nếu chu kỳ dài hơn, và quan trọng là giữ đúng nhịp đó. Rồi hãy ghi chép lại mọi thứ. Quyết định, thay đổi, đầu việc cần làm (action item), tất cả đều đưa vào Notion hay Jira, như một phần của quy trình chứ không phải chuyện tiện thì làm. Sáu tháng sau, tài liệu là thứ duy nhất còn nhớ chuyện gì đã xảy ra.

Phần “mềm” mới là phần khó

#

Tất cả những gì ở trên chỉ là cơ chế. Việc khó hơn là hỏi cả đội xem cách giao tiếp hiện tại có thực sự hiệu quả không, và thay đổi khi nó không hiệu quả. Rồi còn chuyện đào tạo nữa: mỗi người trong đội đến từ một nền tảng khác nhau, và không phải ai cũng từng làm trong một dự án được vận hành tử tế. Còn phải biết lắng nghe cho đàng hoàng thay vì chỉ ngồi chờ đến lượt mình nói, và xử lý mâu thuẫn từ sớm, khi nó còn nhỏ. Mà chẳng có gì trong số này giải quyết một lần là xong: cách làm hiệu quả ở quý trước có thể lặng lẽ hết tác dụng, nên cứ phải kiểm tra lại thường xuyên.

Làm việc trong một đội phát triển phân tán/bất đồng bộ

#

Nếu đội của bạn làm việc từ xa (remote) hoặc chủ yếu trao đổi bất đồng bộ (async), bài nói này rất đáng để bạn bỏ thời gian ra xem:

Tôi không làm hoàn hảo được hết những điều này, mà cũng chẳng ai làm được. Nhưng nhìn lại thì dự án nào suôn sẻ cũng có phần lớn những thứ trên, còn dự án nào khiến tôi khổ sở thì đều thiếu ít nhất ba thứ.

Đó 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.