FINAL CHAPTER - Build a System That Outgrows You.

CHAPTER 12 — FINAL CHAPTER

Build a System That Outgrows You.

Đỉnh cao của người kiến trúc sư không phải xây dựng một công trình hoàn hảo. Mà là một công trình có khả năng tiếp tục tiến hóa khi những hiểu biết của người tạo ra nó không còn đủ.

Tôi muốn tưởng tượng một buổi sáng nào đó trong tương lai.

Một nhân viên bước vào phòng làm việc.

Không phải để xin phê duyệt.

Không phải để báo một sự cố.

Và cũng không phải để hỏi tôi nên xử lý tình huống thế nào.

Cô ấy nói:

"Em nghĩ cách hệ thống mình đang tư vấn cho nhóm khách hàng này chưa đúng."

Tôi hỏi tại sao.

Cô ấy mở dữ liệu.

Chỉ ra một mẫu hình trong hành vi mua hàng.

Giải thích rằng logic hiện tại đang bỏ qua một yếu tố quan trọng.

Sau đó trình bày một phương án khác.

Một bản thử nghiệm đã được xây dựng trong môi trường độc lập.

Có dữ liệu kiểm chứng ban đầu.

Có những giả định chưa chắc chắn.

Có giới hạn rủi ro.

Và có kế hoạch đánh giá trước khi đề xuất tích hợp vào hệ thống chung.

Tôi nhìn vào phương án ấy.

Nó không giống cách tôi đã thiết kế.

Thậm chí có những phần tôi chưa từng nghĩ đến.

Phản ứng đầu tiên của một Software Architect có thể là muốn xem code.

Kiểm tra dữ liệu.

Đánh giá những giả định.

Tìm những điểm có khả năng gây lỗi.

Một phản ứng hoàn toàn bình thường.

Nhưng sau đó tôi nhận ra một điều quan trọng hơn.

Tôi không phải người đầu tiên phát hiện vấn đề.

Không phải người tạo ra giả thuyết.

Không phải người thiết kế thử nghiệm.

Không phải người viết giải pháp.

Và cũng không phải người trực tiếp tổ chức toàn bộ quá trình kiểm chứng.

Một người khác đã thực hiện những công việc đó.

Trong một kiến trúc mà tôi từng góp phần xây dựng.

Nếu phương án của cô ấy thực sự tốt hơn, hệ thống có cơ chế để tiếp nhận nó.

Nếu phương án sai, hệ thống có cơ chế để phát hiện và giới hạn hậu quả.

Và quan trọng nhất, quá trình đó không cần tôi phải là người đưa ra mọi quyết định.

Tôi nghĩ đó sẽ là một khoảnh khắc rất thú vị.

Có thể tôi sẽ cảm thấy tự hào.

Có thể hơi khó chịu.

Và có thể một phần trong tôi sẽ muốn chứng minh rằng phương án cũ vẫn tốt hơn.

Dù sao, tôi cũng là người thiết kế nó.

Con người có một thói quen đáng yêu.

Chúng ta thường cảm thấy những gì mình tạo ra xứng đáng được bảo vệ.

Đặc biệt khi đã dành rất nhiều thời gian, trí tuệ và công sức để xây dựng.

Nhưng nếu tôi thực sự tin vào những nguyên lý đã theo đuổi trong cuốn sách này, tôi phải chấp nhận một điều.

Một kiến trúc tốt không được yêu cầu tương lai phải tiếp tục đồng ý với người đã thiết kế ra nó.

Nếu hệ thống chỉ có thể tiến hóa theo những hướng mà tôi đã dự đoán, nó chưa thực sự phát triển vượt khỏi tôi.

Nó chỉ đang tiếp tục thực hiện những ý tưởng cũ, với nhiều nhân viên và phần mềm hơn.

Tôi muốn một điều khó hơn.

Một tổ chức có khả năng khám phá những điều tôi chưa biết.

Và đủ năng lực để chứng minh khi tôi đã sai.

01. Một hệ thống hoạt động không cần founder chưa chắc đã vượt qua founder.

Hãy tưởng tượng một doanh nghiệp có khả năng vận hành ổn định khi người sáng lập không có mặt.

Đơn hàng vẫn được xử lý.

Khách hàng vẫn được phục vụ.

Kho vẫn chuẩn bị hàng.

Vận chuyển vẫn hoạt động.

Tài chính vẫn được kiểm soát.

Và nhân viên có khả năng giải quyết phần lớn những tình huống thường ngày.

Đây là một thành tựu quan trọng.

Tôi không muốn xem nhẹ nó.

Rất nhiều doanh nghiệp chưa đạt đến mức độ độc lập như vậy.

Nhưng tôi nghĩ nó mới chỉ trả lời một câu hỏi.

Liệu tổ chức có thể tiếp tục thực hiện những điều đã được thiết kế hay không?

Nó chưa trả lời câu hỏi thứ hai.

Liệu tổ chức có thể nhận ra khi những điều đã được thiết kế không còn phù hợp?

Và càng chưa trả lời câu hỏi thứ ba.

Liệu tổ chức có khả năng tạo ra một cấu trúc mới tốt hơn cấu trúc hiện tại?

Tôi muốn phân biệt ba cấp độ trưởng thành.

Operational Continuity — Khả năng duy trì hoạt động.

Tổ chức tiếp tục thực hiện đáng tin cậy những công việc đã được hiểu rõ.

Adaptive Capability — Khả năng thích nghi.

Tổ chức nhận diện những thay đổi trong thực tế và điều chỉnh những quy trình, chính sách hoặc phương pháp trong phạm vi trách nhiệm.

Generative Capability — Khả năng tạo ra năng lực mới.

Tổ chức có thể phát hiện những vấn đề chưa được mô hình hóa, tạo ra giải pháp, kiểm chứng và chuyển những hiểu biết mới thành năng lực có thể tái sử dụng.

Ba cấp độ này không hoàn toàn tách biệt.

Nhưng chúng đòi hỏi những loại năng lực khác nhau.

Một doanh nghiệp có thể rất tốt ở cấp độ thứ nhất.

Mọi thứ vận hành ổn định.

Quy trình rõ ràng.

Nhân viên thực hiện chính xác.

Nhưng khi thị trường thay đổi, tổ chức có thể gặp khó khăn vì những cơ chế hiện tại không còn phù hợp.

Một doanh nghiệp khác có thể thích nghi tốt với những thay đổi đã nhận diện.

Nhưng vẫn phụ thuộc vào một nhóm nhỏ những người có khả năng tạo ra abstraction mới.

Và một tổ chức trưởng thành hơn có thể bắt đầu phân phối khả năng khám phá, thiết kế và phát triển năng lực tới nhiều con người.

Đây mới là cấp độ tôi muốn hướng đến.

A system that survives without its architect is resilient. A system that improves beyond its architect is evolutionary.

Khả năng tồn tại mà không cần người thiết kế là một dạng bền vững.

Khả năng tiếp tục cải thiện vượt khỏi hiểu biết của người thiết kế là một dạng tiến hóa.

Tôi không muốn nhầm lẫn hai thứ đó.

Bởi vì một doanh nghiệp có thể hoạt động rất tốt hôm nay.

Và vẫn trở nên lỗi thời vào ngày mai.

Nếu nó không còn khả năng đặt câu hỏi về chính những nguyên tắc đã khiến nó thành công.

02. Di sản nguy hiểm nhất của founder có thể là những nguyên lý từng rất đúng.

Một quyết định sai thường dễ bị chất vấn.

Nó tạo ra hậu quả.

Nhân viên phàn nàn.

Khách hàng phản ứng.

Báo cáo xuất hiện vấn đề.

Và tổ chức có động lực tìm cách thay đổi.

Nhưng một quyết định từng rất đúng lại có một sức mạnh đặc biệt.

Nó được chứng minh bằng thành công.

Nó tạo ra kết quả.

Nó được mọi người ghi nhớ.

Sau đó trở thành quy trình.

Rồi thành chính sách.

Cuối cùng trở thành một nguyên tắc mà không ai còn thấy cần phải đặt câu hỏi.

"Trước giờ công ty mình làm vậy."

Một câu nói tưởng như vô hại.

Nhưng tôi luôn thấy nó đáng để suy nghĩ.

Bởi vì mọi nguyên lý kinh doanh đều được hình thành trong một bối cảnh.

Một chính sách giá có thể phù hợp với cấu trúc lợi nhuận ở một giai đoạn.

Một quy trình giao hàng có thể tối ưu khi phạm vi phục vụ còn nhỏ.

Một cách phân chia trách nhiệm có thể hiệu quả khi doanh nghiệp có mười nhân viên.

Một cơ chế phân quyền có thể hợp lý khi đội ngũ chưa có nhiều kinh nghiệm.

Và một kiến trúc phần mềm có thể rất phù hợp với những nhu cầu đã được xác định.

Nhưng các điều kiện ấy có thể thay đổi.

Khách hàng thay đổi.

Cấu trúc chi phí thay đổi.

Nhân sự trưởng thành.

Sản phẩm phát triển.

Và những công nghệ mới tạo ra những khả năng trước đây chưa từng tồn tại.

Nếu hệ thống tiếp tục bảo vệ những quy tắc cũ chỉ vì chúng từng đúng, nó có thể dần trở thành một rào cản.

Điều nguy hiểm là những người đang duy trì rào cản ấy có thể hoàn toàn tin rằng mình đang bảo vệ doanh nghiệp.

Họ không cố tình chống lại sự thay đổi.

Họ chỉ đang thực thi những nguyên tắc đã được chứng minh.

Yesterday's successful abstraction can become tomorrow's structural constraint.

Một abstraction từng tạo ra lợi thế có thể trở thành giới hạn của tương lai.

Tôi nghĩ đây là một trách nhiệm quan trọng của người thiết kế.

Không chỉ xây dựng những nguyên lý đúng.

Mà phải thiết kế cơ chế để chúng có thể bị đánh giá lại.

Một số ràng buộc mang tính nền tảng cần được bảo vệ rất chặt chẽ.

