Production incident đã kéo dài ba mươi phút khi một engineer lặng lẽ mở notebook và bắt đầu vẽ request path. Người đó không gõ nhanh nhất. Cũng không nói to nhất. Họ hỏi hai câu rất cẩn thận, tìm ra stale cache key, đề xuất rollback, rồi viết một note nhỏ để lần sau người khác nhận ra pattern sớm hơn. Đến bữa tối, mọi người gọi họ là 10x developer.
Mình hiểu vì sao cụm từ đó hấp dẫn. Team nào cũng từng gặp những người có impact lớn bất thường. Họ nhìn xuyên qua code lộn xộn rất nhanh. Họ làm bug khó trở nên nhỏ lại. Họ design thay đổi có thể xóa cả một lớp việc tương lai. Họ dạy người khác mà không làm ai thấy nhỏ bé. So với output trung bình, contribution của họ có vẻ được nhân lên. Sai lầm không phải là nhận ra impact xuất sắc. Sai lầm là giải thích nó như một năng lực cá nhân hiếm có lơ lửng bên trên hệ thống.
Huyền thoại 10x developer thường biến kết quả của team thành truyền thuyết cá nhân. Nó tưởng tượng một người đi nhanh gấp mười vì họ đơn giản là được tạo ra khác. Nhưng trong công việc thật, impact thường gắn chặt với context. Một senior engineer hiểu lịch sử product, deployment pipeline, failure mode, database quirk và nỗi đau customer có thể đi nhanh hơn vì nhiều năm tích lũy lặng lẽ được nén lại thành judgment. Thứ trông như tốc độ thường là memory, relationship và pattern recognition trở nên visible.
Cũng có nhiều kiểu leverage khác nhau. Viết nhiều code gấp mười hiếm khi là phiên bản có giá trị nhất. Đôi khi engineer có impact cao viết ít code hơn vì họ xóa một abstraction xấu, đơn giản hóa workflow, ngăn một migration tạo nhiều risk hơn value, hoặc dạy ba teammate debug hệ thống độc lập. Một người làm mọi người xung quanh tốt hơn một chút có thể tạo nhiều giá trị hơn người tự mình close nhiều ticket nhất.
Huyền thoại này trở nên nguy hiểm khi nó khuyến khích hero culture. Nếu một người được xem là người duy nhất có thể cứu hệ thống, team có thể ngừng đầu tư vào documentation, onboarding, test coverage, pairing và shared ownership. Hero trở thành bottleneck, rồi thành risk, rồi đôi khi thành một người mệt mỏi không thể nghỉ phép đúng nghĩa. Một team phụ thuộc vào một cá nhân xuất sắc không phải team mạnh. Đó là một hệ thống mong manh với câu chuyện nghe hay.
Nó cũng làm con đường trưởng thành trở nên nản cho những người khác. Nếu excellence được mô tả như món quà bí ẩn, engineer bình thường có thể bỏ lỡ con đường thực tế. Nhưng nhiều thói quen tạo impact cao học được. Đọc code trước khi rewrite. Hỏi failure sẽ trông thế nào. Ghi decision lại. Làm PR nhỏ hơn. Thấy câu hỏi lặp lại thì cải thiện docs. Build tool xóa toil. Share context sớm. Học business rule đứng sau code. Không có gì trong đó quá kịch tính, nhưng tất cả đều compound.
Còn một vấn đề lặng lẽ khác: label 10x thường reward sự giải cứu visible hơn là phòng ngừa invisible. Người sửa incident lúc nửa đêm có thể được ăn mừng. Người design rollout an toàn hơn và ngăn năm incident xảy ra có thể ít được chú ý vì chẳng có gì nổ. Engineering culture trưởng thành học cách coi trọng prevention, simplification và clarity, kể cả khi chúng không tạo ra một câu chuyện anh hùng.
Engineer xuất sắc thật sự có tồn tại. Một số người có taste, discipline, curiosity và patience rất sâu. Một số người nối được product, architecture, operations và human context theo cách làm project đổi hướng. Ghi nhận điều đó là bình thường. Câu hỏi tốt hơn là môi trường nào giúp impact đó khỏe mạnh thay vì cô độc. Team có để họ dạy người khác không? Có lan truyền pattern của họ không? Có bảo vệ họ khỏi việc trở thành cửa thoát hiểm thường trực không?
Nếu muốn có nhiều high-impact engineer hơn, mình nên nghiên cứu hệ thống quanh họ. Điều gì cho họ context? Ai cho họ quyền ra decision? Thói quen nào làm thinking của họ visible? Phần nào của codebase cho phép leverage, và phần nào bắt mọi người tiêu tốn sức vào thao tác tay? Đôi khi con đường tạo thêm impact 10x không phải là tuyển một con người huyền thoại. Nó là bỏ đi những ma sát 0.5x khiến người giỏi dành cả ngày vật lộn với ownership mơ hồ, build chậm, alert ồn và requirement lửng lơ.
Với từng cá nhân, một ambition khỏe hơn không phải là trở thành huyền thoại. Nó là trở nên hữu ích theo cách vượt khỏi đôi tay của mình. Để lại con đường rõ hơn phía sau. Làm hệ thống dễ hiểu hơn. Giúp teammate ra decision tốt hơn mà không cần bạn ở mọi phòng. Chọn reliability nhàm chán thay vì complexity ấn tượng khi product cần điều đó. Để impact được đo không chỉ bằng thứ bạn tự ship, mà bằng thứ trở nên dễ hơn sau khi bạn tham gia.
Cụm 10x developer có lẽ sẽ còn ở lại vì nó gọi tên một cảm giác nhiều người từng thấy. Dù vậy, mình thích một cách nói yên hơn: một số engineer trở thành multiplier. Họ nhân clarity, confidence, safety và learning lên. Họ làm công việc xung quanh bớt rối. Họ biến kinh nghiệm riêng thành năng lực chung. Kiểu impact đó có thật, nhưng nó không phải phép màu.
Lần tới khi ai đó gọi một teammate là 10x, có lẽ nên hỏi chính xác điều gì đã được nhân lên. Output, judgment, trust, maintainability, hay sự trưởng thành của những người xung quanh? Câu trả lời sẽ dạy team nhiều hơn bản thân cái label.