Bài học tôi học được từ người quản lý mà tôi từng ghét
(blog4ems.com)- Giờ đây tôi đã trở thành quản lý kỹ thuật, nhưng vào thời còn làm kỹ sư phần mềm, tôi từng dành nhiều ngày để làm một tính năng phức tạp rồi gửi PR
- Phản hồi rất dứt khoát và lạnh lùng: “Over-engineering. Quá phức tạp. Hãy refactor” là tất cả những gì tôi nhận được
- Tôi đã nổi giận vì chỉ nhận được lời chỉ trích mà không có lấy một lời khen, nhưng câu chuyện với người quản lý đó mới chỉ là khởi đầu
Phong cách lãnh đạo không chiều theo cảm xúc
- Người quản lý này khác với những lãnh đạo mà tôi từng biết
- Không nắm tay chỉ việc, cũng không dùng lời lẽ mềm mỏng
- Ông ấy có những đặc điểm như sau
- Lập tức bác bỏ những ý tưởng còn non
- Ghét sự phức tạp chỉ để tạo ra phức tạp
- Chỉ coi trọng mã sạch, hiệu quả và dễ bảo trì
- Ngay cả trong các buổi retrospective, ông ấy cũng không nói vòng vo mà chỉ thẳng vấn đề
- Ban đầu tôi nghĩ đó là một con người lạnh lùng, nhưng đằng sau là một triết lý khác
Bước ngoặt từ phản hồi làm lung lay lòng tự trọng
- Trong sprint review, tôi trình diễn một tính năng mà mình rất tự tin, nhưng người quản lý cắt ngang và hỏi
“Cái này mong manh đấy. Dưới tải nặng thì sẽ thế nào? Kế hoạch rollback là gì?”
- Khi tôi không thể trả lời tử tế, ông ấy nói:
“Lúc này cậu đang nghĩ như một coder. Cậu phải nghĩ như một engineer”
- Ban đầu tôi tức giận, nhưng rồi cuối cùng cũng nhận ra phong cách viết code của mình thiên về sự khôn khéo hơn là khả năng phục hồi
Bài học thật sự: người quản lý đó không hề công kích cá nhân tôi
- Tư duy của tôi đã thay đổi rất nhiều
- Thay vì viết code “thông minh”, tôi viết code dễ đọc
- Tập trung vào thiết kế có tính đến các tình huống thất bại
- Viết code cho người phát triển tiếp theo, chứ không phải cho bản thân mình
- Sau đó, code review từ người quản lý ấy bắt đầu trôi qua rất nhanh
- Không phải ông ấy thay đổi, mà là chính tôi đã trưởng thành
Ảnh hưởng đến phong cách lãnh đạo của tôi
- Sau khi trở thành quản lý kỹ thuật, tôi thường xuyên nhớ lại trải nghiệm đó
- Tôi không muốn trở thành kiểu lãnh đạo mà mọi người ghét, nhưng cũng không muốn chỉ là một lãnh đạo quá mềm mỏng
- Tôi định hình phong cách của mình theo cách sau
- Đưa ra phản hồi thẳng thắn kèm bối cảnh giải thích
- Nhấn mạnh tư duy hệ thống
- Giữ tiêu chuẩn cao nhưng vẫn đưa ra phản hồi mang tính con người
- Các kỹ sư muốn được thử thách, nhưng không muốn có cảm giác bị xem thường
Khi nào cần một người quản lý cứng rắn
- Lãnh đạo luôn rối rắm vì cái tôi, deadline và áp lực đan xen vào nhau
- Một người quản lý cứng rắn sẽ dọn sạch sự hỗn loạn đó bằng cách
- Khiến bạn nghĩ về khả năng mở rộng thay vì chỉ tính năng
- Khiến bạn viết code có thể bảo trì thay vì code khôn khéo
- Khiến bạn chuẩn bị trước cho thất bại và các tình huống ngoại lệ
- Họ coi trọng khả năng sống sót của code hơn là cảm xúc
Cách sống sót và trưởng thành dưới một người quản lý cứng rắn
- Nếu bạn đang ở dưới một lãnh đạo khiến mình nghẹt thở, có thể đối phó như sau
- Đừng xem đó là công kích cá nhân: phản hồi là dành cho code
- Sau phản hồi, hãy hỏi “tại sao?”: phần lớn lãnh đạo cứng rắn tôn trọng sự tò mò
- Tự nghĩ trước về các điểm có thể thất bại: bạn phải bắt đầu suy nghĩ như người quản lý
- Nếu bạn là lãnh đạo, hãy thực hành những điều sau
- Đưa ra tiêu chuẩn cao, nhưng giải thích vì sao tiêu chuẩn đó quan trọng
- Hãy nói cụ thể thay vì đưa ra phản hồi mơ hồ
- Ăn mừng sự trưởng thành hơn là thành công: nếu lập trình viên phát hiện ra vấn đề trước cả quản lý, hãy khen ngợi họ
Món quà tuyệt vời nhất từ một Pull Request bị từ chối
- Ban đầu tôi bị tổn thương lòng tự trọng, nhưng nhìn lại bây giờ, PR bị từ chối đó lại là cơ hội lớn nhất đời tôi
- Đó là bước ngoặt giúp tôi nhìn việc lập trình không còn là dự án cá nhân mà là xây dựng hệ thống
- Một người quản lý cứng rắn không làm bạn thấy dễ chịu, nhưng sẽ giúp bạn trưởng thành với tư cách một lập trình viên
- Sự trưởng thành thật sự không bắt đầu khi PR được thông qua, mà bắt đầu khi nó bị từ chối
22 bình luận
Nếu có một người quản lý thẳng thắn, không để ý đến cảm xúc và một người quản lý tử tế, biết giữ sự gắn kết, thì kiểu quản lý nào mới có thể thúc đẩy sự phát triển của thành viên trong nhóm thông qua phản hồi? Khi đọc bài trước, tôi đã nảy ra câu hỏi này.
Tôi nghĩ đây là một trò chơi xác suất. Những người có thể bứt lên và trưởng thành dù phải vượt qua xác suất cực kỳ khắc nghiệt thì ở đâu cũng có. Tôi cho rằng người quản lý nên loại trường hợp như vậy ra và cố gắng nâng xác suất chung lên cho toàn đội. Tôi nghĩ một người quản lý hành động vì tin rằng đó là cách riêng của mình để nâng xác suất thì xứng đáng được tôn trọng. Chỉ cần đó không phải là việc giữ nguyên cách làm cũ bấy lâu nay chỉ vì cứ thế cũng được.
Tôi nghĩ kiểu phản hồi như thế này, tùy vào tính cách, tùy vào bối cảnh văn hóa và tùy vào khác biệt cá nhân, khi nghe có thể khiến người ta thấy khó chịu hoặc thậm chí nổi giận. Tuy vậy, về cơ bản, tiếp cận với suy nghĩ rằng "người đó không cố tình làm khổ mình" có lẽ sẽ tốt hơn cả về mặt tinh thần lẫn góc độ phát triển. Khi rơi vào tình huống như vậy, có lẽ ta có thể nhớ đến bài viết này và thử nghĩ rằng "biết đâu người quản lý này cũng vậy?". Một bài viết hay.
Mọi người thường nói nhiều về
kind and direct, nhưng thực ra so với việc tử tế thì thẳng thắn còn khó hơn rất nhiều.Một người lãnh đạo không có giá trị nếu không thể truyền đạt bối cảnh mà người theo sau cần để làm việc, dù không nhất thiết phải cung cấp toàn bộ bối cảnh
Có vẻ đây là bài viết của một người theo sau xuất sắc, người quy công năng lực vượt trội của bản thân cho người khác
Nếu người lãnh đạo không truyền đạt được bối cảnh thì thực ra cũng chẳng cần người lãnh đạo đó
Cần thay thế khẩn cấp
Những lời dễ nghe không phải lúc nào cũng là lời tốt. Tôi cũng nghĩ rằng bình luận review code chỉ vỏn vẹn hai từ "Nasty Code" lại là điều giúp ích cho tôi nhiều nhất trong cuộc đời.
Không phải lập trình viên nào cũng giống nhau.
Tôi đã từng suy nghĩ xem "tư duy hệ thống" là gì, và trong ngữ cảnh của bài viết này, có vẻ đó là cách suy nghĩ từ góc nhìn về cách một ứng dụng vận hành. Nhưng tôi nghĩ đây thực sự là một góc nhìn rất quan trọng.
Mình rất đồng cảm vì đã thấy nhiều trường hợp cứ xuê xoa cho qua rồi cuối cùng codebase trở nên hỗn loạn. Năng lực của người quản lý thực sự rất quan trọng.
Tôi đồng cảm.
Hàm ý của bài viết này dường như là bản thân người đó làm tốt, hơn là vị quản lý kia thực sự xuất sắc. (Có lẽ tác giả là kiểu người vẫn phát triển dù nhận bất kỳ phản hồi nào.)
Tôi nhớ đã từng thấy một nghiên cứu nói rằng khi nhận phản hồi tiêu cực (thiếu bối cảnh), hành vi có khả năng thay đổi theo hướng ngược với kỳ vọng.
Cần nhận ra rằng phản hồi về sản phẩm công việc không phải là sự công kích cá nhân.
Sẽ tốt hơn nếu người quản lý là một người tốt hơn, nhưng công ty không phải là trường học, và chúng ta là những người chuyên nghiệp, nên phải tự mình học cách tiếp nhận phản hồi.
Cũng cần có dũng khí để nói rằng mình không biết khi thực sự không biết.
Có vẻ như bạn đang ở một góc nhìn khá khác với tôi. Có lẽ vì kinh nghiệm của tôi còn ít, nên tôi chỉ thường thấy rằng những phản hồi không rõ ràng, hoặc những phản hồi có cách chỉ đối tượng mơ hồ, ngược lại chỉ gây phản tác dụng...
Chính tả bị sai.
"Phải nhận ra rằng đó không phải là sự chỉ trích." -> bạn nên viết là "Phải nhận ra rằng đó không phải là sự chỉ trích".
Có lẽ bạn biết đây không phải là sự công kích cá nhân, nhưng tôi nghĩ ngay khi nhìn thấy góp ý của tôi, bạn đã cảm thấy bực rồi. Có người gọi đó là
jo-sam-mo-sa, nhưng quả thật con người dường như tiếp nhậnjo-sam-mo-savàjo-sa-mo-samtheo những cách khác nhau.ps. Ban đầu tôi cũng không biết bạn viết sai chính tả, chỉ đến khi muốn tìm ví dụ và đưa vào công cụ kiểm tra chính tả thì tôi mới phát hiện ra chỗ viết sai của bạn.
Nếu được sửa lỗi chính tả thì chỉ cần nói cảm ơn, tôi không biết, là giải quyết được rồi; có vẻ đây không phải chuyện đáng để nổi giận. Tôi cho rằng việc nghĩ rằng người khác cũng sẽ cảm thấy giống như bản thân mình đã cảm thấy là một sự khái quát hóa nguy hiểm. Và cũng không phải là "việc chấp nhận" mà là "việc tiếp nhận".
Tôi nghĩ người chuyên nghiệp là người có thể giải quyết cả những việc gây căng thẳng.
Tôi không định biện minh cho việc khiến người khác bị căng thẳng. Khi làm việc một cách chuyên nghiệp, chắc chắn sẽ có những lúc bực bội, nhưng tôi cho rằng giải quyết chúng một cách khôn ngoan mới là sự chuyên nghiệp.
Tôi không phải là chuyên gia chính tả. Commu cũng không phải là công ty.
Tôi thực sự đồng ý với bình luận này. Tôi nghĩ đó là vì năng lực và thái độ tiếp nhận của người nhận đều rất xuất sắc. Tôi cho rằng người quản lý đó có triết lý rất rõ ràng, nhưng lại không biết cách tiếp cận tốt để truyền triết lý của mình cho cả nhóm.
Có lẽ đây chính là kiểu “ném ra mơ hồ mà vẫn bắt ý ngon lành”... haha
Một bài viết thực sự rất hay. Có lẽ tôi sẽ phải tiếp tục đọc lại bài này cả trước lẫn sau khi gửi PR.
Có vẻ để không trở thành công kích cá nhân thì cần xây dựng sự gắn kết tốt từ trước. (Đặc biệt là trong bối cảnh xã hội Hàn Quốc)
Cá nhân tôi chú ý đến cách dùng chủ ngữ. Việc over-engineering là ở "đoạn code này", chứ không phải là "đối phương" sai.
Nhớ đến bài Trong đầu chuyên gia rốt cuộc đang diễn ra chuyện gì. Khi nhận được những review như “Over-engineering đấy. Quá phức tạp. Hãy refactor đi”, “Cái này dễ bị tổn thương. Khi có tải thì sẽ thế nào? Kế hoạch rollback là gì?”, có lẽ cũng nên hỏi vì sao họ lại nghĩ vậy, họ đang dự đoán vấn đề gì, và đang nghĩ đến hướng cải thiện nào. (Không phải là nói tác giả đã không làm vậy, chỉ là trong những tình huống như thế, tôi chợt nghĩ liệu có cách nào để thu được nhiều giá trị hơn không)
Bài viết rất hay..