Nhưng nhiều chính sách kinh doanh chỉ là những giải pháp phù hợp với điều kiện tại một thời điểm.

Chúng không nên được đối xử như chân lý vĩnh cửu.

Tôi muốn tổ chức có khả năng phân biệt.

Điều gì là một nguyên tắc bảo vệ bắt buộc?

Điều gì là chính sách có thể thay đổi?

Điều gì chỉ là một giả thuyết đang được thử nghiệm?

Và điều gì đã trở thành thói quen mà không còn ai nhớ lý do tồn tại?

Nếu không phân biệt được, chúng ta có thể xây dựng một hệ thống rất nhất quán.

Nhưng nhất quán trong việc bảo vệ quá khứ.

03. Doanh nghiệp cần hai loại hệ thống: một để vận hành, một để thay đổi cách vận hành.

Trong những chương trước, tôi đã bàn nhiều về Business Operating System.

Dữ liệu chung.

Quyền hạn rõ ràng.

Ràng buộc được thực thi.

Workflow phản ánh những cam kết kinh doanh.

Và khả năng quan sát kết quả.

Những thành phần ấy giúp tổ chức vận hành đáng tin cậy.

Nhưng nếu muốn phát triển vượt khỏi thiết kế ban đầu, chúng ta cần một năng lực khác.

Khả năng thay đổi chính Business Operating System.

Không phải bằng những quyết định tùy hứng.

Mà thông qua một cơ chế có thể kiểm chứng.

Tôi thích nghĩ đến hai vòng hoạt động.

Vòng thứ nhất là Operational Loop.

Một yêu cầu xuất hiện.

Hệ thống nhận diện tình huống.

Áp dụng những quy tắc phù hợp.

Thực hiện hành động.

Và ghi nhận kết quả.

Vòng này cần tốc độ, tính nhất quán và độ tin cậy.

Vòng thứ hai là Evolutionary Loop.

Tổ chức quan sát những kết quả.

Nhận diện những trường hợp mà mô hình hiện tại chưa giải thích được.

Đưa ra giả thuyết.

Thiết kế cách kiểm chứng.

Thử nghiệm trong phạm vi phù hợp.

Và nếu có bằng chứng đủ tốt, cập nhật những năng lực hoặc nguyên tắc đang được sử dụng.

Vòng này cần khả năng phân tích, phản biện, thử nghiệm và học hỏi.

Hai vòng hoạt động với những nhịp độ khác nhau.

Một đơn hàng không thể chờ chúng ta hoàn thành một cuộc nghiên cứu về kiến trúc.

Nhưng một chính sách kinh doanh quan trọng cũng không nên bị thay đổi chỉ vì một giao dịch bất thường vừa xuất hiện.

Nếu trộn lẫn hai vòng, chúng ta có thể tạo ra sự hỗn loạn.

Một nhân viên gặp ngoại lệ.

Quy trình lập tức được sửa.

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

Chính sách lập tức thay đổi.

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

Hệ thống lập tức tối ưu lại.

Cuối cùng, tổ chức liên tục thay đổi những điều kiện mà chính nó đang cố gắng vận hành.

Tôi muốn một kiến trúc khác.

Run the business through stable rules. Evolve the business through controlled learning.

Vận hành bằng những cơ chế đủ ổn định.

Tiến hóa bằng quá trình học hỏi có kiểm soát.

Hai vòng phải kết nối với nhau.

Nhưng không nên thay thế nhau.

Nếu chỉ có vòng vận hành, doanh nghiệp có thể ổn định nhưng chậm thích nghi.

Nếu chỉ có vòng tiến hóa, tổ chức có thể đầy ý tưởng nhưng thiếu khả năng tạo ra kết quả đáng tin cậy.

Tôi muốn cả hai.

Bởi vì một hệ thống chỉ biết thực thi sẽ dần lỗi thời.

Còn một hệ thống chỉ biết thay đổi sẽ không bao giờ đủ ổn định để tạo ra giá trị lâu dài.

04. Muốn tổ chức biết học, trước hết phải cho nó biết mình chưa hiểu điều gì.

Tôi nghĩ có một vấn đề khá tinh vi trong cách nhiều doanh nghiệp quản lý thông tin.

Chúng ta rất thích ghi nhận những điều đã được xác định.

Đơn hàng đã hoàn thành.

Doanh thu đã ghi nhận.

Khách hàng đã được phân loại.

Sản phẩm đã có thuộc tính.

Quy trình đã được phê duyệt.

Và những quyết định đã được đưa ra.

Nhưng có một loại thông tin khác cũng rất quan trọng.

Những điều tổ chức chưa chắc chắn.

Một nhân viên nghi ngờ dữ liệu sản phẩm chưa chính xác.

Một người quản lý nhận thấy chính sách hiện tại có thể đang tạo ra tác dụng phụ.

Một nhân viên tư vấn phát hiện những trường hợp khách hàng có hành vi không phù hợp với mô hình hiện tại.

Một chuyên gia nhận ra một giả định kỹ thuật cần được kiểm chứng lại.

Những tín hiệu ấy thường được trao đổi bằng lời.

Trong tin nhắn.

Trong cuộc họp.

Hoặc trong những lần nhân viên hỏi quản lý.

Sau đó chúng có thể biến mất.

Không nhất thiết vì chúng không quan trọng.

Mà vì tổ chức chưa có một cách rõ ràng để biến những nghi ngờ có cơ sở thành đối tượng cần nghiên cứu.

Tôi muốn một cơ chế có thể ghi nhận sự không chắc chắn một cách có cấu trúc.

Không phải biến mọi nghi ngờ thành task.

Cũng không phải mở một hệ thống quản lý hàng nghìn ý tưởng mà không ai đọc.

Tôi muốn phân biệt.

Điều gì thực sự đã được quan sát?

Điều gì chỉ là giả thuyết?

Bằng chứng hiện tại là gì?

Những yếu tố nào chưa được hiểu?

Nếu giả thuyết đúng, tác động có thể lớn đến đâu?

Và ai có đủ chuyên môn để tiếp tục đánh giá?

Tôi thích một cấu trúc rất đơn giản cho những phát hiện quan trọng.

Observation — Chúng ta thực sự nhìn thấy điều gì?

Hypothesis — Chúng ta nghĩ cơ chế nào đã tạo ra hiện tượng ấy?

Prediction — Nếu giả thuyết đúng, chúng ta kỳ vọng điều gì?

Test — Làm sao kiểm chứng với chi phí và rủi ro phù hợp?

Decision — Kết quả nào đủ để giữ nguyên, sửa đổi hoặc loại bỏ giả thuyết?

Đây không phải một mẫu biểu bắt buộc cho mọi công việc.

Nó là một phương pháp tư duy.

Điều quan trọng không phải nhân viên điền đủ năm ô.

Mà là họ học cách phân biệt sự kiện với cách diễn giải.

Và phân biệt một ý tưởng thú vị với một giả thuyết có thể kiểm chứng.

An organization that cannot represent uncertainty cannot systematically learn from it.

Một tổ chức chỉ lưu trữ những kết luận mà không lưu được những câu hỏi quan trọng có thể trở nên rất giỏi thực thi.

Nhưng không nhất thiết giỏi học hỏi.

Tôi muốn những người có năng lực bắt đầu nhìn thấy không chỉ điều hệ thống đang biết.

Mà cả những nơi hệ thống có thể chưa hiểu đúng thực tế.

Đó là nơi những abstraction mới thường bắt đầu.

05. Một ví dụ nhỏ: khi dữ liệu đúng nhưng ý nghĩa bị hiểu sai.

Hãy tưởng tượng một doanh nghiệp phân phối bao bì có hệ thống gợi ý sản phẩm đi kèm.

Khách hàng chọn một loại ly.

Hệ thống phân tích dữ liệu giao dịch và đề xuất những sản phẩm thường được mua cùng.

Trong danh sách xuất hiện các loại nắp, ống hút và những loại ly khác.

Một nhân viên nhìn vào và nhận xét:

"Những loại nắp này có kích thước khác với chiếc ly đang được xem."

Một người khác có thể kết luận hệ thống gợi ý sai.

Nhưng tôi không muốn vội kết luận như vậy.

Bởi vì một quán có thể mua nhiều loại ly với nhiều kích thước trong cùng một đơn hàng.

Họ có thể cần những loại nắp khác nhau cho những loại ly khác nhau.

Một sản phẩm được mua cùng không nhất thiết phải là phụ kiện lắp trực tiếp vào sản phẩm đang được xem.

Vấn đề thực sự có thể nằm ở cách chúng ta diễn giải quan hệ dữ liệu.

Frequently Bought Together không đồng nghĩa với Physically Compatible.

Hai loại quan hệ hoàn toàn khác nhau.

Một quan hệ được xác định từ hành vi mua hàng.

Quan hệ còn lại đòi hỏi những điều kiện về cấu trúc hoặc kỹ thuật của sản phẩm.

Nếu hệ thống dùng dữ liệu mua cùng để tuyên bố hai sản phẩm tương thích, đó có thể là một lỗi về ngữ nghĩa.

Nhưng nếu nó dùng dữ liệu mua cùng để gợi ý những sản phẩm mà khách thường cần bổ sung vào giỏ hàng, một loại nắp có kích thước khác chưa chắc là gợi ý sai.

Chúng ta cần xem xét mục đích của tính năng.

Không chỉ nhìn vào bề ngoài của kết quả.

Tôi thích ví dụ này vì nó cho thấy một vấn đề quan trọng.

Dữ liệu có thể chính xác nhưng abstraction dùng để diễn giải dữ liệu vẫn có thể sai.

Và một tổ chức biết học phải có khả năng phân biệt hai thứ ấy.

Một nhân viên có kiến thức sản phẩm sâu có thể nhận ra một quan hệ kỹ thuật chưa phù hợp.

Một người phụ trách dữ liệu có thể giải thích rằng quan hệ đang được tính từ lịch sử mua hàng.

Một người thiết kế sản phẩm có thể xác định những loại đề xuất nào cần được tách riêng trong giao diện.

