- Bài viết bàn về khái niệm "lời khuyên nguy hiểm (dangerous advice)": hữu ích với kỹ sư senior giỏi nhưng có thể gây hại cho kỹ sư còn non kinh nghiệm
- Những thứ như quyền truy cập SQL production là "công cụ sắc bén (sharp tools)"
- Tự đặt ưu tiên công việc, đôi khi cố ý phá vỡ quy tắc công ty, và giữ lập trường mạnh mẽ ngay cả khi còn bất định là các ví dụ cụ thể của lời khuyên nguy hiểm
- Phần lớn lời khuyên nghề nghiệp là giả tạo, được viết để né trách nhiệm hoặc quản lý ấn tượng; còn để thực sự làm xong việc thì cần hành động ngoài các quy tắc chính thức
- Manager có giới hạn mang tính cấu trúc nên không thể trực tiếp đưa ra kiểu lời khuyên này vì rủi ro sẽ quay lại với chính họ
- Lời khuyên nguy hiểm mang đặc tính rủi ro cao, phần thưởng cao, và điều cốt lõi là hiểu được vùng phi hiển thị (illegible) nằm ngoài các quy tắc chính thức của tổ chức
Ẩn dụ về "công cụ sắc bén" và "lời khuyên nguy hiểm"
- "Sharp tools" là những công cụ như ssh, kubectl, hay console SQL production có quyền đọc-ghi, có thể cực kỳ hữu ích hoặc gây thiệt hại lớn tùy theo năng lực người dùng
- "Lời khuyên nguy hiểm" cũng có đặc tính tương tự, chỉ có thể được tận dụng đúng nếu có năng lực và khả năng phán đoán
- Đưa lời khuyên nguy hiểm cho sai người cũng giống như cấp quyền truy cập SQL production cho sai người
Ví dụ cụ thể về lời khuyên nguy hiểm
- Tự quyết định nên làm việc gì
- Đôi khi cố ý phá vỡ các quy tắc thành văn của công ty
- Giữ lập trường mạnh mẽ ngay cả khi còn bất định
- Tự nhận diện bản thân như một 'grifter' ở mức nào đó
- Cố ý tránh mọi hoạt động không liên quan đến việc shipping
Vì sao phần lớn lời khuyên nghề nghiệp là giả tạo
- Kỹ sư giỏi khao khát lời khuyên nguy hiểm vì cùng lý do họ muốn có các công cụ sắc bén
- Phần lớn lời khuyên nghề nghiệp được viết nhằm né trách nhiệm (liability avoidance) hoặc gây ấn tượng với người khác (impress people)
- Nếu là người thực sự muốn làm xong việc, rồi bạn sẽ làm những hành vi nguy hiểm này vì chúng rõ ràng là hữu ích
- Tình huống mà ai cũng biết thực tế không vận hành như quy tắc chính thức nói, nhưng không ai nói cho bạn biết, gây ra cảm giác bị tách rời sâu sắc
- Khi còn là junior, một vài đồng nghiệp nói chuyện thẳng thắn một cách không chính thức đã giúp ích rất nhiều
Vì sao manager không thể đưa ra lời khuyên nguy hiểm
- Nếu manager khuyên bỏ qua chính sách công ty mà kỹ sư thực hiện sai (ví dụ: công khai đăng lên Slack rằng manager đã cho phép), thì manager sẽ chịu thiệt hại lớn hơn
- Lãnh đạo ở các công ty công nghệ có xu hướng xem kỹ sư như "những kẻ ngốc hữu dụng (useful idiots)", và kỳ vọng manager phải hành xử chuyên nghiệp
- Nhiều manager thực ra muốn đưa ra kiểu lời khuyên này, và sẽ đánh giá rất cao nếu kỹ sư tự hành động theo cách đó
- Với manager, việc quản lý một kỹ sư giỏi mà sẽ hiệu quả hơn nhiều nếu tiếp cận công việc chiến lược hơn và bớt bị trói buộc bởi job description là điều cực kỳ bức bối
Bản chất của lời khuyên nguy hiểm: rủi ro cao, phần thưởng cao
- Cần có can đảm để làm theo lời khuyên nguy hiểm
- Chính vì đặc tính rủi ro cao, phần thưởng cao, nó hữu ích một cách vượt trội cho kỹ sư mạnh và có hại cho kỹ sư yếu
- Nếu bạn không thấy thoải mái thì tuyệt đối không nên làm theo; nhưng nếu bạn đã làm việc theo kiểu này và đang lo về những sai lầm dài hạn, thì có lẽ điều đó không áp dụng với bạn
Phản ứng trên Hacker News và các yếu tố phi hiển thị của tổ chức
- Trên Hacker News có lẫn cả phản ứng rất tích cực lẫn rất tiêu cực
- Sai lầm cốt lõi trong các bình luận tiêu cực là xem tổ chức như một tập hợp các quy tắc thành văn, và cho rằng phương thức vận hành chủ yếu trong tổ chức là hợp tác chính thức, có cấu trúc
- Đây là kiểu sai lầm mà James C. Scott gọi là ưu tiên quá mức cho tính khả độc (legibility) trong Seeing Like a State
- Trong mọi cộng đồng đều tồn tại những thành phần phi hiển thị nhưng giữ vai trò chịu lực cốt lõi (load-bearing illegible)
- Suy nghĩ cẩn trọng về phần phi hiển thị này trong chính công việc của mình là luận điểm cốt lõi của bài viết này và của toàn bộ blog
Chưa có bình luận nào.