# Quan Tưởng Như Doanh Nghiệp Phần Mềm

Trong thế giới phần mềm hiện đại, có một nghịch lý thú vị: các công ty lớn thường chậm chạp và kém hiệu quả hơn các công ty nhỏ, nhưng họ lại thống trị thị trường. Điều này có vẻ vô lý, nhưng khi phân tích qua lăng kính của “khả năng đọc hiểu” (legibility) và “khả năng không đọc hiểu” (illegibility), mọi thứ trở nên rõ ràng hơn.

## Khái niệm cốt lõi: Khả năng đọc hiểu

Ý tưởng chính của James C. Scott trong tác phẩm “Seeing Like A State” có thể được diễn đạt qua ba điểm:

1. Các tổ chức hiện đại thực hiện sự kiểm soát bằng cách tối đa hóa “khả năng đọc hiểu”: thay đổi hệ thống để mọi phần của nó đều có thể đo lường, báo cáo, và quản lý.
2. Tuy nhiên, các tổ chức này phụ thuộc vào một lượng lớn công việc “không đọc hiểu”: công việc không thể theo dõi hoặc lập kế hoạch, nhưng vẫn thiết yếu.
3. Việc tăng cường khả năng đọc hiểu do đó thường làm giảm hiệu quả – nhưng những lợi ích khác đủ lớn để các tổ chức vẫn sẵn sàng làm như vậy.

### Định nghĩa rõ ràng

Theo nghĩa đen, “khả năng đọc hiểu” là công việc có thể dự đoán, ước tính tốt, có hồ sơ giấy tờ, và không phụ thuộc vào các yếu tố tình huống (như sự có mặt của người cụ thể). Lập kế hoạch theo quý, OKRs, và Jira đều tồn tại để làm cho công việc trở nên “có thể đọc hiểu”. Công việc “không đọc hiểu” là tất cả những thứ khác: hỏi và giúp đỡ lẫn nhau, sử dụng kiến thức ngầm không được hoặc không thể viết ra, thích ứng với những thay đổi không được lên lịch, và dựa vào các mối quan hệ cá nhân.

## Tại sao các công ty phần mềm cần cả hai loại công việc

Việc suy nghĩ về khả năng đọc hiểu và không đọc hiểu giải thích nhiều điều khó hiểu về các công ty phần mềm lớn. Nó giải thích tại sao các công ty làm nhiều việc dường như rõ ràng là phản tác dụng, tại sao quy tắc thực tế thường không đồng bộ với quy tắc được viết ra, và tại sao các công ty lại surprisingly chấp nhận việc phá vỡ quy tắc trong một số ngữ cảnh.

### Ví dụ từ lịch sử: Rừng của Đức

James C. Scott đã viết về phong trào “hiện đại chủ nghĩa cao” trong quản trị sản xuất (trong số những thứ khác) những khu rừng trật tự của Đức thế kỷ 19. Để sản xuất gỗ quy mô lớn, nhà nước Đức yêu cầu khả năng đọc hiểu: những khu rừng mà một thanh tra có thể đến để đếm số lượng cây khỏe mạnh. Điều đó có nghĩa là bạn phải có thể đi bộ qua khu rừng – tức là bụi rậm phải được kiểm soát – và cây cối nên được bố trí theo những hàng gọn ghẽ của một loại duy nhất.

Những người ủng hộ khả năng đọc hiểu thường mô tả quy trình của họ là “biện pháp hiệu quả” hoặc cách “tránh lãng phí”. Nhưng nói chung, những khu rừng “hiệu quả” mới thực tế kém hiệu quả hơn nhiều so với những khu rừng cũ “không đọc hiểu”. Chúng sản xuất ít gỗ mỗi năm và đòi hỏi nhiều công sức hơn để chống lại bệnh tật, vì bụi rậm hóa ra lại giữ vai trò quan trọng đối với sức khỏe của đất, và sự đa dạng loài hóa ra lại là một tài sản.