Và một người có trách nhiệm kinh doanh có thể đánh giá cách hiển thị nào thực sự giúp khách hàng lựa chọn tốt hơn.

Không nhất thiết cần founder trực tiếp kết nối mọi thông tin.

Điều cần có là một cơ chế giúp những hiểu biết khác nhau gặp nhau đúng chỗ.

Nếu một nhân viên phát hiện một vấn đề, họ phải có khả năng đưa ra bằng chứng.

Nếu một mô hình bị chất vấn, người phụ trách phải có khả năng giải thích.

Nếu cần thay đổi, phải có người sở hữu quyết định.

Và nếu kết quả được kiểm chứng, hiểu biết mới có thể được chuyển thành năng lực chung.

Đây là một ví dụ nhỏ.

Nhưng nguyên lý của nó có thể áp dụng ở nhiều nơi.

Giá bán.

Chi phí giao hàng.

Phân loại khách hàng.

Chính sách công nợ.

Gợi ý sản phẩm.

Và những mô hình AI đang được sử dụng trong doanh nghiệp.

Tổ chức không thể trưởng thành nếu chỉ người thiết kế ban đầu mới có quyền quyết định rằng mô hình của mình đang sai.

A mature system must allow reality to challenge its abstractions — regardless of who created them.

Đây là một điều kiện quan trọng để hệ thống có thể vượt qua người kiến trúc sư ban đầu.

06. Không phải ai cũng phải biết tạo abstraction mới.

Tôi muốn tránh một sự lạc quan thiếu thực tế.

Nếu mục tiêu là tổ chức có khả năng tiếp tục phát triển, liệu chúng ta có cần đào tạo mọi nhân viên thành người có tư duy kiến trúc?

Không.

Tôi không nghĩ điều đó cần thiết.

Và cũng không nghĩ nó khả thi.

Con người có những khác biệt có thật về năng lực nhận thức, kiến thức, kinh nghiệm và động lực.

Một số người rất giỏi thực hiện những công việc có cấu trúc.

Một số người rất giỏi xây dựng quan hệ khách hàng.

Một số có chuyên môn sâu về một lĩnh vực.

Một số có khả năng tổ chức và phát triển con người.

Và một số có khả năng nhận diện những mẫu hình trừu tượng, kết nối nhiều lĩnh vực rồi thiết kế cơ chế mới.

Tôi không muốn biến tất cả thành cùng một loại người.

Một tổ chức có thể học hỏi tốt khi những loại năng lực ấy được kết nối.

Người làm việc trực tiếp phát hiện những tín hiệu.

Người có chuyên môn giải thích những giới hạn thực tế.

Người có khả năng phân tích đưa ra giả thuyết.

Người có năng lực thiết kế chuyển những giả thuyết phù hợp thành cơ chế.

Người vận hành kiểm chứng khả năng thực thi.

Và người chịu trách nhiệm kinh doanh đánh giá giá trị của thay đổi.

Không nhất thiết mỗi vai trò phải thuộc về một người riêng biệt.

Nhưng chúng ta cần nhận ra đó là những loại đóng góp khác nhau.

Distributed intelligence does not require identical intelligence. It requires complementary capabilities connected by a learning architecture.

Trí tuệ phân tán không có nghĩa mọi người đều phải có khả năng giống nhau.

Nó có nghĩa tổ chức biết kết nối những năng lực khác nhau thành một quá trình tạo ra hiểu biết mới.

Đây là một nguyên lý mà tôi nghĩ rất quan trọng.

Bởi vì nếu chỉ tìm thêm những người có khả năng abstraction như founder, doanh nghiệp có thể bị giới hạn bởi một nguồn lực rất khan hiếm.

Nhưng nếu xây dựng được cơ chế khiến nhiều người có thể đóng góp một phần vào quá trình học hỏi, chúng ta có thể giảm mức độ phụ thuộc vào một cá nhân mà không cần nhân bản chính cá nhân đó.

Tôi không cần một nhân viên kho phải tự thiết kế toàn bộ hệ thống logistics.

Nhưng tôi muốn người đó có khả năng phát hiện khi quy trình thực tế không phù hợp với những giả định của hệ thống.

Tôi không cần một nhân viên bán hàng phải hiểu toàn bộ Business Operating System.

Nhưng tôi muốn họ có khả năng đặt câu hỏi khi dữ liệu hoặc chính sách đang tạo ra một kết quả bất hợp lý.

Tôi không cần một designer phải trở thành CEO.

Nhưng tôi muốn họ đủ hiểu khách hàng để phản biện một phương án thiết kế không phù hợp với đối tượng sử dụng.

Và tôi muốn những người có khả năng kết nối các tín hiệu đó có cơ hội phát triển thành những người thiết kế, chuyên gia hoặc lãnh đạo trong phạm vi phù hợp.

Đây là một cách phân phối năng lực thực tế hơn rất nhiều so với việc yêu cầu tất cả phải trở thành thiên tài.

07. Đừng tìm một người kế thừa toàn bộ bộ não founder.

Khi người sáng lập bắt đầu trở thành nút thắt, câu hỏi thường xuất hiện là:

"Ai có thể thay thế anh ta?"

Tôi nghĩ cách đặt câu hỏi đó có thể khiến chúng ta đi sai hướng.

Bởi vì năng lực của một founder thường hình thành từ một tổ hợp rất đặc biệt.

Kiến thức kỹ thuật.

Kinh nghiệm kinh doanh.

Hiểu biết thị trường.

Những quyết định đã từng đưa ra.

Các sai lầm đã trải qua.

Và khả năng kết nối những yếu tố ấy thành một mô hình tổng thể.

Tìm một người có cùng tổ hợp năng lực có thể rất khó.

Ngay cả khi tìm được, người đó chưa chắc phù hợp với vai trò mà doanh nghiệp thực sự đang thiếu.

Tôi thích một cách tiếp cận khác.

Decompose the founder's role.

Phân rã vai trò của người sáng lập.

Những trách nhiệm nào thực sự cần năng lực chiến lược?

Những hoạt động nào cần khả năng vận hành?

Những quyết định nào có thể được chuyển thành chính sách?

Những vấn đề kỹ thuật nào nên thuộc về người có chuyên môn?

Những hoạt động phát triển con người nào cần một người lãnh đạo phù hợp?

Và những năng lực kiến trúc nào cần được phát triển ở nhiều người theo thời gian?

Khi phân tích như vậy, chúng ta có thể phát hiện một điều thú vị.

Không nhất thiết phải có một người thay thế founder.

Có thể cần một hệ thống mới để phân phối những trách nhiệm trước đây tập trung vào founder.

Một người phụ trách vận hành thực sự sở hữu kết quả của hoạt động thường ngày.

Những người có chuyên môn sâu chịu trách nhiệm về các lĩnh vực cụ thể.

Những người phát triển sản phẩm chịu trách nhiệm về những năng lực mới.

Những cơ chế kiểm soát quan trọng được thực thi bởi nền tảng.

Và founder tiếp tục chịu trách nhiệm về những lựa chọn chiến lược, những nguyên lý cốt lõi và những thay đổi kiến trúc vượt khỏi phạm vi đã được phân quyền.

Theo thời gian, một số người có thể phát triển đủ năng lực để tiếp nhận thêm những trách nhiệm phức tạp.

Không phải mọi thứ cần được chuyển giao cùng lúc.

Và không phải mọi quyết định đều nên được phân tán.

Điểm quan trọng là giảm sự phụ thuộc một cách có chủ đích.

Succession is not always replacing a person. Sometimes it is redesigning the system so the person's responsibilities no longer need to reside in one place.

Tôi nghĩ đây là một cách hiểu quan trọng.

Bởi vì nếu doanh nghiệp chỉ tìm một người có thể làm mọi thứ giống founder, nó có thể dành nhiều năm theo đuổi một điều kiện không thực tế.

Trong khi những phần công việc có thể được phân quyền và hệ thống hóa vẫn tiếp tục phụ thuộc vào founder.

Tôi không muốn như vậy.

Tôi muốn kiến trúc thay đổi trước khi sự phụ thuộc trở thành một cuộc khủng hoảng.

08. Phân quyền không có nghĩa tạo ra nhiều trung tâm quyền lực không rõ ràng.

Có một rủi ro khác khi tổ chức phát triển nhiều người có năng lực.

Những người đó bắt đầu có quan điểm riêng.

Phương pháp riêng.

Và đôi khi những lợi ích khác nhau.

Một người phụ trách vận hành muốn bảo đảm tính ổn định.

Một người phát triển sản phẩm muốn thay đổi nhanh hơn.

Một nhóm kinh doanh muốn linh hoạt về chính sách.

Bộ phận tài chính muốn kiểm soát rủi ro.

Và nhóm kỹ thuật muốn bảo vệ tính nhất quán của hệ thống.

Tất cả đều có lý do hợp lý.

Nhưng nếu không có kiến trúc quyền hạn rõ ràng, sự phân tán năng lực có thể trở thành sự phân tán quyền quyết định một cách hỗn loạn.

Tôi không muốn doanh nghiệp phải đạt đồng thuận tuyệt đối cho mọi thay đổi.

Một hệ thống như vậy có thể rất chậm.

Nhưng tôi cũng không muốn mọi khác biệt đều phải được đưa đến CEO.

Điều đó sẽ tái tạo chính nút thắt mà chúng ta đang cố gắng giải quyết.

Tôi nghĩ phải thiết kế quyền quyết định theo phạm vi ảnh hưởng.

Một quyết định chỉ ảnh hưởng đến phương pháp làm việc trong một nhóm có thể được xử lý trong nhóm đó, nếu nằm trong quyền hạn và ràng buộc đã được thống nhất.

Một thay đổi ảnh hưởng đến capability chung cần người chịu trách nhiệm về capability đó tham gia.

Một thay đổi chính sách thương mại có thể cần thẩm quyền kinh doanh và tài chính tương ứng.

