Connecting the Dots.

Có một kiểu cuộc họp mà tôi luôn thấy đặc biệt thú vị.

Bộ phận bán hàng phàn nàn rằng quy trình quá cứng nhắc.

Bộ phận kho cho rằng nhân viên bán hàng liên tục tạo ra những yêu cầu bất hợp lý.

Bộ phận vận chuyển nói rằng kế hoạch giao hàng cứ thay đổi vào phút cuối.

Bộ phận kế toán khẳng định mọi người không tuân thủ quy định.

Và quản lý kết luận rằng chúng ta cần tăng cường phối hợp giữa các phòng ban.

Một kết luận nghe rất chuyên nghiệp.

Cũng rất khó phản đối.

Bởi vì chẳng ai có thể nghiêm túc đứng lên tuyên bố rằng công ty nên giảm cường phối hợp.

Thế là cuộc họp kết thúc.

Mỗi bộ phận trở về công việc của mình, mang theo một danh sách những điều cần cải thiện.

Bán hàng phải chú ý hơn.

Kho phải chủ động hơn.

Vận chuyển phải linh hoạt hơn.

Kế toán phải hỗ trợ hơn.

Và quản lý phải giám sát chặt chẽ hơn.

Một tuần sau, những vấn đề tương tự tiếp tục xuất hiện.

Tôi không cho rằng những người tham gia cuộc họp thiếu thông minh.

Họ có thể rất giỏi trong lĩnh vực của mình.

Nhưng họ đang nhìn vào những phần khác nhau của cùng một hệ thống, thông qua những góc nhìn khác nhau, với những mục tiêu và thông tin khác nhau.

Điều khiến tôi tò mò không phải là ai đúng, ai sai.

Mà là một câu hỏi khác:

Có khi nào những vấn đề tưởng chừng không liên quan này thực chất đang được tạo ra bởi cùng một cấu trúc?

Và nếu đúng, tại sao chúng ta không nhìn thấy nó?

01. Chúng ta thường nhìn thấy sự kiện, không phải cấu trúc.

Bộ não con người rất giỏi nhận diện những sự kiện cụ thể.

Một đơn hàng giao trễ.

Một nhân viên báo giá sai.

Một khách hàng ngừng mua.

Một chương trình khuyến mãi không hiệu quả.

Một bộ phận liên tục quá tải.

Mỗi sự kiện có thời gian, địa điểm, người liên quan và hậu quả tương đối rõ ràng.

Chúng dễ được ghi nhận, dễ được thảo luận và thường có một người có thể bị yêu cầu giải trình.

Nhưng cấu trúc tạo ra những sự kiện đó lại không dễ quan sát như vậy.

Chúng ta không thể trực tiếp nhìn thấy một cơ chế phân quyền thiếu hợp lý.

Không thể chụp ảnh một luồng thông tin bị đứt gãy.

Không thể mở camera để quan sát một vòng phản hồi đang tạo ra động cơ sai lệch.

Chúng chỉ bộc lộ thông qua hành vi và kết quả.

Đó là lý do tôi thích phân biệt ba tầng khi quan sát một vấn đề.

Events — Những gì đã xảy ra.

Một đơn hàng giao trễ vì thông tin thay đổi.

Patterns — Những gì liên tục xảy ra.

Các đơn hàng có yêu cầu đặc biệt thường có tỷ lệ giao trễ cao hơn.

Structures — Những cơ chế khiến mẫu hình đó xuất hiện.

Hệ thống cho phép thay đổi cam kết với khách hàng sau khi kế hoạch vận chuyển đã được xác lập, nhưng không có cơ chế đồng bộ và đánh giá lại tính khả thi.

Ba tầng này dẫn đến ba loại câu hỏi hoàn toàn khác nhau.

Ai đã giao đơn hàng trễ?

Tại sao những đơn có yêu cầu đặc biệt thường giao trễ?

Và điều gì trong cách doanh nghiệp vận hành khiến nhóm đơn đó có xác suất giao trễ cao hơn?

Câu hỏi đầu tiên tìm người xử lý sự kiện.

Câu hỏi thứ hai tìm quy luật.

Câu hỏi thứ ba tìm cơ chế.

Không có câu hỏi nào vô dụng.

Nhưng nếu chúng ta chỉ dừng ở câu hỏi đầu tiên, tổ chức sẽ dành phần lớn thời gian để giải quyết những hậu quả của chính cấu trúc mà nó chưa nhận diện được.

Chúng ta không thể sửa một cấu trúc mà mình chưa biết nó tồn tại.

Và điều đáng nói là phần lớn cấu trúc trong doanh nghiệp không được tạo ra bởi một quyết định duy nhất.

Chúng hình thành từ hàng trăm quyết định nhỏ, được đưa ra ở những thời điểm khác nhau, bởi những con người khác nhau.

Một quy định được bổ sung để xử lý rủi ro.

Một ngoại lệ được cho phép để giữ khách hàng.

Một bước phê duyệt được thêm vào vì từng xảy ra sai sót.

Một chỉ tiêu được điều chỉnh để thúc đẩy năng suất.

Mỗi quyết định đều có thể hợp lý khi đứng riêng.

Nhưng khi kết hợp với nhau, chúng có thể tạo ra một hệ thống có hành vi mà không ai thực sự dự định từ đầu.

Đây là một trong những điều thú vị nhất của Systems Thinking.

Hành vi của toàn bộ hệ thống không nhất thiết là tổng đơn giản của ý định từng thành phần.

Một tổ chức có thể chứa rất nhiều người đang cố gắng làm đúng, nhưng vẫn liên tục tạo ra kết quả sai.

Không phải vì tất cả đều ngu.

Mà vì cấu trúc kết nối những nỗ lực đó có vấn đề.

02. Cùng một dữ liệu, những câu chuyện hoàn toàn khác nhau.

Hãy tưởng tượng doanh thu của một nhóm khách hàng giảm 15%.

Nhân viên bán hàng cho rằng khách đang gặp khó khăn kinh doanh.

Marketing cho rằng đối thủ đã đưa ra chương trình tốt hơn.

Bộ phận sản phẩm nghi ngờ danh mục hàng hóa không còn phù hợp.

Quản lý nhận định rằng đội ngũ chăm sóc khách hàng chưa đủ tốt.

Và một người đặc biệt yêu thích công nghệ đề xuất xây dựng hệ thống AI dự báo khách hàng rời bỏ.

Tôi hiểu người cuối cùng.