Tuy nhiên, những lợi thế của khả năng đọc hiểu là to lớn. Một khi bạn biết chính xác số lượng cây bạn có, bạn có thể lập kế hoạch trước, thực hiện các giao dịch lớn, tránh tham nhũng, và v.v. Đối với tôi, đây là điểm thú vị nhất mà Scott đưa ra. Các tổ chức lớn thực sự nghĩ rằng khả năng đọc hiểu nhiều hơn sẽ tự động tăng hiệu quả. Nhưng ngay cả khi điều đó trở nên rõ ràng là sai, các tổ chức này vẫn tiếp tục thúc đẩy khả năng đọc hiểu, vì những lợi ích khác quá mạnh mẽ.

## Áp dụng vào công ty phần mềm

Điều này cũng giống như trong các công ty phần mềm. Hầu như là một chân lý trong số các kỹ sư phần mềm rằng một kỹ sư đơn lẻ có thể hiệu quả hơn khi làm việc một mình so với việc làm việc trong một nhóm. Đó là lý do tại sao có nhiều giai thoại về việc các kỹ sư nghỉ phép cuối cùng mới hoàn thành được một số công việc, hoặc về công việc hiệu quả được thực hiện vào ban đêm và cuối tuần.

Tương tự, điều đó rõ ràng đối với bất kỳ kỹ sư thực hành nào rằng công việc do kỹ sư thúc đẩy nhanh hơn nhiều so với công việc được áp đặt từ trên cao. Công việc do kỹ sư thúc đẩy không cần phải được dịch thành điều có ý nghĩa, không cần phải chủ động truyền đạt theo mọi hướng, và nói chung có thể được thực hiện theo cách trực tiếp và hiệu quả nhất.

Đó là lý do tại sao các công ty phần mềm nhỏ thường tốt hơn nhiều so với các công ty phần mềm lớn trong việc cung cấp phần mềm: điều đó không quan trọng khi công ty lớn gấp mười số lượng kỹ sư vào vấn đề nếu công ty nhỏ hiệu quả gấp hai mươi lần.

## Tại sao khả năng đọc hiểu lại có giá trị với các công ty công nghệ

Vậy khả năng đọc hiểu có nghĩa gì đối với một công ty công nghệ, trên thực tế? Nó có nghĩa là:

1. Người đứng đầu một bộ môn biết, đối với kỹ sư, tất cả các dự án bộ môn hiện đang làm việc
2. Người đứng đầu đó cũng biết (hoặc có thể yêu cầu) một danh sách toàn diện về tất cả các dự bộ đã giao trong quý vừa qua
3. Người đứng đầu có khả năng lập kế hoạch công việc ít nhất một quý trước (tốt hơn nữa là lâu hơn)
4. Người đứng đầu có thể, trong trường hợp khẩn cấp, chỉ đạo toàn bộ nguồn lực của bộ môn vào công việc ngay lập tức

Lưu ý rằng “giao phần mềm chất lượng cao” hoặc “làm cho khách hàng hài lòng” hoặc thậm chí “kiếm tiền” không nằm trong danh sách này. Tất cả những điều này đều là những điều các công ty công nghệ muốn làm, nhưng chúng không phải là khả năng đọc hiểu.

Công ty phần mềm nhỏ của chúng tôi chỉ đáp ứng một tiêu chí này: khả năng chuyển hướng sang một vấn đề cần giải quyết ngay lập tức. Thông tin khác bị khóa trong đầu của các kỹ sư khác nhau, những người có thể hoặc không thể nhớ họ đã làm gì hai tháng trước (và chắc chắn sẽ không sẵn sàng cam kết làm việc hai tháng tới). Điều đó không nhất thiết là vấn đề, miễn là mọi người đều đồng thuận về những gì cần làm và sản phẩm đang tiếp tục cải thiện.

