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.

Cách giải quyết có một cái tên nghe khá chán: quy tắc làm việc chung của đội (team norms). Center for Creative Leadership định nghĩa chúng là “một tập hợp các quy tắc hay nguyên tắc vận hành định hình cách các thành viên trong đội tương tác với nhau”. Nghe thì như giấy tờ của phòng nhân sự, nhưng thật ra chỉ là viết ra những điều mà ai cũng tưởng là hiển nhiên.

Nghiên cứu khiến tôi bị thuyết phục

#

Project Aristotle của Google đã nghiên cứu khoảng 180 đội trong chính công ty họ để tìm ra điều gì làm nên những đội giỏi. Câu trả lời khiến chính họ bất ngờ: trong đội có những ai không quan trọng bằng việc cả đội làm việc với nhau như thế nào. Bạn có thể dồn toàn nhân tài vào một đội mà kết quả vẫn chỉ ở mức xoàng, nếu những thỏa thuận làm việc chung lộn xộn.

Nghiên cứu chỉ ra năm yếu tố giúp các đội mạnh nổi bật hơn hẳn: an toàn tâm lý, sự đáng tin cậy, cấu trúc và sự rõ ràng, ý nghĩa, và tác động. Trong đó, an toàn tâm lý, tức là có thể hỏi một câu ngớ ngẩn hay nhận mình sai mà không bị “trả giá”, là yếu tố đóng vai trò lớn nhất. Những con số đi kèm thì khó mà cãi được: giải thích thêm 43% mức chênh lệch về hiệu suất, năng suất cao hơn 19%, đổi mới nhiều hơn 31%, tỉ lệ nghỉ việc thấp hơn 27%.

Điều tôi thích ở danh sách này là không yếu tố nào trong năm cái là tính cách bẩm sinh. Tất cả đều là những thứ một đội có thể chủ động xây dựng, và quy tắc làm việc chung chính là cách để xây.

Quy tắc làm việc chung trong công việc hằng ngày

#

Họp hành là chỗ dễ bắt đầu nhất, vì những thói quen xấu ở đây lộ ra quá rõ. Chương trình họp được gửi trước, họp bắt đầu và kết thúc đúng giờ, và mọi người tóm tắt lại những gì mình vừa nghe trước khi phản bác. Tôi đặc biệt thích phiên bản thẳng thừng của quy tắc về chương trình họp: không có chương trình họp thì không họp.

Các quy tắc về giao tiếp quan trọng hơn nhưng lại khó thấy hơn. Của tôi gói gọn lại thế này: mặc định cứ trao đổi nhiều hơn mức mình nghĩ là cần, ghi lại các quyết định ở chỗ ai cũng tìm được, và đừng để cuộc họp là kênh trao đổi duy nhất. Có những người sẽ không bao giờ lên tiếng trong một phòng tám người, nên hãy chủ động tìm đến hỏi thẳng họ. Có rất nhiều bằng chứng cho thấy những đội có góc nhìn đa dạng làm tốt hơn những đội đồng nhất, nhưng chỉ khi những góc nhìn đó thực sự được nói ra.

Khi có bất đồng: hãy mặc định rằng người kia có ý tốt, tranh luận về vấn đề chứ đừng nhắm vào con người, và tìm hiểu xem mọi người thực sự cần gì, thay vì cứ bám lấy lập trường họ đã chọn. Còn nếu hiếm hoi lắm mới có một vụ tranh cãi mãi không dứt, khi đó hãy mời một bên thứ ba trung lập vào.

Đặt ra quy tắc chung mà không biến thành thủ tục hành chính

#