Tôi cũng thích công nghệ.

Nhưng lúc này, chúng ta chưa thực sự biết điều gì đang xảy ra.

Chúng ta có một quan sát: doanh thu giảm.

Phần còn lại là các giả thuyết.

Có thể số lượng khách hàng đang giảm.

Có thể số lượng đơn hàng trên mỗi khách giảm.

Có thể giá trị trung bình mỗi đơn giảm.

Có thể một nhóm sản phẩm bị thiếu hàng trong thời gian dài.

Có thể doanh thu giảm nhưng lợi nhuận lại tăng vì doanh nghiệp đã ngừng phục vụ những giao dịch kém hiệu quả.

Hoặc đơn giản, năm ngoái có một vài đơn hàng bất thường làm mức so sánh trở nên sai lệch.

Tất cả những khả năng đó có thể cùng xuất phát từ một con số.

Và mỗi khả năng sẽ dẫn đến một quyết định hoàn toàn khác.

Đây là lý do tôi không xem khả năng connecting the dots là việc tìm ra một câu chuyện nghe hợp lý từ dữ liệu.

Con người vốn rất giỏi kể chuyện.

Đặc biệt là khi câu chuyện đó phù hợp với điều họ đã tin từ trước.

Một người tin rằng nhân viên thiếu trách nhiệm sẽ nhìn thấy bằng chứng về sự thiếu trách nhiệm.

Một người tin rằng doanh nghiệp cần thêm phần mềm sẽ liên tục phát hiện những vấn đề có thể giải quyết bằng phần mềm.

Một người tin rằng khách hàng chỉ quan tâm đến giá sẽ diễn giải gần như mọi sự sụt giảm doanh thu theo hướng cạnh tranh giá.

Chúng ta không chỉ quan sát thực tế.

Chúng ta còn quan sát thực tế thông qua mô hình đã tồn tại trong đầu mình.

Và mô hình đó có thể sai.

Dữ liệu không tự động tạo ra hiểu biết. Nó chỉ cung cấp những dấu vết để chúng ta kiểm chứng hiểu biết của mình.

Một người có nhiều dữ liệu chưa chắc nhìn thấy nhiều hơn.

Đôi khi họ chỉ có nhiều vật liệu hơn để xây dựng một câu chuyện sai.

Với những biểu đồ rất đẹp.

03. Nhìn thấy điểm chung không có nghĩa đã tìm thấy nguyên nhân chung.

Giả sử chúng ta quan sát ba vấn đề.

Nhân viên bán hàng thường xuyên phải hỏi quản lý về chính sách giá.

Bộ phận kho thường xuyên phải hỏi về cách xử lý hàng hóa đặc biệt.

Bộ phận chăm sóc khách hàng thường xuyên phải hỏi về quyền hỗ trợ khách.

Một người có thể kết luận:

"Công ty đang thiếu quy trình."

Một người khác nói:

"Nhân viên không có khả năng tự chủ."

Một người thứ ba đề xuất:

"Chúng ta cần đào tạo kỹ năng ra quyết định."

Cả ba nhận định đều có thể chứa một phần sự thật.

Nhưng tôi muốn đi sâu hơn.

Điều gì khiến những quyết định này phải được chuyển đến cấp trên?

Có phải vì người thực hiện thiếu thông tin?

Hay vì họ có thông tin nhưng không có quyền quyết định?

Hay vì họ có quyền nhưng không biết giới hạn của quyền đó?

Hay vì quyết định có tác động đến nhiều bộ phận, nhưng không ai thực sự sở hữu kết quả cuối cùng?

Những nguyên nhân này rất khác nhau.

Nếu thiếu thông tin, chúng ta cần cải thiện khả năng truy cập dữ liệu.

Nếu thiếu quyền hạn, chúng ta cần xem lại cấu trúc phân quyền.

Nếu giới hạn không rõ, chúng ta cần định nghĩa decision boundaries.

Nếu trách nhiệm kết quả bị phân mảnh, chúng ta cần xem lại ownership và cơ chế phối hợp.

Một giải pháp đúng với nguyên nhân này có thể hoàn toàn vô dụng với nguyên nhân khác.

Đây là điều tôi muốn nhấn mạnh:

Abstraction không phải tìm một khái niệm đủ rộng để gom mọi vấn đề vào chung một cái hộp.

Nói rằng "công ty thiếu quy trình" không phải một phát hiện sâu sắc nếu chúng ta không thể xác định chính xác cơ chế nào đang thiếu.

Nói rằng "tất cả là vấn đề con người" cũng chẳng giúp ích gì nếu không thể chỉ ra con người đang thiếu năng lực nào và vì sao.

Một abstraction có giá trị phải giữ lại những khác biệt quan trọng, đồng thời loại bỏ những chi tiết không ảnh hưởng đến bản chất.

Trong Software Engineering, chúng ta không tạo ra một abstraction tốt chỉ bằng cách gom nhiều function vào cùng một class rồi đặt cho nó cái tên thật hoành tráng.

Trong kinh doanh cũng vậy.

Nếu gom tất cả vấn đề vào một khái niệm chung chung như "nâng cao hiệu quả phối hợp", chúng ta có thể tạo ra một chương trình cải tiến kéo dài sáu tháng.

Với workshop.

Slide.

KPI.

Và những buổi họp đánh giá tiến độ của chính chương trình cải tiến.

Cuối cùng, mọi người phối hợp rất tốt để báo cáo rằng việc phối hợp đang được cải thiện.

Còn vấn đề ban đầu?

Vẫn ở đó.

Chỉ là bây giờ nó có thêm một bộ tài liệu rất chuyên nghiệp.

04. Cấu trúc thường nằm ở ranh giới giữa những thứ tưởng như không liên quan.

Một trong những điều tôi học được từ Software Architecture là các vấn đề khó thường xuất hiện tại ranh giới.

Giữa hai service.

Giữa database và application.

Giữa một transaction và một hệ thống bên ngoài.

Giữa giả định của thành phần này và cam kết của thành phần khác.

Mỗi thành phần có thể hoạt động đúng theo thiết kế riêng của mình.

Nhưng khi tương tác, chúng tạo ra lỗi.

Trong doanh nghiệp, ranh giới cũng quan trọng như vậy.

Giữa bán hàng và vận chuyển.

Giữa marketing và vận hành.

Giữa kế toán và chính sách thương mại.

Giữa mục tiêu cá nhân và kết quả chung.

