Có một câu nói được thốt ra trong các nhóm âm thầm, thường giữa những kỹ sư đã ở đủ lâu để cảm nhận sự vắng mặt của nó: "Tôi có thể nói điều tôi thật sự nghĩ ở đây." Nghe có vẻ đơn giản. Trong thực tế, nó hiếm có — và vô cùng quý giá. Những điều kiện tạo ra nó không đến tình cờ. Chúng được xây dựng, từng tương tác một, bởi những người chọn cách tử tế.
Không phải dễ chịu. Tử tế. Sự khác biệt quan trọng hơn vẻ ngoài, và hiểu sai điều đó khiến các nhóm trả giá đắt.
Bài viết này là khám phá thực tế về ý nghĩa thực sự của kind engineering — trong những khoảnh khắc hàng ngày của review code, cuộc gọi sự cố, cuộc trò chuyện phản hồi, và những lựa chọn yên lặng về cách chúng ta đối xử với những người làm việc cùng. Phần lớn suy nghĩ ở đây được định hình bởi kind.engineering, một tài nguyên tôi giới thiệu cho bất kỳ ai quan tâm đến xây dựng nhóm lành mạnh. Những ý tưởng dưới đây là tổng hợp và kinh nghiệm của riêng tôi; hãy coi trang web đó là tài liệu đọc thêm thiết yếu.
Tử tế không giống dễ chịu
Sự nhầm lẫn giữa tử tế và dễ chịu là nguyên nhân của một số lượng đáng ngạc nhiên những nhóm rối loạn. Dễ chịu thoải mái — nó làm dịu những khoảnh khắc khó xử, giữ hoà khí, và cảm thấy ấm áp. Nhưng thường là rỗng tuếch. Người dễ chịu nói với bạn bản demo trông tuyệt khi nó có lỗi nghiêm trọng. Người dễ chịu approve pull request thay vì để lại comment có vẻ phê bình. Người dễ chịu đồng ý trong cuộc họp và im lặng trong khi một quyết định tệ tiến lên.
Tử tế thì khác. Tử tế nói sự thật vì nó quan tâm đến bạn. Nó nói điều khó, nhưng theo cách khiến bạn muốn phát triển chứ không phải trốn chạy. Tác giả của kind.engineering nắm bắt điều này đẹp: dễ chịu mang bánh đến; tử tế đến gặp manager của bạn và nói "người này đang làm việc xuất sắc — hãy đề xuất họ cho vai trò lead tiếp theo." Một hành động thì dễ và không tốn gì. Cái kia cần nỗ lực và đầu tư vào tương lai của người khác.
| Chiều cạnh | Không tử tế | Dễ chịu | Tử tế |
|---|---|---|---|
| Với một PR có lỗi | "Cái này hoàn toàn sai." | Approve không comment để tránh ma sát. | "Tôi nghĩ cách tiếp cận này có race condition ở dòng 24 — đây là điều tôi sẽ thử thay thế." |
| Sau một sự cố production | "Ai viết cái này? Sao lại pass review?" | Tiếp tục; không đề cập lại. | Chạy retrospective blameless; hỏi "điều gì cho phép chuyện này xảy ra?" chứ không phải "ai đã cho phép?" |
| Đưa ra phản hồi về thiết kế | "Cái này không có nghĩa lý gì." | "Trông ổn!" — kể cả khi có vấn đề thật. | "Tôi không chắc chiến lược caching sẽ chịu được tải — chúng ta có thể đi qua expected read pattern không?" |
| Nói không | "Không phải vấn đề của tôi." | Nói có với mọi thứ; kiệt sức hoặc không deliver được. | "Tôi không thể nhận việc này trong sprint này, nhưng đây là khi tôi có thể, hoặc đây là người có thể giúp ngay bây giờ." |
| Công nhận công việc của người khác | Không thừa nhận gì. | Khen ngợi mơ hồ trên kênh nhóm. | Nêu đóng góp cụ thể công khai; vận động khả năng hiển thị với leadership. |
Hãy chú ý rằng tử tế thường xuyên là khó nhất trong ba cái. Nó đòi hỏi bạn phải thành thật, chu đáo, và đầu tư — tất cả cùng một lúc. Dễ chịu thì rẻ. Tử tế cần nỗ lực. Và không tử tế, dù hiệu quả ngắn hạn, hầu như luôn làm mọi thứ tệ hơn theo thời gian.
Dễ chịu tối ưu hoá cho sự thoải mái của bạn — sự khó chịu khi nói điều khó. Tử tế tối ưu hoá cho sự phát triển của họ. Thường thì hai điều này kéo theo hướng ngược nhau. Kind engineering có nghĩa là chọn phát triển thay vì thoải mái, nhất quán.
Tại sao tử tế là bộ khuếch đại
Nếu tử tế chỉ là điều tốt đẹp — một khát vọng đạo đức nhưng không phải đòn bẩy thực tế — nó vẫn đáng theo đuổi. Nhưng nghiên cứu và kinh nghiệm sống của các nhóm hiệu quả cao cho thấy nó mạnh hơn thế: một bộ khuếch đại thực sự về sản lượng kỹ thuật.
Cơ chế chạy qua an toàn tâm lý — thuật ngữ từ nhà nghiên cứu tổ chức Amy Edmondson, sau đó được phổ biến hóa bởi Project Aristotle của Google. Phát hiện của bà, được xác nhận trong các nhóm ở nhiều ngành, là yếu tố dự đoán lớn nhất về hiệu quả của nhóm không phải IQ trung bình của thành viên, hay sự thanh lịch của quy trình, hay chất lượng tooling. Mà là liệu thành viên nhóm có cảm thấy an toàn để chấp nhận rủi ro liên cá nhân không: đặt câu hỏi "ngớ ngẩn", thừa nhận không biết điều gì đó, báo hiệu vấn đề tiềm ẩn trước khi chắc chắn, bất đồng với đồng nghiệp cấp cao.
Trong một nhóm an toàn về mặt tâm lý, kỹ sư junior nghi ngờ có lỗi sẽ nói ra. Kỹ sư không hiểu quyết định thiết kế sẽ hỏi, thay vì dành ba ngày build sai thứ. Người phát hiện lựa chọn deployment rủi ro sẽ lên tiếng trong cuộc họp review thay vì hy vọng người khác làm điều đó. Đây không phải là hành động can đảm kịch tính. Chúng là luồng thông tin hàng ngày phân biệt các nhóm bắt vấn đề sớm với các nhóm bắt chúng trong production.
Tử tế là thứ xây dựng an toàn tâm lý. Khi bạn trả lời câu hỏi không một chút coi thường, bạn làm cho người đó — và mọi người quan sát — dễ đặt câu hỏi hơn trong tương lai. Khi bạn chạy incident review blameless, bạn làm dễ hơn cho người ta báo cáo near-miss lần sau. Khi bạn đưa ra phản hồi thành thật, chăm sóc và người nhận phát triển từ đó, cả nhóm học được rằng phản hồi là món quà chứ không phải mối đe dọa.
Lợi ích thực tế tích luỹ nhanh chóng:
- Lỗi nổi lên sớm hơn. Khi người ta không sợ trông kém cỏi, họ báo hiệu mối lo ngại mơ hồ trước khi chúng trở thành sự cố thật.
- Học tập tăng tốc. Câu hỏi được đặt ra. Kiến thức được chia sẻ. Junior phát triển nhanh hơn.
- Tỷ lệ nghỉ việc giảm. Người ta không rời bỏ nhóm nơi họ cảm thấy được tôn trọng và được đầu tư. Họ rời bỏ nhóm nơi họ cảm thấy bị hạ thấp.
- Quyết định cải thiện. Quan điểm đa dạng thực sự được bày tỏ thay vì tự kiểm duyệt vì phòng bị chi phối bởi giọng nói to nhất.
Tử tế trong thực tế
Triết học hữu ích cho đến khi bạn cần để lại comment trên pull request lúc 4 giờ chiều thứ Sáu. Đây là những gì kind engineering trông như thế nào trong những khoảnh khắc thực sự quan trọng.
Trong code review
Review code có lẽ là bài kiểm tra tử tế với tần suất cao nhất trong kỹ thuật. Làm tốt, đây là một trong những thực hành có giá trị nhất mà nhóm có. Làm không tử tế, nó trở thành nguồn lo sợ khiến mọi người tránh submit công việc, trì hoãn review vì oán giận, hoặc ngừng tham gia hoàn toàn.
Một vài nguyên tắc nhất quán cải thiện động lực:
- Hiểu lý do trước khi comment về cái gì. Đặt câu hỏi mở trước khi đưa ra phán xét. "Tôi tò mò tại sao cái này dùng polling thay vì callback — có ràng buộc nào tôi đang bỏ lỡ không?" mời đối thoại. "Cái này nên dùng callback" đóng nó lại.
- Gắn nhãn nitpick của bạn. "Nit: tôi sẽ dùng tên biến mô tả hơn đây, nhưng hoàn toàn ổn để giữ." Từ đó nói với tác giả: điều này là tuỳ chọn, tôi không block vì điều này, và các comment lớn hơn là những cái đáng sự chú ý thật sự của bạn.
- Phân biệt code với người. "Function này làm nhiều thứ" là phản hồi về code. "Bạn luôn viết function làm quá nhiều thứ" là phản hồi về một người. Một cái hữu ích; cái kia chỉ là khó chịu.
- Chuyển sang trò chuyện đồng bộ cho phản hồi dài. Nếu bạn có sáu mối lo ngại lớn về một cách tiếp cận, một bức tường comment có thể cảm thấy như bị trừng phạt công khai. Một cuộc gọi mười phút thì tử tế hơn, nhanh hơn, và có khả năng thực sự giải quyết vấn đề hơn.
Bạn cũng có thể xem bài viết đồng hành về cách review code nhã nhặn để có phân tích sâu hơn về chủ đề này.
Trong sự cố
Sự cố là bài kiểm tra áp lực đối với văn hoá nhóm. Dưới áp lực và với hậu quả thật, mọi thói quen — tốt và xấu — đều được khuếch đại. Những nhóm tử tế và hiệu quả nhất chạy retrospective blameless: giả định rằng mọi người hành động với thông tin và công cụ họ có, và khi hệ thống thất bại, hệ thống — không phải cá nhân — là thứ cần thay đổi.
Đây không phải là về việc hạ thấp trách nhiệm. Mà là về việc hiểu rằng cùng một lỗi hiếm khi xảy ra trong cô lập. Ai đó deploy config tệ vì quy trình deployment không yêu cầu đôi mắt thứ hai. Ai đó bỏ qua cảnh báo vì cảnh báo đó là một trong bốn mươi cái phát đi sáng đó. Tìm ra người để đổ lỗi cảm thấy như là đã giải quyết xong, nhưng không sửa được gì. Post-mortem blameless tìm ra khoảng trống trong quy trình mà con người rơi vào — và sửa điều đó thay thế.
Trong cuộc họp
Kỹ sư tử tế tạo ra không gian. Họ chú ý khi ai đó chưa lên tiếng và mời họ vào. Họ không lấn át người suy nghĩ chậm bằng cách nói nhanh liên tục. Họ tóm tắt quyết định để mọi người, không chỉ những ai lên tiếng nhiều nhất, có thể ra về với cùng sự hiểu biết. Họ theo dõi các cam kết để thời gian và lời nói của mọi người được coi là có nghĩa.
Trong việc nói không
Ngược lại với suy nghĩ thông thường, nói không rõ ràng và sớm thường tử tế hơn là nói có và không deliver được. Khi bạn nhận công việc mà mình không thể hoàn thành, người hỏi dành thời gian chờ đợi và lên kế hoạch xung quanh một cam kết sẽ không thành hiện thực. Khi bạn nói "Tôi không thể nhận cái này cho đến ngày 15, nhưng đây là người có thể giúp sớm hơn" — đó là thông tin hữu ích cho phép họ đưa ra quyết định thật sự.
Trong glue work và sponsorship
Một số công việc kỹ thuật tử tế nhất gần như vô hình: người viết tài liệu onboarding để người mới tiếp theo không phải dành ba ngày bối rối, người vận động trong cuộc họp lên kế hoạch cho ý tưởng của junior thay vì để nó bị nói qua, người nói với manager của đồng nghiệp về một phần công việc xứng đáng được ghi nhận. Đây là sponsorship — chủ động đầu tư vào sự phát triển và khả năng hiển thị của người khác. Nó tốn tương đối ít và tích luỹ rất nhiều.
Mỗi tuần một lần, hãy tự hỏi: có ai trong nhóm này có công việc tốt đang không được nhìn thấy không? Rồi nói điều gì đó cụ thể về nó, trong đúng phòng, với đúng người. Đây là một trong những việc có tác động nhất mà kỹ sư tử tế làm — và gần như không ai làm điều đó nhất quán.
Tử tế không có nghĩa là dễ bị ép buộc
Đây là phản đối xuất hiện thường xuyên nhất, và nó xứng đáng được trả lời trực tiếp. Kind engineering hoàn toàn tương thích với tiêu chuẩn cao — thực tế, nó đòi hỏi chúng. Mục tiêu không phải là làm mọi người thoải mái; mà là làm cho sự tham gia thành thật, mang tính xây dựng thành có thể. Những điều đó khác nhau.
Duy trì tiêu chuẩn cao một cách tử tế có nghĩa là: rõ ràng về tiêu chuẩn là gì, giải thích tại sao nó quan trọng, và giúp người đó đáp ứng nó — thay vì chỉ ghi nhận rằng họ chưa đạt. "Tôi không thể merge cái này mà không có test vì coverage của chúng ta là thứ đứng giữa chúng ta và sự cố chúng ta có sáu tháng trước" vừa tiêu chuẩn cao vừa tử tế. "Cái này không có test, điều đó rõ ràng là không chấp nhận được" là tiêu chuẩn cao nhưng không tử tế. Kết quả bạn muốn là như nhau; con đường đến đó rất khác nhau.
Bất đồng tốt cũng là tử tế. Khi bạn không đồng ý với một quyết định, nói rõ ràng, với lý lẽ của bạn, là một món quà — đặc biệt nếu sau đó bạn cam kết với quyết định nếu nó đi theo hướng khác. Điều không tử tế là bất đồng thụ động: đồng ý trong phòng và sau đó làm suy yếu kết quả, hoặc giữ im lặng và để quyết định tệ tiến lên vì lên tiếng cảm thấy khó xử.
Kỹ sư tử tế cũng bảo vệ nhóm của họ. Điều đó đôi khi có nghĩa là những cuộc trò chuyện khó khăn với stakeholder về timeline không thực tế, hoặc đẩy lùi yêu cầu sẽ đốt cháy những người không thể tự vận động trong phòng đó. Đó không phải là dễ chịu — đó là sự quan tâm thật sự, được thực hiện với một số chi phí cá nhân.
Nếu bạn thấy mình không bao giờ đưa ra phản hồi phê bình, không bao giờ nêu mối lo ngại trong retrospective, hoặc luôn làm dịu mọi thứ — đó không phải là tử tế. Đó là né tránh xung đột mặc quần áo của sự tử tế. Người ở phía kia xứng đáng được nghe sự thành thật của bạn. Họ không mỏng manh như bạn có thể lo sợ.
Tử tế với chính mình
Kỹ sư không tử tế với bản thân thường không tử tế với người khác. Làm việc quá mức mãn tính, từ chối cầu cứu, nhu cầu luôn trông có năng lực — đây không phải là đức hạnh. Chúng là những pattern kiệt sức làm mòn phán đoán, tạo ra oán giận, và làm sự cộng tác thực sự trở nên khó khăn hơn.
Văn hoá hero — việc tôn vinh người thức cả đêm để sửa sự cố, một mình viết lại component, luôn sẵn sàng và luôn deliver — hấp dẫn nhưng nguy hiểm. Nó khiến người hero cảm thấy không thể thiếu và âm thầm tạo ra áp lực khổng lồ cho mọi người khác phải thể hiện theo cách tương tự. Nó cũng tập trung kiến thức một cách nguy hiểm và làm nhóm dễ vỡ khi người đó không có mặt.
Nhịp độ bền vững không phải là dấu hiệu của tham vọng thấp. Đó là điều cho phép bạn suy nghĩ rõ ràng, đưa ra phản hồi tốt, thực sự hiện diện trong cuộc trò chuyện, và tiếp tục làm việc tốt trong nhiều năm thay vì kiệt sức trong vài tháng. Những kỹ sư tử tế với bản thân — người đặt giới hạn, cầu cứu, thừa nhận sự không chắc chắn — có xu hướng là những người mà đồng nghiệp muốn làm việc cùng nhất. Tính dễ tổn thương, hóa ra, xây dựng tin tưởng. Thể hiện sự bất khả xâm phạm thì không.
Điều này cũng có nghĩa là cầu cứu sớm, không phải muộn. Câu hỏi được hỏi khi bạn bị kẹt hai giờ là tử tế với bản thân và với người bạn hỏi — nó cung cấp cho họ ngữ cảnh hữu ích và một vấn đề có thể giải quyết. Câu hỏi tương tự được hỏi sau hai ngày đấu tranh im lặng thì khó hơn cho tất cả mọi người.
Tử tế mở rộng theo vai trò và quy mô nhóm như thế nào
Kind engineering trông hơi khác tùy theo vị trí bạn ngồi và quy mô tổ chức, dù cốt lõi vẫn không đổi.
Với tư cách individual contributor, phần lớn sự tử tế của bạn là địa phương: review code, pair programming, cách bạn trả lời câu hỏi trên Slack, liệu bạn có document thứ bạn vừa tìm ra để người tiếp theo không phải làm lại không. Những khoảnh khắc này nhỏ từng cái và rất lớn gộp lại. Một nhóm nơi mọi IC đối xử với những việc trên như là một phần công việc là nơi làm việc tốt hơn đáng chú ý so với nhóm không làm vậy.
Với tư cách tech lead, bạn có ảnh hưởng không tương xứng đối với các chuẩn mực của nhóm. Cách bạn đưa ra phản hồi trở thành cách phản hồi được đưa ra. Nếu bạn đặt câu hỏi thay vì đưa ra phán xét, người khác cũng sẽ làm vậy. Nếu bạn tôn vinh ai đó đã nêu vấn đề sớm thay vì chỉ trích lỗi của họ, bạn làm dễ hơn cho mọi người nêu vấn đề sớm. Đầu tư tử tế có giá trị nhất của bạn là thiết lập văn hoá tương tác của nhóm — và cách nhanh nhất để làm điều đó là tự mình làm mẫu hành vi, trong mọi review code và mọi cuộc họp.
Với tư cách manager, đòn bẩy thay đổi. An toàn tâm lý giờ bao gồm: tôi có mất việc nếu nói điều này không? Đó là mối lo ngại thật của nhiều người, và nó cần được giải quyết chủ động — qua lời nói, qua phản ứng với việc chấp nhận rủi ro, qua những gì bạn làm khi mọi người mang tin xấu đến. Manager phản ứng với tin xấu bằng sự thất vọng huấn luyện nhóm của họ giấu tin xấu. Manager phản ứng bằng "cảm ơn đã cho tôi biết sớm, hãy cùng suy nghĩ về điều này" huấn luyện nhóm của họ cho biết sớm. Sự khác biệt về kết quả là rất lớn.
Trong các tổ chức lớn hơn, tử tế theo quy mô thường có nghĩa là tạo ra các cấu trúc khiến hành vi tử tế trở thành mặc định: template post-mortem blameless, chuẩn mực review code rõ ràng trong engineering handbook, quy trình phản hồi 360 nổi bật các pattern liên cá nhân, tiêu chí thăng chức bao gồm cách ai đó phát triển và hỗ trợ đồng đội, không chỉ những gì họ cá nhân ship.
Những điều cốt lõi cần nhớ
- Tử tế không phải là dễ chịu: dễ chịu tránh khó chịu; tử tế nói sự thật vì nó quan tâm đến sự phát triển của người khác.
- An toàn tâm lý là cơ chế: khi mọi người cảm thấy an toàn để lên tiếng, vấn đề nổi lên sớm hơn, học tập tăng tốc, và nhóm hoạt động tốt hơn.
- Tử tế có thực hành: đặt câu hỏi trước khi phán xét trong review; chạy retrospective blameless; nói không rõ ràng; sponsor khả năng hiển thị của người khác.
- Tiêu chuẩn cao và tử tế tương thích: rõ ràng về tiêu chuẩn, giải thích tại sao nó quan trọng, giúp người đó đáp ứng — đừng chỉ ghi nhận khoảng cách.
- Tử tế với bản thân không phải tuỳ chọn: văn hoá hero là văn hoá mỏng manh; nhịp độ bền vững, cầu cứu, và thừa nhận sự không chắc chắn đều xây dựng niềm tin mà sự tử tế đòi hỏi.
- Vai trò của bạn định hình đòn bẩy của bạn: IC xây dựng chuẩn mực trong tương tác hàng ngày; lead làm mẫu hành vi ở cấp nhóm; manager tạo ra sự an toàn cấu trúc qua phản ứng của họ với rủi ro và tin xấu.
- Đọc thêm: những ý tưởng trong bài này được định hình bởi kind.engineering — một tài nguyên chu đáo, thực tế về giao tiếp, sự thành thật, và an toàn tâm lý trong các nhóm kỹ thuật.
Tử tế tích luỹ. Mỗi review thành thật mà tiếp nhận tốt, mỗi câu hỏi được trả lời không một chút coi thường, mỗi post-mortem blameless thực sự tìm ra khoảng trống — mỗi cái là một khoản gửi nhỏ vào tài khoản niềm tin mà cả nhóm rút ra. Theo thời gian, tài khoản đó là thứ phân biệt các nhóm cảm thấy như nơi công việc tốt xảy ra với các nhóm không phải vậy. Đáng để xây dựng cẩn thận.
Nếu bạn muốn đi sâu hơn vào một thực hành cụ thể, bài tiếp theo trong loạt này xem xét nghề thủ công của Cách viết Pull Request xuất sắc — bản thân nó là hành động tử tế đối với reviewer của bạn.