Lập trình viên tệ nhất mà tôi từng biết
(dannorth.net)- Một nhóm tư vấn tại Big Bank từng cố đo năng suất cá nhân bằng số story/story point đã hoàn thành, và Tim Mackinnon liên tục nhận điểm 0 theo chỉ số đó
- Lý do anh nhận điểm 0 không phải vì không làm việc, mà vì anh không nhận story dưới tên mình và dành phần lớn thời gian trong ngày cho lập trình cặp đôi
- Với các lập trình viên ít kinh nghiệm, thay vì đưa luôn đáp án, anh tạo ra việc học thông qua các câu hỏi kiểu Socrates; còn với senior, anh cùng họ tìm ra lời giải tốt hơn từ những góc nhìn khác nhau
- Khi có Tim cùng làm, cả nhóm làm việc hiệu quả hơn, năng suất hơn và đồng bộ hơn; cuối cùng người quản lý vẫn giữ Tim lại và lặng lẽ bỏ chỉ số năng suất cá nhân
- Cách đo tách riêng đóng góp cá nhân có thể biến những đóng góp như của Tim thành 0, vì vậy năng suất nên được nhìn qua tác động kinh doanh và dòng chảy ở cấp độ nhóm
“Lập trình viên 0 điểm” do chỉ số cá nhân tạo ra
- Một nhóm ở Big Bank đã áp dụng chỉ số hiệu suất cá nhân để đánh giá thành tích cá nhân và phục vụ mục tiêu phát triển
- Người quản lý tránh các chỉ số dễ bị thao túng như số dòng code hay số lỗi, và chọn đo số story hoặc story point đã hoàn thành vì cho rằng chúng đại diện cho giá trị kinh doanh
- Vì mỗi người đều gắn tên mình vào story trong một công cụ giống Jira, việc tạo chỉ số năng suất cá nhân là rất dễ
- Điểm số của Tim Mackinnon không chỉ thấp, mà theo đúng nghĩa đen là 0 điểm trong từng tuần và từng vòng lặp
- Người quản lý cho rằng nên đưa Tim ra khỏi nhóm và thay bằng người thực sự “giao” story, nhưng trưởng nhóm đã từ chối
Điều Tim thực sự mang lại
- Tim không nhận story dưới tên mình, mà thay vào đó làm việc bằng cách pairing với các thành viên khác nhau mỗi ngày
- Khi làm việc với các lập trình viên ít kinh nghiệm, anh để họ trực tiếp cầm lái và nhẹ nhàng dẫn họ đến lời giải
- Không ép đáp án hay thúc ép họ theo ý mình
- Tạo ra những khoảnh khắc học hỏi bằng các câu hỏi như “what if”, “how else” và câu hỏi kiểu Socrates
- Với các lập trình viên senior, anh làm việc theo cách gần với đồng sáng tạo hoặc sparring, áp dụng các thế giới quan khác nhau vào vấn đề để tạo ra kết quả mà một mình khó có thể nghĩ tới
- Thay vì trực tiếp giao phần mềm, Tim xây dựng nên đội ngũ giao phần mềm
- Cả nhóm vận hành hiệu quả và năng suất hơn
- Làm việc đồng bộ hơn và bao dung hơn
- Trải nghiệm cộng tác cũng vui vẻ hơn
- Khi người quản lý đến quan sát nhóm, Tim luôn đang làm “việc của người khác” cùng chính người đó, và nhờ vậy chất lượng đầu ra cao hơn, thời gian mang lại giá trị cũng ngắn hơn
- Cuối cùng nhóm vẫn giữ Tim lại và chọn trách nhiệm ở cấp độ nhóm thay cho chỉ số năng suất cá nhân
- Theo dõi và ghi nhận tác động kinh doanh mà họ mang lại cho tổ chức như một đơn vị hiệu suất cao
Nên nhìn năng suất ở đâu
- Việc đo năng suất tự nó vẫn cần thiết, và để có trách nhiệm rõ ràng thì tác động kinh doanh có thể đo được là lý tưởng nhất
- Số tiền tiết kiệm được
- Số tiền tạo ra được
- Số tiền được bảo vệ
- Nếu khó đo tác động kinh doanh trực tiếp, có thể dùng các chỉ số kinh doanh thay thế
- Trong các hệ thống thích nghi phức tạp, ngay cả tiền đề rằng có thể tách riêng và đo đóng góp của từng cá nhân cũng đã bị lung lay
- Các chỉ số DORA không đo đóng góp của từng “piston” cá nhân mà đo cách hệ thống công việc vận hành
- Có thể xem đó là chỉ số về văn hóa Westrum
- Cũng có thể xem là chỉ số về cách các thay đổi kỹ thuật chảy vào production
- Chỉ số cá nhân có thể biến đóng góp thực sự của những người như Tim thành 0, và cách nhìn vào thành quả ở cấp độ nhóm cùng dòng chảy ở cấp độ hệ thống là phù hợp hơn
1 bình luận
Ý kiến trên Hacker News
Khoảng 20 năm trước, tôi làm ở một công ty phần mềm tầm trung bán ứng dụng desktop cho Mac và Windows; cả đội hầu như chỉ có kinh nghiệm với Mac và mới đang học Windows, nên phiên bản Windows có rất nhiều vấn đề.
Khi đó tôi được biết đến như một chuyên gia Windows, nên được tuyển vào để cải thiện phiên bản đó và giúp đội quen với lập trình Windows.
Phần đầu mỗi ngày của tôi chủ yếu giống như “đi thăm bệnh”: ghé phòng các lập trình viên khác để pair programming, điều tra lỗi, thảo luận các best practice của Windows API; về sau một đồng nghiệp hỏi tôi “sao anh có thể dư dả thời gian như vậy”.
Vài tháng sau, trong đánh giá hiệu suất, tôi nhận được nhận xét rằng “năng suất chưa như kỳ vọng, đặc biệt khi xét đến việc năng suất của phần còn lại trong đội gần đây đã tăng lên”; tôi cứ nghĩ đó chính là lý do họ tuyển tôi.
Chia sẻ tri thức là lợi ích lớn nhất bạn có thể mang lại cho các lập trình viên khác, nhưng những người chọn con đường đó lại được tưởng thưởng quá ít.
Nếu không có những lập trình viên như vậy, thế giới phần mềm hiện nay đã chẳng thể tiến gần đến mức này; dù không được cảm ơn trực tiếp, họ chắc chắn vẫn có giá trị.
Mọi việc sửa chữa đều có cùng mức ưu tiên nhưng độ khó khác nhau; sau một tháng vừa học vừa thấy chẳng ai làm, tôi nhận sửa trạm gốc, nên mất nhiều thời gian hơn nhưng lại quan trọng hơn nhiều với vận hành.
Trong cuộc họp cuối tháng, biểu đồ tròn về tỷ lệ sử dụng được đưa ra, và tôi trông tệ hơn nhiều so với các đàn anh lành nghề.
Khi đó tôi học được vì sao các đàn anh chỉ chọn việc nhanh và dễ, cũng như sự tồn tại của chính trị nội bộ; gặp một sếp tệ từ sớm trong sự nghiệp hóa ra lại là điều may.
Sếp mới thừa nhận rằng trong kỳ đánh giá đầu tiên, ban đầu ông ấy đã viết sẵn kế hoạch cải thiện hiệu suất, nhưng sau khi chuyển sang văn phòng mở và thấy người ta xếp hàng đến nhờ tôi giúp, còn tôi thì không từ chối ai, ông ấy đã bỏ nó đi.
Mất chỗ ngồi có vách ngăn thì hơi khó chịu, nhưng nhờ chuyện đó tôi bắt đầu nhìn văn phòng mở theo hướng tích cực.
Tất nhiên bây giờ tôi không làm ở bất kỳ văn phòng nào nữa, và cũng không định nhận lại công việc nào không phải làm tại nhà.
Chỉ sau khi danh tiếng đã được tạo dựng thì bạn mới có thể thay đổi điều gì đó; trước đó thì rất khó.
Quá nhiều người tối ưu vì “đội” rồi bị sa thải hoặc bị bỏ qua khi thăng chức vì cấp trên nhìn nhận tiêu cực; ngược lại, người đã có danh tiếng tốt theo tiêu chí mà công ty hiện coi trọng thì thường được dung thứ cho cả hành vi xấu trong một thời gian khá dài.
Không biết người đó có lập tức rời sang nơi tốt hơn, bắt đầu bớt chia sẻ thời gian để khớp với chỉ số hiệu suất của công ty, hay thuyết phục được một người đủ cao trong sơ đồ tổ chức rằng mình thực sự được tuyển cho đúng vai trò đó hay không.
Tôi nhớ đến một giai thoại ở Bell Labs.
Có người tính ra những nhân viên năng suất nhất theo tiêu chí như số bằng sáng chế, rồi phát hiện nhiều người trong số họ ăn trưa với cùng một người.
Bản thân người đó không có năng suất cá nhân cao, nhưng luôn đặt ra những câu hỏi sâu sắc và thuyết phục, khiến đồng nghiệp trở nên năng suất hơn theo cách đo được.
Các luật sư ở bộ phận bằng sáng chế của Bell Labs cố tìm một nguyên lý tổ chức để giải thích vì sao một số người năng suất hơn, và điểm chung duy nhất là những nhân viên có nhiều bằng sáng chế thường ăn trưa hoặc ăn sáng với kỹ sư điện Harry Nyquist.
Nyquist không đưa ra ý tưởng cụ thể; ông khơi gợi để mọi người tự suy nghĩ, và hơn hết là đặt ra những câu hỏi hay.
Tập thể con người là một cấu trúc tinh tế, nên bầu không khí nhóm tốt và những câu hỏi hay có thể âm thầm cải thiện tình hình.
Nếu không thì khó được trả lương công bằng.
Tôi thì không.
Ở một công ty tôi làm trong vài năm, nếu không tạo được 10 point mỗi tuần thì sẽ bị đưa vào diện cải thiện hiệu suất, bất kể là junior hay senior
Tôi đã trải qua nhiều đội, và chỉ cần nhìn mức độ căng thẳng của các lập trình viên là biết ngay đội đó đo point như thế nào
Những đội cố đo point với thiện ý thì căng thẳng, hầu hết có dấu hiệu burnout và làm 60 giờ mỗi tuần
Ngược lại, những đội xem hệ thống như một trò chơi và hiểu rằng đó là một nhiệm vụ bất khả thi thì cho ticket point cao nhất có thể, hoặc tách thành các ticket nhỏ để liên tục tích điểm, và họ hạnh phúc, không căng thẳng
Trong môi trường như vậy, làm đúng luật là chiến lược của kẻ ngốc, và khi cuối cùng tôi nghỉ, 7 kỹ sư senior của công ty đều theo tôi ra đi trong vòng 4 tháng
Mục tiêu là chia thành những story có thể hoàn thành đều đặn, không căng thẳng, thay vì những story có độ bất định và rủi ro lớn
Không có nghĩa là chỗ làm đó trông tốt đẹp, nhưng những lập trình viên bị xem là đã “chơi” hệ thống nhìn chung có vẻ đã làm đúng theo cách Scrum muốn khuyến khích
Tuy nhiên, ép mức point tối thiểu mỗi tuần và khuyến khích thổi phồng point là quản lý tồi tệ
Vì họ vắt được nhiều việc hơn từ cùng những con người đó so với khi không gây áp lực
Sếp cũ từng nói thẳng rằng để hoàn thành dự án thì sẽ “tuyển người vào rồi đốt họ”, và lên kế hoạch chỉ cần họ làm hữu ích trong 6 tháng là đủ
Nếu ai chịu được căng thẳng và đãi ngộ thấp mà vẫn ở lại thì với công ty coi như là phần thêm, còn tôi cũng không trụ lâu
Nếu tuần đó không làm xong hết, ticket vẫn được đánh dấu hoàn thành, rồi phần việc còn lại được mở mới dưới dạng bug
“Khi một thước đo trở thành mục tiêu, thước đo đó không còn là một thước đo tốt nữa”
Ở một số nơi, việc biết được nhà quản lý có thể kỳ vọng điều gì quan trọng hơn năng suất thuần túy hướng tới mục tiêu
Những người ước lượng với thiện ý có thể đã nghĩ ban lãnh đạo cũng hành xử với thiện ý, nhưng nhiều dự án được tạo ra từ mong muốn chủ quan, hoặc đặt deadline ngắn một cách nhân tạo để “tạo động lực” cho mọi người
Sự căng thẳng đó có thể chẳng tạo ra giá trị gì ngoài sự thỏa mãn cảm xúc cho nhà quản lý
Khi hiệu suất của kỹ sư phần mềm được người không có chuyên môn kỹ thuật đánh giá, kết quả có thể rất kịch tính
Bạn tôi, “Tommy”, là một nhân viên IT rất giỏi về mạng, và chỉ vài tuần sau khi chuyển sang một công ty năng lượng thuộc sở hữu nhà nước, anh ấy phải tái xây dựng toàn bộ mạng bằng thiết bị hiện đại, bao gồm tất cả các tòa nhà của trụ sở chính
Công ty định thuê nhà thầu bên ngoài, nhưng khi thấy chi phí do bộ phận tài chính đưa ra, Tommy đã rất ngạc nhiên và nói rằng anh ấy có thể tự làm nếu có thiết bị vật lý như router, switch, cáp và 2 người phụ trách đi dây
Anh ấy hoàn thành việc đó trong vài tuần với chi phí chưa đến một phần mười ngân sách ban đầu, nhưng thứ nhận được chỉ là lời “cảm ơn, làm tốt lắm” bằng miệng từ sếp
Làm kỹ thuật IT trong thời mà các sếp lạc hậu không hiểu giá trị thật thì thật cay đắng
Sau đó Tommy có thể vào làm với tư cách contractor và nhận thêm thù lao
Một lập trình viên thật sự xuất sắc mà tôi từng làm cùng vừa viết code rất tốt, vừa viết cả thứ code kinh khủng đáng ra phải đập đi ngay, và cả hai đều là những yếu tố khiến làm việc với anh ấy rất dễ chịu
Giá trị của code tốt thì không cần giải thích, và có khả năng chúng tôi vẫn đang dùng code của anh ấy
Nhưng anh ấy cũng cực kỳ giỏi trong tình huống khẩn cấp
Khi khách hàng bị dừng hoàn toàn và có thể là lỗi của chúng tôi, anh ấy lập tức xuất hiện, nhanh chóng nắm vấn đề, rồi viết và cài đặt thật nhanh một đoạn spaghetti code bẩn để giúp khách hàng chạy lại
Đó là thứ code nhức mắt, không thể check-in cũng không thể refactor, nhưng nó tránh được khủng hoảng trước mắt trong khi ai đó về sau sửa lại cho đúng
Tôi thậm chí còn khâm phục năng lực thứ hai này hơn, vì trên hết đó là một kỹ năng hiếm, và anh ấy đơn giản là một người tốt nên ai cũng quý
Dù vậy, tôi hoàn thành việc nhanh, và nhiều lần thứ code kỳ quặc của tôi đã cứu nguy bằng cách giải quyết tình huống khẩn cấp hoặc giúp thắng thầu
Tôi khó giao tiếp với các lập trình viên “hướng tới hoàn hảo”; với họ, nếu code chưa được thiết kế đủ kỹ thì dù hiểu rằng cần tốc độ, nó vẫn có vẻ không có giá trị
Tất nhiên họ chắc cũng nghĩ ngược lại về tôi
Hiện giờ chúng tôi tạo các cuộc họp hằng tuần để giảm nhẹ vấn đề, và việc đó hoạt động khá tốt
Khó nhất là quyết định kiểu tiếp cận nào phù hợp khi không phải tình huống khẩn cấp nhưng lịch rất gấp và đặc tả không rõ ràng; ít nhất thì quyết định đó được đưa ra chung
Không phải không thể tự học, nhưng cách học thuộc đến mức có thể gõ máy móc các bài toán và lời giải phổ biến thật sự là việc rất đau khổ với tôi
Trừ khi bạn sở hữu công ty, bạn luôn bị đánh giá bằng giá trị nhìn thấy được bên ngoài
Nếu nhà tuyển dụng không nhìn thấy giá trị của bạn bằng mắt, khả năng bạn trụ lại ở đó là thấp
Một hệ thống hiệu suất hoàn toàn theo năng lực là lý tưởng, nhưng nếu việc tuyển dụng hay đánh giá nằm trong tay người khác, thành công phụ thuộc 100% vào cách người đó nhìn bạn
Nhận thức đó hình thành từ vẻ bề ngoài, bất kể nó có thực sự có giá trị cho công ty hay không
Điều đang nói ở đây không phải kỹ năng lập trình hay giá trị thực, mà là tuyển dụng và đánh giá; cũng có nhiều người vừa năng suất cao vừa quản lý danh tiếng rất tốt
Cá nhân tôi muốn các senior trong đội thực sự làm được những việc thật sự khó
Việc giúp junior làm việc cũng tốt, nhưng với những việc khó và phức tạp mà một junior thiếu kiến thức, kinh nghiệm và kỹ năng giao tiếp không thể làm được thì vẫn cần người thành thạo
Không hình thức pair programming nào có thể thay thế hoàn toàn điều đó
Cần tránh tình huống các tính năng giá trị thấp được triển khai rất tốt, nhưng các công việc có tác động cao, ưu tiên cao lại không hoàn thành vì những người giàu kinh nghiệm nhất bận giúp những người ít kinh nghiệm hơn mấy việc như cách viết unit test
Việc được giao cho junior không mặc nhiên có nghĩa đó là bài toán dễ; nếu không thì làm sao có thể phát triển engineer được
Không nên để mọi senior dành thời gian cho mentoring junior và cộng tác, nhưng nếu trong đội có vài người như thế thì họ đóng vai trò nhân sức mạnh và mang lại lợi ích cho toàn đội
Dù lúc tuyển dụng chưa biết, nếu anh ấy đã tìm được một vai trò ngách hữu ích, công ty lẽ ra nên biến nó thành một vai trò chính thức
Anh ấy là một coach, và nếu được tuyển cho vai trò đó thì ổn, nhưng có lẽ nếu công ty muốn coach thì họ đã thuê riêng
Có những tính năng khó mà junior dù được cho vô hạn thời gian cũng không hoàn thành được, vì họ chưa có kỹ năng, và kỹ năng đó phải mất nhiều năm mới có
Đôi khi cần sự giúp đỡ của senior, nhưng nếu vì thế mà senior không làm ra được gì thì từ góc nhìn công ty, ý nghĩa khá yếu
Tính năng khó nên giao cho người đủ senior, còn nếu muốn nuôi dưỡng junior thì hãy chia cho họ phần dễ hơn của công việc đó và để senior giải thích mình đang làm gì
Thái độ giúp đỡ mọi người của Tim thật tuyệt, nhưng việc các programmer khác cần nhiều trợ giúp đến mức Tim hoàn toàn không có thời gian tạo ra sản phẩm của riêng mình cũng là điều kỳ lạ
Vấn đề không nằm ở Tim, mà ở cách quản lý cho rằng việc các chuyên gia luôn ở trạng thái cần được giúp đỡ, và một Tim giống như tình nguyện viên lúc nào cũng sẵn sàng giúp, là ổn
Ngay từ đầu, nếu một trong các senior đã làm đúng thì junior lẽ ra cũng phải có thể sửa được
Nếu chính senior đó đã làm mà cấu trúc vẫn khiến mọi thứ khó và phức tạp, thì đáng hỏi tại sao lại gọi người đó là senior
Dù vậy, công việc của mọi senior không thể chỉ là giúp junior
Ngày nay rất khó trở thành người như vậy
Mọi thứ đều xoay quanh thành tích nhìn thấy được, nên những người như vậy dễ trở thành đối tượng bị cắt giảm, và tôi đã trực tiếp trải qua
Team player, mentor, software architect ngày càng bị đẩy ra ngoài, còn coder xả ra nhiều code thì chiếm chỗ
Dù technical debt khiến khả năng giao tính năng và bảo trì giảm dần theo thời gian, manager vẫn thích developer đều đặn viết hơn 5.000 dòng mỗi tuần, bất kể số tính năng thực sự được phát hành hay số bug
Với tư cách team lead và engineer từng quản lý các dự án phức tạp, người viết hơn 2.000 dòng code mỗi tuần khiến tôi thấy đáng sợ
Đó là hơn 100.000 dòng code mỗi năm, và phải nghĩ đến độ phức tạp không cần thiết
Rất có khả năng cùng một tính năng có thể được triển khai bằng 10.000 dòng, ít bug hơn và trong một nửa thời gian, nhưng như vậy chỉ là 380 dòng mỗi tuần nên manager sẽ không thích
Tôi có xu hướng cho rằng developer tạo ra hàng nghìn dòng không suy nghĩ đủ sâu về hướng đi dài hạn của dự án, và phần lớn số code đó gần như là code sẽ bị vứt bỏ
Google đã thể chế hóa điều này ở một mức độ nào đó bằng vai trò Tech Lead, và engineer này được kỳ vọng hành động như một người nhân sức mạnh và mentor hơn là một individual contributor
Nó không phải lúc nào cũng vận hành như thiết kế, có lẽ thậm chí chỉ hiếm khi vận hành đúng, và TL có thể sa vào điều phối con người, lập kế hoạch và những tranh luận vụn vặt đến mức không thể làm việc như engineer
Dù vậy, ý đồ của vai trò này là ổn
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
Ý tưởng đo lường mọi thứ và hành động theo những con số có được đã tồn tại từ thế kỷ 19
Từ khi đó các manager đã lặp lại cùng một thông lệ, và kết quả cũng xuất hiện khá ổn định theo cùng một cách
Chủ một công ty tôi từng làm một thời gian ngắn muốn viết lại web service từ đầu mỗi 6 tháng để chạy theo web framework mới nhất và các trào lưu
Nếu có một anh hùng 5.000 dòng mỗi tuần thì chắc ông ấy đã tuyển ngay tại chỗ
Với dự án bảo trì, có khi tôi trải qua cả tuần không tự viết dòng nào, thậm chí dành cả tuần chỉ để giảm số dòng code
Tuyệt vời
Trong môn rowing có bài tập gọi là seat racing, trong đó người ta thêm bớt người vào nhiều tổ hợp của tám vị trí để tìm ra tổ hợp nhanh nhất
Sức mạnh cá nhân cũng là một chỉ số, nhưng ai được ngồi trên thuyền đua là do tốc độ của đội quyết định
Cuối cùng, tổ hợp nhanh nhất hiếm khi đơn giản là tám người mạnh nhất, và thường có một hai người “như có phép thuật”, dù trên giấy tờ trông không xuất sắc hơn, nhưng đưa vào thuyền nào cũng làm thuyền đó nhanh hơn
Họ cải thiện một cách tinh tế sự cân bằng, nhịp điệu và sức mạnh của những người khác
Một số coach không sẵn lòng chấp nhận điều này và chống lại nó, kết quả là có ít chiến thắng hơn
Điều này rất giống với các đội phần mềm, và rốt cuộc điều quan trọng là tổ hợp và kết quả
Khi được yêu cầu huấn luyện về “lãnh đạo kỹ thuật”, tôi luôn nói rằng hãy chú ý kỹ đến nhân viên kiểu người thúc đẩy
Sự giúp đỡ của họ khiến các nhân viên khác làm việc năng suất và hiệu quả hơn; có người còn tìm thấy sự hài lòng trong công việc lớn hơn ở việc giúp người khác làm thật tốt, thay vì tự mình làm những việc đáng kinh ngạc rồi nhận hết công lao
Những người như vậy thường bị chấm điểm thấp, nhưng nếu mất họ thì năng suất của đội sẽ giảm ròng
Vì vậy tôi muốn đưa ra công cụ để phân biệt giữa người thực sự không năng suất và người có năng suất được thể hiện thông qua thành công của người khác
Việc chỉ đo một chỉ số rồi quản lý theo nó tuyệt đối không phải là điều tốt
Vì người biết “chơi” chỉ số sẽ “thắng”, và hành vi đó dẫn đến thăng tiến
Tôi cũng đã nói điều này với ban lãnh đạo Google, nhưng Laszlo nói: “Đây là hệ thống chúng ta có, nó không hoàn hảo nhưng chúng ta sẽ đi theo nó. Bạn chọn làm việc trong khuôn khổ đó hay không là tùy bạn”
Chỉ riêng cuộc họp đó cũng đủ để biết ban lãnh đạo cấp cao có muốn tạo ra một môi trường kỹ thuật tốt hơn hay không
Nhiều quản lý mới, đặc biệt là những người từng là kỹ sư đóng góp cá nhân, nghĩ rằng nếu giữ lại thành viên “giỏi nhất” và cho ra đi thành viên “kém” thì cả tinh thần lẫn sản lượng của đội đều sẽ tốt hơn
Nhưng “giỏi nhất” theo cách họ hiểu dựa trên tiêu chuẩn làm tốt công việc cũ của chính họ, chứ không phải tiêu chuẩn quản lý con người
Vì vậy họ ưu ái những người có kỹ năng và thói quen giống mình, và đánh giá thấp những người có kỹ năng và thói quen khác
Khoảnh khắc họ nhận ra điều này và mắt mở to ra lúc nào cũng rất thú vị
Chính sách lãi suất bằng không đã làm tăng các vai trò như giám đốc cấp cao chuyên quản lý bảng Jira và xử lý danh sách việc cần làm, trong khi lại thiếu những người có thể làm công việc thực tế
Tôi không phản đối ý tưởng rằng có thể có những người thúc đẩy năng suất của người khác, nhưng rốt cuộc để một việc gì đó hoàn thành thì vẫn cần những “người khác” đó
Nếu không, tổ chức sẽ hoại tử