Giữa những gì khách hàng được hứa và những gì hệ thống thực sự có khả năng thực hiện.

Lấy một ví dụ.

Nhân viên bán hàng muốn giữ khách nên hứa giao hàng trong ngày.

Bộ phận vận chuyển muốn tối ưu chi phí nên lập tuyến dựa trên tổng số điểm giao và khoảng cách.

Cả hai đều đang theo đuổi một mục tiêu hợp lý.

Nhưng nếu hệ thống không có một cơ chế chung để xác định thời gian giao hàng khả thi, lời hứa của người bán và kế hoạch của người giao có thể liên tục xung đột.

Vấn đề không nằm hoàn toàn trong bộ phận bán hàng.

Cũng không nằm hoàn toàn trong vận chuyển.

Nó nằm ở interface giữa hai chức năng.

Một cam kết được tạo ra ở nơi không sở hữu đầy đủ thông tin để bảo đảm cam kết đó.

Đây là kiểu cấu trúc mà nếu chỉ nhìn từng bộ phận riêng lẻ, chúng ta rất dễ bỏ qua.

Bởi vì mỗi bộ phận có thể chứng minh mình đã làm đúng.

Sales đã chăm sóc khách hàng.

Vận chuyển đã tối ưu tuyến.

Kho đã xuất hàng đúng quy trình.

Kế toán đã kiểm soát chi phí.

Tất cả đều đúng.

Và đơn hàng vẫn trễ.

Một hệ thống không thể được đánh giá chỉ bằng mức độ đúng đắn của từng thành phần.

Chúng ta còn phải đánh giá tính nhất quán của các cam kết khi chúng đi qua những ranh giới đó.

Sometimes the problem is not inside the components. It is in the contract between them.

Đây là một nguyên lý của kỹ thuật phần mềm mà tôi thấy có giá trị lớn trong thiết kế tổ chức.

Không phải vì doanh nghiệp thực sự là một chương trình máy tính.

Mà vì cả hai đều phải giải quyết bài toán phối hợp giữa những thành phần có trạng thái, trách nhiệm và giới hạn khác nhau.

05. Thời gian là thứ khiến các quy luật trở nên khó nhìn thấy.

Không phải mọi vấn đề đều có nguyên nhân xuất hiện ngay trước hậu quả.

Đôi khi, khoảng cách giữa một quyết định và kết quả của nó kéo dài hàng tháng.

Một doanh nghiệp giảm chi phí đào tạo nhân viên.

Trong tháng đầu tiên, chi phí vận hành giảm.

Báo cáo trông tốt hơn.

Ba tháng sau, tỷ lệ sai sót của nhân viên mới bắt đầu tăng.

Sáu tháng sau, các quản lý kỳ cựu phải dành nhiều thời gian hơn để hỗ trợ.

Một năm sau, doanh nghiệp nhận thấy năng lực mở rộng đội ngũ bị giới hạn.

Lúc này, nguyên nhân và hậu quả đã cách nhau quá xa.

Người đưa ra quyết định ban đầu có thể không còn nhớ mối liên hệ.

Nhân viên mới được tuyển vào cũng chẳng biết chuyện gì đã xảy ra.

Và tổ chức có thể kết luận:

"Thị trường lao động bây giờ chất lượng quá kém."

Có thể.

Nhưng cũng có thể chúng ta đang nhìn thấy hậu quả muộn của một lựa chọn quản trị trước đó.

Đây là lý do feedback delay khiến tư duy hệ thống trở nên khó khăn.

Một hành động có thể tạo ra lợi ích ngay lập tức và chi phí trong tương lai.

Một giải pháp có thể giảm áp lực ở bộ phận này nhưng chuyển áp lực sang bộ phận khác.

Một chính sách có thể hoạt động tốt ở quy mô nhỏ nhưng tạo ra tác dụng phụ khi quy mô tăng.

Nếu chỉ đo lường những kết quả gần nhất, chúng ta rất dễ khen thưởng những quyết định tạo ra chi phí dài hạn.

Hoặc ngược lại, loại bỏ một cải tiến đúng hướng chỉ vì lợi ích của nó chưa kịp xuất hiện.

Tôi không thích kiểu đánh giá quản trị chỉ dựa trên một bức ảnh chụp tại một thời điểm.

Tôi muốn nhìn thấy một đoạn phim.

Điều gì xảy ra trước đó?

Những quyết định nào đã được đưa ra?

Các thành phần của hệ thống phản ứng ra sao?

Và những phản ứng đó quay trở lại ảnh hưởng đến quyết định ban đầu như thế nào?

Một cơ chế thưởng theo số lượng đơn có thể khiến nhân viên tăng tốc tạo đơn.

Số đơn tăng khiến kho và vận chuyển quá tải.

Chất lượng giao hàng giảm làm khách phàn nàn.

Nhân viên bán hàng dành nhiều thời gian xử lý khiếu nại hơn, khiến khả năng phát triển khách mới suy giảm.

Nếu doanh nghiệp chỉ nhìn số đơn ở giai đoạn đầu, chính sách có vẻ thành công.

Nếu nhìn toàn bộ chu kỳ, kết quả có thể hoàn toàn khác.

Một quyết định không chỉ tạo ra kết quả. Nó còn có thể thay đổi chính những điều kiện sẽ ảnh hưởng đến các quyết định tiếp theo.

Đó là lý do feedback loops quan trọng.

Và cũng là lý do những vấn đề quản trị hiếm khi có thể hiểu đầy đủ bằng một sơ đồ nguyên nhân — kết quả đơn tuyến.

06. Connecting the dots không phải trò chơi nối hình.

Có một điểm yếu khá thú vị trong cách con người tìm kiếm quy luật.

Chúng ta có xu hướng nhìn thấy những mẫu hình ngay cả khi chúng không thực sự tồn tại.

Nhìn lên bầu trời, con người có thể nối các ngôi sao thành những chòm sao mang hình dạng rất sống động.

Nhưng những đường nối đó phần lớn là sản phẩm của trí tưởng tượng.

Các ngôi sao không nhất thiết gần nhau trong không gian chỉ vì chúng trông gần nhau từ Trái Đất.

Vấn đề tương tự có thể xảy ra khi chúng ta phân tích doanh nghiệp.

Một nhân viên nghỉ việc sau khi công ty thay đổi chính sách.

Chúng ta kết luận chính sách khiến nhân viên nghỉ việc.

Một chương trình marketing được triển khai trước khi doanh thu tăng.