Một công ty phần mềm điển hình lớn đáp ứng gần như tất cả các tiêu chí này – tôi nói gần như, vì ở một số công ty hoặc bộ môn, khả năng chỉ đạo công việc ngay lập tức đã suy giảm (sẽ nói về điều này sau). Nhưng ngoài ra, các công ty lớn thường rất giỏi trong việc ghi chép những gì đang được làm việc, nhớ những gì đã được giao trong quá khứ, và lập kế hoạch công việc trong trung hạn đến dài hạn.

### Giá trị thực sự

Tại sao những khả năng này lại có giá trị đối với một công ty phần mềm lớn khi các công ty phần mềm nhỏ có thể làm mà không cần chúng? Đây là phần hơi vượt ra ngoài lĩnh vực chuyên môn của tôi, nhưng tôi khá chắc chắn câu trả lời chính là các giao dịch doanh nghiệp lớn. Việc thực hiện các giao dịch với khách hàng doanh nghiệp lớn cực kỳ có lợi nhuận. Bất kỳ SaaS đủ lớn nào do đó sẽ chuyển hướng từ khách hàng nhỏ sang khách hàng doanh nghiệp, nếu có thể. Nhưng các giao dịch doanh nghiệp (a) có thể mất nhiều tháng để thiết lập, và (b) đòi hỏi phải cam kết tính năng dài hạn. Một công ty không đọc hiểu không được cấu hình để có thể gắn bó với một giao dịch doanh nghiệp nhàm chán trong nhiều tháng, liên tục trả lời câu hỏi và cung cấp tính năng. Khách hàng doanh nghiệp lớn đơn giản sẽ không tin tưởng một công ty phần mềm nhỏ để cung cấp những thứ họ cần trong năm hoặc hai năm tới.

Khách hàng như vậy thường đánh giá rất cao khả năng đọc hiểu và do đó yêu cầu nhà cung cấp của họ cũng phải có khả năng đọc hiểu. Thực tế, các tổ chức có khả năng đọc hiểu cao khó có thể giao tiếp hoàn toàn với các tổ chức có khả năng đọc hiểu thấp và ngược lại. Họ không có quyền truy cập vào những chứng nhận phù hợp, họ không nói cùng một ngôn ngữ, và v.v. Điều này tạo ra áp lực thực sự đối với các công ty công nghệ đang phát triển phải trở nên có khả năng đọc hiểu hơn, ngay cả khi nó làm giảm khả năng giao phần mềm của họ.

## Giả định về khả năng đọc hiểu

Trong quá trình theo đuổi khả năng đọc hiểu, các công ty công nghệ lớn đưa ra những giả định đơn giản hóa về bản chất công việc công nghệ. Ví dụ, họ giả định:

– Bất kỳ kỹ sư nào có cùng chức vụ đều thực hiện công việc tương tự nhau.
– Kỹ sư có thể được chuyển đổi và tổ chức lại mà không làm giảm năng suất đáng kể.
– Một đội ngũ sẽ duy trì cùng mức năng suất theo thời gian, nếu có cùng số lượng kỹ sư.
– Các dự án có thể được ước tính trước, mặc dù có một số sai lệch. Thời gian dành cho việc ước tính một dự án càng nhiều, ước tính sẽ càng chính xác.

Tất nhiên, tất cả những điều này đều sai. Trong cùng một chức vụ, có sự khác biệt đáng kể về khả năng kỹ thuật. Kỹ sư có các kỹ năng và sở thích khác nhau, và sẽ làm việc hiệu quả hơn nhiều trên các dự án phù hợp với họ. Vì lý do này, năng suất của một đội ngũ có mối quan hệ yếu với số lượng kỹ sư trong đội.

Ước tính dự án phần lớn là hư cấu. Chính xác hơn, chúng là biểu diễn: ước tính ban đầu xác định loại công việc kỹ thuật được thực hiện để giao vào thời điểm ước tính đó, không phải ngược lại. Vì lý do này, việc chia nhỏ một dự án thành các phần và ước tính từng phần thường mang lại một ước tính kém chính xác hơn, vì nó khiến việc kỹ sư phù hợp với ngày giao hàng chung khó khăn hơn.

