Năm nay, lời khuyên quản lý nào tôi đọc cũng nói cùng một điều: hãy thấu cảm hơn. Được thôi. Nhưng chẳng lời khuyên nào cho bạn biết giới hạn nằm ở đâu.
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 thực ra để làm gì#
Thấu cảm ở vị trí lãnh đạo không phải là tỏ ra dễ chịu trong các buổi họp. Mà là để cảm xúc thật của mọi người thực sự được cân nhắc khi bạn ra quyết định, khi góp ý, hay khi quyết định cách đội làm việc. 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.
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.