Chúng ta cho rằng chương trình marketing đã tạo ra tăng trưởng.

Một bộ phận đạt kết quả tốt sau khi bổ nhiệm quản lý mới.

Chúng ta khẳng định người quản lý mới là nguyên nhân.

Tất cả đều có thể đúng.

Nhưng thứ tự xuất hiện không tự động chứng minh quan hệ nhân quả.

Có thể nhân viên đã có ý định nghỉ việc từ trước.

Có thể doanh thu tăng vì yếu tố mùa vụ.

Có thể bộ phận đó đang hưởng lợi từ một thay đổi được triển khai nhiều tháng trước khi quản lý mới xuất hiện.

Tôi đặc biệt cảnh giác với những lời giải thích quá thanh lịch.

Những câu chuyện có thể kết nối tất cả sự kiện vào một luận điểm duy nhất thường rất hấp dẫn.

Chúng tạo ra cảm giác rằng chúng ta đã hiểu vấn đề.

Nhưng cảm giác hiểu biết và hiểu biết thực sự không phải cùng một thứ.

Một mẫu hình đẹp không có nghĩa nó đúng. Một lời giải thích hợp lý không có nghĩa nó đã được chứng minh.

Vậy làm sao để phân biệt?

Tôi thích đặt câu hỏi ngược.

Nếu giả thuyết này đúng, chúng ta kỳ vọng sẽ quan sát thấy điều gì khác?

Nếu giả thuyết này sai, dữ liệu nào có thể khiến chúng ta phát hiện ra?

Có trường hợp nào tương tự nhưng kết quả lại khác không?

Và liệu có một giả thuyết khác giải thích cùng những quan sát đó tốt hơn?

Ví dụ, nếu chúng ta cho rằng việc thiếu quyền tự chủ khiến nhân viên phải liên tục hỏi quản lý, hãy tìm một nhóm nhân viên đã được trao quyền rõ ràng hơn.

Họ có thực sự ít cần can thiệp hơn không?

Chất lượng quyết định có được duy trì không?

Hay số lần hỏi giảm chỉ vì nhân viên bắt đầu tự quyết, trong khi sai sót và tổn thất tăng lên?

Nếu không kiểm tra những hậu quả đó, chúng ta rất dễ tuyên bố thành công dựa trên một chỉ số không đầy đủ.

Đây là điều tôi thích ở tư duy kỹ thuật.

Một giả thuyết không nên chỉ giải thích được những điều đã xảy ra.

Nó nên giúp chúng ta đưa ra những dự đoán có thể được kiểm chứng.

The value of a mental model is not how elegantly it explains yesterday, but how reliably it helps us navigate tomorrow.

Đôi khi một mô hình rất đơn giản nhưng dự đoán tốt lại có giá trị hơn một lý thuyết hoành tráng giải thích được mọi thứ sau khi chúng đã xảy ra.

07. Noise và Signal — Khả năng quan trọng nhất có thể là biết điều gì không đáng quan tâm.

Tôi không nghĩ người giỏi tư duy hệ thống nhất thiết là người nhìn thấy nhiều vấn đề hơn.

Đôi khi, họ là người biết bỏ qua nhiều vấn đề hơn.

Một doanh nghiệp vận hành mỗi ngày sẽ tạo ra vô số tín hiệu.

Doanh thu một nhóm khách hàng giảm.

Một nhân viên có kết quả bất thường.

Một sản phẩm bán chậm.

Một khách hàng phàn nàn.

Một chỉ số tăng đột ngột.

Một chiến dịch có tỷ lệ chuyển đổi thấp hơn dự kiến.

Nếu chúng ta phản ứng với mọi biến động, tổ chức sẽ liên tục thay đổi phương hướng.

Hôm nay sửa chính sách giá.

Ngày mai thay đổi KPI.

Ngày kia điều chỉnh quy trình.

Tuần sau lại sửa những thứ vừa triển khai vì kết quả chưa như mong đợi.

Rốt cuộc, mọi người dành nhiều thời gian thích nghi với các quyết định quản trị hơn là thực hiện công việc kinh doanh.

Đây cũng là một dạng hỗn loạn.

Hỗn loạn được tạo ra bởi chính nỗ lực kiểm soát hỗn loạn.

Có những biến động là ngẫu nhiên.

Có những vấn đề xuất hiện một lần rồi biến mất.

Có những chỉ số dao động trong phạm vi bình thường.

Và có những thay đổi có ý nghĩa thực sự nhưng cần thời gian đủ dài mới bộc lộ.

Nếu thiếu khả năng phân biệt, người quản lý sẽ rất dễ trở thành nguồn phát sinh biến động lớn nhất của tổ chức.

Tôi thích nghĩ đến ba câu hỏi.

Thứ nhất, vấn đề này có thực sự bất thường so với mức biến động thông thường hay không?

Thứ hai, nếu nó là bất thường, tác động của nó có đủ lớn để cần can thiệp hay không?

Thứ ba, nếu cần can thiệp, chúng ta đã hiểu đủ về nguyên nhân để đưa ra hành động hợp lý chưa?

Tôi không xem đó là một công thức cứng nhắc.

Có những sự cố nghiêm trọng chỉ cần xuất hiện một lần đã đòi hỏi hành động ngay.

Nhưng với phần lớn những biến động không có tính khẩn cấp, sự kiên nhẫn có kỷ luật là một năng lực rất đáng giá.

Không phải mọi tín hiệu đều yêu cầu một quyết định. Và không phải mọi quyết định đều tạo ra cải thiện.

Một người nhìn thấy cấu trúc phải biết khi nào nên hành động.

Nhưng họ cũng phải biết khi nào không nên.

Bởi vì thay đổi một hệ thống khi chưa hiểu rõ nguyên nhân có thể tạo ra nhiều nhiễu hơn chính vấn đề ban đầu.

Và khi đó, chúng ta lại phải phân tích những nhiễu mới.

Một vòng lặp rất phù hợp cho những người thích bận rộn.

Không phù hợp lắm cho người muốn xây dựng một doanh nghiệp hiệu quả.

08. Tại sao có người nhìn thấy cấu trúc còn người khác thì không?

Đây là một câu hỏi tôi thực sự thấy khó.

Tại sao hai người có thể tiếp xúc với cùng một dữ liệu, cùng một môi trường kinh doanh, thậm chí có kinh nghiệm tương đương, nhưng lại đưa ra những cách hiểu hoàn toàn khác nhau?