Một thay đổi kiến trúc có ảnh hưởng rộng cần được đánh giá ở cấp có đủ trách nhiệm đối với toàn hệ thống.

Và những lựa chọn chiến lược lớn vẫn cần một cơ chế quyết định cuối cùng rõ ràng.

Không phải ai cũng có quyền phủ quyết mọi thứ.

Nhưng những người có thông tin liên quan phải có cơ hội cung cấp thông tin và phản biện trước khi quyết định được đưa ra, tương xứng với mức độ rủi ro.

Distributed ownership requires explicit decision rights. Otherwise, autonomy becomes political negotiation.

Một tổ chức không thể phát triển tốt nếu quyền hạn chỉ được xác định bằng mức độ thân thiết với founder.

Hoặc bằng khả năng tranh luận mạnh hơn người khác.

Hoặc bằng việc ai gửi tin nhắn trước.

Tôi muốn quyền quyết định tồn tại trong cấu trúc.

Không phải trong những cuộc đấu quyền lực không chính thức.

Và tôi muốn người lãnh đạo có khả năng bảo vệ những ranh giới ấy.

Ngay cả khi bản thân họ có thể trực tiếp giải quyết vấn đề nhanh hơn.

Bởi vì nếu CEO liên tục đi vòng qua những người được giao trách nhiệm, tổ chức sẽ học được rằng quyền hạn chính thức chỉ có giá trị cho đến khi CEO xuất hiện.

Một cơ chế khá hiệu quả để phá hủy khả năng tự chủ.

09. Một tổ chức biết học phải có quyền sửa cả những guardrails của mình.

Trong Chapter 6, tôi đã nói rằng guardrails tạo ra nền tảng cho sự tự do.

Chúng bảo vệ những ràng buộc quan trọng.

Cho phép con người tự chủ trong phạm vi an toàn.

Và giảm nhu cầu can thiệp trực tiếp của người quản lý.

Nhưng có một vấn đề.

Guardrails cũng có thể trở nên lỗi thời.

Một giới hạn chiết khấu có thể không còn phản ánh đúng cấu trúc lợi nhuận.

Một cơ chế phân quyền có thể quá hẹp khi đội ngũ đã phát triển năng lực.

Một chính sách phân bổ khách hàng có thể cần được điều chỉnh khi mô hình kinh doanh thay đổi.

Một quy tắc gợi ý sản phẩm có thể không còn phù hợp với dữ liệu mới.

Nếu không có quyền sửa guardrails, Freedom to Build cuối cùng vẫn bị giới hạn bởi những giả định ban đầu của founder.

Nhưng nếu ai cũng có thể sửa guardrails, hệ thống sẽ mất ý nghĩa bảo vệ.

Vì vậy, cần một lớp quản trị khác.

Governance of Governance.

Không chỉ xác định quy tắc nào đang được áp dụng.

Mà xác định ai có quyền đề xuất, kiểm chứng, phê duyệt và triển khai thay đổi đối với những quy tắc đó.

Một nhân viên có thể phát hiện một chính sách không phù hợp.

Họ không nhất thiết có quyền trực tiếp sửa chính sách.

Nhưng phải có một con đường hợp lệ để đưa phát hiện ấy vào quá trình đánh giá.

Người phụ trách chính sách cần có trách nhiệm xem xét.

Những giả định quan trọng cần được kiểm chứng.

Và nếu thay đổi được chấp thuận, hệ thống phải có khả năng triển khai và theo dõi kết quả.

Tôi thích nghĩ về những chính sách quan trọng như những thành phần có phiên bản.

Chúng có người sở hữu.

Có phạm vi áp dụng.

Có lý do tồn tại.

Có lịch sử thay đổi.

Và có những điều kiện để được đánh giá lại.

Không phải mọi quy định đều cần một hệ thống quản trị phức tạp.

Mức kiểm soát phải tương xứng với tác động.

Nhưng những cơ chế có khả năng ảnh hưởng đến hàng nghìn giao dịch không nên được sửa tùy tiện.

Cũng không nên tồn tại vĩnh viễn chỉ vì người viết chúng là founder.

A self-evolving organization must be able to change its rules without abandoning the principles that make change safe.

Tôi không nghĩ một hệ thống có thể tự động xác định mọi thay đổi đúng.

Cuối cùng vẫn cần con người phán đoán.

Nhưng nếu trách nhiệm và quy trình đã rõ, những thay đổi ấy không nhất thiết phải phụ thuộc vào một người duy nhất.

Đó là một bước tiến rất quan trọng.

Từ hệ thống thực thi những quy tắc do founder tạo ra.

Sang hệ thống có khả năng tiếp nhận và kiểm chứng những quy tắc mới do nhiều người đóng góp.

10. Những cơ chế học hỏi cũng có thể trở thành quan liêu.

Tôi muốn tự phản biện một chút.

Sau khi đọc những điều vừa viết, một người có thể đề xuất xây dựng cả một hệ thống rất hoành tráng.

Mọi ý tưởng phải có hồ sơ.

Mọi giả thuyết phải có tài liệu.

Mọi thay đổi phải có hội đồng.

Mọi thử nghiệm phải có báo cáo.

Mọi quyết định phải được ghi nhận.

Và mọi cơ chế phải được đánh giá định kỳ.

Nghe rất chuyên nghiệp.

Nhưng tôi không chắc đó là điều mình muốn.

Bởi vì một tổ chức có thể trở nên quan liêu chính trong quá trình cố gắng xây dựng khả năng học hỏi.

Những người có ý tưởng tốt bắt đầu phải dành nhiều thời gian chuẩn bị tài liệu hơn là thử nghiệm.

Những quyết định rủi ro thấp bị trì hoãn vì không đủ chữ ký.

Những thay đổi nhỏ trở thành dự án.

Và cơ chế cải tiến bắt đầu cần thêm một cơ chế cải tiến khác để cải tiến chính nó.

Tôi đã từng thấy dạng phức tạp này trong phần mềm.

Framework được xây dựng để giúp phát triển nhanh hơn.

Sau đó framework trở nên quá phức tạp.

Chúng ta xây thêm công cụ để quản lý framework.

Rồi viết tài liệu để giải thích cách sử dụng công cụ quản lý framework.

Cuối cùng, việc phát triển một chức năng đơn giản đòi hỏi phải hiểu cả một hệ sinh thái.

Một thành tựu khá ấn tượng về khả năng tạo công ăn việc làm cho Software Engineer.

Nhưng tôi không nghĩ doanh nghiệp cần tái tạo nó ở cấp tổ chức.

Tôi muốn những cơ chế học hỏi nhẹ tương xứng với mức độ rủi ro và tác động.

Một thử nghiệm nhỏ, có thể đảo ngược, không ảnh hưởng đến dữ liệu hoặc cam kết quan trọng, có thể được thực hiện tương đối nhanh.

Một thay đổi chính sách có phạm vi ảnh hưởng rộng cần đánh giá chặt chẽ hơn.

Một ý tưởng chưa đủ cơ sở có thể được ghi nhận để theo dõi, không nhất thiết phải lập tức triển khai.

Và một hiện tượng chỉ là biến động ngẫu nhiên có thể được bỏ qua.

Learning architecture must reduce the cost of learning, not turn learning into another bureaucracy.

Tôi nghĩ đây là một điểm cân bằng khó.

Nếu quá ít cấu trúc, tổ chức không giữ lại được tri thức.

Nếu quá nhiều cấu trúc, quá trình học hỏi trở nên chậm và tốn kém.

Một kiến trúc tốt phải biết phần nào cần được ghi nhận, kiểm chứng và quản lý.

Và phần nào nên được để cho con người tự xử lý trong phạm vi trách nhiệm của họ.

Không phải mọi suy nghĩ đều cần một ticket.

Không phải mọi giả thuyết đều cần một dashboard.

Và chắc chắn không phải mọi ý tưởng xuất hiện lúc 11 giờ đêm của founder đều xứng đáng trở thành một dự án bắt đầu lúc 8 giờ sáng hôm sau.

Dù phải thừa nhận rằng người viết những dòng này có thể chính là đối tượng cần được nhắc nhở thường xuyên nhất.

11. Khi một nút thắt biến mất, nút thắt khác sẽ xuất hiện.

Tôi không muốn kết thúc cuốn sách bằng ảo tưởng rằng một kiến trúc tổ chức tốt có thể loại bỏ mọi giới hạn tăng trưởng.

Không có hệ thống nào làm được điều đó.

Một doanh nghiệp có thể giải quyết được sự phụ thuộc vào founder trong việc tạo phần mềm.

Nhưng rồi phát hiện năng lực kho bãi chưa đáp ứng tốc độ tăng trưởng.

Có thể mở rộng kho.

Nhưng hệ thống vận chuyển chưa đủ công suất.

Có thể phát triển logistics.

Nhưng vốn lưu động trở thành giới hạn.

Có thể giải quyết tài chính.

Nhưng năng lực phát triển đội ngũ quản lý chưa theo kịp.

Và khi những vấn đề đó được cải thiện, một nhóm ràng buộc mới có thể xuất hiện.

Đây không nhất thiết là dấu hiệu thất bại.

Nó là một phần tự nhiên của quá trình phát triển.

Growth does not eliminate constraints. It changes which constraints matter most.

Tôi không muốn một tổ chức không bao giờ gặp vấn đề.

Tôi muốn một tổ chức có khả năng nhận diện giới hạn mới đủ sớm, hiểu đúng bản chất và phân bổ nguồn lực để giải quyết.

Đây là sự khác biệt giữa việc liên tục phản ứng với những sự cố và chủ động phát triển năng lực.

Nếu doanh nghiệp tăng số đơn hàng nhưng kho không đủ khả năng xử lý, chúng ta có một vấn đề công suất thực tế.

Không phải mọi vấn đề công suất đều cần AI.

Không phải mọi giới hạn logistics đều có thể giải quyết bằng thuật toán.

Một chiếc xe tải vẫn phải chạy qua đường.

Một kho hàng vẫn cần không gian vật lý.

Và một nhân viên vẫn cần thời gian để phát triển năng lực.