Tuy nhiên, những giả định này đủ đúng cho mục đích của chúng, đó là cung cấp khả năng đọc hiểu cho các nhà điều hành phụ trách công ty. Dù ước tính dự án có chính xác hay không, nó vẫn có thể được sử dụng để lập kế hoạch và giao tiếp với các tổ chức lớn khác (chính những tổ chức này thường nhận thức rằng những ước tính này không nên được coi là hoàn toàn nghiêm túc).

## Khu vực tạm thời cho phép không đọc hiểu

Tôi đã đề cập ở trên rằng các công ty đôi khi mất khả năng ưu tiên công việc ngay lập tức. Điều này là do các quy trình làm cho công việc trở nên có khả năng đọc hiểu cũng gây ra sự chậm trễ đáng kể. Hãy xem xét các bước mà một công ty giả định lớn có thể thực hiện trước khi bắt đầu viết mã cho một vấn đề:

1. Ai đó có một ý tưởng sản phẩm.
2. Họ mang ý tưởng đó đến Tổ chức Sản phẩm, nơi nó bước vào giai đoạn “lập kế hoạch”. Các cuộc họp được tổ chức về ý tưởng.
3. Khi Tổ chức Sản phẩm chính thức quyết định họ muốn thực hiện nó, ý tưởng sau đó chuyển đến Tổ chức Kỹ thuật: vào tay một hội đồng các kỹ sư kiến trúc, những người được giao nhiệm vụ xem xét kỹ thuật ban đầu. Họ xác định cách nó phù hợp với các ưu tiên kỹ thuật chung và đưa ra một ước tính thời gian rất rough.
4. Các Phó chủ tịch và quản lý cấp cao trong tổ chức kỹ thuật sau đó đàm phán xem đội ngũ nào sẽ sở hữu công việc. Thường đây là một quyết định nửa kỹ thuật, nửa tổ chức (vì dịch vụ công việc nên thuộc về ít nhất là một câu hỏi kỹ thuật).
5. Cuối cùng, công việc đến với đội ngũ. Nó nhập vào danh sách công việc lập kế hoạch của đội, nơi trưởng kỹ thuật của đội chia nó thành các phần nhỏ hơn.
6. Các phần nhỏ hơn của công việc nhập vào danh sách công việc của đội, và được ước tính trong cuộc họp lập kế hoạch hàng tuần của đội.
7. Cuối cùng, một số phần công việc này được đưa vào sprint tiếp theo, và được lấy lên bởi một kỹ sư thực sự có thể làm nó.

Tôi để lại nhiều phần quan trọng của quy trình này: các cập nhật trên mỗi công việc, sau đó được tổng hợp lên các cấp quản lý cao hơn, xem xét pháp lý và thiết kế, có thể tự chúng mất vài tuần, và sau đó là các bước cuối cùng liên quan đến việc giao thay đổi cho khách hàng. Tất cả những điều này làm cho công việc rất có khả năng đọc hiểu, nhưng không có gì tương thích với công việc phải được thực ngay bây giờ. Bạn làm gì khi có một vấn đề kỹ thuật đột ngột, khẩn cấp – có thể bạn sắp tràn cột ID int trên bảng người dùng, hoặc một số khách hàng lớn đang gặp phải lỗi gây đình trệ?

### Giải pháp sáng tạo

Để giải quyết loại vấn đề này, các công ty công nghệ thường dành quyền tạo ra các khu vực tạm thời mà công việc không đọc hiểu được cho phép. Đôi khi chúng được gọi là “đội ngũ ảo”, hoặc “đội ngũ đặc nhiệm” (hoặc thậm chí cái tên sặc sỡ “đội ngũ hổ”). Chúng được cấu thành từ các kỹ sư được lựa chọn kỹ lưỡng mà tổ chức tin tưởng. Thường không có quản lý được chỉ định hoàn toàn, mà là một số kỹ sư cấp cao được giao nhiệm vụ chạy dự án. Các đội ngũ này được trao một nhiệm vụ lỏng lẻo – như “ngăn chặn cơ sở dữ liệu sụp đổ vài ngày một lần” – và được phép làm bất cứ điều gì cần thiết để hoàn thành nó.