Tôi không tin câu trả lời đơn giản là người này thông minh hơn người kia.

Trí thông minh có vai trò.

Kinh nghiệm cũng vậy.

Nhưng tôi nghĩ khả năng nhận diện cấu trúc còn phụ thuộc vào cách chúng ta tổ chức tri thức trong đầu.

Một người chỉ quen giải quyết vấn đề trong một lĩnh vực có thể sở hữu kiến thức rất sâu về lĩnh vực đó.

Họ biết chính xác điều gì thường xảy ra và cách xử lý nhanh nhất.

Nhưng đôi khi, sự thành thạo ấy khiến họ ít đặt câu hỏi về những giả định nền tảng.

Ngược lại, người tiếp xúc với nhiều lĩnh vực có thể nhận ra những nguyên lý tương đồng giữa các tình huống rất khác nhau.

Một vấn đề phân quyền trong doanh nghiệp có thể gợi nhớ đến authorization trong Software Engineering.

Một nút thắt cổ chai trong phê duyệt đơn hàng có thể được phân tích bằng tư duy queueing.

Một chương trình thưởng làm phát sinh hành vi không mong muốn có thể được nhìn qua incentive design.

Một quy trình liên tục tạo ra ngoại lệ có thể được xem xét như một kiến trúc thiếu khả năng xử lý các trạng thái hợp lệ.

Những mối liên hệ này có giá trị vì chúng mở rộng không gian giải pháp.

Chúng cho phép chúng ta sử dụng những công cụ tư duy được phát triển trong lĩnh vực này để khám phá vấn đề trong lĩnh vực khác.

Nhưng cũng có một rủi ro.

Sự giống nhau giữa hai vấn đề không đồng nghĩa giải pháp của chúng có thể được sao chép nguyên vẹn.

Con người không phải microservice.

Một tổ chức không phải database.

Và thị trường không phải một chương trình có thể debug bằng cách đặt breakpoint.

Ẩn dụ kỹ thuật có thể giúp chúng ta đặt câu hỏi tốt hơn.

Nhưng nó không thay thế được việc hiểu bản chất kinh tế, tâm lý và xã hội của doanh nghiệp.

Một người có khả năng kết nối nhiều lĩnh vực nhưng thiếu kiến thức nền tảng cũng có thể tạo ra những liên tưởng rất sáng tạo.

Và rất sai.

Vì vậy, tôi nghĩ tư duy hệ thống cần hai năng lực tưởng như đối lập.

Breadth — Đủ rộng để nhận ra những nguyên lý có thể xuất hiện ở nhiều lĩnh vực.

Depth — Đủ sâu để hiểu tại sao một nguyên lý có thể đúng ở đây nhưng không còn đúng ở nơi khác.

Chỉ có chiều sâu, chúng ta có nguy cơ bị mắc kẹt trong chuyên môn.

Chỉ có chiều rộng, chúng ta có nguy cơ trở thành người biết nói rất nhiều về mọi thứ nhưng không thực sự hiểu thứ gì.

Tôi không thấy lựa chọn nào đặc biệt hấp dẫn.

09. Khả năng này có thể được đào tạo không?

Tôi nghĩ có.

Nhưng không hoàn toàn theo cách chúng ta thường hiểu về đào tạo.

Không ai trở thành người có khả năng tư duy hệ thống sâu sắc chỉ vì tham gia một khóa học hai ngày về Systems Thinking.

Cũng không phải cứ đọc vài cuốn sách về Mental Models là có thể nhìn thấy cấu trúc trong mọi vấn đề.

Những khái niệm đó chỉ cung cấp ngôn ngữ và công cụ.

Năng lực thực sự hình thành khi chúng ta liên tục sử dụng chúng để giải quyết những vấn đề có hậu quả thật.

Tôi cho rằng có những khác biệt về tố chất nhận thức giữa con người.

Khả năng xử lý nhiều biến số, nhận diện quan hệ trừu tượng, duy trì mô hình phức tạp trong trí nhớ và linh hoạt thay đổi giả định không nhất thiết giống nhau ở mọi người.

Chúng ta không nên giả vờ rằng tất cả đều có cùng điểm xuất phát.

Nhưng sự khác biệt về điểm xuất phát không có nghĩa khả năng phát triển là cố định.

Một người có thể học cách phân biệt sự kiện với giả thuyết.

Học cách không vội kết luận từ một trường hợp.

Học cách tìm những yếu tố bất biến giữa các tình huống khác nhau.

Học cách phân tích tác động chéo giữa các bộ phận.

Học cách nhận diện những giả định mà trước đây mình chưa từng đặt câu hỏi.

Và quan trọng hơn, học cách kiểm chứng xem cách hiểu của mình có đúng hay không.

Tôi đặc biệt thích một phương pháp rất đơn giản.

Khi một vấn đề xảy ra, thay vì chỉ hỏi phải giải quyết thế nào, hãy yêu cầu người phân tích đưa ra một mô hình giải thích.

Họ nghĩ nguyên nhân là gì?

Bằng chứng nào hỗ trợ nhận định đó?

Nếu nhận định đúng, điều gì sẽ xảy ra khi chúng ta thay đổi một yếu tố cụ thể?

Và sau khi can thiệp, kết quả có phù hợp với dự đoán không?

Nếu không, phải điều chỉnh mô hình.

Không phải điều chỉnh câu chuyện để bảo vệ kết luận cũ.

Sự khác biệt này rất quan trọng.

Bởi vì nhiều người không thực sự học từ kinh nghiệm.

Họ chỉ tích lũy thêm những câu chuyện để chứng minh mình đã đúng từ đầu.

Một người có thể làm việc hai mươi năm nhưng chỉ lặp lại một năm kinh nghiệm hai mươi lần.

Trong khi một người khác có thể học rất nhanh nếu họ liên tục kiểm chứng và cập nhật cách hiểu của mình.

Kinh nghiệm không tự động tạo ra năng lực trừu tượng. Khả năng học từ kinh nghiệm mới là điều quyết định giá trị của nó.

Tôi không nghĩ mọi người đều có thể đạt đến cùng một trình độ abstraction.

Nhưng tôi tin phần lớn mọi người có thể cải thiện đáng kể chất lượng tư duy nếu môi trường làm việc buộc họ phải đưa ra lập luận, tiếp nhận phản biện và chịu trách nhiệm với dự đoán của mình.