Phần mềm không loại bỏ được những giới hạn đó.

Nhưng một kiến trúc vận hành tốt có thể giúp tổ chức nhìn thấy chúng rõ hơn.

Dự báo tốt hơn.

Phân bổ nguồn lực hợp lý hơn.

Giảm những sai sót không cần thiết.

Và tránh sử dụng những người có năng lực đặc biệt để liên tục giải quyết những vấn đề đã có thể được hệ thống hóa.

Tôi nghĩ đây là mục tiêu thực tế hơn rất nhiều.

Không phải một doanh nghiệp tăng trưởng vô hạn mà không gặp trở ngại.

Mà là một doanh nghiệp có khả năng học và thay đổi cấu trúc khi giới hạn tăng trưởng di chuyển.

A scalable organization is not one without bottlenecks. It is one that can repeatedly recognize and redesign around them.

Người sáng lập có thể là nút thắt hôm nay.

Ngày mai có thể là kho.

Ngày kia có thể là năng lực quản lý.

Và vài năm sau, có thể là một mô hình kinh doanh đã không còn phù hợp.

Tôi không muốn dành cả đời để giải quyết từng giới hạn bằng khả năng cá nhân.

Tôi muốn xây dựng một tổ chức có khả năng ngày càng tự tham gia vào quá trình ấy.

12. Compounding Capability — Khi tri thức không còn phải được khám phá lại từ đầu.

Có một điều khiến tôi thấy đặc biệt hứng thú với kiến trúc tổ chức.

Khả năng tích lũy năng lực qua thời gian.

Một nhân viên phát hiện một vấn đề.

Tổ chức hiểu nguyên nhân.

Một quy tắc hoặc công cụ mới được tạo ra.

Những người khác sử dụng.

Sau đó, có người phát hiện một vấn đề ở cấp độ cao hơn.

Họ không cần giải quyết lại những điều đã được hiểu.

Họ xây dựng dựa trên năng lực đã tồn tại.

Một công cụ tư vấn sản phẩm có thể sử dụng dữ liệu sản phẩm chung.

Một micro-product mới có thể sử dụng cùng capability tạo giỏ hàng.

Một nhóm kinh doanh mới có thể sử dụng những cơ chế kiểm soát tài chính đã được xây dựng.

Một nhân viên mới có thể tiếp cận tri thức chuyên môn mà những người đi trước đã tích lũy.

Và một người có khả năng thiết kế có thể sử dụng những abstraction cũ để giải quyết những bài toán mới.

Nếu các năng lực đó thực sự có thể tái sử dụng, tổ chức không phải bắt đầu lại từ con số không mỗi khi xuất hiện một nhu cầu.

Each solved problem can become an asset for solving future problems.

Nhưng tôi muốn nhấn mạnh chữ có thể.

Không phải mọi vấn đề được giải quyết đều tự động trở thành tài sản.

Một quyết định chỉ tồn tại trong trí nhớ người quản lý không dễ được tái sử dụng.

Một đoạn code không có người bảo trì có thể trở thành khoản nợ.

Một tài liệu không còn phản ánh thực tế có thể khiến người sử dụng hiểu sai.

Và một quy tắc được nhân rộng khi chưa được kiểm chứng đầy đủ có thể tạo ra tổn thất trên phạm vi lớn.

Vì vậy, sự tích lũy năng lực cần nhiều hơn việc lưu trữ.

Nó cần khả năng xác định giá trị.

Chuẩn hóa ở mức phù hợp.

Cung cấp interface.

Quản lý vòng đời.

Và loại bỏ những thứ không còn hữu ích.

Tôi nghĩ đây là một dạng Capability Compounding.

Không phải tăng trưởng số lượng tính năng.

Mà là tích lũy những năng lực giúp tổ chức giải quyết các vấn đề mới với chi phí và mức độ phụ thuộc ngày càng hợp lý hơn.

Một công cụ tốt giúp nhiều người làm việc hiệu quả.

Một người có chuyên môn giúp phát triển những người khác.

Một abstraction tốt được sử dụng trong nhiều tình huống.

Một nền tảng chung làm giảm chi phí thử nghiệm những ý tưởng mới.

Và những kết quả của các thử nghiệm ấy tiếp tục cải thiện nền tảng.

Nếu vòng lặp đó hoạt động, doanh nghiệp bắt đầu có một dạng đòn bẩy vượt khỏi năng lực cá nhân của founder.

Nhưng tôi không muốn đo nó chỉ bằng số lượng sản phẩm hoặc số dòng code.

Tôi muốn nhìn vào những câu hỏi khó hơn.

Một người mới có thể đạt năng lực cơ bản nhanh hơn không?

Một nhóm có thể tự xây dựng giải pháp với ít hỗ trợ hơn không?

Những ngoại lệ đã hiểu có giảm mức độ phụ thuộc vào quản lý không?

Một năng lực được tạo ra có thể được nhiều nhóm tái sử dụng không?

Và khi một người quan trọng rời khỏi tổ chức, những năng lực mà họ đã giúp xây dựng có còn tiếp tục tạo ra giá trị không?

Nếu những điều đó cải thiện, tổ chức có thể đang thực sự tích lũy năng lực.

Không chỉ tích lũy phần mềm.

13. Người xuất sắc không nên là nơi tổ chức cất giữ tri thức.

Tôi muốn quay lại với những con người xuất sắc.

Trong nhiều doanh nghiệp, họ là người nắm giữ những hiểu biết quan trọng nhất.

Biết phải xử lý tình huống nào.

Biết khách hàng nào cần chú ý.

Biết quy trình nào thực sự đang hoạt động.

Biết những quy tắc bất thành văn.

Và biết cách giải quyết những vấn đề mà người khác gặp khó khăn.

Những người như vậy rất có giá trị.

Nhưng tôi không muốn tổ chức sử dụng họ chủ yếu như những kho lưu trữ tri thức.

Tôi muốn họ trở thành những người tạo ra tri thức mới.

Một chuyên gia không nên dành phần lớn thời gian để trả lời cùng một câu hỏi.

Họ nên có cơ hội chuyển những câu trả lời đã ổn định thành tài liệu, công cụ hoặc cơ chế để người khác sử dụng.

Sau đó tiếp tục giải quyết những vấn đề khó hơn.

Một người quản lý giỏi không nên phải mãi mãi trực tiếp xử lý mọi ngoại lệ.

Họ nên phát triển được đội ngũ và những cơ chế giúp phạm vi trách nhiệm của mình vận hành tốt hơn.

Một Software Architect không nên là người duy nhất hiểu toàn bộ hệ thống.

Họ nên tạo ra những contract, abstraction và phương pháp giúp những người khác có thể xây dựng những phần phù hợp một cách độc lập.

Và founder không nên trở thành kho lưu trữ cuối cùng của mọi hiểu biết về doanh nghiệp.

Tôi nghĩ đây là một sự thay đổi rất lớn.

From knowledge holders to capability creators.

Từ người nắm giữ tri thức sang người tạo ra năng lực.

Không phải ai cũng có khả năng thực hiện bước chuyển ấy ở cùng một mức độ.

Và không phải mọi vai trò đều yêu cầu điều đó.

Nhưng với những người có năng lực cao, tôi muốn tổ chức tạo ra một con đường.

Khám phá.

Giải thích.

Kiểm chứng.

Chuyển giao.

Và tiếp tục khám phá.

Nếu một người càng giỏi càng phải xử lý nhiều công việc cũ, chúng ta đang sử dụng năng lực của họ theo một cách rất hạn chế.

Nếu một người càng giỏi càng có khả năng tạo ra những cơ chế giúp người khác làm tốt hơn, tổ chức đang bắt đầu nhân rộng giá trị của họ.

Đây là loại scale mà tôi thấy đáng theo đuổi.

Không cần phải có hàng trăm thiên tài.

Nhưng cần có một kiến trúc biết sử dụng tốt những người có năng lực đặc biệt.

Và biết chuyển một phần thành quả của họ thành lợi thế chung.

14. Founder phải được phép không còn là người hiểu sâu nhất.

Tôi nghĩ đây là một trong những thách thức khó nhất về mặt tâm lý.

Người sáng lập thường bắt đầu với lợi thế hiểu biết rất lớn.

Họ hiểu sản phẩm.

Hiểu khách hàng.

Hiểu cách doanh nghiệp kiếm tiền.

Hiểu những ràng buộc.

Và hiểu tại sao nhiều quyết định quan trọng đã được đưa ra.

Những hiểu biết ấy tạo ra quyền lực.

Nhưng khi tổ chức phát triển, không có lý do gì founder phải tiếp tục là người hiểu sâu nhất về mọi lĩnh vực.

Một người phụ trách in ấn lâu năm có thể hiểu những giới hạn kỹ thuật cụ thể tốt hơn tôi.

Một người trực tiếp phát triển một phân khúc khách hàng có thể hiểu hành vi của nhóm khách ấy sâu hơn tôi.

Một người phụ trách vận chuyển có thể hiểu những biến động thực tế của tuyến giao tốt hơn tôi.

Và một người chuyên sâu về dữ liệu sản phẩm có thể phát hiện những vấn đề mà tôi chưa từng quan sát.

Tôi không xem đó là một mối đe dọa.

Nếu những năng lực ấy thực sự tồn tại, chúng là tài sản của tổ chức.

Nhưng founder phải học cách sử dụng chúng.

Không phải yêu cầu mọi người chứng minh rằng họ giỏi hơn mình trong mọi vấn đề.

Mà phải biết lĩnh vực nào có người sở hữu hiểu biết sâu hơn.

Và khi nào cần tin vào kết quả chuyên môn đã được kiểm chứng.

Tôi không muốn quyền lãnh đạo trở thành một cuộc thi xem ai thông minh nhất.

Quyền lãnh đạo phải đi cùng trách nhiệm về cấu trúc và kết quả chung.

Một người có thể giữ quyền quyết định chiến lược mà không cần trực tiếp đưa ra mọi kết luận chuyên môn.