Đây là một sự thỏa thuận thông minh giữa không đọc hiểu hoàn toàn, như tôi đã thảo luận ở trên, sẽ khiến công ty không thể thực hiện các giao dịch với khách hàng giàu nhất của mình, và khả năng đọc hiểu hoàn toàn, sẽ buộc ngay cả các vấn đề khẩn cấp có thể gây chết công ty cũng phải trải qua toàn bộ quá trình mệt mỏi của việc xác định phạm vi, lập kế hoạch và ước tính.

Ngay cả khi bị cô lập trong một đội ngũ tạm thời, sự không đọc hiểu được cho phép vẫn tồn tại awkwardly với phần còn lại của tổ chức. Các kỹ sư bên ngoài đội ngũ không thích thấy các kỹ sư khác được tự do làm việc mà không gánh nặng quy trình: hoặc vì họ ghen tị, hoặc vì họ là người tin vào quy trình và cho rằng loại công việc đó là không chấp nhậnably nguy hiểm. Các nhà quản lý cũng không thích mở rộng mức độ tin tưởng đó. Đó là lý do tại sao các nỗ lực được cho phép như vậy gần như luôn luôn là tạm thời. Phần lớn công việc không đọc hiểu xảy ra trong các tổ chức lớn vẫn chưa được cho phép.

## Khu vực vĩnh viễn không được cho phép không đọc hiểu

Nếu bạn là một kỹ sư trong đội A, và bạn cần đội B làm một số công việc nào đó cho bạn, cách thức chính thức để làm điều này là tạo một vấn đề trong danh sách “lập kế hoạch” của họ và đợi nó đi qua toàn bộ quy trình mười hai bước trước khi cuối cùng nó đi vào một trong các sprint của họ, nơi hy vọng ai đó sẽ lấy nó lên và làm. Việc này có thể mất vài tuần đến vài tháng. Khi điều bạn muốn chỉ là một thay đổi một dòng, thật khó chịu khi xem xét yêu cầu công việc của bạn trải qua tất cả các bước này – mỗi bước mất nhiều lần hơn thời gian cần thiết để đơn giản thực hiện công việc.

Cách thức chính thức để giải quyết vấn đề này là đội A nên dự đoán trong quy trình lập kế hoạch của họ rằng đội B sẽ cần làm công việc này, để phần cho đội B có thể nhập vào danh sách của họ tại cùng thời điểm nó nhập vào danh sách của đội A. Cách này (lý thuyết) chúng nên hoàn thành vào khoảng cùng thời điểm. Bất kỳ kỹ sư phần mềm thực hành nào cũng biết ý tưởng này vô cùng ngớ ngẩn. Bạn không bao giờ có thể dự đoán mọi thay đổi phải thực hiện hàng tháng trước khi bắt đầu viết mã.

Cách thức thực tế để giải quyết vấn đề này là các kênh ngầm không đọc hiểu. Một kỹ sư trong đội A tiếp cận một kỹ sư trong đội B hỏi “hey, bạn có thể thực hiện thay đổi này một dòng cho tôi không”. Kỹ sư trong đội B sau đó thực hiện ngay lập tức, có thể tạo một công việc, có thể không. Sau đó là xong! Điều này hoạt động tuyệt vời, nhưng nó không đọc hiểu vì công ty không thể dự đoán hoặc lập kế hoạch cho nó – nó phụ thuộc vào các mối quan hệ giữa nhân viên giữa các đội ngũ, điều rất khó định lượng. Nếu bạn là một kỹ sư được yêu thích, khả năng kéo các kênh ngầm này của bạn lớn hơn đáng kể so với nếu bạn mới vào nghề hoặc có danh tiếng xấu. Nhưng mức độ bạn được yêu thích không phải là điều công ty có thể sử dụng chính thức khi họ lập kế hoạch các dự án.

