Chuyện về import antigravity
Có lần tôi xem một anh bạn kỹ sư Python viết dòng code vô cùng kỳ lạ: import antigravity. Cả team bây giờ cười, chứ anh kia cười lâu rồi. Khi anh chạy nó, trình duyệt bật ra một bức tranh xkcd với câu chuyện cười về Python - một nước cờ thông minh, bỏ mặc tính thực dụng để trao cho developer những phút thở lực.
Nhưng mà câu chuyện phía sau hay hơn. Dòng code đó được tạo bởi Skip Montanaro vào năm 2008, như một lời nhắc nhở rằng: cái gì quan trọng nhất trong việc viết code không phải là syntax hay pattern, mà là tâm thế. Đôi khi bạn cần quên đi quy tắc, cười một lúc, rồi tiếp tục.
Nghe có vẻ hơi triết học, nhưng đó là chính xác cái mà tôi muốn nói hôm nay.
Trọng lực tổ chức là gì?
Hãy tôi giải thích nó bằng vật lý - rồi quay lại với code.
Trong vũ trụ, trọng lực là lực kéo các vật thể về phía nhau. Trong một tổ chức, "trọng lực tổ chức" cũng là lực tương tự, nhưng nó không kéo khối đá, mà kéo con người. Nó kéo:
- Quyết định kỹ thuật về phía cũ ("Chúng ta vẫn làm như vậy từ năm 2015")
- Team về phía những gì đã quen ("Đây là cách ta luôn làm")
- Tổ chức về phía inertia ("Tại sao chúng ta lại phải thay đổi?")
Cái nguy hiểm của trọng lực tổ chức là nó không khô khan, không là văn bản nào từ cuốn sách quản lý. Nó là kết hợp của:
- Thói quen - chúng ta thích lặp lại những gì biết
- Sợ hãi - sợ thất bại khi thử cái mới
- Áp lực từ stakeholder - "Hãy giữ nguyên, đó mới là an toàn"
- Kiệt sức xin phép - phải thuyết phục quá nhiều người
Những loại trọng lực tôi đã gặp
1. Trọng lực kỹ thuật (Technical Gravity)
Tình huống: Năm 2016, tôi tham gia vào một dự án legacy. Hệ thống nó là một monolithic beast - 2 triệu dòng code, tất cả tập trung trong một folder. Mọi người muốn refactor, tách thành microservices, dùng framework mới.
Nhưng việc refactor cứ bị kéo lại. Tại sao?
Vì mỗi dòng code mới bạn viết đều phải tương thích với 2 triệu dòng cũ. Trọng lực ở đây là technical debt - nó hút tất cả năng lượng bạn, không còn sức để bay.
2. Trọng lực tâm lý (Psychological Gravity)
Tình huống: Tôi làm việc với một team dưới 30 tuổi, họ muốn dùng Node.js, nhưng công ty quyết định dùng .NET vì "đó là ngôn ngữ của chúng ta".
Không ai nói là Node.js tệ. Nhưng cái khó là mọi người sợ. Sợ mình không biết, sợ mình sẽ fail, sợ mình sẽ phải học lại từ đầu.
Trọng lực ở đây là sợ hãi - nó không khó đánh bại về mặt kỹ thuật, nhưng khó đánh bại về tâm lý.
3. Trọng lực chính trị (Political Gravity)
Tình huống: Anh bạn tôi trong một công ty khác muốn refactor legacy database. Plan rất chi tiết, chi phí rõ ràng, lợi ích rõ ràng.
Nhưng ông VP không đồng ý. Lý do? "Nếu code đang chạy, sao phải sửa?"
Trọng lực ở đây là sự phản đối từ những người ở trên - họ sợ rủi ro, sợ kinh phí tăng vọt, sợ project bị delay. Quyết định kỹ thuật bị kéo ngược bởi chính trị.
4. Trọng lực từ "người đi trước" (Legacy Inertia)
Tình huống: Một công ty tôi từng tư vấn, họ vẫn dùng Flash vào năm 2020 vì "kiến trúc được thiết kế vào năm 2010 và nó hoạt động".
Không ai muốn bảo trì Flash nữa. Vendor Adobe ngừng hỗ trợ rồi. Nhưng con đường bị tạo lập rồi - mỗi feature mới đều phải vừa với Flash. Trọng lực là path dependency, cái lực kéo bạn trên con đường đã định rồi, chứ không phải con đường tốt nhất.
Làm thế nào để chống lại trọng lực?
Không có công thức magic. Tôi không thể nói "làm vậy là xong". Nhưng dựa trên 20 năm trong nghề, tôi thấy vài nguyên tắc:
Bước 1: Nhận thức được trọng lực
Bạn không thể chống lại cái bạn không thấy.
Hỏi team: "Tại sao ta vẫn dùng cái này?" Nếu câu trả lời là "Vì ta vẫn làm như vậy từ trước", đó là insight inertia - bạn không biết tại sao, hay không muốn biết.
Viết xuống danh sách:
- Technical debt (cái gì chậm, khó bảo trì, khó mở rộng?)
- Team friction (cái gì khiến team không hạnh phúc?)
- Stakeholder fear (cái gì khiến boss sợ hãi?)
Bước 2: Đo lường, không phỏng đoán
"Code của chúng ta chậm" không phải kết luận. Đó là cảm tính.
Hãy đo. Dùng profiler. Chạy benchmark. Tìm chỗ đau thực sự.
Khi bạn có số liệu, trọng lực yếu đi. Vì bây giờ không phải "ta cảm thấy", mà "ta biết".
Bước 3: Lựa chọn trận chiến nhỏ, không toàn bộ
Cái sai lầm lớn nhất mà tôi thấy: team muốn "refactor toàn bộ hệ thống trong 3 tháng".
Không được.
Thay vào đó, lựa chọn một phần nhỏ. Sửa cái module A. Thành công. Rồi module B. Thành công nữa. Rồi C.
Mỗi lần thành công, trọng lực yếu dần. Người khác sẽ thấy, sẽ tin.
Bước 4: Kể chuyện, không chỉ số liệu
Boss không phải nhà khoa học. Ông ta nghe story.
"Chúng ta refactor database layer. Kết quả, query giảm 80% thời gian. Giờ team có thể build feature mới mau gấp 3 lần."
Nói vậy hơn là "Ta optimize database queries, latency giảm 200ms".
Kinh nghiệm 20 năm
Cái tôi học được là: trọng lực tổ chức mạnh nhất khi bạn cô đơn.
Một mình bạn muốn thay đổi? Khó vô cùng. Nhưng nếu bạn có 2-3 người khác đứng cùng bên cạnh bạn, nói chung một giọng, "Đây là cách đúng", trọng lực tự động yếu đi.
Vậy nên task của leader không phải là "convince everyone", mà là "tìm những người sáng cũng thấy vấn đề".
Những người đó, họ sẽ là anchors để bạn chống lại trọng lực.
Gửi các bạn trẻ
Nếu các bạn là junior hay mid-level dev, có thể các bạn cảm thấy lực kéy mạnh từ trọng lực tổ chức. Các bạn muốn dùng framework mới, nhưng boss nói "ta chỉ dùng cái ta quen".
Hiểu bạn.
Nhưng đó không phải một cái lệnh. Đó là một bài toán. Bạn cần:
- Chứng minh rằng cái mới tốt hơn (benchmark, case study)
- Giảm rủi ro (proof-of-concept trong dự án nhỏ)
- Tìm người đồng tình (mentor, senior dev)
- Kiên nhẫn (không thay đổi trong 1 ngày)
Triết lý
Những năm 2015-2020, tôi từng bị mắc kẹt trong tư duy "phải có cách tốt nhất, phải tìm solution hoàn hảo".
Lạc lối vào những cuốn sách design patterns, vào những bài viết blog về microservices, rồi quay về công ty bảo team "ta phải refactor hết".
Điều tôi học được là: cái đơn giản nhất thường là đúng nhất.
Không phải lúc nào bạn cũng cần đánh bại trọng lực bằng "cách làm tốt nhất". Đôi khi bạn chỉ cần: hiểu vấn đề, tìm được người đồng tình, lên plan nhỏ, rồi bắt đầu.
Gravity sẽ yếu dần.
Bạn đã từng phải chống lại "trọng lực" nào?
Là cái gì? Legacy code? Team inertia? Boss sợ mạo hiểm?
Hãy share với tôi. Tôi muốn nghe.
/Son Do - believe in basic
#1percentbetter #techleadership #organizationalgravity #antigravity