Một founder có thể bảo vệ những nguyên tắc cốt lõi mà vẫn chấp nhận rằng phương pháp triển khai tốt nhất có thể đến từ người khác.

The founder should own the direction and the architecture of responsibility, not every answer inside the organization.

Nhưng điều này đòi hỏi một sự trưởng thành rất đặc biệt.

Bởi vì với người đã quen tự giải quyết vấn đề, việc để một người khác xử lý có thể khiến họ cảm thấy mình đang đánh mất một phần giá trị.

Đặc biệt khi người đó làm khác cách mình sẽ làm.

Tôi nghĩ phải phân biệt hai chuyện.

Mất quyền kiểm soát một cách thiếu cấu trúc.

Và chuyển quyền quyết định cho một người có đủ năng lực, thông tin và trách nhiệm trong một kiến trúc rõ ràng.

Chuyện thứ nhất nguy hiểm.

Chuyện thứ hai có thể là điều kiện để tổ chức trưởng thành.

Tôi không muốn giữ quyền quyết định chỉ vì mình có khả năng đưa ra câu trả lời nhanh hơn.

Tôi muốn giữ những quyết định thực sự cần trách nhiệm của mình.

Và để những người khác phát triển những năng lực mà họ có thể sở hữu tốt hơn tôi.

Đó không phải sự nhượng bộ.

Đó là một quyết định thiết kế.

15. Một hệ thống tự tiến hóa vẫn cần con người chịu trách nhiệm.

Tôi muốn tránh một hiểu lầm.

Khi nói về tổ chức có khả năng tự học và tự phát triển, tôi không nói đến một doanh nghiệp có thể tự động thay đổi mọi thứ mà không cần con người.

Một tổ chức không phải sinh vật có ý chí riêng.

Nó là tập hợp những con người, công cụ, nguồn lực, quy tắc và những quan hệ trách nhiệm.

Những quyết định vẫn phải được đưa ra.

Những rủi ro vẫn phải được đánh giá.

Những xung đột vẫn phải được giải quyết.

Và những lựa chọn lớn vẫn cần người chịu trách nhiệm cuối cùng.

Tôi không muốn thay thế một founder quá tập trung quyền lực bằng một hệ thống không ai thực sự có quyền quyết định.

Một tổ chức được điều hành bởi những hội đồng không rõ trách nhiệm có thể còn kém hiệu quả hơn.

Bởi vì khi mọi người cùng có quyền tham gia nhưng không ai chịu trách nhiệm cuối cùng, những quyết định khó có thể bị trì hoãn rất lâu.

Tôi muốn distributed capability, không phải distributed ambiguity.

Năng lực được phân tán.

Trách nhiệm vẫn phải rõ ràng.

Một nhóm có thể tự tạo micro-product trong phạm vi được phép.

Nhưng sản phẩm đưa vào production phải có người sở hữu trách nhiệm phù hợp.

Một chuyên gia có thể đề xuất thay đổi dữ liệu hoặc quy tắc.

Nhưng những thay đổi ảnh hưởng đến toàn hệ thống cần được kiểm chứng bởi người có thẩm quyền.

Một người quản lý có thể tự quyết trong phạm vi của mình.

Nhưng phải chịu trách nhiệm về kết quả.

Và founder vẫn có thể giữ những quyết định chiến lược quan trọng mà không cần trở thành người can thiệp vào mọi hoạt động.

A system that outgrows its founder does not eliminate leadership. It creates more capable leadership at more appropriate levels.

Tôi muốn một tổ chức có nhiều người đủ khả năng chịu trách nhiệm.

Không chỉ nhiều người có ý tưởng.

Không chỉ nhiều người biết sử dụng công nghệ.

Mà có nhiều người có khả năng nhìn thấy vấn đề, đưa ra quyết định, kiểm chứng kết quả và điều chỉnh khi cần thiết.

Đó là một loại năng lực khó xây dựng.

Nhưng tôi nghĩ nó tạo ra giá trị lớn hơn rất nhiều so với việc chỉ tăng số lượng nhân viên.

16. Làm sao biết tổ chức thực sự đang phát triển vượt khỏi founder?

Tôi muốn có những bằng chứng.

Không chỉ cảm giác.

Một founder có thể tự hào rằng đội ngũ đã trưởng thành.

Nhưng vẫn phải trực tiếp quyết định những vấn đề quan trọng nhất.

Một doanh nghiệp có thể có rất nhiều quản lý.

Nhưng những người đó chỉ thực hiện các chỉ đạo từ trên xuống.

Một tổ chức có thể có rất nhiều micro-product.

Nhưng mọi sản phẩm vẫn phải được founder trực tiếp thiết kế và phê duyệt.

Nếu như vậy, năng lực thực sự chưa chắc đã được phân phối.

Tôi thích một số phép thử.

Thử nghiệm thứ nhất: Những điều đã biết.

Nếu founder không tham gia hoạt động thường ngày trong một khoảng thời gian được chuẩn bị phù hợp, những quy trình đã ổn định có tiếp tục hoạt động đáng tin cậy không?

Không chỉ có chạy.

Mà có duy trì chất lượng, hiệu quả kinh tế và khả năng xử lý những ngoại lệ đã biết không?

Thử nghiệm thứ hai: Những điều thay đổi.

Nếu một chính sách trở nên không phù hợp, bộ phận chịu trách nhiệm có thể nhận diện, đưa ra đề xuất và thực hiện quá trình điều chỉnh hợp lệ không?

Hay mọi thay đổi vẫn phải đợi founder phát hiện?

Thử nghiệm thứ ba: Những điều chưa từng tồn tại.

Nếu một người có năng lực phát hiện một cơ hội mới, họ có thể tạo ra một giả thuyết, xây dựng thử nghiệm và kiểm chứng giá trị mà không cần founder trực tiếp thực hiện từng bước không?

Thử nghiệm thứ tư: Những sai lầm của chính kiến trúc.

Nếu một abstraction do founder thiết kế đang tạo ra kết quả không phù hợp, tổ chức có cơ chế để phát hiện, chất vấn và sửa đổi nó không?

Hay mọi người tiếp tục sử dụng vì tin rằng founder chắc chắn có lý do?

Tôi nghĩ thử nghiệm thứ tư đặc biệt quan trọng.

Bởi vì một tổ chức có thể vận hành rất độc lập trong phạm vi những điều founder đã dự đoán.

Nhưng vẫn không có khả năng vượt qua những giới hạn trong cách tư duy của người đó.

Một hệ thống chỉ biết thực thi mô hình của founder có thể hoạt động hàng chục năm.

Nhưng nếu thế giới thay đổi theo hướng mô hình ấy không còn phù hợp, nó sẽ gặp khó khăn.

The true test of organizational independence is not whether people can follow the founder's design without him. It is whether they can improve that design when he is wrong.

Tôi không kỳ vọng tổ chức vượt qua tất cả những phép thử này ngay lập tức.

Chúng đòi hỏi năng lực khác nhau.

Và mức độ độc lập có thể được mở rộng theo thời gian.

Nhưng tôi muốn biết chúng ta đang tiến đến đâu.

Không phải chỉ đo số lượng nhân sự.

Không phải chỉ đo số lượng tính năng.

Và không phải chỉ đo doanh thu.

Mà còn nhìn vào khả năng duy trì, cải thiện và tạo ra những năng lực mới của chính tổ chức.

17. Đừng nhầm sự phát triển của doanh nghiệp với sự bất tử của doanh nghiệp.

Có một điều tôi muốn nói rõ trước khi kết thúc.

Không có kiến trúc nào bảo đảm doanh nghiệp sẽ tồn tại mãi mãi.

Một công ty có thể sở hữu công nghệ rất tốt.

Đội ngũ mạnh.

Quy trình đáng tin cậy.

Và khả năng học hỏi đáng kể.

Nhưng vẫn có thể thất bại.

Thị trường có thể thay đổi nhanh hơn khả năng thích nghi.

Một mô hình kinh doanh có thể không còn hiệu quả.

Nguồn lực tài chính có thể không đủ.

Một đối thủ có thể tạo ra lợi thế mà doanh nghiệp không có khả năng đáp ứng.

Và có những biến động nằm ngoài khả năng kiểm soát.

Tôi không xem Business Operating System như một lời hứa về sự bất tử.

Cũng không xem Organizational Engineering là phương pháp giúp mọi doanh nghiệp chắc chắn thành công.

Nó chỉ có thể giúp nâng cao khả năng vận hành, học hỏi, thích nghi và sử dụng nguồn lực một cách hợp lý.

Nhưng những năng lực đó vẫn phải được đặt trong một chiến lược kinh doanh có giá trị thực tế.

Một doanh nghiệp không thể tự động hóa để vượt qua một mô hình kinh doanh không còn nhu cầu.

Không thể chỉ dùng AI để thay thế niềm tin của khách hàng.

Và không thể dùng một kiến trúc tổ chức đẹp để phủ nhận những giới hạn kinh tế cơ bản.

Tôi nghĩ người thiết kế cần đủ khiêm tốn để hiểu điều đó.

Mục tiêu không phải tạo ra một công trình không bao giờ thất bại.

Mà là một công trình có khả năng phát hiện vấn đề, học từ thực tế và thay đổi trước khi những khiếm khuyết trở nên không thể khắc phục.

Resilience is not immortality. Adaptability is not a guarantee of success.

Nhưng tôi vẫn xem chúng là những năng lực đáng được xây dựng.

Bởi vì trong một thế giới liên tục thay đổi, một tổ chức không có khả năng học hỏi sẽ phải phụ thuộc vào việc những giả định ban đầu của mình tiếp tục đúng.

Một chiến lược khá nguy hiểm.

Đặc biệt nếu những giả định đó được đưa ra bởi một người rất thông minh và cực kỳ tự tin.

Tôi biết loại người ấy.

Khá rõ.

18. The Architect's Paradox — Thành tựu lớn nhất có thể là thứ không còn cần đến mình.

Có một nghịch lý mà tôi muốn dành phần cuối của cuốn sách để suy nghĩ.