Các kênh ngầm là sự hiện diện liên tục ở tất cả các cấp độ của công ty. Ngoài các kênh ngầm giữa các kỹ sư khác đội, còn có kênh ngầm bên trong các đội, giữa các nhà quản lý, quản lý sản phẩm, và v.v. Thường khi một câu hỏi được hỏi chính thức trong không gian công cộng, nó đã được tập dượt và làm việc riêng với người trả lời câu hỏi. Không có điều gì trong số này có thể được ghi lại như một phần của quy trình chính thức của công ty, nhưng nó vẫn mang gánh nặng. Nhiều quy trình chính đơn giản không thể hoạt động mà không có các cơ chế đồng thuận hoặc van an toàn do các kênh ngầm cung cấp.

## Xung đột và giải pháp

Đôi khi các kênh ngầm có thể tồi tệ. Đầu năm nay tôi đã viết “Bảo vệ thời gian của bạn khỏi những kẻ săn mồi trong các công ty công nghệ lớn” về cách một số người sử dụng các kênh ngầm để tự mình hưởng lợi trên các kỹ sư non nớt mà họ yêu cầu công việc. Và điều đó không bao giờ cảm thấy tốt khi bạn cảm thấy mọi người trong một cuộc họp đã thảo luận riêng về chủ đề trước đó ngoại trừ bạn. Vì những lý do này, một số người nghĩ rằng các kênh ngầm chính là một điều tồi, và rằng tất cả giao tiếp nên thông qua các kênh chính thức, có khả năng đọc hiểu.

## Ba loại nhân vật trong tổ chức

Có một văn bản khác cũng có ảnh hưởng như “Seeing Like A State”. Một này không phải là một cuốn sách, mà là một bài đăng blog: “Nguyên tắc Gervais” của Venkatesh Rao. Rao chia các tổ chức thành ba nhóm. Ở đỉnh là những “kẻ vô cảm”, người một cách mỉa mai sử dụng các quy tắc tổ chức để lợi ích của chính họ. Ở trung cấp quản lý là những “người ngây thơ”, những người bị mua vào các quy tắc chính thức của tổ chức và không nhận ra rằng có một trò chơi sâu hơn đang được chơi trên đầu họ. Bên dưới họ là những “kẻ thua cuộc”, những người nhận ra có một trò chơi đang được chơi nhưng không muốn tham gia. Tên gọi “kẻ thua cuộc” không phải là một phán xét giá trị – tôi nghĩ nó có nghĩa là tình cảm chỉ ra những người như những người dẫn đầu trong Clerks, những người quá chân thành để tham gia vào trò chơi công ty.

Tôi không đồng ý với mọi thứ trong “Nguyên tắc Gervais”, mặc dù tôi nghĩ nó đáng đọc (nếu bạn quan tâm đến điều này, bạn cũng nên đọc tác phẩm xuất sắc “Moral Mazes”). Nhưng các danh mục ở đây có thể được đọc rất tự nhiên theo thuật ngữ khả năng đọc hiểu. Cả kẻ vô cảm và kẻ thua cuộc đều tham gia với thế giới không đọc hiểu của tổ chức. Kẻ vô cảm sử dụng thế giới này để leo lên thang cấp, trong khi kẻ thua cuộc sử dụng nó để tạo ra một vị thế thoải mái, ít nỗ lực cho chính mình.

Những “người ngây thơ” chỉ tham gia với các quy trình có khả năng đọc hiểu. Họ là những người, khi muốn được thăng chức, đi tra cứu thang công việc chính thức và lập kế hoạch cách họ có thể thể hiện từng giá trị ở cấp tiếp theo. Họ quan tâm đến việc làm mọi thứ theo sách. Khi họ bị ép vào một cuộc gặp với thế giới không đọc hiểu, phản ứng của họ là lắc đầu và bắt đầu soạn thảo các cập nhật đến quy trình có khả năng đọc hiểu có thể phù hợp với một sự mô phỏng nhạt nhòa hơn của quy trình không đọc hiểu hiệu quả hơn.