Cách mà CCL khuyến nghị bắt đầu từ trải nghiệm thực tế chứ không phải lý thuyết, và tôi cũng sẽ làm theo cách đó. Mỗi người kể về đội tốt nhất và đội tệ nhất mà mình từng ở, cả nhóm cùng mổ xẻ xem điều gì khiến từng đội như vậy, rồi những điểm chung rút ra được sẽ trở thành đề xuất: những hành vi cụ thể cho chính đội này, được cả nhóm tranh luận và thống nhất, chứ không phải áp từ trên xuống. Sau đó, quyết định luôn từ đầu chuyện gì sẽ xảy ra khi có người phá quy tắc (kể cả khi người đó là người quản lý), viết các quy tắc ra ở chỗ dễ thấy, và thỉnh thoảng xem lại.

Tôi chỉ muốn thêm đúng một quy tắc: bắt đầu với ba đến năm cái thôi. Quy tắc chung chỉ có tác dụng khi đã thành thói quen, mà chẳng ai tập nổi mười thói quen cùng một lúc.

Những chỗ dễ đổ bể

#

Cách nhanh nhất để giết chết các quy tắc chung là người lãnh đạo phớt lờ chúng. Nếu tôi bỏ qua quy tắc về chương trình họp chỉ vì đang bận, cả đội sẽ nhận ra ngay, và mọi thứ biến thành diễn kịch. Sự nhất quán của người đứng đầu quan trọng hơn câu chữ của bất kỳ quy tắc nào.

Vài cái bẫy khác cũng nên để ý. Người mới vào chỉ biết đến các quy tắc qua lời truyền miệng, thay vì được giải thích rõ ràng trong quá trình hội nhập nhân viên mới (onboarding). Các đội làm việc xuyên quốc gia cứ nghĩ cái mặc định của mình cũng là mặc định của mọi người (hãy nói rõ ra những điều vẫn ngầm hiểu). Và có những người coi cả chuyện này là đặt ra quy trình chỉ để có quy trình. Với nhóm cuối cùng này, mời họ cùng viết các quy tắc hiệu quả hơn nhiều so với ngồi giảng giải cho họ nghe.

Cũng nên biết các quy tắc chung thực sự được củng cố ở đâu. Các nghiên cứu về những đội hiệu suất cao lần nào cũng tìm ra ba thói quen giống nhau: buổi khởi động dự án (kickoff) tử tế, các buổi 1:1 đều đặn, và các buổi họp nhìn lại (retrospective). Chính ở những buổi đó, các thỏa thuận được đặt ra, được thử thách và lặng lẽ điều chỉnh lại, chứ không phải trong một văn bản chính sách nào.

Tôi không nghĩ quy tắc chung là phép màu. Nhưng dữ liệu của Google cũng chỉ về cùng một hướng với trải nghiệm của tôi cho tới giờ: cách một đội làm việc với nhau quan trọng hơn việc trong đội có những ai. Vì vậy, đội tôi giữ bộ quy tắc thật ngắn gọn. Chỉ vài thỏa thuận, viết ở chỗ ai cũng thấy, và được xem lại khi không còn đúng nữa. Sáu tháng nữa hỏi lại tôi xem chúng có trụ được không nhé.

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.

Tháng này tôi bắt đầu quản lý một đội kỹ sư, chỉ vài tuần sau khi viết bài về những gì thay đổi khi chuyển từ kỹ sư phần mềm lên quản lý kỹ thuật. Có một điều không ai nói trước với tôi: việc gì cũng có vẻ gấp. Đội mới, công ty mới, và một danh sách việc cần làm đã có từ lâu trước khi tôi tới. Tôi không thể làm hết cùng một lúc, nên tôi chọn ra ba việc phải làm cho đúng trước khi đụng tới bất cứ thứ gì khác.

Làm quen với đội

#

Tôi đang đặt lịch 1:1 với từng người, và cố giữ cho các buổi này xoay quanh con người, chứ không phải chuyện sprint. Họ muốn gì cho sự nghiệp của mình? Dạo này điều gì làm họ bực mình? Nếu được, ngày mai họ muốn thay đổi gì? Trong mấy buổi này, việc của tôi chủ yếu là im lặng và lắng nghe. Niềm tin không thể xây xong trong tuần đầu tiên, nhưng chắc chắn có thể mất ngay trong tuần đầu tiên.