Một người kiến trúc sư thường được đánh giá qua những gì họ tạo ra.

Một cấu trúc tốt.

Một hệ thống mạnh.

Một công trình có khả năng vận hành đáng tin cậy.

Những thành tựu đó mang dấu ấn của người thiết kế.

Nhưng trong một tổ chức, nếu mọi thứ luôn phải mang dấu ấn của cùng một người, khả năng phát triển có thể bị giới hạn.

Một hệ thống thực sự trưởng thành phải cho phép những người đến sau tiếp tục cải thiện nó.

Có thể họ hiểu một số lĩnh vực sâu hơn người thiết kế ban đầu.

Có thể họ tìm ra những cách giải quyết khác.

Có thể họ loại bỏ những thành phần từng được xem là rất quan trọng.

Và có thể họ tạo ra những năng lực mà người sáng lập chưa từng hình dung.

Tôi muốn điều đó xảy ra.

Không phải vì tôi không còn tin vào khả năng thiết kế của mình.

Mà vì tôi hiểu mọi khả năng đều có giới hạn.

Kể cả khả năng abstraction.

Kể cả kinh nghiệm.

Kể cả những mô hình đã từng tạo ra thành công.

Một người có thể rất giỏi trong một giai đoạn.

Nhưng doanh nghiệp không nên bị buộc phải tồn tại mãi mãi bên trong những giới hạn nhận thức của người đó.

The architect's ultimate achievement is not a system that perfectly preserves his thinking. It is a system capable of producing thinking that surpasses his own.

Tôi thích ý tưởng này.

Nó khác với việc tạo ra một bộ quy trình để người khác làm đúng những gì mình đã định nghĩa.

Khác với việc viết phần mềm để nhân viên không cần suy nghĩ.

Và khác với việc xây dựng một tổ chức nơi mọi quyết định được thực thi nhất quán theo những nguyên lý ban đầu.

Những điều đó vẫn có giá trị.

Nhưng chúng chưa phải điểm kết thúc.

Tôi muốn một kiến trúc có khả năng tạo ra thêm những người có khả năng kiến tạo.

Không nhất thiết giống nhau.

Không nhất thiết giỏi cùng một lĩnh vực.

Nhưng đủ khả năng phát hiện những vấn đề mới, đưa ra giải pháp và chịu trách nhiệm với kết quả.

Một nhân viên có thể trở thành chuyên gia.

Một chuyên gia có thể tạo ra công cụ.

Một người xây dựng sản phẩm có thể phát triển thành người sở hữu một lĩnh vực kinh doanh.

Một người quản lý có thể phát triển đội ngũ mới.

Và một người có khả năng tư duy hệ thống có thể bắt đầu thiết kế những cơ chế mà tổ chức chưa từng có.

Những năng lực đó không cần phải xuất hiện theo một lộ trình cố định.

Nhưng tổ chức phải có khả năng nhận diện, hỗ trợ và sử dụng chúng.

Tôi không muốn tất cả tiếp tục chờ một người duy nhất nghĩ ra điều tiếp theo.

Bởi vì nếu mọi ý tưởng lớn đều phải đến từ founder, doanh nghiệp có thể phát triển rất nhanh.

Nhưng vẫn không thực sự vượt khỏi founder.

19. Một ngày nào đó, người ta sẽ sửa những thứ tôi đã xây dựng.

Tôi muốn nghĩ đến tương lai ấy.

Một ngày nào đó, những quy trình mà tôi từng rất tự hào có thể không còn phù hợp.

Một abstraction tôi từng thấy rất thanh lịch có thể bị thay thế bởi mô hình tốt hơn.

Một công cụ tôi đã dành nhiều đêm để xây dựng có thể không còn cần thiết.

Và một người có thể nói:

"Cách này ngày xưa hợp lý, nhưng bây giờ mình nên thay đổi."

Tôi hy vọng khi đó tổ chức sẽ không trả lời:

"Không được. Cái này do founder thiết kế."

Tôi muốn họ hỏi:

"Tại sao?"

"Thay đổi sẽ tạo ra giá trị gì?"

"Những ràng buộc nào cần bảo vệ?"

"Chúng ta có bằng chứng gì?"

"Và làm sao kiểm chứng phương án mới?"

Nếu câu trả lời đủ tốt, tôi muốn hệ thống có khả năng chấp nhận thay đổi.

Kể cả khi điều đó có nghĩa phải loại bỏ một phần công trình của tôi.

Tôi không nghĩ giá trị của người kiến trúc sư nằm ở việc mọi thứ họ từng thiết kế phải được duy trì mãi mãi.

Đó không phải kiến trúc.

Đó là xây dựng tượng đài.

Một tượng đài có thể rất đẹp.

Nhưng không có khả năng tự thay đổi khi thực tế thay đổi.

Tôi không muốn doanh nghiệp trở thành một tượng đài dành cho người sáng lập.

Tôi muốn nó là một hệ thống sống.

Một hệ thống liên tục tiếp xúc với thị trường.

Học từ những sai lầm.

Phát hiện cơ hội.

Phát triển con người.

Và chuyển những hiểu biết mới thành năng lực chung.

Nếu một ngày những gì tôi xây dựng trở nên lỗi thời, tôi muốn tổ chức có đủ năng lực để thay thế chúng.

Không phải vì tôi đã thất bại.

Mà vì một trong những mục tiêu lớn nhất của tôi đã thành công.

The system has learned to outgrow its architect.

Tôi nghĩ đó là một thành tựu đáng giá.

Dù có thể không dễ chịu cho cái tôi của người thiết kế.

Đặc biệt là một người từng quen nghĩ mình có khả năng nhìn thấy cấu trúc nhanh hơn người khác.

20. The Book That Should Never Be Finished.

Tôi đã dành phần lớn cuốn sách để bàn về những hệ thống.

Những vấn đề lặp lại.

Trách nhiệm của con người và kiến trúc.

Chi phí của ngoại lệ.

Khả năng nhìn thấy cấu trúc.

Abstraction.

Guardrails.

Business Operating System.

Automation.

Phát triển năng lực con người.

Freedom to Build.

Và cuối cùng là giới hạn của chính người sáng lập.

Tôi không muốn kết thúc bằng cách tuyên bố mình đã tìm ra một phương pháp hoàn chỉnh.

Thực ra, nếu có điều gì khiến tôi ngày càng thận trọng hơn trong quá trình thiết kế hệ thống, đó là việc nhận ra mỗi mô hình đều chỉ phản ánh một phần thực tế mà chúng ta đã có khả năng hiểu tại thời điểm xây dựng nó.

Một mô hình có thể rất tốt.

Nhưng vẫn có giới hạn.

Một nguyên lý có thể tạo ra kết quả tích cực.

Nhưng vẫn cần được kiểm chứng khi bối cảnh thay đổi.

Một cơ chế có thể hoạt động đáng tin cậy.

Nhưng vẫn tạo ra những tác dụng phụ mà người thiết kế chưa dự đoán.

Và một người có thể rất giỏi nhận diện cấu trúc.

Nhưng vẫn có những cấu trúc mà họ chưa nhìn thấy.

Tôi không xem những giới hạn đó là lý do để từ bỏ việc thiết kế.

Ngược lại.

Chúng là lý do để xây dựng những hệ thống có khả năng học hỏi.

Tôi cũng muốn xem cuốn sách này theo cách tương tự.

Không phải một bộ nguyên tắc bất biến.

Không phải tài liệu chứng minh người viết đã hiểu mọi thứ.

Mà là một tập hợp những mô hình tư duy được hình thành từ việc quan sát, thiết kế và vận hành những hệ thống thực tế.

Theo thời gian, sẽ có những trường hợp mới xuất hiện.

Có thể một cơ chế tạo ra kết quả tốt hơn dự kiến.

Có thể một phương pháp thất bại.

Có thể một quyết định nhân sự cho thấy giới hạn của một nguyên lý mà tôi từng rất tin tưởng.

Và có thể một người trong tổ chức đưa ra một cách hiểu tốt hơn cách tôi đã trình bày.

Tôi muốn những bằng chứng ấy có khả năng thay đổi cuốn sách.

Một kết luận không còn phù hợp nên được điều chỉnh.

Một giả thuyết chưa đủ bằng chứng nên được thừa nhận là chưa đủ bằng chứng.

Và một nguyên lý được kiểm chứng trong thực tế nên được phát triển sâu hơn.

A book about learning systems should itself remain capable of learning.

Tôi nghĩ điều đó phù hợp với tinh thần của toàn bộ hành trình này.

Không phải viết ra một kiến trúc hoàn hảo.

Mà là liên tục tìm cách hiểu thực tế tốt hơn.

Và chuyển những hiểu biết ấy thành những năng lực có khả năng tạo ra giá trị.

Nếu một ngày tổ chức của tôi có thể tiếp tục phát triển những ý tưởng trong cuốn sách mà không cần tôi trực tiếp tham gia, tôi sẽ xem đó là một kết quả rất thú vị.

Bởi vì lúc ấy, những nguyên lý này không còn chỉ thuộc về tác giả.

Chúng đã trở thành một phần năng lực tư duy của những con người khác.

Và có lẽ, những người ấy sẽ đưa chúng đi xa hơn rất nhiều.

EPILOGUE

The Architect of Chaos.

Tôi không thích những vấn đề lặp lại.

Không phải vì tôi thiếu kiên nhẫn với khó khăn.

Tôi thích những vấn đề khó.

Những vấn đề chưa có câu trả lời.

Những tình huống khiến chúng ta phải xem xét lại những điều từng tin là đúng.

Những giới hạn buộc chúng ta phải học thêm một lĩnh vực mới.

Và những sự kiện tưởng chừng không liên quan nhưng có thể đang che giấu một cấu trúc sâu hơn.

Tôi thích khoảnh khắc những mối liên hệ bắt đầu xuất hiện.

Khi một trăm vấn đề không còn là một trăm vấn đề độc lập.

Khi những ngoại lệ cho thấy một nguyên lý chưa được nhận diện.