Ngược lại, nếu tổ chức chỉ yêu cầu nhân viên làm theo hướng dẫn và không bao giờ đặt câu hỏi, chúng ta không nên ngạc nhiên khi họ không phát triển được khả năng tự giải quyết vấn đề mới.

Chúng ta đã thiết kế một môi trường không cần tư duy độc lập.

Rồi lại phàn nàn vì nhân viên không biết tư duy độc lập.

Một cách quản trị khá sáng tạo.

Theo nghĩa tệ nhất của từ sáng tạo.

10. Mối nguy hiểm của người luôn nhìn thấy cấu trúc.

Tôi muốn dành một phần riêng cho rủi ro này.

Bởi vì nếu một người thực sự có khả năng phát hiện quy luật nhanh hơn người khác, họ rất dễ phát triển một thói quen nguy hiểm.

Tin rằng mình luôn nhìn thấy nhiều hơn người khác.

Lúc đầu, sự tự tin đó có thể đến từ những trải nghiệm có thật.

Họ phát hiện một vấn đề trước khi nó trở nên nghiêm trọng.

Họ dự đoán một kết quả mà người khác không nhận ra.

Họ thiết kế một giải pháp hiệu quả từ những dữ liệu tưởng chừng rời rạc.

Thành công lặp lại làm niềm tin tăng lên.

Và dần dần, niềm tin có thể biến thành một giả định ngầm:

Nếu người khác không hiểu điều mình đang nhìn thấy, có lẽ họ chưa đủ năng lực.

Đôi khi điều đó đúng.

Nhưng không phải lúc nào cũng đúng.

Có thể người khác đang sở hữu một thông tin mà mình chưa có.

Có thể họ nhìn thấy một ràng buộc thực tế mà mô hình của mình đã bỏ qua.

Có thể một giải pháp rất thanh lịch trên lý thuyết sẽ tạo ra chi phí triển khai mà người thiết kế chưa đánh giá đầy đủ.

Và cũng có thể mình đã sai.

Đây là lý do tôi không thích xây dựng một hình ảnh thần bí về người có tư duy hệ thống.

Không có ai đứng ngoài hệ thống để quan sát nó với sự khách quan tuyệt đối.

Người thiết kế cũng là một thành phần trong hệ thống.

Họ có giới hạn nhận thức.

Có động cơ riêng.

Có những trải nghiệm ảnh hưởng đến cách đánh giá.

Và có những giả định chưa được kiểm chứng.

Đặc biệt, khi một người vừa thiết kế hệ thống, vừa nắm quyền điều hành, những sai lầm trong tư duy của họ có thể được khuếch đại bởi quyền lực.

Một giả định sai từ nhân viên có thể ảnh hưởng đến một giao dịch.

Một giả định sai từ người thiết kế kiến trúc có thể ảnh hưởng đến hàng nghìn giao dịch.

Điều nguy hiểm nhất không phải là người lãnh đạo mắc sai lầm.

Mà là tổ chức không còn khả năng phát hiện và phản biện những sai lầm ấy.

Nếu mọi quyết định đều phải đi qua một người, và mọi người khác chỉ được phép thực thi, doanh nghiệp có thể vận hành rất nhất quán.

Nhất quán theo cả những giả định đúng lẫn những giả định sai.

Tôi muốn một môi trường nơi người khác có thể nói:

"Tôi nghĩ anh đang bỏ qua một biến số."

Hoặc:

"Dữ liệu hiện tại chưa đủ để kết luận như vậy."

Hoặc đơn giản:

"Em không đồng ý. Đây là lý do."

Không phải mọi ý kiến phản biện đều đúng.

Nhưng khả năng phản biện phải tồn tại độc lập với việc người có quyền lực có thích nghe nó hay không.

Một người giỏi nhận diện cấu trúc vẫn cần những cơ chế có thể phát hiện khi chính mô hình của họ sai.

Nếu không, khả năng abstraction có thể chuyển từ lợi thế thành rủi ro.

Bởi vì một người không nhìn thấy cấu trúc có thể giải quyết sai một vấn đề.

Một người nhìn thấy sai cấu trúc có thể thiết kế ra một hệ thống khiến hàng nghìn vấn đề mới xuất hiện.

Và nếu người đó còn đặc biệt tự tin vào khả năng của mình?

Chúng ta sẽ có một thảm họa được triển khai với tốc độ rất cao.

11. Insight chỉ thực sự có giá trị khi nó thay đổi được một điều gì đó.

Tôi không đánh giá cao những insight chỉ dừng lại ở mức nghe rất thông minh.

Một người có thể mô tả doanh nghiệp bằng những thuật ngữ cực kỳ sâu sắc.

Feedback loops.

Emergent behavior.

Complex adaptive systems.

Structural constraints.

Organizational entropy.

Tuyệt vời.

Nhưng sau buổi thảo luận, nếu không ai biết phải quan sát thêm điều gì, kiểm chứng giả thuyết nào hoặc thay đổi cơ chế nào, thì chúng ta mới chỉ hoàn thành một hoạt động trí tuệ.

Không nhất thiết vô ích.

Nhưng chưa phải thiết kế hệ thống.

Với tôi, một insight có giá trị thường dẫn đến ít nhất một trong ba kết quả.

Nó giúp chúng ta dự đoán tốt hơn một hiện tượng.

Nó giúp chúng ta đưa ra quyết định tốt hơn khi đối diện với một tình huống.

Hoặc nó giúp chúng ta thay đổi cơ chế để tạo ra kết quả mong muốn một cách đáng tin cậy hơn.

Một phát hiện có thể bắt đầu rất nhỏ.

Chẳng hạn, doanh nghiệp nhận thấy những yêu cầu cần nhiều cấp phê duyệt thường có thời gian xử lý biến động mạnh.

Quan sát đó dẫn đến một giả thuyết về nút thắt cổ chai.

Chúng ta phân tích luồng quyết định.

Phát hiện một số trường hợp có thể được xử lý theo quy tắc rõ ràng.

Thiết kế lại quyền hạn.

Triển khai thử.

Đo thời gian xử lý, tỷ lệ sai sót và kết quả kinh doanh.

Nếu các chỉ số cải thiện, giả thuyết được hỗ trợ.

Nếu không, chúng ta tiếp tục tìm hiểu.

Một insight như vậy không cần một cái tên hoành tráng.

Nó tạo ra giá trị vì giúp tổ chức hoạt động tốt hơn.

Tôi thích những ý tưởng có thể đi từ bảng trắng vào hoạt động thực tế.

Từ một mô hình trong đầu đến một cơ chế vận hành.