Mỗi người lại làm việc theo một kiểu rất khác nhau. Có người muốn được hướng dẫn chi tiết, có người thì làm tốt nhất khi bạn để họ yên, và nếu đối xử với người này theo cách dành cho người kia thì chẳng ai vui cả. Cuốn “The Manager’s Path” của Camille Fournier viết về chuyện này rất hay. Hóa ra sự đồng cảm và thật lòng lắng nghe mới là phần lớn công việc.

Hiểu vì sao mọi thứ lại như bây giờ

#

Mỗi quy trình, mỗi chỗ kỳ quặc trong kiến trúc đều là dấu vết của một quyết định nào đó trong quá khứ. Trước khi thay đổi gì, tôi muốn biết người ta đã thử những gì, cái gì đã thất bại, và công ty thật sự quan tâm đến điều gì.

Công ty nào cũng có những luật bất thành văn về cách các quyết định thực sự được đưa ra. Tôi nắm được chúng càng nhanh thì càng làm được nhiều việc cho đội. Andrew Grove có nói ý này trong cuốn “High Output Management”: bạn không thể gắn công việc của đội với bức tranh lớn khi chính mình còn chưa hiểu bức tranh đó.

Đọc mã nguồn

#

Tôi không cần phải là người lập trình giỏi nhất đội nữa, nhưng tôi cần hiểu kiến trúc, những chỗ đang gây khó chịu, và nợ kỹ thuật (technical debt) đang bị chôn ở đâu. Vì vậy tôi đọc mã, mày mò quy trình triển khai, và hỏi mọi người rằng nếu có một tuần rảnh thì họ sẽ sửa gì. Câu trả lời cho câu hỏi cuối cùng này thường là bản lộ trình (roadmap) thành thật nhất mà bạn có được.

Làm vậy cũng là cách để đội thấy rằng tôi quan tâm đến chính công việc họ làm, chứ không chỉ đến mấy quy trình bọc quanh nó.

Rồi thì đứng sang một bên

#

Khi đã có nền móng đó, kế hoạch rất đơn giản: cung cấp bối cảnh, chia sẻ mục tiêu, và để đội tự đưa ra các quyết định kỹ thuật. Việc của tôi không phải là duyệt từng pull request, mà là lo cho mọi người có đủ những gì họ cần và đang đi đúng hướng. Cuốn “The Phoenix Project” của Gene Kim cũng lập luận y như vậy: những đội được tự quyết thì đi nhanh hơn và làm ra phần mềm tốt hơn những đội lúc nào cũng phải chờ cấp trên gật đầu.

Sách cho người mới làm quản lý kỹ thuật

#

Gom lại ba cuốn sách tôi đã nhắc tới ở trên:

Ngoài ra, mỗi khi có người hỏi quản lý kỹ thuật mới nên đọc gì, còn hai cuốn nữa cũng thường được nhắc tới: “An Elegant Puzzle” của Will Larson, nói về phần hệ thống của công việc quản lý (quy mô đội, lập kế hoạch, thiết kế tổ chức), và “Resilient Management” của Lara Hogan, một cuốn ngắn và thực tế về việc hiểu đội của mình, đặt kỳ vọng rõ ràng và giao tiếp rành mạch.

Sáu tháng nữa hỏi lại tôi xem mọi chuyện thế nào nhé.

Tôi cũng sắp bước sang vai trò này, nên thời gian gần đây tôi đi hỏi chuyện những người đã từng chuyển, và tìm được gì thì đọc nấy. Bài học rõ nhất cho tới giờ là: từ kỹ sư lên quản lý kỹ thuật (Engineering Manager) không phải là leo thêm một bậc. Thực ra bạn đang bước ngang sang một công việc khác hẳn. Thành quả của bạn không còn là những dòng mã mình viết ra, mà là những gì cả đội làm ra. Ai cũng nói vậy, và theo tôi thấy thì ai cũng vẫn xem nhẹ chuyện này.

