Sau vài tháng quản lý một đội lập trình viên, tôi nhận ra phần lớn những va chạm mình phải xử lý không đến từ kỹ thuật. Vấn đề là mỗi người đang làm việc theo những giả định ngầm khác nhau: một code review nên được phản hồi trong bao lâu, “xong” thực sự nghĩa là gì, nhắn Slack cho ai đó hai lần liền thì có bị coi là bất lịch sự không. Chẳng ai sai cả. Chỉ là chúng tôi chưa bao giờ ngồi lại thống nhất luật chơi.
Cách giải quyết có một cái tên nghe khá chán: team norms, tức những quy tắc làm việc chung của đội. Center for Creative Leadership định nghĩa team norms 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à team norms chính là cách để xây.
Team norms 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õ. Agenda đượ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ề agenda: không có agenda 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 team norms 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à manager), 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. Team norms 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 team norms là người lãnh đạo phớt lờ chúng. Nếu tôi bỏ qua quy tắc về agenda 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 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 team norms 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 kickoff tử tế, các buổi 1:1 đều đặn, và retro. 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ĩ team norms 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é.