Khi một abstraction giúp giải quyết cả một nhóm tình huống.

Và khi một cấu trúc mới khiến những con người bình thường có thể làm tốt những công việc từng đòi hỏi năng lực đặc biệt.

Đó là những điều khiến tôi hứng thú với Software Engineering.

Và cũng là những điều khiến việc xây dựng doanh nghiệp trở thành một thử thách đáng giá.

Nhưng sau tất cả, tôi nghĩ mình đã học được một điều quan trọng.

Nhìn thấy cấu trúc trong hỗn loạn chỉ là bước đầu tiên.

Một người có thể nhìn thấy cấu trúc rất giỏi.

Có thể tạo ra abstraction.

Có thể thiết kế hệ thống.

Có thể viết phần mềm.

Có thể giải quyết những vấn đề mà người khác gặp khó khăn.

Nhưng nếu toàn bộ năng lực đó vẫn chỉ tồn tại trong một con người, tổ chức chưa thực sự trưởng thành.

Nó đang sở hữu một cá nhân mạnh.

Không nhất thiết một kiến trúc mạnh.

Tôi không muốn dừng ở việc trở thành người giỏi nhất trong phòng.

Tôi muốn xây dựng một tổ chức mà năng lực của những con người bên trong có thể kết hợp, tích lũy và phát triển vượt khỏi giới hạn của từng cá nhân.

Một tổ chức nơi những công việc đã hiểu rõ có thể được thực hiện đáng tin cậy.

Những sai lầm đã được nhận diện không cần liên tục lặp lại.

Những người có năng lực có đủ không gian để phát triển.

Những ý tưởng mới có khả năng được kiểm chứng.

Và những nguyên lý đã lỗi thời có thể được thay thế mà không cần một cuộc khủng hoảng.

Tôi không muốn một tổ chức không có sự hỗn loạn.

Điều đó không thực tế.

Một thị trường sống sẽ luôn tạo ra những thay đổi.

Một doanh nghiệp đang phát triển sẽ luôn gặp những giới hạn mới.

Và những con người có khả năng suy nghĩ độc lập sẽ luôn đưa ra những ý tưởng, những cách làm và đôi khi những mâu thuẫn mà người thiết kế ban đầu chưa từng dự đoán.

Tôi không muốn loại bỏ hoàn toàn những điều ấy.

Tôi muốn tổ chức có khả năng hấp thụ sự hỗn loạn mà không bị phá hủy bởi nó.

Và quan trọng hơn, có khả năng học từ sự hỗn loạn để trở nên tốt hơn.

Một vấn đề xuất hiện.

Chúng ta quan sát.

Phân tích.

Phân biệt noise với signal.

Tìm những cấu trúc có thể giải thích hiện tượng.

Đưa ra giả thuyết.

Kiểm chứng.

Và nếu hiểu biết đủ đáng tin cậy, chuyển nó thành một cơ chế có thể tái sử dụng.

Sau đó, hệ thống tiếp tục hoạt động.

Cho đến khi xuất hiện một vấn đề mới.

Đôi khi vấn đề ấy sẽ cho thấy cơ chế cũ chưa đủ tốt.

Đôi khi nó đòi hỏi một abstraction mới.

Và đôi khi nó sẽ khiến chúng ta phải thừa nhận rằng một điều từng tin tưởng rất lâu thực ra đã sai.

Tôi nghĩ đó là một quá trình không có điểm kết thúc cố định.

Và tôi cũng không muốn nó có một điểm kết thúc như vậy.

Bởi vì một tổ chức ngừng đặt câu hỏi về những gì mình đã hiểu có thể đang bắt đầu ngừng học hỏi.

Còn một người kiến trúc sư tin rằng mình đã hoàn thành bản thiết kế cuối cùng có lẽ đang đánh giá quá cao khả năng dự đoán tương lai của bản thân.

Tôi không muốn trở thành người như vậy.

Tôi muốn tiếp tục giải quyết những vấn đề mới.

Nhưng tôi cũng muốn ngày càng nhiều người khác có khả năng giải quyết những vấn đề mà trước đây chỉ mình tôi có thể xử lý.

Tôi muốn họ phát triển chuyên môn.

Tạo ra công cụ.

Thiết kế quy trình.

Xây dựng sản phẩm.

Phát triển những lĩnh vực kinh doanh.

Và đôi khi, đưa ra những mô hình tốt hơn những gì tôi đã thiết kế.

Nếu một ngày điều đó xảy ra, tôi không muốn phản ứng bằng câu hỏi:

"Ai cho phép sửa cái này?"

Tôi muốn hỏi:

"Điều gì khiến chúng ta tin rằng cách mới tốt hơn?"

Và nếu họ có đủ bằng chứng, tôi muốn tổ chức có khả năng tiếp tục mà không cần sự đồng ý mang tính cá nhân của tôi đối với mọi chi tiết.

Đó mới là điều khó.

Không phải viết code.

Không phải thiết kế database.

Không phải tạo thêm một abstraction.

Mà là thiết kế một kiến trúc mà trong đó, chính những abstraction do mình tạo ra cũng có thể được người khác kiểm chứng và thay thế.

Tôi nghĩ đó là một dạng trách nhiệm rất lớn.

Và cũng là một dạng tự do.

Tự do khỏi việc phải là người giải quyết mọi vấn đề.

Tự do khỏi sự phụ thuộc vào những gì mình đã biết.

Và tự do để tiếp tục khám phá những điều chưa từng được hiểu.

Một người sáng lập có thể dành cả đời để xây dựng một doanh nghiệp cần đến mình.

Điều đó không khó hiểu.

Cảm giác được cần đến có sức hấp dẫn rất lớn.

Nhân viên hỏi.

Mình trả lời.

Vấn đề xuất hiện.

Mình giải quyết.

Mọi người chờ quyết định.

Mình đưa ra quyết định.

Và tổ chức tiếp tục hoạt động.

Một vai trò rất quan trọng.

Nhưng tôi nghĩ có một thành tựu lớn hơn.

Đó là khi những điều mình từng phải trực tiếp giải quyết không còn cần đến mình nữa.

Không phải vì chúng đã trở nên không quan trọng.

Mà vì tổ chức đã phát triển đủ năng lực để tự xử lý.

Khi đó, tôi có thể tiếp tục tập trung vào những vấn đề mới.

Và những người khác có thể tiếp tục làm điều tương tự trong những lĩnh vực của họ.

Đến một ngày, tổ chức có thể tạo ra nhiều năng lực mới hơn những gì tôi có khả năng tự xây dựng.

Nó có thể phát hiện những cơ hội mà tôi chưa nhìn thấy.

Có thể phát triển những chuyên môn mà tôi không sở hữu.

Có thể tạo ra những sản phẩm mà tôi chưa từng nghĩ đến.

Và có thể tiếp tục cải thiện cả những cơ chế mà tôi từng rất tự hào.

Nếu điều đó thực sự xảy ra, tôi nghĩ mình đã đạt được một thành tựu rất đáng giá.

Không phải vì doanh nghiệp không còn cần founder.

Mà vì doanh nghiệp đã không còn bị giới hạn bởi những gì founder có thể trực tiếp làm, trực tiếp biết và trực tiếp tưởng tượng.

Đó là điều tôi muốn xây dựng.

Một hệ thống không tồn tại để tôn vinh người thiết kế.

Một tổ chức không chỉ biết làm theo.

Một kiến trúc không cần giả định mọi con người đều xuất sắc.

Và một môi trường mà những người có khả năng phát triển có thể tiếp tục tạo ra những điều tốt hơn.

Tôi không muốn là người cuối cùng có khả năng nhìn thấy cấu trúc trong hỗn loạn.

Tôi muốn là người góp phần xây dựng một tổ chức nơi khả năng ấy không còn chỉ tồn tại trong một bộ não.

The Architect of Chaos.

Không phải người có khả năng kiểm soát mọi sự hỗn loạn.

Mà là người cố gắng xây dựng những cấu trúc giúp con người có thể sống, làm việc, học hỏi và tiếp tục phát triển giữa một thế giới không bao giờ hoàn toàn có trật tự.

Và nếu một ngày, một nhân viên đến gặp tôi, không phải để xin giải pháp, mà để giải thích rằng họ vừa tìm ra một cấu trúc tốt hơn cấu trúc tôi đã thiết kế...

Tôi hy vọng mình sẽ đủ tỉnh táo để không vội bảo vệ cái tôi.

Đủ tò mò để lắng nghe.

Đủ năng lực để phản biện.

Và đủ trưởng thành để chấp nhận khi họ đúng.

Bởi vì đến lúc ấy, người kiến trúc sư không còn là nguồn duy nhất tạo ra kiến trúc.

Công trình đã bắt đầu có khả năng tự phát triển.

Tôi sẽ nhìn vào những gì họ vừa tạo ra.

Có thể nó chưa hoàn hảo.

Có thể vẫn còn những điểm cần kiểm chứng.

Và có thể tôi vẫn nhìn thấy một vài cách cải thiện.

Nhưng nếu tổ chức đã đủ năng lực tự tiếp tục quá trình ấy, tôi nghĩ mình không cần phải giành lấy bàn phím.

Một cảm giác có lẽ khá xa lạ.

Đặc biệt đối với một thằng Software Engineer đã quá quen với việc thấy vấn đề là muốn tự sửa.

Tôi có thể sẽ im lặng vài giây.

Nhìn vào hệ thống.

Nhìn vào những con người đang tiếp tục xây dựng nó.

Rồi nhận ra một điều.

For the first time, I am no longer the only architect.

Và đó không phải là thất bại của tôi.

Đó là bằng chứng rằng công trình đã bắt đầu trưởng thành.

Fuck.

I think I've finally built something bigger than myself.

END OF BOOK ONE

THE ARCHITECT OF CHAOS

Understanding Chaos. Designing Order. Engineering People & Scale.

Ông Chú Hay Chửi — MrLee

The system should raise the floor without lowering the ceiling.

And the architect should build a system capable of outgrowing its architect.