- Kỹ sư cấp cao ưu tiên ‘hành động hiệu quả’ hơn là ‘đúng đắn’, nên họ không cố ngăn chặn mọi dự án sai lầm
- ‘Dự án tệ’ có thể bao gồm các vấn đề về kỹ thuật, chính trị và UX, và thường thay đổi tùy theo đánh giá chủ quan
- Ảnh hưởng cần được quản lý như tài khoản ngân hàng, vì nếu phản đối quá thường xuyên, bạn có thể mất niềm tin và rơi vào trạng thái ‘phá sản chính trị’
- Việc có can thiệp hay không được quyết định dựa trên mức độ gần gũi với dự án, tác động đến đội ngũ, và quy mô thiệt hại với toàn công ty
- Thay vì cố giải quyết mọi vấn đề, cần chọn thời điểm can thiệp một cách chiến lược, còn lại thì quan sát và chuẩn bị phương án ứng phó
Định nghĩa và ví dụ về dự án tệ
- ‘Dự án tệ’ xuất hiện dưới nhiều dạng như giải quyết vấn đề không cần thiết, thiết kế quá phức tạp, động cơ chính trị
- Ở góc độ UX, đó có thể là giải quyết một vấn đề không hề tồn tại hoặc phá vỡ luồng đang hoạt động tốt
- Về mặt kỹ thuật, đó là độ phức tạp quá mức, chọn sai thư viện, kiến trúc kém hiệu quả
- Về mặt chính trị, đó là các dự án phục vụ thăng chức hoặc chạy theo trào lưu
- Tốt hay tệ là một đánh giá mang tính chủ quan và thường chỉ bộc lộ theo thời gian, nên lúc đầu không phải lúc nào cũng rõ ràng
- Một ví dụ tại Google: một dự án mà đội nền tảng muốn chuyển giao luồng người dùng cốt lõi cho đội khác đã thất bại vì lý do chính trị
- Về mặt kỹ thuật nó rất tốt, nhưng đã bị loại bỏ sau 2 năm vì vấn đề quyền hạn giữa các tổ chức
- Bài học rút ra là: chính trị và độ chính xác trong việc xác định vấn đề cũng quan trọng ngang với mức độ hoàn thiện kỹ thuật
Vì sao không thể ngăn chặn mọi dự án tệ
- Các công ty phần mềm có xu hướng thiên về ‘triển khai nhanh’, nên việc nêu lo ngại thường bị xem là làm chậm tiến độ
- Vì vậy, nếu không bị coi là vấn đề lớn, các cảnh báo rất dễ bị bỏ qua
- Việc phản đối lặp đi lặp lại dễ khiến bạn bị gắn nhãn là người tiêu cực, trong khi những thất bại được ngăn chặn thì lại không được ghi nhận
- Phản đối có thể ảnh hưởng đến cơ hội thăng chức của người khác hoặc các dự án do lãnh đạo cấp cao hậu thuẫn, nên luôn có rủi ro chính trị
- Sự chú ý mà một kỹ sư có thể gánh vác là hữu hạn, và nếu can thiệp vào mọi vấn đề thì rất dễ trở nên cay hoài nghi
Quản lý ảnh hưởng như một ‘tài khoản ngân hàng’
- Ảnh hưởng là một loại tài sản được tích lũy qua thành tích và hợp tác, và mỗi lần phản đối là một lần rút ra
- Tấm séc $5: góp ý nhỏ ở mức code review
- Tấm séc $500: phản biện về quyết định kiến trúc hoặc tiến độ
- Tấm séc $50,000: cố gắng dừng một dự án cấp điều hành
- Nếu liên tục can thiệp vào những vấn đề nhỏ, bạn sẽ không còn dư địa để xử lý các vấn đề lớn
- Khi ảnh hưởng cạn kiệt, bạn có thể rơi vào trạng thái ‘phá sản chính trị’, như bị loại khỏi các cuộc họp hoặc ý kiến bị phớt lờ
Tiêu chí để quyết định thời điểm can thiệp
- Kiểm chứng chuyên môn: xác nhận rằng nhận định của bản thân có đủ cơ sở
- Nhận thức giới hạn của việc lên tiếng: nêu ý kiến không phải là ‘ra lệnh’ mà là ‘chia sẻ góc nhìn’
- Ba yếu tố để đánh giá
- Mức độ gần gũi (Proximity): càng gần đội của mình thì chi phí can thiệp càng thấp
- Tác động đến đội ngũ (Team Impact): nếu thất bại sẽ gây hại trực tiếp cho đội, giá trị can thiệp sẽ cao hơn
- Quy mô công ty (Company Scale): nếu thất bại ảnh hưởng lớn đến toàn tổ chức thì cần can thiệp
Cách ứng phó với các dự án tệ
- Can thiệp trực tiếp: yêu cầu dừng dự án hoặc gửi tài liệu nêu quan ngại mạnh mẽ
- Cần có sự chắc chắn và sẵn sàng chấp nhận rủi ro
- Can thiệp một phần: điều chỉnh hướng thiết kế hoặc dẫn dắt sang giải pháp tốt hơn
- Nếu tiếp cận với thái độ hợp tác, bạn có thể được nhìn nhận là ‘người hỗ trợ’
- Không can thiệp: khi quán tính chính trị quá lớn hoặc giới hạn ảnh hưởng khiến việc can thiệp không còn đáng giá
- Nếu đội của mình có liên quan, hãy chuẩn bị phương án như giảm phụ thuộc hoặc xây dựng giải pháp thay thế
- Nếu không liên quan, hãy âm thầm quan sát và chỉ chia sẻ ý kiến trong phạm vi nội bộ
- Quản lý đội ngũ: chia sẻ thực tế một cách thẳng thắn với thành viên, nhưng loại bỏ các chi tiết chính trị không cần thiết
Kết luận
- Nhận thức rằng “đúng đắn và hiệu quả là hai điều khác nhau” là điểm cốt lõi
- Trong các công ty lớn, chính trị và bối cảnh thường vận hành mạnh hơn logic, nên không thể sửa mọi sai lầm
- Cần sử dụng ảnh hưởng và niềm tin một cách chiến lược để tập trung vào những thời điểm thật sự có thể tạo ra thay đổi
- Trong những trường hợp còn lại, hãy chia sẻ với đồng nghiệp, chuẩn bị phương án và học hỏi thông qua quan sát
- Dù không thể giải quyết hoàn hảo mọi thứ, đây vẫn là một cách tiếp cận bền vững
1 bình luận
Ý kiến Hacker News
Nhớ lại có một quản lý từng nói: “Đôi khi phải để người khác thất bại”
Việc cứ liên tục chống đỡ cho một số người đã tốn quá nhiều năng lượng. Tôi từng hy vọng rồi sẽ có lúc họ tự bơi được, nhưng đôi khi đúng là nên dùng công sức đó vào chỗ tốt hơn
Có một dự án được triển khai mà không có sự tham gia của tôi, và nếu thiếu kiến thức của tôi thì nó tuyệt đối không thể thành công. Đội đó tệ đến mức họ vừa làm vừa trộn câu hỏi vào như một phần công việc
Hơn nữa, khi biết ban lãnh đạo hạ thấp đội của tôi và lại khen ngợi họ, tôi thật sự cảm thấy bị xúc phạm. Phần triển khai của họ rất kinh khủng
Có những quản lý không thích nghe rằng ý tưởng của họ không hiệu quả. Nếu phản bác, bạn sẽ bị quy là nguyên nhân gây ra thất bại
Vì thế tôi vẫn để công việc tiếp tục, nhưng thường xuyên cập nhật tình hình cho họ. Như vậy họ có thể tự nhìn thấy thất bại đã được dự báo trước, đồng thời tách tôi ra khỏi thất bại đó
Thất bại của cá nhân có chi phí thấp hơn và mang tính giáo dục. Thậm chí đôi khi cách tiếp cận của họ lại hiệu quả, khiến tổ chức có thêm tài sản tri thức mới
Họ có thể thất bại mà vẫn không học được gì. Nhưng nếu bạn đã làm hết sức thì ít nhất vẫn có sự thanh thản lương tâm
Việc một dự án có “tệ” hay không phần lớn là chủ quan trong hầu hết vòng đời của nó
Đã từng có người ngoài tìm cách phản đối và dừng một dự án, nhưng cuối cùng khi nó được ra mắt và thành công thì uy tín của họ sụp đổ
Cần rất thận trọng khi dùng danh tiếng của mình vào việc gì
Tôi biết thế giới không phải lúc nào cũng đầy nắng và cầu vồng, nhưng lúc đó tôi thật sự rất thất vọng
Giống câu “không phải khỉ của tôi, không phải gánh xiếc của tôi”, tôi không can dự vào những việc không phải trách nhiệm của mình
Ngay cả khi làm kiến trúc sư, tôi cũng không đưa ra lời khuyên không cần thiết về UI hay business logic ngoài phạm vi của mình
Những gì quản lý cấp trên đã quyết thì tôi cứ thế làm theo. Khi làm consultant tôi cũng giữ nguyên nguyên tắc đó
Tôi chỉ can thiệp thận trọng trong đúng chuyên môn của mình. Và cũng chỉ khi có sự chấp thuận của C-suite
Lời khuyên này khá phù hợp với công ty vừa và nhỏ. Nhưng ở doanh nghiệp lớn thì việc phản đối một dự án hầu như chẳng có nhiều ý nghĩa
Nếu thành công thì bạn trông như kẻ ngốc, còn nếu thất bại thì cũng chẳng ai nhớ
ROI thật sự xuất hiện khi bạn đưa ra giải pháp sau thất bại. Mọi người thích “người giải quyết vấn đề”
Trước đây tôi từng đề xuất test E2E tự động nhưng bị từ chối, đến khi sự cố nổ ra thì tôi mang framework đó ra và được đối xử như anh hùng
Thành ra sống ở cấp bậc thấp hơn mà ít stress có khi còn khôn ngoan hơn
Ngược lại, doanh nghiệp lớn lãng phí nhiều năm và hàng triệu đô vì chính trị
Tôi thuộc phe “không nên phớt lờ vấn đề”
Nếu đang ở vị trí có thể giúp, thì dù lặng lẽ cũng nên đề xuất cách tiếp cận khác. Không nhất thiết phải phản ứng cảm tính
Ở tổ chức nhỏ, ý tưởng tốt dễ được chấp nhận hơn, nhưng ở tổ chức lớn thì rủi ro chính trị cao hơn nhiều
Xác suất thực sự giúp được thường thấp hơn xác suất làm mất uy tín. Vì thế phải chọn đúng trận để đánh
Nhưng ở tổ chức lớn, để thay đổi một dự án đã chạy rồi thì tốn rất nhiều thời gian và năng lượng
Thực ra nhiều khi chúng ta không thể kiểm soát dự án đó. Tiêu đề chính xác hơn sẽ là “tôi không biết vì sao đội khác lại làm như vậy”
Tính chuyên nghiệp là nói ra khi cần phải nói. Nhưng theo kinh nghiệm của tôi thì gần như chẳng có gì thay đổi
Hiện giờ tôi đang chứng kiến đúng tình huống như vậy
Chủ doanh nghiệp chọn nền tảng low-code vì chi phí và tốc độ, nhưng cuối cùng lại cần một mức độ tùy biến chắp vá khổng lồ
Đội của tôi deploy bằng TypeScript nhiều lần mỗi ngày, còn đội kia mỗi tháng deploy một lần và đang làm những trò kỳ quặc với curl
Lời khuyên này rất hay trong thực tế chính trị của Big Tech, nhưng rốt cuộc cũng hơi giống chủ nghĩa hòa bình doanh nghiệp
Ở môi trường khác thì không có dư tiền và động lực để đốt bỏ như vậy
(Dù vậy, Lalit đã gói được động lực tổ chức phức tạp vào một bài ngắn rất tốt)
Người cứ liên tục bắt bẻ cuối cùng sẽ bị dán nhãn là người tiêu cực
Rốt cuộc lời khuyên cốt lõi là hãy để dành năng lượng cho thời điểm quan trọng. Không phải mọi vấn đề đều quyết định sự sống còn của công ty
Kỹ sư không có quyền về mặt chính trị để “để một dự án tệ thất bại”
Đó là trách nhiệm của ban lãnh đạo. Kỹ sư chỉ cần đưa ra lời khuyên kỹ thuật
Tuy vậy, cần hiểu những động lực này để sự nghiệp của mình không bị ảnh hưởng
Cuộc tranh chấp lãnh địa giữa đội sản phẩm và đội nền tảng là hệ quả của việc thiếu lãnh đạo rõ ràng
Nếu muốn hiểu vì sao chuyện này xảy ra thường xuyên, có thể tham khảo bài viết liên quan đến Google
Kiểu tư duy này rất phổ biến ở các tổ chức lớn, đặc biệt là cơ quan nhà nước
Chi phí do phòng ban khác gánh, còn quyền lực thì được đo bằng số người mình quản lý
Để ngăn dạng hoại tử tổ chức này, lãnh đạo phải thiết lập hệ thống đo lường và phòng ngừa rõ ràng
Bỏ qua vốn chính trị không có nghĩa là nó biến mất
Đây là một phép so sánh hay
Khi xây dựng được năng lực lãnh đạo và niềm tin, bạn sẽ có không gian để nói “bạn sai rồi”
Nhưng lý do lãnh đạo không phải lúc nào cũng tin kỹ sư là vì đôi khi chính kỹ sư mới là người sai
Kỹ sư rất giỏi phát hiện khiếm khuyết, nhưng lại yếu hơn trong việc hiểu bối cảnh kinh doanh
Vì vậy, ngay cả với những “ý tưởng trông rất ngớ ngẩn”, ta cũng nên hiểu bối cảnh rồi mới đánh giá
Khi bạn phân biệt được đâu là ý tưởng thật sự cần phải giết chết và đâu chỉ là ý tưởng có khiếm khuyết, bạn sẽ có được niềm tin trong tổ chức