Từ một giả thuyết đến một thay đổi có thể kiểm chứng.

Từ một hiểu biết của cá nhân đến một năng lực có thể được nhiều người sử dụng.

Insight is not the destination. It is the beginning of engineering.

Đó là sự khác biệt giữa việc nhìn thấy cấu trúc và thực sự trở thành người thiết kế cấu trúc.

12. Khi người nhìn thấy cấu trúc trở thành giới hạn của tổ chức.

Có một nghịch lý mà tôi nghĩ những người sáng lập doanh nghiệp nên đặc biệt chú ý.

Khả năng kết nối các vấn đề, phát hiện quy luật và thiết kế giải pháp có thể là lợi thế rất lớn của founder trong giai đoạn đầu.

Khi doanh nghiệp còn nhỏ, một người có khả năng nhìn toàn cục có thể đưa ra những quyết định nhanh và nhất quán hơn nhiều so với một tổ chức bị chia cắt bởi các phòng ban.

Họ hiểu khách hàng.

Hiểu sản phẩm.

Hiểu công nghệ.

Hiểu vận hành.

Và có thể kết nối những thông tin mà người khác chỉ nhìn thấy một phần.

Đây là một lợi thế thực sự.

Nhưng khi doanh nghiệp phát triển, chính lợi thế đó có thể tạo ra một vấn đề mới.

Mọi người bắt đầu phụ thuộc vào khả năng nhận diện cấu trúc của founder.

Những vấn đề mới được chuyển lên.

Những quyết định khó được chuyển lên.

Những mâu thuẫn giữa các bộ phận được chuyển lên.

Và những thay đổi quan trọng đều cần founder giải thích tại sao phải thực hiện.

Ban đầu, hệ thống hoạt động tốt vì một người có thể xử lý nhanh hơn cả nhóm.

Nhưng sau một thời gian, tốc độ phát triển của tổ chức bắt đầu bị giới hạn bởi khả năng quan sát, phân tích và truyền đạt của người đó.

Founder có thể nhìn thấy cấu trúc rất nhanh.

Nhưng những người khác cần thời gian để hiểu.

Founder có thể nhận ra mối liên hệ giữa năm vấn đề chỉ sau một cuộc trao đổi.

Nhưng bộ phận vận hành có thể cần nhiều tuần để chuyển hiểu biết đó thành quy trình và thói quen làm việc.

Founder có thể thiết kế một kiến trúc mới trong đầu.

Nhưng tổ chức chưa chắc có đủ năng lực triển khai, kiểm chứng và duy trì nó.

Khi đó, vấn đề không còn đơn giản là chất lượng của những insight.

Nó là khả năng chuyển hóa insight thành năng lực tập thể.

Một kiến trúc chỉ tồn tại trong đầu người thiết kế không thể trở thành nền tảng mở rộng lâu dài.

Một quyết định đúng nhưng không thể được truyền đạt, kiểm chứng hoặc thực thi nhất quán vẫn là một quyết định mong manh.

Và một tổ chức chỉ có một người đủ khả năng nhìn toàn cục đang sở hữu một điểm tập trung rủi ro rất lớn.

Điều thú vị là giải pháp không nhất thiết phải tìm thêm những người có khả năng tư duy giống hệt founder.

Có thể điều đó rất khó.

Thậm chí không thực tế.

Nhưng chúng ta có thể thiết kế tổ chức để giảm mức độ phụ thuộc vào khả năng nhận thức của một cá nhân.

Những giả định quan trọng được làm rõ.

Những quy tắc đã hiểu được chuyển thành cơ chế.

Những dữ liệu cần thiết được cung cấp đúng nơi.

Những quyết định có thể phân quyền được đưa đến người đủ năng lực.

Những ngoại lệ thực sự mới được giữ lại cho những người có khả năng giải quyết chúng.

Và những mô hình tư duy quan trọng được truyền đạt thông qua vấn đề thật, phản biện thật và kết quả thật.

Không phải để tất cả mọi người suy nghĩ giống nhau.

Mà để họ có thể tự ra quyết định tốt trong phạm vi trách nhiệm của mình.

Đây là một bước trưởng thành rất khác so với việc founder tiếp tục trở nên giỏi hơn.

Tổ chức không thể mở rộng mãi bằng cách tăng năng lực của người thông minh nhất. Nó phải học cách phân phối một phần năng lực đó vào kiến trúc và con người.

Và đây có lẽ là một trong những bài toán khó nhất của người thiết kế hệ thống.

Bởi vì để giải quyết nó, người đó phải ngừng xem khả năng của mình là lời giải mặc định cho mọi vấn đề.

Họ phải thiết kế một tổ chức ngày càng ít cần đến chính mình.

Một ý tưởng rất đẹp.

Và cũng khá khó chịu với cái tôi của người sáng lập.

13. Nhìn thấy cấu trúc không phải điểm kết thúc.

Sau nhiều năm làm việc với phần mềm và điều hành doanh nghiệp, điều khiến tôi hứng thú nhất vẫn là những khoảnh khắc một vấn đề đột nhiên trở nên rõ ràng.

Không phải khi chúng ta có thêm một báo cáo.

Không phải khi một dashboard xuất hiện thêm vài biểu đồ.

Mà là khi những sự kiện tưởng chừng rời rạc bắt đầu cho thấy một cơ chế chung.

Một sai sót trong quy trình.

Một vấn đề phân quyền.

Một biến động trong năng suất.

Một quyết định tạo ra tác dụng phụ.

Những điều trước đó được xem như các câu chuyện riêng biệt bỗng có thể được phân tích thông qua một mô hình thống nhất.

Cảm giác ấy rất thú vị.

Giống như nhìn vào một bản đồ với hàng trăm con đường chằng chịt và đột nhiên nhận ra phần lớn tình trạng ùn tắc đang được tạo ra bởi một vài nút giao quan trọng.

Nhưng tôi không cho rằng việc nhìn thấy cấu trúc là một năng lực thần bí.

Nó là kết quả của quan sát, kiến thức, khả năng nhận diện mẫu hình, tư duy trừu tượng và sự sẵn sàng liên tục kiểm chứng những giả định của mình.

Một phần có thể đến từ tố chất.

Một phần đến từ kinh nghiệm.

Một phần đến từ môi trường cho phép con người đặt câu hỏi và học từ những lần phán đoán sai.

Và có lẽ một phần đến từ sự tò mò đủ lớn để không chấp nhận những lời giải thích quá dễ dàng.

