Trên xe, tôi ngồi cạnh chị chánh văn phòng (chief of staff), và hai người nói chuyện về việc tìm cho mình một sở thích. Cả hai đều thấy rằng với nhịp sống bận rộn bây giờ, khó mà tìm được một sở thích để tự mình tận hưởng. Từ đó câu chuyện chuyển sang thời đại học. Thú vị là chị ấy từng là nghệ sĩ và rất mê làm nghệ thuật 3D. Nhưng theo lời chị kể, cái áp lực lúc nào cũng phải sáng tác có vẻ không hợp với nếp sống của chị. Thế là tôi đùa rằng chị nên làm một tác phẩm cho cái văn phòng hơi bị vô hồn của chúng tôi. Haha

Tới quán, chúng tôi tìm được ngay một cái bàn đủ rộng cho cả nhóm. Được ngồi cùng nhau nói về những điều thực sự quan trọng với mỗi người, vui lắm.

Mọi người đều rất tôn trọng ý kiến của nhau, còn anh CEO và người điều phối thì khéo léo dẫn dắt buổi workshop để cả nhóm kịp giờ cho hoạt động tiếp theo.

Hoạt động tiếp theo là ghé thăm một nhà chưng cất whisky! Tôi vốn mê whisky, nên đây đúng là dịp hoàn hảo để khoe chút hiểu biết (có phần hơn mức trung bình) của mình về cách làm whisky và cách thưởng thức nó. Anh hướng dẫn viên nhận luôn thử thách giới thiệu cả nhà chưng cất bằng hai thứ tiếng Anh và Hàn. Đầu tiên, chúng tôi xem công đoạn cho lúa mì vào thùng lớn rồi ngâm để chiết lấy đường. Sau đó là xem mẻ rượu đã lên men được chừng vài ngày. Cuối cùng là nồi chưng cất, trông giống như một viên sô-cô-la hình giọt nước khổng lồ. Bên trong nóng khoảng 30 độ, nên khi hướng dẫn viên bảo cả nhóm ra ngoài xem các kho chứa, ai cũng thấy nhẹ cả người.

Trong kho, các thùng rượu làm từ đủ loại gỗ được xếp chồng lên tận mái. Một số thùng có dán nhãn Gochujang (tương ớt Hàn Quốc) ở đầu thùng, một kiểu kết hợp mang hơi hướng Hàn Quốc. Chúng tôi còn được thử whisky rót thẳng từ thùng, nồng độ khoảng 60%! Cổ họng ai cũng như bốc cháy!

Để kết thúc buổi tham quan, chúng tôi được nếm các sản phẩm hoàn chỉnh của họ, gồm những loại whisky ủ trong các thùng có tuổi khác nhau. Chúng tôi còn được thử cả gin, mà theo tôi thì chọn món này là hơi xui, vì nó có nhiều hương vị na ná mùi nấm.

Cuối ngày, cả nhóm lên xe về lại Seoul, ghé một quán bar làm vài ly nhẹ nhàng rồi mới ai về nhà nấy. Một ngày mà làm được bao nhiêu thứ, và tôi nghĩ qua những lúc cùng nhau vui chơi như vậy, chúng tôi đã hiểu nhau hơn nhiều!

Nếu bạn đang tìm chỗ làm ở Hàn Quốc, cứ liên hệ với tôi nhé!

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é.

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.

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