Tôi nghĩ việc gọi những người này là ngây thơ là quá mỉa mai. Quy trình có khả năng đọc hiểu vẫn rất quan trọng – sau tất cả, nó là phần lớn những gì tổ chức làm. Cải thiện các quy trình chính thức vẫn là công việc có đòn bẩy cao, ngay cả khi các quy trình chính thức không bao giờ có thể mô tả toàn bộ cách một tổ chức hoạt động. Những người đầu tư vào khả năng đọc hiểu có giá trị thực sự đối với bất kỳ công ty công nghệ nào.

Tuy nhiên, việc suy nghĩ về mọi người trong danh mục của Rao – những người khai thác không đọc hiểu, những người thấy nó khó chịu, và những người sử dụng nó một cách thoải mái – có thể làm sáng tỏ. Nhiều khu vực xung đột thường xuyên trong các công ty phần mềm bắt nguồn từ ma sát giữa các nhóm người này.

## Kết luận

Tôi viết rất nhiều về việc nhận biết và sử dụng không đọc hiểu trong các công ty công nghệ:

– Phá vỡ các quy tắc (chính thức, có khả năng đọc hiểu) đôi khi là điều đúng cần làm
– Cảnh giác với các quản lý sản phẩm sành sỏi (và những người khác) khai thác các kênh không đọc hiểu để “mài giũa” công việc từ các kỹ sư non nớt
– Kỹ sư có năng lực nên làm việc trên “cược phụ” nằm ngoài quy trình lập kế hoạch thông thường
– Việc được thăng chức lên cấp Staff và cao hơn có rất ít liên quan đến thang công việc chính thức

Nói chung, lời khuyên về các quy trình không đọc hiểu là những gì tôi gọi là “lời khuyên nguy hiểm”. Nó nguy hiểm vì nếu bạn làm cho nó có khả năng đọc hiểu – ví dụ, nếu bạn công bố công khai rằng bạn đang hoàn thành một phần công việc thông qua kênh ngầm thay vì quy trình chính thức – bạn sẽ bị tổ chức trừng phạt ngay cả khi chuỗi quản lý của bạn muốn bạn làm điều đó. Bạn không thể nói to về nó. Nó phải ở trạng thái không đọc hiểu.

Tôi nhận được nhiều phản hồi tiêu cực trên những bài đăng này từ những người nói rằng bạn không bao giờ nên đi vòng quanh quy trình chính thức. Theo họ, nếu nó cần thay đổi, bạn nên thay đổi quy trình đó thay vì đi vòng quanh nó. Nói cách khác, mọi thứ diễn ra trong một công ty công nghệ đều phải có khả năng đọc hiểu, và các quy trình không đọc hiểu nên bị dập tắt và chuyển đổi thành các quy trình có khả năng đọc hiểu.

Tôi nghĩ quan điểm này là ngây thơ. Tất cả các tổ chức – công ty công nghệ, các câu lạc bộ xã hội, chính phủ – đều có cả hai mặt: có khả năng đọc hiểu và không đọc hiểu. Mặt có khả năng đọc hiểu quan trọng, sau khi đạt đến một kích thước nhất định. Nó cho phép tổ chức làm những điều nếu không sẽ không thể: lập kế hoạch dài hạn, phối hợp với các tổ chức rất lớn khác, và v.v. Nhưng mặt không đọc hiểu cũng quan trọng không kém. Nó cho phép công việc hiệu suất cao, cung cấp một van xả cho các quy trình không phù hợp với hoàn cảnh hiện tại, và đáp ứng mong muốn tự nhiên của con người về tin đồn và đồng thuận mềm mại.

Sự cân bằng giữa khả năng đọc hiểu và không đọc hiểu là chìa khóa để hiểu tại sao các công ty công nghệ lớn hoạt động như chúng làm, và tại sao ngay cả khi chúng có thể kém hiệu quả hơn trong việc sản xuất phần mềm, chúng vẫn có thể thống trị thị trường và đạt được lợi nhuận khổng lồ.