- “Kỹ sư 10x” nghe có vẻ hợp lý về mặt trực giác, nhưng trên thực tế việc đo lường năng suất một cách khách quan là rất khó, và việc xem đó là đặc tính cá nhân bất biến cũng là một cách tiếp cận sai lầm
- Quyền sở hữu thực chất và kết quả đầu ra của phần mềm được quyết định bởi sự hợp tác và năng lực ở cấp độ đội ngũ kỹ thuật
- Một tổ chức thực sự xuất sắc không chỉ là nơi có những người đặc biệt vượt trội, mà là nơi tạo ra môi trường để những kỹ sư bình thường liên tục tạo ra kết quả tốt
- Hệ thống cần được thiết kế với việc tính đến thực tế rằng người bình thường có thể mắc lỗi hoặc kiệt sức, và cần tập trung vào việc xây dựng “đội 10x”
- Thiết kế hệ thống phần mềm và văn hóa nên dựa trên đặc điểm, sự đa dạng và khả năng phát triển của “người bình thường”
- Cuối cùng, chỉ số cốt lõi của năng suất là tác động kinh doanh, và điều quan trọng là tuyển dụng cũng như xây dựng đội ngũ với “người phù hợp” thay vì “nhân tài giỏi nhất”
Ca ngợi những kỹ sư “bình thường”
- Bài viết này phê phán khái niệm “kỹ sư 10x” và giải thích tầm quan trọng của các tổ chức nơi những kỹ sư bình thường vẫn có thể tạo ra hiệu quả làm việc tập thể xuất sắc
Huyền thoại “kỹ sư 10x” và những giới hạn của nó
- Ai cũng từng có trải nghiệm gặp một kỹ sư phi thường trong sự nghiệp, như thể một phù thủy
- Từ đó, khái niệm “kỹ sư 10x” ra đời, nhưng nó có rất ít cơ sở và còn dễ củng cố định kiến
- Gần như không thể xác định một thước đo duy nhất cho năng suất
- Tổ hợp các biến số như tech stack sử dụng, domain, giai đoạn phát triển, tình hình thị trường, kinh nghiệm... là vô hạn
- Một người có thể là kỹ sư 10x ở một lĩnh vực cụ thể, nhưng ở phần lớn lĩnh vực khác lại chỉ bình thường hoặc dưới mức trung bình
- Dù từng là một DBRE xuất sắc, theo thời gian người đó vẫn có thể trở thành bình thường trong chính lĩnh vực ấy
- Cuối cùng, không ai có thể luôn giỏi hơn gấp 10 lần trong mọi lĩnh vực
Quyền sở hữu phần mềm lấy đội ngũ làm trung tâm
- Phần mềm là thứ được đội ngũ sở hữu và quản lý, chứ không phải do cá nhân phụ trách
- Mọi quá trình như bàn giao, bảo trì, cải tiến, mở rộng, tái cấu trúc phần mềm đều diễn ra ở cấp độ nhóm
- Một hệ thống do một người sở hữu sẽ trở thành điểm lỗi đơn lẻ (SPOF) nếu người đó vắng mặt vì nghỉ phép, chuyển việc..., và sẽ trở thành điểm yếu của tổ chức
- Ở startup, quyền sở hữu cá nhân có thể là điều khó tránh trong giai đoạn đầu, nhưng khi tổ chức phát triển thì nhất định phải chuyển sang quyền sở hữu theo nhóm
- Nhiệm vụ cốt lõi của lãnh đạo kỹ thuật là tập trung xây dựng đội ngũ hiệu suất cao, và điều quan trọng là tạo ra đội 10x thay vì “kỹ sư 10x”
Điều kiện của một tổ chức hiệu suất cao thực sự
- Nhiều công ty thích xây dựng đội ngũ xoay quanh người từng làm ở FAANG, tốt nghiệp trường danh tiếng, hoặc Staff Engineer
- Nhưng một tổ chức thực sự tốt là nơi kỹ sư bình thường có thể tạo ra tác động thực chất một cách ổn định
- Năng lực cạnh tranh lớn hơn không nằm ở một tổ chức mà chỉ “người giỏi nhất” mới tạo ra kết quả, mà là ở việc xây dựng một hệ thống nơi cả lập trình viên bình thường cũng có thể chủ động phát triển và tạo ảnh hưởng tích cực lên sản phẩm lẫn kinh doanh
- Trái lại, chính kiểu tổ chức này lại nuôi dưỡng được nhiều kỹ sư đẳng cấp thế giới hơn
Định nghĩa lại ý nghĩa của “bình thường”
- Ngành phần mềm đang đầy rẫy tư duy lấy giới tinh hoa làm trung tâm như “top 10%”, “top .1%”
- Nhưng điều quan trọng là thừa nhận rằng phần lớn kỹ sư là người bình thường, trưởng thành qua nhiều trải nghiệm và quá trình rèn luyện đa dạng
- Không ai sinh ra đã là một “kỹ sư xuất sắc” bẩm sinh
- Kỹ sư vĩ đại là được tạo nên - ai cũng có thể trở nên xuất sắc thông qua học hỏi và kinh nghiệm
Thiết kế hệ thống cho người bình thường
- Khi tuyển dụng, việc nhìn vào điểm mạnh vượt trội là đúng, nhưng khi thiết kế hệ thống thì phải tính đến thực tế rằng con người một cách bình thường sẽ mắc lỗi, mệt mỏi và dựa vào sự quen thuộc
- Kỹ sư thông thường chịu ảnh hưởng của thiên kiến nhận thức, sự mệt mỏi, biến động cảm xúc
- Chỉ khi hệ thống được thiết kế theo góc nhìn của kỹ sư bình thường chứ không phải số ít cực kỳ thông minh, thì năng lực sáng tạo của nhân tài mới có thể tập trung vào chính sản phẩm
Cách xây dựng một “đội 10x”
- Rút ngắn tối đa khoảng cách giữa việc viết code và triển khai
- Chu kỳ triển khai nhanh giúp giảm gánh nặng nhận thức, cho phép thử nghiệm và nhận phản hồi nhanh hơn
- Càng triển khai chậm thì càng nhiều thay đổi bị dồn lại cùng lúc, khiến việc truy vết vấn đề và rollback trở nên khó khăn
- Giúp việc khôi phục sau lỗi và rollback trở nên dễ dàng
- Lập trình viên phải có thể tự triển khai code và nhanh chóng khôi phục khi phát hiện vấn đề
- Làm cho hành vi đúng trở nên dễ, và hành vi sai trở nên khó
- Hợp tác với designer và platform engineer để xây dựng guardrail và cơ chế self-service
- Đầu tư tích cực vào công cụ observability và instrumentation
- Trực quan hóa cách code thực sự vận hành để mọi kỹ sư đều có thể dễ dàng hiểu hệ thống và debug
- Đầu tư nguồn lực kỹ thuật vào công cụ nội bộ và nâng cao năng suất
- Những hệ thống như vậy cần ownership riêng và phải trở thành ưu tiên ở cấp toàn công ty
- Xây dựng văn hóa hòa nhập
- Môi trường nơi ai cũng có thể đặt câu hỏi, mắc lỗi và khám phá
- Đội ngũ có nền tảng, kỹ năng và thâm niên đa dạng sẽ bền bỉ hơn và thích ứng tốt hơn với thay đổi
- Tổ chức đội ngũ pha trộn kỹ sư ở mọi cấp độ
- Cấu trúc nơi từ junior đến senior cùng học hỏi, chỉ dạy và phát triển với nhau
- Những hệ thống như vậy cũng có thể tái sử dụng cho onboarding người mới, luân chuyển giữa các nhóm...
Thước đo thực sự của năng suất: "tác động kinh doanh"
- Cuối cùng, thước đo năng suất của kỹ thuật phần mềm là tác động kinh doanh
- Bản chất không phải là viết thật nhiều code, mà là giải quyết vấn đề và tạo ra giá trị
- Trên thực tế, những người thực sự vận hành ngành công nghiệp không phải Staff+ engineer mà là kỹ sư senior và mid-level
- Họ tạo nên nền móng của tổ chức và liên tục thúc đẩy hoạt động kinh doanh tiến lên
- Nếu chỉ cấp Staff+ mới có thể tạo ra tác động, đó là dấu hiệu cho thấy tổ chức đang có vấn đề
Tổ chức nuôi dưỡng kỹ sư đẳng cấp thế giới
- Một tổ chức thực sự tốt là nơi ngay cả khi không phải kỹ sư xuất sắc, ai cũng có thể tạo ra tác động
- Tổ chức tốt nhất là nơi, ngay cả khi không cố tình chỉ tuyển người ở đẳng cấp hàng đầu thế giới, vẫn tự nhiên sản sinh ra nhiều kỹ sư đẳng cấp thế giới nhất
- Nhân tài sẽ tụ về nơi kỹ sư có thể tập trung vào giải quyết vấn đề, phát triển và tạo tác động, và chính “trải nghiệm làm việc hạnh phúc và trưởng thành” sẽ tạo nên một vòng tuần hoàn tích cực
- Lãnh đạo không nên phụ thuộc vào năng lực cá nhân của người giỏi, mà phải kết nối điều đó với sự phát triển của toàn tổ chức và giá trị cho khách hàng
Tuyển “người phù hợp” thay vì “nhân tài giỏi nhất”
- Ngành này luôn cố tìm kiếm “người giỏi nhất”, nhưng điều thực sự quan trọng là hệ thống và môi trường
- So với “nhân tài giỏi nhất”, việc tìm người phù hợp với đội ngũ và tổ chức là lợi thế cạnh tranh lớn hơn
- Thay vì một người không có điểm yếu, cách hiệu quả hơn là xây dựng đội ngũ với nhân sự phù hợp có điểm mạnh đặc trưng, giúp tăng cường sự đa dạng và hài hòa của tổ chức
- Một đội ngũ hòa nhập và đa dạng thực sự tạo ra thành quả, tăng trưởng và thành công dài hạn
- Nơi mà mọi người thích công việc, tiếp tục trưởng thành và tạo ra kết quả có ý nghĩa mới là tổ chức đẳng cấp thế giới thực sự, và trong một văn hóa nơi có thể học hỏi cả từ thất bại lẫn sai lầm, cả kỹ sư lẫn tổ chức đều cùng phát triển
- Chính những tổ chức như vậy mới thu hút được thế hệ kỹ sư tiếp theo, đồng thời cũng là môi trường mà những người vốn đã xuất sắc muốn gắn bó
1 bình luận
Ý kiến trên Hacker News
Tôi đồng cảm với quan điểm cho rằng đơn vị tối thiểu của quyền sở hữu phần mềm và delivery là đội ngũ kỹ thuật, nhưng cũng thấy hơi tiếc. Cấu trúc như vậy gắn liền với một văn hóa nơi kỹ sư trở thành công dân hạng hai so với quản lý hay bộ phận sản phẩm. Chúng ta chỉ chịu trách nhiệm về delivery, còn những quyết định thực sự có ý nghĩa thì không thể tự chủ đưa ra vượt quá một phạm vi rất nhỏ của đội. Ở những đội tốt nhất, khoảng thời gian có quyền tự quyết kéo dài hàng tháng, thậm chí hàng năm, nhưng ở đa số đội thì chỉ co lại còn vài ngày hoặc vài tuần. Tuy vậy, trên thực tế hoàn toàn có thể xây dựng một cấu trúc nơi kỹ sư có quyền sở hữu thực chất mà hệ thống vẫn bền vững lâu dài, không dễ vỡ hay trở nên rủi ro. Bí quyết là tạo ra slack, khuyến khích công việc chất lượng và cho mọi thành viên đủ tự do để linh hoạt chuyển đổi công việc. Mỗi người vừa có quyền sở hữu vừa đưa ra quyết định dài hạn, đồng thời vẫn có thể cộng tác ad hoc và chia sẻ tri thức ngầm, nên những kịch bản như ai đó đột nhiên nhảy vào hỗ trợ hoặc tiếp quản hoàn toàn cũng diễn ra rất tự nhiên. Theo kinh nghiệm thực tế, những đội như vậy có nhiều lần rewrite hơn đội bình thường, nhưng nhìn chung lại năng suất hơn rất nhiều. Rewrite hệ thống từng phần nhỏ một cách dần dần cực kỳ hiệu quả cho cả sự tiến hóa của thiết kế lẫn việc tích lũy tri thức và năng lực trong tổ chức. Nhìn bề ngoài có thể giống lãng phí, nhưng đó là phần dư địa thiết yếu để toàn bộ tổ chức trở nên linh hoạt và có khả năng phục hồi. Tôi ngày càng tin rằng nhiều quy trình top-down cố cắt giảm cái gọi là lãng phí thực ra đang xóa bỏ chính phần “slack” quan trọng đó
Những người ngoài kỹ thuật thường không thể đánh giá ngay các quyết định dài hạn do kỹ sư đưa ra, và cũng không biết nên thưởng cho chúng thế nào. Điều này đúng cả khi chỉ cần rời khỏi chính đội kỹ sư đó. Với các công việc dài hạn mang giá trị nội tại, họ không có khả năng trực tiếp đánh giá liệu giá trị đó có thực hay không. Nếu bạn tự tin vào quyết định dài hạn của mình và cách mình sử dụng slack time, thì việc được thưởng theo delivery cũng không sao. Đến một lúc nào đó, công việc dài hạn ấy sẽ quay lại bằng kết quả tốt hơn
Tôi nghĩ rewrite phần mềm giữ vai trò quan trọng trong quá trình phát triển. “Agile” đúng nghĩa là không quá ám ảnh với kiến trúc đầu tiên, mà tạo prototype nhanh để linh hoạt thích nghi với thay đổi yêu cầu. Việc viết code giống như viết văn: bản nháp đầu tiên có thể thô, nhưng cứ viết ra trước rồi cải thiện ở phiên bản thứ hai sẽ hiệu quả hơn nhiều. Mục tiêu của bản nháp đầu không phải là làm cho tốt, mà là tạo ra thứ gì đó thật nhanh để khám phá problem space và nhận ra các edge case. Cách làm này lại không thuyết phục được ban điều hành. Chỉ cần thấy một prototype chạy được là họ sẽ nói “đưa ngay ra mắt đi”, chứ không cho thời gian để rewrite. Nếu có một giải pháp, thì nên làm phẳng hệ thống phân cấp trong tổ chức và thực sự trả lại quyền sở hữu code cho kỹ sư. Một cấu trúc nơi kỹ sư và product owner cùng ra quyết định theo cách dân chủ sẽ là điều đáng mong muốn
Trước đây tôi cũng từng coi trọng “quyền sở hữu cá nhân”, và bây giờ vẫn nghĩ kỹ sư có thể có quyền sở hữu, nhưng cũng phải thừa nhận rằng trên thực tế nhiều kỹ sư không hề muốn điều đó. Đa số kỹ sư thấy ổn nếu ở cấp độ đội, nhưng lại không mấy quan tâm đến quyền sở hữu ở cấp cá nhân. Với họ, đây đơn giản chỉ là kế sinh nhai. Nếu giao việc này cho từng cá nhân, nó dễ tạo ra mất lòng tin trong đội hoặc cô lập những thành viên không có thiên hướng lãnh đạo, và cuối cùng rất dễ dẫn tới tình trạng không ai có quyền tự quyết thực sự. Một cấu trúc trao quyền sở hữu và quyền tự quyết ở cấp đội đơn giản hơn nhiều và hiệu quả hơn nhiều. Đây cũng là kiểu động lực có thể tồn tại nhờ có team lead hoặc manager. Nếu giao quyền sở hữu phần mềm cho từng cá nhân thì rủi ro thất bại quá lớn, do biến động nhân sự, độ ổn định, sự nghiệp và nhiều yếu tố khác. Dù tổ chức có lành mạnh đến đâu thì vẫn luôn có các vấn đề lớn nhỏ, và trong cấu trúc kiểu này, con đường dẫn đến thất bại sẽ ngắn nhất. Nghĩ theo hình ảnh hộp số thì dễ hiểu hơn: nếu chỉ có một bánh răng mà nó hỏng, bạn không đi tiếp được; nếu có nhiều bánh răng, dù bất tiện hơn, bạn vẫn có thể tiếp tục ngay cả khi một cái vừa hỏng
Tôi thực sự nghĩ quyền sở hữu cá nhân theo nghĩa thực chất là khả thi. Thậm chí có lẽ đó là cách duy nhất để thật sự “năng suất”. Nhưng đây không phải điểm cốt lõi. Mỗi cá nhân là không thể thay thế, nhưng thành viên trong đội thì tùy cấu trúc mà có thể thay thế ở mức nào đó. Tổ chức càng lớn càng muốn tính dự đoán ở cấp đội, và để làm được điều đó thì cần khả năng thay thế thành viên, tức redundancy. Trong kỹ thuật cũng vậy: độ tin cậy và khả năng phục hồi cần redundancy, còn hiệu quả là một trade-off với việc giảm redundancy
Chúng tôi làm việc trong kiểu cấu trúc mà trách nhiệm chỉ gói gọn ở “delivery”, nên quyền sở hữu rốt cuộc chỉ làm tăng gánh nặng mà không có phần thưởng thực chất. Công việc bị giới hạn ở mức chỉ gắn tính năng lên trang. Nếu có thêm trách nhiệm thì cũng nên có thêm đãi ngộ tương xứng. Manager hay executive được trả nhiều hơn theo số người họ chịu trách nhiệm, thì lập trình viên cũng phải như vậy
Tôi tin chắc rằng những đội tốt nhất là nơi văn hóa giúp các kỹ sư bình thường tạo ra thành quả phi thường. So với cái mà người ta hay gọi là “engineering quality” hay tuyển dụng nhân tài, văn hóa, niềm tin, hệ thống và quy trình quan trọng hơn rất nhiều. Có câu rằng “ai cũng có thể xây dựng một tổ chức có các kỹ sư giỏi nhất”, nhưng trên thực tế số tổ chức làm được điều đó thực sự rất ít. Gần như toàn là các công ty trading hoặc các tổ chức đặc thù/nghiên cứu. Tôi thật sự không hiểu vì sao những nơi khác lại không làm được. Cuối cùng thì ngay cả khái niệm “năng suất” nghĩa là gì cũng đã mơ hồ. Cũng có những hệ thống đánh giá thực chất là đang đo khả năng chịu đựng và vượt qua dysfunction trong tổ chức, nhưng tôi không nghĩ đó mới là ý nghĩa của một “top engineer”
Nguồn cung kỹ sư thực sự xuất sắc là có hạn, nên các công ty lớn hơn rốt cuộc sẽ kéo cùng một nhóm nhân tài ấy đi bằng công việc thú vị hơn hoặc lương cao hơn
Vấn đề tiền bạc mà người khác nói đến là lớn, nhưng “thời gian” cũng là yếu tố rất lớn. Công ty không có dư địa để chờ một nhân tài “unicorn” hoàn hảo xuất hiện, nên thường buộc phải lấp chỗ trống bằng người có thể tuyển ngay. Ở một số công ty, đặc biệt trong các lĩnh vực như quant finance, một siêu kỹ sư duy nhất hội đủ khả năng của lập trình viên hệ thống, nhà toán học và chuyên gia thị trường tài chính có thể tạo ra giá trị lớn hơn rất nhiều so với một đội gồm ba chuyên gia riêng lẻ. Nhưng để tìm được người như vậy thì mất quá nhiều thời gian. Ngay cả trong web development, những lập trình viên “full stack” thực sự hiểu sâu toàn diện từ network protocol, system admin, distributed systems, database cho đến frontend cũng cực kỳ hiếm. Chỉ những tổ chức có đủ thời gian và chi phí mới có thể tập hợp kiểu nhân tài này để làm ra sản phẩm tốt nhất. Tất nhiên, sản phẩm có thực sự cần tới mức chất lượng đó hay không lại là một câu hỏi khác
Về căn bản, nguồn cung “kỹ sư giỏi nhất” trên toàn thế giới là cực kỳ hạn chế. Nếu bạn có thể trả mức lương thuộc top 10% và tập hợp rồi giữ được lượng nhân tài tương xứng, thì đó đã là thành công. Thực ra không phải “ai cũng” làm được điều này; cần có lãnh đạo thực sự biết thiết kế một hệ thống xã hội-kỹ thuật tập trung vào học hỏi và phát triển. Bản thân điều đó cũng đã là một thành tựu lớn
Vấn đề lớn nhất là phần lớn quản lý cấp một đến cấp hai không thực sự giỏi. Họ thiếu khả năng tạo ra và duy trì một môi trường năng suất. Giải pháp tận gốc rốt cuộc vẫn là trả “nhiều tiền”. Khi tiền đủ lớn, người ta có thể chấp nhận hầu hết các điều kiện khó khăn
Bỏ qua vấn đề ngân sách, một kỹ sư thực sự xuất sắc đôi khi lại không phù hợp với teamwork. Một bộ óc quá nổi bật đôi khi có thể trở thành chướng ngại cho những thỏa hiệp cần thiết hoặc những việc nhàm chán nhưng bắt buộc phải làm
Tôi không thể đồng ý nhiều với lập luận rằng “business impact là thước đo năng suất duy nhất”. Cách nhìn đó khiến trọng tâm bị kéo về những thay đổi đo được và thành quả ngắn hạn, làm lỡ mất giá trị thực sự của các kỹ sư lành nghề. Giá trị của người thực sự giỏi nằm ở chỗ ngăn chặn trước những landmine có thể khiến dự án hay công ty suýt đổ vỡ. Nhưng những “rủi ro đã biến mất” như vậy rất khó đo lường, và gần như không thể truyền đạt theo cách nghe có vẻ bình thường
“Impact” không nhất thiết là góc nhìn ngắn hạn. Những người tạo ra impact lớn nhất cho tổ chức là những người hành động với góc nhìn dài hạn
Tôi cố tình nói về “năng suất” hay “impact” như những khái niệm mơ hồ. Ví dụ kiểu như “xét tổng thể thì X đã làm việc rất tốt”. Những điều như vậy khó lượng hóa, cũng khó quy định rõ ràng, nhưng vốn dĩ trong các tổ chức phức tạp và sáng tạo, trực giác và phán đoán của con người mới quan trọng hơn. Việc cố gắng lượng hóa quản trị bằng mọi giá về bản chất là thiển cận
Tôi không đồng ý với việc chỉ đo giá trị của kỹ sư bằng quản lý dự án hay tránh né rủi ro, nhưng cũng thấy không thoải mái khi quy mọi thứ về “business impact”. Trên đời có rất nhiều việc có ý nghĩa với cá nhân, nhân loại và thế giới mà không liên quan đến tiền bạc. Những kỹ sư tôi kính trọng nhất không phải các nhân vật thần thoại của Silicon Valley hậu 2001, mà là John von Neumann, Robert Oppenheimer, Nikola Tesla, Leonardo da Vinci, những người đã xây các cống dẫn nước của La Mã và kim tự tháp Ai Cập, hay các nhà thiên văn của Babylon-Mesoamerica. Họ có để lại business impact không? Dù Tesla từng đem lợi nhuận cho Westinghouse trong một giai đoạn, điều đó cũng không giải thích được thành tựu của ông. Thực tế là về mặt kinh doanh ông khá bình thường. Các bậc thầy của ngành điện toán hiện đại cũng tương tự. Việc Nvidia hay Geoff Hinton đạt thành công khổng lồ cũng có phần nhờ “vận may” khi internet được quảng cáo hóa và dữ liệu bùng nổ. Cũng có rất nhiều trường hợp người thật sự giỏi bị lãng quên rồi biến mất. Ngay cả một đại gia như Doug Lenat của giới AI cuối cùng cũng có thể không được lịch sử khai quật do dòng chảy thời cuộc. Thành công trong nhiều trường hợp không liên quan nhiều đến nỗ lực cá nhân
Hoặc bạn xây dựng hệ thống hiệu quả, hoặc bạn xây dựng hệ thống giảm thiểu khả năng thảm họa; đó là một lựa chọn đánh đổi. Trên thực tế rất khó chứng minh thảm họa nào đã được ngăn chặn, và vì tác động tiêu cực là “sự kiện đã không xảy ra”, nên cũng khó thể hiện nó như một kết quả
Công ty nên cố gắng định lượng tốt hơn rủi ro của những “điều chưa biết”
May mắn là từ trước đến nay tôi đã làm việc ở nhiều đội rất tốt, và hiện tại cũng đang dẫn dắt một đội như vậy. Trái với bài viết, càng là những đội như thế thì tổ chức lại càng khó quản lý hơn. Các tổ chức lớn vì quá tập trung vào tiêu chuẩn hóa nên thường khiến kỹ sư giỏi không thể phát huy hết năng lực và cũng đánh mất động lực. Tôi không đồng ý với góc nhìn bi quan rằng không thể đào tạo mọi người thành kỹ sư giỏi. Trên thực tế, nếu đầu tư đều đặn thì hoàn toàn có thể đào tạo họ thành những kỹ sư xuất sắc, và về dài hạn lợi ích thu được từ việc có một nguồn nhân tài mạnh hơn sẽ vượt xa chi phí đầu tư đó
Chỉ vì không đo lường hiệu quả được không có nghĩa là bản thân thứ đó không tồn tại. Năng suất cá nhân, tức hiệu quả công việc của từng người, chắc chắn là có. Có lẽ chỉ là năng suất ở cấp nhóm dễ đo hơn mà thôi. “Business impact” ngược lại còn tùy tiện hơn nhiều, và nếu dùng loại thước đo đó thì rất khó giữ lại những người thật sự năng suất. Việc đánh giá chuyên môn là cực kỳ khó nếu không có kinh nghiệm tương đương; bạn có thể đưa lời khuyên, nhưng chuyện đối phương có đủ độ mở trí tuệ để tiếp nhận hay không lại là vấn đề khác. Làm sao biết được tôi là thiên tài hay chỉ là một người quá tự tin
Vấn đề không phải là không thể “đo” năng suất, mà là thậm chí không thể “định nghĩa” nó một cách trừu tượng. Kể cả khi bạn chỉ đo xem ai đóng góp nhiều hơn “replacement” đến đâu, thì kết quả đó cũng không giải thích được chính xác nó được tạo ra như thế nào. Trên thực tế, ảnh hưởng của một cá nhân được quyết định bởi bối cảnh và toàn bộ tổ chức. Nếu cố đưa ra một định nghĩa trực tiếp hơn thì đáp án lại khác nhau rất xa theo từng tổ chức và hoàn cảnh. Đây là điều rất đáng suy nghĩ, nhưng bản thân tiêu chí “kỹ sư Top 1%” có thật sự có ý nghĩa hay không cũng đã là điều đáng nghi
Thiên tài thực sự có thể giải thích kết quả của mình một cách lịch thiệp và dễ hiểu. Vì vậy tôi nghĩ sự khác biệt hoàn toàn có thể được nhận ra
Tôi thích câu “tổ chức tốt nhất là tổ chức giúp một kỹ sư bình thường có thể làm nên công việc vĩ đại”. Không cần mọi thành viên trong đội đều là siêu sao. Điều thực sự quan trọng là mức độ hỗ trợ để một lập trình viên trung bình có thể thể hiện năng lực đủ tốt và đáng tin cậy
Nguyên tắc “làm cho điều đúng trở nên dễ, và điều sai trở nên khó” giống hệt khẩu hiệu cốt lõi của mọi platform team mà tôi từng gặp. Mục tiêu là thiết kế hệ thống sao cho với những vấn đề kỹ sư gặp phải, “đáp án đúng” tự động hiện ra trước mắt và có thể triển khai dễ dàng. Nếu hệ thống có độ tin cậy và dễ quản lý, từ đó tự nhiên rèn được “cơ bắp” phát triển theo đúng hướng, thì cả tổ chức sẽ được hưởng lợi. Chân lý này sẽ còn đúng về sau
Mỗi khi người ta nhắc đến đủ loại ngôn ngữ/framework như golang, python, COBOL, lisp, perl, React, brainfuck, tôi luôn có cảm giác từ lâu rằng mọi người có xu hướng nhầm React với toàn bộ hệ sinh thái frontend. Trên thực tế, ngoài React vẫn còn cả một thế giới frontend rất đa dạng, nhưng dường như ai cũng nghĩ React là tất cả
Ở công ty tôi, chúng tôi luôn thích tuyển một kỹ sư mức trung bình nhưng có thái độ tốt hơn. Những người chỉ có hồ sơ đẹp nhưng thái độ tệ thường rất giỏi xây dựng danh tiếng cá nhân nên dễ lấy được niềm tin từ cấp trên, rồi sau đó trở thành người gần như bất khả xâm phạm. Một khi kiểu người này đã bám rễ, những người xung quanh dù thấy bất công cũng rất khó lên tiếng. Cấp trên cũng dễ bỏ qua những dữ liệu trái với nhận thức của mình, vì dựa vào nhận thức luôn dễ hơn nhiều so với bám vào dữ liệu khách quan
Tôi thật sự đồng cảm với quan điểm rằng “ai cũng có thể xây dựng một tổ chức làm việc cùng các kỹ sư giỏi nhất, và việc chỉ tập trung vào năng lực cá nhân sẽ làm mờ vai trò thực sự của người lãnh đạo. Tạo ra một hệ thống để các kỹ sư ít kinh nghiệm hơn có thể dốc sức tạo kết quả là một lợi thế cạnh tranh khổng lồ”. Tôi không phải kỹ sư 10x, nhưng nhìn từ trải nghiệm gần đây thì khi trong đội có nhiều người còn thiếu kinh nghiệm và kỹ năng, tôi là người duy nhất phải ôm các ticket phức tạp. Nếu kiểu này lặp đi lặp lại, gần như tôi sẽ phải xử lý phần lớn công việc một mình, và thực tế vai trò đó vừa nặng nề vừa khiến tôi thấy không công bằng. Thành thật mà nói, tôi nghĩ một SRE giỏi nên có chút lười biếng, nên tôi rất muốn đồng đội chia sẻ bớt công việc. Vì vậy tôi đã cày rất nặng trong vài tuần để đưa vào nhiều lớp trừu tượng cho những phần phức tạp nhất của hệ thống này (tôi chủ yếu làm IAC; trong phần mềm cũng có mô hình tương tự). Kết quả là cả những kỹ sư tương đối thiếu kỹ năng hay kinh nghiệm cũng bắt đầu chia sẻ được vai trò của tôi, còn thời gian của tôi thì có thể dùng cho những vấn đề thú vị hơn. Đây là lần đầu tiên tôi thử làm điều như vậy mà không hề có ai chỉ đạo. Ngược lại, nếu không có cấu trúc kiểu này mà cứ hành xử như một anh hùng đơn độc, thì cả đội sẽ chỉ chạy theo phía sau để dọn lỗi, và cuối cùng sẽ biến thành một đội cực kỳ kém hiệu quả