- Ý chính của “Seeing Like A State” của James C. Scott là các tổ chức tìm cách tăng “tính dễ đọc” (legibility) của hệ thống để mọi thứ đều có thể được đo lường và báo cáo
- Nhưng trên thực tế, “công việc không dễ đọc” vốn không thể theo dõi hay dự đoán lại là yếu tố thiết yếu, và nếu chỉ coi trọng tính dễ đọc thì nghịch lý là hiệu quả còn giảm đi
- Đặc biệt, các doanh nghiệp lớn biến công việc thành thứ “dễ đọc” thông qua các quy trình như kế hoạch theo quý, OKR, Jira, nhưng điều này nghịch lý thay lại làm giảm hiệu quả, và một công ty nhỏ có thể hiệu quả hơn doanh nghiệp lớn tới 20 lần
- Để ứng phó với tình huống khẩn cấp, tổ chức cho phép các vùng không dễ đọc tạm thời như “tiger team”, và sự phối hợp phi chính thức qua backchannel giữa các kỹ sư cũng đóng vai trò quan trọng không kém quy trình chính thức
- Thành công của công ty công nghệ phụ thuộc vào việc duy trì sự cân bằng giữa quy trình dễ đọc và công việc thực tế không dễ đọc, vì chỉ một trong hai thôi thì tổ chức sẽ không vận hành đúng cách
Mở đầu: Ý tưởng cốt lõi của “Seeing Like A State”
- Tư tưởng cốt lõi trong cuốn “Seeing Like A State” của James C. Scott có thể tóm tắt thành ba điểm sau
- Các tổ chức hiện đại kiểm soát hệ thống bằng cách biến chúng thành dạng có “tính dễ đọc” (legibility) tối đa, để mọi bộ phận đều có thể được đo lường và báo cáo
- Nhưng các tổ chức này lại phụ thuộc vào một khối lượng lớn công việc “không dễ đọc” (illegible). Tức là có rất nhiều công việc thiết yếu nhưng không thể theo dõi hay lập kế hoạch
- Việc gia tăng tính dễ đọc thường làm suy giảm hiệu quả, nhưng những lợi ích khác của nó như kiểm soát, lập kế hoạch, tính minh bạch lại được xem là rất đáng giá
- Tính dễ đọc là loại công việc có thể dự đoán, đầu ra có thể theo dõi, và không phụ thuộc vào một nguồn lực con người cụ thể. Ví dụ: quản lý lịch trình, OKR, Jira
- Tính không dễ đọc là công việc mang tính ứng biến hoặc dựa trên tri thức ngầm, tức là những dạng phối hợp không thể viết thành văn bản hay chuẩn hóa, các thay đổi đột ngột, hoặc công việc phụ thuộc vào quan hệ giữa con người với nhau
Ví dụ về “nhìn như một nhà nước”
- Scott dùng ví dụ “khu rừng có trật tự” ở Đức thế kỷ 19 để giải thích nỗ lực của tổ chức trong việc kiểm soát và chuẩn hóa vì mục tiêu hiệu quả
- Người ta kỳ vọng rằng nếu quản lý khu rừng sao cho có thể nắm được toàn bộ cây cối trong một cái nhìn, thì việc lập kế hoạch, giao dịch và phân bổ tài nguyên sẽ hiệu quả hơn
- Nhưng trên thực tế, sự đa dạng của khu rừng và vai trò của thảm thực vật tầng thấp đã bị bỏ qua, khiến năng suất giảm và rừng dễ tổn thương hơn trước bệnh tật và ký sinh trùng
- Nói cách khác, dù nhắm tới cả hiệu quả lẫn tính minh bạch, việc theo đuổi tính dễ đọc quá mức lại dẫn đến kết quả ngược là làm giảm hiệu quả
Tính dễ đọc và không dễ đọc trong công ty phần mềm
- Doanh nghiệp phần mềm cũng vậy: đội ngũ nhỏ hoặc cá nhân đôi khi có thể hiệu quả hơn
- Trong giới kỹ sư phần mềm, gần như là điều hiển nhiên rằng một kỹ sư làm việc một mình có thể hiệu quả hơn khi làm như một thành viên trong đội
- Công việc do kỹ sư tự dẫn dắt thường tiến triển nhanh hơn nhiều so với công việc được chỉ đạo từ trên xuống, vì không cần phải chuyển dịch nó sang một hình thức “có ý nghĩa” hoặc chủ động giao tiếp theo mọi hướng
- Lý do các công ty phần mềm nhỏ có thể giỏi hơn hẳn doanh nghiệp lớn trong việc cung cấp phần mềm là vì ngay cả khi doanh nghiệp lớn có nhiều hơn 10 lần số kỹ sư, điều đó cũng không thành vấn đề nếu công ty nhỏ hiệu quả hơn 20 lần
- Ở doanh nghiệp lớn, nhiều thủ tục và công cụ được đưa vào để biến công việc của kỹ sư thành thứ “dễ đọc”
- Điều này thuận lợi cho việc lập kế hoạch, đo lường và báo cáo công việc, nhưng có thể làm giảm năng suất phần mềm thực tế
- Công ty nhỏ có thể phản ứng ngay với vấn đề hoặc chấp nhận thay đổi rất nhanh (một năng lực không dễ đọc)
- Lý do doanh nghiệp lớn vẫn duy trì các quy trình phức tạp thay vì hiệu quả kiểu đó có liên quan đến các hợp đồng enterprise quy mô lớn. Khách hàng lớn đòi hỏi nhà cung cấp phải có tính dự đoán và độ tin cậy
- Để làm việc với các khách hàng này, kế hoạch dài hạn, cam kết tính năng và tài liệu hóa tiến độ là những yếu tố dễ đọc mang tính bắt buộc
- Quy trình vẫn được duy trì vì giá trị mà tính dễ đọc tạo ra (tính bằng đô la) lớn hơn khả năng sản xuất phần mềm hiệu quả hơn
Giá trị thực tế của tính dễ đọc mà doanh nghiệp lớn coi trọng
- Trong các công ty phần mềm quy mô lớn, tính dễ đọc có nghĩa là
- Có thể nắm được tất cả các dự án đang diễn ra, xuống tới từng kỹ sư cá nhân
- Có thể ngay lập tức xuất ra danh sách các dự án đã hoàn thành trong quý trước
- Có thể lập kế hoạch công việc trước ít nhất một quý (hoặc hơn)
- Khi có tình huống khẩn cấp, có thể huy động toàn bộ nguồn lực của bộ phận để đưa vào xử lý công việc ngay lập tức
- Ngoại trừ khả năng phản ứng linh hoạt tức thời, các công ty phần mềm nhỏ hầu như không đáp ứng được những yêu cầu này
- Doanh nghiệp lớn mạnh ở ghi chép, phân loại và lập kế hoạch dài hạn, nhưng lại có thể yếu đi ở khả năng phản ứng nhanh (huy động nguồn lực tổ chức ngay tức thì)
- Việc đảm bảo tính dễ đọc như vậy chủ yếu đóng vai trò then chốt trong niềm tin với khách hàng enterprise, hợp đồng và hợp tác dài hạn
Những giả định để đạt được tính dễ đọc và giới hạn của chúng
- Trong quá trình thúc đẩy tính dễ đọc, doanh nghiệp lớn đặt ra các giả định đơn giản như sau
- Giả định rằng mọi kỹ sư cùng cấp bậc đều làm việc gần như tương đương nhau
- Giả định rằng việc điều chuyển hoặc tái tổ chức kỹ sư không gây tổn thất năng suất
- Giả định rằng nếu số lượng kỹ sư trong đội giữ nguyên thì mức năng suất cũng sẽ được duy trì theo thời gian
- Giả định rằng dự án có thể được ước lượng trước và có một biên sai số nhất định
- Nhưng trên thực tế
- Ngay cả cùng cấp bậc, chênh lệch năng lực vẫn rất lớn, và chuyên môn cùng mối quan tâm có thể tạo ra khác biệt lớn về năng suất theo từng dự án
- Quy mô đội ngũ và năng suất chỉ có tương quan yếu
- Việc ước lượng dự án gần như là một ảo tưởng, và trên thực tế cách làm việc đôi khi còn bị thay đổi để khớp với lịch ước lượng
- Dù vậy, các giả định này vẫn hữu ích cho giao tiếp nội bộ, thỏa thuận với các doanh nghiệp lớn bên ngoài và lập kế hoạch kinh doanh
Những vùng không dễ đọc được cho phép tạm thời
- Ở doanh nghiệp lớn, các quy trình tạo ra tính dễ đọc gây ra độ trễ nghiêm trọng
- Ý tưởng sản phẩm → giai đoạn lập kế hoạch của bộ phận sản phẩm → rà soát kỹ thuật của bộ phận engineering → VP và các quản lý cấp cao thương lượng việc phân bổ đội → vào backlog kế hoạch của đội → backlog ticket của đội → vào sprint → bắt đầu làm việc thực tế
- Đây là một cấu trúc hoàn toàn không tương thích với những công việc cần phải làm ngay lập tức
- Để giải quyết vấn đề này, tổ chức cho phép các vùng không dễ đọc tạm thời như “đội ảo”, “đội xung kích”, “tiger team”
- Được tạo thành từ những kỹ sư được chọn lọc mà tổ chức tin tưởng
- Thường hoàn toàn không có quản lý được phân công, và một kỹ sư rất cấp cao sẽ điều hành dự án
- Được giao một sứ mệnh lỏng và về cơ bản được phép làm bất cứ điều gì để đạt mục tiêu
- Đây là một sự thỏa hiệp khôn ngoan giữa tính không dễ đọc hoàn toàn và tính dễ đọc hoàn toàn
- Nó đi vòng qua quy trình chính thức, nhưng không vận hành thường trực mà chỉ được duy trì tạm thời
- Ngay cả tính không dễ đọc được cho phép cũng cùng tồn tại khá gượng gạo với phần còn lại của tổ chức, và các kỹ sư khác có thể nhìn thấy sự tự do làm việc không phải gánh nặng quy trình rồi cảm thấy ghen tị hoặc cho rằng điều đó nguy hiểm
Những vùng không dễ đọc thường trực và không được cho phép
- Cách chính thức để kỹ sư ở đội A yêu cầu đội B làm việc là tạo một issue trong backlog “kế hoạch”, đi qua quy trình 12 bước rồi chờ đến khi nó vào sprint, và việc này mất từ vài tuần đến vài tháng
- Giải pháp chính thức là đội A phải dự đoán công việc của đội B trong quy trình lập kế hoạch, nhưng điều đó phi lý vì không thể dự đoán mọi thay đổi từ vài tháng trước khi bắt đầu viết code
- Cách giải quyết thực tế là backchannel không dễ đọc
- Một kỹ sư đội A hỏi kỹ sư đội B: “Bạn có thể sửa giúp tôi một dòng này không?”
- Kỹ sư đội B làm ngay, còn việc có tạo ticket hay không là tùy chọn
- Điều này không dễ đọc vì nó phụ thuộc vào mối quan hệ cá nhân giữa các kỹ sư
- Backchannel tồn tại liên tục ở mọi cấp độ trong công ty
- Backchannel xuyên đội giữa các kỹ sư, backchannel trong nội bộ đội, giữa các quản lý, giữa các product manager
- Khi một câu hỏi được nêu ra trong không gian chính thức, rất nhiều trường hợp người trả lời đã được tập dượt và rà soát riêng từ trước
- Backchannel có thể đi sai hướng, và đôi khi được dùng để trục lợi bằng cách hy sinh những kỹ sư ngây thơ
Kẻ thao túng, người ngây thơ và kẻ thua cuộc
- “Nguyên tắc Gervais” của Venkatesh Rao chia tổ chức thành ba nhóm
- “Kẻ thao túng” ở tầng trên cùng dùng các quy tắc tổ chức một cách đầy hoài nghi vì lợi ích riêng
- “Người ngây thơ” (clueless) ở tầng quản lý trung gian tin vào các quy tắc chính thức của tổ chức và không nhận ra rằng phía trên chúng còn có một trò chơi sâu hơn đang diễn ra
- Bên dưới họ, “kẻ thua cuộc” (losers) nhận ra trò chơi đó đang diễn ra nhưng không muốn tham gia
- Có thể đọc các nhóm này dưới góc độ tính dễ đọc
- Cả kẻ thao túng lẫn kẻ thua cuộc đều tham gia vào thế giới không dễ đọc của tổ chức
- “Người ngây thơ” chỉ tham gia vào các quy trình dễ đọc, và khi muốn thăng chức thì họ xem thang bậc nghề nghiệp chính thức rồi lên kế hoạch thể hiện từng giá trị ở cấp tiếp theo như thế nào
- Gọi họ là “người ngây thơ” thì hơi quá cay nghiệt
- Các quy trình dễ đọc vẫn cực kỳ quan trọng và chiếm phần lớn những gì tổ chức làm
- Cải thiện quy trình chính thức vẫn là công việc có đòn bẩy rất cao
- Suy nghĩ về con người theo các nhóm này giúp hiểu rằng những vùng xung đột thường xuyên trong công ty phần mềm bắt nguồn từ ma sát giữa các nhóm đó
Suy nghĩ cuối cùng
- Điều quan trọng là phải nhận ra và tận dụng thế giới không dễ đọc trong tổ chức
- Tôi đã viết khá nhiều về việc nhận ra và sử dụng tính không dễ đọc trong các công ty công nghệ
- Lời khuyên về các quy trình không dễ đọc thuộc loại “lời khuyên nguy hiểm”
- Nếu công khai tuyên bố rằng bạn hoàn thành công việc qua backchannel thay vì quy trình chính thức, bạn sẽ bị tổ chức trừng phạt
- Bạn vẫn sẽ bị phạt ngay cả khi chuỗi quản lý thực ra muốn bạn làm vậy
- Tôi thường nhận được rất nhiều phản hồi tiêu cực nói rằng tuyệt đối không bao giờ nên đi vòng qua quy trình chính thức, nhưng tác giả cho rằng quan điểm đó là ngây thơ
- Mọi tổ chức đều có cả mặt dễ đọc lẫn mặt không dễ đọc
- Mặt dễ đọc quan trọng từ một quy mô nhất định trở lên, và nó cho phép lập kế hoạch dài hạn cũng như phối hợp với các tổ chức lớn khác
- Mặt không dễ đọc cũng quan trọng không kém, vì nó cho phép công việc hiệu suất cao, tạo ra van an toàn cho các quy trình không còn phù hợp với tình huống hiện tại, đồng thời đáp ứng nhu cầu rất tự nhiên của con người về chuyện trò hậu trường và sự đồng thuận mềm
1 bình luận
Ý kiến Hacker News
Tôi đồng cảm với phần lớn nội dung, nhưng muốn phản đối giả định rằng ban lãnh đạo mặc nhiên cho rằng "legibility" đáng giá đến mức có thể biện minh cho mọi chi phí. Nếu CEO phải để ý đến mọi chi tiết công việc (ví dụ: song song hóa unit test), thì khác nào bộ não phải ý thức mỗi lần di chuyển một ngón tay, và như vậy sẽ chẳng làm được gì cả. Thực tế, CEO, tức người đứng đầu một công ty, chỉ có thể kiểm soát khoảng 7% toàn bộ. Phần còn lại do từng nhân viên lấp đầy, và bản thân họ chỉ đóng vai trò bộ não chứ không phải toàn bộ cơ thể. Nhưng các lãnh đạo dễ lầm tưởng mình là quan trọng nhất, rồi lướt qua những lĩnh vực mà họ thiếu thời gian hoặc chuyên môn (ví dụ: khác biệt giữa một kỹ sư xuất sắc tốt nghiệp MIT và một kỹ sư mức trung bình từ bootcamp). Khi nói về thành công của Google cũng vậy, người ta thường chỉ ghi công cho hai nhà sáng lập hoặc CEO thay vì hàng chục nhân sự thực thi xuất sắc
Một phần ở đây là đúng, nhưng có lẽ không cực đoan đến vậy. Tôi làm ở một công ty khoảng 5.000 người (không nhỏ, nhưng cũng không đến mức Amazon). Hầu hết các quy tắc đều có lý do khá chính đáng. Ví dụ, việc cần 2 người review code là để ngăn sai sót. Không phải lúc nào review cũng chặn lỗi, nhưng nếu deploy không qua review thì sự cố sẽ xảy ra thường xuyên hơn. Những quy tắc như vậy buộc người ta ít nhất phải kiểm tra. Tất nhiên, sẽ có lúc phải phá lệ (chẳng hạn phần lớn thành viên đội đều đang bị kéo vào xử lý sự cố khẩn cấp). Khi đó, việc cho phép ngoại lệ theo đúng tinh thần của quy tắc là hợp lý. Nhưng ở những nơi chỉ toàn quy tắc quan liêu thuần túy, khó hiểu (kiểu ai đó cố chấp bám lấy quy trình của riêng mình rồi chỉ lặp đi lặp lại "cách của anh sai rồi"), thì tôi sẽ rời đi. Nếu môi trường coi trọng quy trình hay cái tôi cá nhân hơn tiến độ và kết quả thực sự, thì đổi việc là đáp án
Sau TDD, sức hút của câu "không test được thì cũng chưa thực sự được triển khai" đã mạnh lên rất nhiều. Từ "legibility" thực sự rất phù hợp để mô tả điều này. Ở Tritium, chúng tôi có hàng trăm unit test, nhưng chỉ đến khi xây dựng blog thì mới lộ ra những lỗi mang tính chất lượng mà unit test không bắt được (những thứ khó xác minh bằng test). Xem https://tritium.legal/blog/eat. Có lẽ đây cũng là lý do game indie chống chọi khá tốt trước logic của thị trường. Nhà phát triển game trực tiếp dùng sản phẩm của mình (Food-dogging) và nhờ đó cải thiện chất lượng. Họ không cần một bề mặt legibility quá mức như phần mềm ở các tập đoàn lớn. Cốt lõi là cần cả chỉ số định tính lẫn định lượng
Test, đặc biệt là unit test, rất dễ mắc "hiệu ứng cột đèn". Phần vụn vặt hoặc kém quan trọng thường dễ test hơn, nên người ta chỉ test những thứ dễ. Nếu tổ chức chỉ chăm chăm vào các chỉ số dễ đo như line coverage, thì sẽ có nguy cơ bỏ sót những kiểm chứng thực sự có ý nghĩa nhưng khó hơn. Các đánh giá mang tính định tính như review của kỹ sư giàu kinh nghiệm cũng rất quan trọng
Phát triển game có vòng lặp phản hồi ngắn hơn rất nhiều so với các lĩnh vực phần mềm khác. Ví dụ, nếu có memory leak thì vấn đề sẽ bộc lộ ngay hàng trăm lần mỗi giây. Code chậm sẽ thể hiện ngay qua giật hình, khiến người ta phải để tâm đến cả góc độ hiệu năng như cache coherence hay việc có dùng GC hay không
Tôi thích TDD, nhưng cuối cùng thì test thủ công vẫn là bắt buộc. Nếu không tự mình test, những vấn đề ngoài dự kiến sẽ xuất hiện rất thường xuyên. Đặc biệt những thứ như tính thân thiện với người dùng chỉ thật sự lộ rõ khi dùng thử thực tế
Tôi rất thích các bài viết của Sean, và bài này cũng khiến tôi đồng cảm trên toàn bộ phạm vi sản phẩm. Ví dụ, khoảng một năm trước, một số người phụ trách sản phẩm và kỹ sư đã cố gắng làm ra thứ gì đó có thể giúp ích cho các team khác. Do cấu trúc lúc đó, việc xin phê duyệt qua kênh chính thức (legible channel) là không thực tế, nên họ triển khai theo cách phi chính thức (illegible channel) dựa trên sự tin cậy và tôn trọng. Nó được thúc đẩy theo kiểu grassroots, và ngược lại còn nhanh chóng lan truyền trong công ty qua truyền miệng rồi đạt được traction. Cuối cùng giờ đây ban điều hành đang tận dụng trường hợp này như thể là câu chuyện thành công của họ, nhưng khi quay ngược lại để bổ sung mọi thủ tục chính thức (legible channel) và hợp thức hóa bằng chứng sau đó thì quy trình khá đau đớn. Dù vậy, do rủi ro thất bại đã giảm đi rất nhiều nên mọi thứ vẫn dễ hơn. Đây là dự án đem lại cho tôi nhiều ý nghĩa và niềm vui nhất trong vài năm gần đây
Càng làm việc lâu trong công ty và tiếp xúc với office politics, tôi càng thấy nó giống geopolitics hay ngoại giao. Đi xa hơn nữa thì còn thấy những đường song song với quan hệ xã hội và quan hệ tình cảm. Có lẽ là vì tôi có xu hướng kiểu nhà toán học, thích xây dựng các mô hình trừu tượng
Chính trị là chủ đề tôi thích nhất. Tôi thích đọc sách, tạp chí và đủ loại tài liệu, và thành thật mà nói tôi cũng không quá khó chịu với chính trị công sở. Điểm cốt lõi là con người rốt cuộc vẫn hành xử như con người. Mỗi cá nhân (và tổ chức cũng vậy) đều có những điều họ mong muốn và những điều họ sợ hãi, và quá trình cân bằng chúng là một kiểu thú vị. Nó gần như giải một bài toán kỹ thuật, chỉ khác ở chỗ yêu cầu ở đây là "con người". Chính quá trình giải những vấn đề như vậy làm tôi thấy hấp dẫn
Mãi gần đây tôi mới nhận ra điều này. Ban đầu tôi nhìn ngoại giao như kết quả của một hệ phức hợp do hàng trăm nhà ngoại giao tạo nên, nhưng thực ra nó gần như chỉ là quan hệ con người giữa một vài người có quyền lực. Có thể tiếp cận nó gần giống như những gì diễn ra ở nhà trẻ
Đây là hiện tượng rất tự nhiên ở mức bản năng. So với các quan hệ xã hội (như tình cảm), những điểm tương đồng giữa tập đoàn lớn và chính phủ còn rõ hơn. Doanh nghiệp thường gần với kiểu độc đoán (autocratic) hoặc phong kiến (feudal) hơn nhiều. Có rất nhiều khác biệt, nhưng càng lớn thì chúng càng có xu hướng giống chính phủ hơn. Bộ máy quan liêu phát triển cao là một trong số đó
Wiki về lý thuyết trò chơi
Nếu nhìn vào việc ngày càng nhiều chính trị gia hiện đại xuất thân từ công việc văn phòng thông thường, thì hiện tượng này cũng chẳng có gì lạ
Tôi làm trong mảng bảo mật CNTT, và ở đây tình huống này còn rõ rệt hơn. Khi đội của chúng tôi phải nhận những yêu cầu "không giúp ích cho chỉ số trực tiếp của đội", tôi tự hỏi liệu có phương án thay thế nào ngoài cách không chính thức (back channel) hay không. Nếu ai biết thì rất muốn nghe
Bài viết hay, nhưng tôi muốn nói về một điều mà người ta luôn bỏ qua. Bài gốc hơi đáng tiếc ở chỗ mô tả kỹ sư phần mềm (SWE) chỉ như lá trên cây, tức cỡ công nhân trong dây chuyền lắp ráp. Nhưng như phần "Legible assumptions" cũng nói, trên thực tế kỹ sư còn mở rộng các kết nối trong cấu trúc tổ chức bằng "code", tức cũng đảm nhiệm một vai trò mang tính quản lý. Vấn đề chỉ khác đối tượng áp dụng, còn nỗi trăn trở thì khá giống nhau
Có ai đồng ý với đoạn trong bài rằng "vì sao các công ty nhỏ không cần mà các công ty phần mềm lớn lại nhất định cần năng lực này? Không phải chuyên môn của tôi, nhưng có lẽ là vì các dự án cho doanh nghiệp lớn" không? Xin ý kiến
Tôi nghĩ không hẳn là vì các thương vụ với doanh nghiệp lớn, mà là vì "luồng thông tin ở quy mô lớn" trong nội bộ. Có thể hình dung một tổ chức với m nhân viên như một ma trận giao tiếp m*m. Khi còn ít người, gần như mọi ô đều là 1 (giao tiếp chặt chẽ), nhưng khi quy mô tăng thì phần lớn sẽ chuyển thành 0 (đứt quãng) hoặc 0.5 (giao tiếp không chính thức). Nhưng rốt cuộc thông tin chính là bản thân công ty. Vì vậy cần một cấu trúc mà manager và quy trình chính thức chịu trách nhiệm cho "dòng chảy" của thông tin. Hoạch định, thăng chức, rà soát... đều là để đảm bảo loại legibility này
Công ty nhỏ của tôi vẫn thường đảm nhận các dự án cho doanh nghiệp lớn, nhưng không cần đòi hỏi legibility nghiêm ngặt đến mức đó trong nội bộ mà vẫn chốt được thương vụ. Trước khách hàng thì legibility trong quản lý dự án là cần thiết, nhưng họ không can thiệp chi li vào cách phát triển nội bộ. Kết luận là việc các công ty lớn ám ảnh với legibility là vì bản thân họ đã là doanh nghiệp lớn hoặc đang hướng tới trở thành như vậy
Tôi đã ở trong lĩnh vực hình ảnh y tế khá lâu, và phần lớn chủ doanh nghiệp không thực sự hiểu rằng họ đang ở trong ngành dịch vụ/giải pháp CNTT. Năng lực dịch vụ CNTT mới là yếu tố thành công thực sự. So với bản thân việc chẩn đoán, tác động lớn hơn nhiều đến từ việc những nhân sự không phải chuyên gia X-quang đã nỗ lực nâng cao tính tiện dụng và hiệu quả của nền tảng
Dù tổ chức có lớn đến đâu thì cũng phải luôn sẵn sàng cho nhiều đợt audit nội bộ và bên ngoài. Auditor có xu hướng muốn xem càng nhiều tài liệu quy trình càng tốt. Ví dụ như trường hợp này, trong tình huống xấu nhất auditor thậm chí có thể "sa thải" khách hàng của mình
Phần đó (là vì các thương vụ với doanh nghiệp lớn) vẫn có vẻ hơi lạ. Tôi xuất thân từ startup và hiện là quản lý cấp trung ở một công ty tầm trung, và tôi thấy khi quy mô tổ chức tăng lên thì luôn cần thêm một mức cấu trúc tối thiểu để chỉ cho mọi người cách làm việc. Dù ghét quy trình đến đâu thì khi vượt quá Dunbar’s Number, chỉ dựa vào sự đồng cảm và giao tiếp không chính thức cũng sẽ chạm giới hạn. Trường hợp ngoại lệ cực đoan chắc chỉ có Steam, nhưng ở đó cũng chỉ tuyển một kiểu nhân tài nhất định và chính trị nội bộ thì rất nặng
Ngay cả việc chọn từ legibility cũng đã rất thú vị. Nó gợi cảm giác về sự phân đôi giữa quy trình chính thức và phi chính thức. Khi công ty còn nhỏ, cách làm phi chính thức vận hành tốt, nhưng khi vượt qua một ngưỡng nhất định thì không thể tránh khỏi việc đưa vào các quy tắc và quy trình chính thức. Về dài hạn, quy tắc sẽ sinh ra tính cứng nhắc và không theo kịp thay đổi. Người ta dần bám chặt vào bản thân quy trình hơn là mục tiêu. Việc thoát ra khỏi guồng quen thuộc để giữ được cái mới là không dễ. Người ta hay nói tiền bạc giống như máu trong công ty, nhưng thực ra hiếm khi tiền là nền tảng thật sự của động lực. Tiền là điều kiện cần, nhưng theo tôi nó không phải lý do tồn tại tự thân
Đây luôn là vấn đề cân bằng. Tôi đã làm engineering manager 25 năm và từng làm ở những công ty rất nặng quy trình. Nó ngột ngạt, nhưng cũng có điểm mạnh trong việc liên tục tạo ra phần cứng đẳng cấp thế giới (không phải phần mềm). Những thứ như tài liệu hóa là cần thiết, nhưng nếu quá nghiêm ngặt thì dự án có nguy cơ bị đông cứng. Overhead giao tiếp là vấn đề nghiêm trọng nhất. Vì thế mà một vài team giỏi làm việc cùng nhau trong thời gian dài có thể tạo ra năng suất khổng lồ, và "tri thức bộ lạc" (tribal knowledge) thực sự là chất xúc tác rất quan trọng. Tôi viết bài Concrete Galoshes cũng để bàn về các yếu tố cấu trúc và tính cứng nhắc kiểu này. Bài học lớn nhất là "không thể mặc cùng một bộ đồ cho mọi dự án". Mỗi dự án cần cấu trúc và mức overhead khác nhau