Những gì thực sự thay đổi

Bạn không còn trực tiếp giải các bài toán kỹ thuật nữa, mà chuyển sang giải các bài toán về con người. Lịch làm việc kín mít những buổi 1:1, họp lên kế hoạch, họp để các đội thống nhất với nhau. Chuyện tuyển dụng và đánh giá hiệu suất giờ đổ lên đầu bạn. Phần lớn công việc là lo cho đội có đủ những gì họ cần để yên tâm làm việc: đủ bối cảnh, thứ tự ưu tiên rõ ràng, và càng ít chuyện vớ vẩn càng tốt.

Cái khó là bạn vẫn phải giữ đủ trình độ kỹ thuật để không bị lép vế khi bàn về kiến trúc và để đưa ra những quyết định hợp lý, trong khi lại phải chấp nhận rằng mình không còn là người trực tiếp viết mã. Những người quản lý tôi từng thấy cố ôm cả hai việc thường làm dở cả hai.

Kỹ sư và quản lý kỹ thuật, đặt cạnh nhau

Trong bảng này, vòng phản hồi là điều mà những người đi trước hay dặn tôi nhất. Làm kỹ sư thì gần như ngày nào bạn cũng có một chiến thắng nho nhỏ. Làm quản lý thì thành quả vẫn có thật, nhưng đến chậm, và bạn phải quen với việc có khi phải mất một thời gian khá lâu mới biết một quyết định của mình là đúng hay sai.

Những kỹ năng có vẻ quan trọng

Giao tiếp chiếm gần hết công việc. Bạn trở thành người “phiên dịch” giữa đội mình, bộ phận sản phẩm và ban lãnh đạo, và một phần lớn đến bất ngờ của công việc chỉ là đảm bảo ba bên đang nói về cùng một chuyện. Niềm tin quan trọng hơn mọi quy trình: nếu mọi người không thấy yên tâm khi báo với bạn chỗ nào đang hỏng, bạn sẽ là người biết chuyện sau cùng. Lịch làm việc thì sẽ tìm mọi cách nuốt chửng bạn, nên giữ lại thời gian để suy nghĩ, và thời gian cho đội, là một cuộc chiến không có hồi kết. Cuối cùng, bạn phải hiểu công ty thực sự đang muốn đạt được điều gì, không thì bạn chẳng thể chỉ cho ai một hướng đi có ích.

Chuẩn bị từ trước khi có chức danh

Lời khuyên tôi nghe đi nghe lại, và cũng là điều tôi đã tự kiểm chứng được: hãy bắt đầu dẫn dắt trước khi có ai trao chức danh cho bạn. Đứng ra lo một dự án, kèm cặp một đồng nghiệp, hay tổ chức một việc gì đó. Suốt năm qua tôi làm trưởng dự án, và trải nghiệm đó giúp tôi nhiều hơn bất kỳ cuốn sách nào. Dù vậy, sách vẫn có ích. Cuốn “The Manager’s Path” của Camille Fournier thì ai cũng giới thiệu, và đọc xong tôi hiểu vì sao. Đừng để kỹ năng kỹ thuật bị cùn, vì các cuộc tranh luận về kiến trúc sẽ không dừng lại đâu. Và hãy tìm một người cố vấn (mentor) đã từng đi qua con đường này, họ sẽ giúp bạn tránh những sai lầm mà chỉ khi nhìn lại mới thấy hiển nhiên.

Được cái này, mất cái kia

Bạn có nhiều tiếng nói hơn trong chuyện sản phẩm được làm ra như thế nào, nhưng lại hiếm khi tự tay làm. Tôi đoán sẽ có những ngày thấy chuyện đó thật tuyệt, và cũng có những ngày nhớ viết mã đến phát điên. Ai từng chuyển sang vai trò này cũng bảo tôi đó là chuyện bình thường. Sáu tháng nữa hỏi lại tôi nhé.

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.

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.

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