Tôi không đặc biệt hứng thú với câu trả lời:

"Vấn đề này trước giờ vẫn vậy."

Tôi muốn biết tại sao.

Tại sao nó xuất hiện?

Tại sao nó lặp lại?

Tại sao những giải pháp trước đó không hiệu quả?

Tại sao người này xử lý được nhưng người khác không?

Tại sao một thay đổi nhỏ lại tạo ra tác động lớn?

Và liệu có một nguyên lý sâu hơn giải thích được nhiều hiện tượng cùng lúc hay không?

Đôi khi câu trả lời sẽ rất đơn giản.

Đôi khi chúng ta phải xây dựng một mô hình phức tạp.

Đôi khi cần thêm dữ liệu.

Và đôi khi phải chấp nhận rằng mình chưa đủ hiểu để đưa ra kết luận.

Tôi không xem sự không chắc chắn là một thất bại.

Tôi xem nó là trạng thái bình thường của việc khám phá những hệ thống phức tạp.

Điều đáng sợ không phải là chưa có câu trả lời.

Mà là tin rằng mình đã có câu trả lời khi thực tế chưa đủ cơ sở.

Một người có khả năng connecting the dots không chỉ biết nối những điểm có liên quan. Họ còn phải có đủ kỷ luật để không nối những điểm vốn chẳng liên quan gì đến nhau.

Điều thứ hai thường khó hơn điều thứ nhất.

Bởi vì một cấu trúc đẹp có sức hấp dẫn rất lớn.

Đặc biệt khi chính mình là người phát hiện ra nó.

Lời kết: The Architect's Mind.

Tôi nghĩ sự khác biệt lớn nhất giữa người giải quyết sự kiện và người thiết kế hệ thống nằm ở cách họ đặt câu hỏi.

Một người hỏi:

"Chúng ta phải xử lý vấn đề này thế nào?"

Người khác hỏi:

"Điều gì đang khiến vấn đề này liên tục xuất hiện?"

Và một người khác nữa có thể hỏi:

"Có bao nhiêu vấn đề mà chúng ta đang xem là độc lập thực chất chỉ là những biểu hiện khác nhau của cùng một cấu trúc?"

Câu hỏi cuối cùng có thể mở ra những cách tiếp cận rất khác.

Nhưng nó cũng đi kèm một trách nhiệm lớn hơn.

Bởi vì một khi chúng ta tin rằng mình đã tìm thấy cấu trúc, những quyết định tiếp theo có thể ảnh hưởng đến hàng trăm con người, hàng nghìn giao dịch và cả hướng phát triển của doanh nghiệp.

Vì vậy, khả năng nhìn thấy quy luật phải đi cùng khả năng nghi ngờ chính quy luật mình vừa phát hiện.

Khả năng trừu tượng phải đi cùng sự tôn trọng những khác biệt thực tế.

Và khả năng thiết kế phải đi cùng trách nhiệm kiểm chứng kết quả.

Tôi không muốn trở thành người luôn có câu trả lời.

Tôi muốn trở thành người có khả năng đặt ra những câu hỏi khiến chúng ta hiểu vấn đề sâu hơn.

Nếu một trăm vấn đề xuất hiện, tôi không nhất thiết muốn tìm ra một trăm giải pháp.

Tôi muốn biết liệu chúng có thực sự là một trăm vấn đề hay không.

Có thể chúng là mười vấn đề.

Có thể chỉ là ba.

Và có thể, sau rất nhiều phân tích, chúng ta nhận ra rằng chúng thực sự độc lập và phải được xử lý riêng.

Tôi vẫn xem đó là một kết quả tốt.

Bởi vì mục tiêu không phải chứng minh rằng mọi thứ đều có liên hệ với nhau.

Mục tiêu là hiểu chính xác những mối liên hệ nào thực sự tồn tại.

Connecting the dots is not about finding connections everywhere. It is about discovering the connections that actually matter.

Và khi đã nhìn thấy những mối liên hệ đó, chúng ta có cơ hội làm một việc thú vị hơn rất nhiều so với việc tiếp tục giải quyết từng vấn đề.

Chúng ta có thể thay đổi cấu trúc tạo ra chúng.

Đó là nơi công việc thực sự bắt đầu.

Nhưng trước hết, còn một câu hỏi mà tôi nghĩ chúng ta chưa trả lời đầy đủ.

Nếu đã nhìn thấy một trăm vấn đề thực chất chỉ có chung một vài nguyên nhân, làm thế nào để chuyển hiểu biết đó thành một nguyên lý thiết kế đủ đơn giản, đủ chính xác và đủ linh hoạt để có thể tái sử dụng?

Làm thế nào để loại bỏ hàng nghìn chi tiết mà không đánh mất những khác biệt quan trọng?

Và làm thế nào để một mô hình trong đầu có thể trở thành một cấu trúc hoạt động trong thế giới thực?

Đó là bài toán của Abstraction.

Một trong những năng lực quyền lực nhất của kỹ thuật.

Và cũng là một trong những năng lực dễ bị hiểu sai nhất.

Còn nếu sau tất cả những phân tích này, bạn vẫn cho rằng mọi vấn đề trong công ty đều có chung một nguyên nhân là nhân viên quá ngu...

Tôi có một tin khá buồn.

Có thể bạn vừa bỏ qua một điểm chung quan trọng hơn nhiều.

Người tuyển dụng, phân quyền và thiết kế cách những nhân viên đó làm việc.

Và nếu người đó chính là bạn?

Chúc mừng.

Bạn vừa successfully connected the dots.

Fuck. Welcome to the club.

END OF PART I — UNDERSTANDING CHAOS

Chúng ta đã học cách nhận diện sự lặp lại, phân biệt trách nhiệm của con người và hệ thống, hiểu cái giá của những ngoại lệ và nhìn thấy cấu trúc ẩn sau những sự kiện.

Nhưng hiểu được sự hỗn loạn chỉ là bước đầu tiên.

Thử thách tiếp theo là thiết kế một trật tự có khả năng tồn tại, vận hành và tiến hóa trong thế giới thực.

NEXT — PART II: DESIGNING ORDER

CHAPTER 05 — ABSTRACTION IS A SUPERPOWER

Từ hàng trăm vấn đề đến một nguyên lý thiết kế: nghệ thuật loại bỏ sự phức tạp mà không đánh mất bản chất.

The Architect of Chaos — Ông Chú Hay Chửi