Tôi từng nghĩ một trong những lợi thế lớn nhất của mình là khả năng giải quyết vấn đề nhanh.
Một nhân viên gặp tình huống khó.
Tôi có thể nhìn vào dữ liệu, xác định nguyên nhân và đưa ra hướng xử lý.
Một bộ phận gặp vấn đề vận hành.
Tôi có thể quan sát quy trình, nhận ra những điểm bất hợp lý và đề xuất một cấu trúc mới.
Một chức năng phần mềm chưa đáp ứng được nhu cầu.
Tôi có thể phân tích, thiết kế, viết code và triển khai.
Đôi khi toàn bộ quá trình diễn ra nhanh đến mức người đề xuất vấn đề còn chưa kịp hình dung đầy đủ giải pháp.
Tôi khá thích điều đó.
Nó tạo ra một cảm giác rất dễ chịu.
Vấn đề xuất hiện.
Tôi giải quyết.
Hệ thống tốt hơn.
Doanh nghiệp tiếp tục phát triển.
Một vòng lặp có vẻ hoàn hảo.
Cho đến khi tôi nhận ra một điều.
Mỗi lần tôi giải quyết được một vấn đề mà không cần đến người khác, tổ chức lại có thêm một lý do để tiếp tục phụ thuộc vào tôi.
Ban đầu, điều đó không đáng lo.
Doanh nghiệp còn nhỏ.
Một người có khả năng nhìn toàn cục và thực thi nhanh có thể tạo ra lợi thế rất lớn.
Không cần nhiều cấp quản lý.
Không cần những cuộc họp kéo dài.
Không cần mất hàng tuần để chuyển một ý tưởng thành giải pháp.
Một vấn đề xuất hiện vào buổi sáng.
Đến buổi chiều, nó có thể đã được xử lý.
Tuyệt vời.
Nhưng rồi doanh nghiệp phát triển.
Khách hàng tăng.
Sản phẩm tăng.
Nhân viên tăng.
Những mối quan hệ giữa các bộ phận trở nên phức tạp hơn.
Và những vấn đề mới bắt đầu xuất hiện với tốc độ ngày càng cao.
Tôi vẫn giải quyết vấn đề rất nhanh.
Nhưng có điều gì đó đã thay đổi.
Trước đây, một vấn đề được giải quyết là một bước tiến.
Bây giờ, mỗi vấn đề được giải quyết lại có thể kéo theo thêm ba vấn đề mới cần tôi tham gia.
Một tính năng mới cần nhân viên hiểu cách sử dụng.
Một quy trình mới cần người quản lý thay đổi cách điều hành.
Một cơ chế phân quyền mới cần xác định ai thực sự có đủ năng lực nhận trách nhiệm.
Một công cụ mới cần được tích hợp vào hoạt động thường ngày.
Và một ý tưởng kinh doanh mới cần người biến nó thành kết quả thực tế.
Tôi có thể tiếp tục viết phần mềm nhanh hơn.
Tiếp tục thiết kế hệ thống tốt hơn.
Tiếp tục tạo ra những abstraction mới.
Nhưng tôi bắt đầu nghi ngờ rằng vấn đề không còn nằm ở tốc độ tạo ra giải pháp.
Tốc độ phát triển của người thiết kế đã vượt quá tốc độ hấp thụ của tổ chức.
Và nếu điều đó đúng, tôi vừa đối diện với một nghịch lý khá khó chịu.
Người đang tạo ra nhiều năng lực mới nhất cho doanh nghiệp cũng có thể chính là người khiến doanh nghiệp không kịp phát triển năng lực để sử dụng chúng.
Một lợi thế cạnh tranh.
Đồng thời là một giới hạn tăng trưởng.
Cùng nằm trong một con người.
Fuck.
Chúng ta có một vấn đề thú vị.
01. The Hero Stage — Khi founder là giải pháp tốt nhất.
Hầu hết doanh nghiệp nhỏ đều trải qua một giai đoạn mà người sáng lập trực tiếp tham gia vào rất nhiều hoạt động.
Bán hàng.
Tuyển dụng.
Xử lý khách hàng.
Quản lý tài chính.
Thiết kế quy trình.
Phát triển sản phẩm.
Và giải quyết những tình huống bất ngờ.
Trong giai đoạn này, việc founder tập trung quyền quyết định có thể hoàn toàn hợp lý.
Thông tin còn phân mảnh.
Những nguyên tắc kinh doanh chưa được kiểm chứng đầy đủ.
Quy mô chưa đủ lớn để cần nhiều cấp quản lý.
Và người sáng lập có thể là người duy nhất hiểu rõ mối liên hệ giữa các hoạt động.
Một nhân viên bán hàng nhìn thấy vấn đề của khách.
Người phụ trách kho nhìn thấy vấn đề của hàng hóa.
Kế toán nhìn thấy vấn đề của dòng tiền.
Nhưng founder có thể nhìn thấy ảnh hưởng của một quyết định lên cả ba.
Khả năng đó tạo ra tốc độ.
Một quyết định không cần đi qua nhiều cấp.
Một vấn đề không cần được giải thích lại cho nhiều người.
Một sự thay đổi không cần mất hàng tuần để thống nhất.
Đây là lợi thế của việc tập trung thông tin và quyền quyết định vào một bộ não có khả năng xử lý tốt.
Tôi không cho rằng mô hình này sai.
Thậm chí, trong nhiều tình huống, cố gắng xây dựng một bộ máy quản trị cồng kềnh quá sớm có thể làm giảm lợi thế của doanh nghiệp nhỏ.
Nhưng có một điều kiện quan trọng.
Một kiến trúc hiệu quả ở quy mô nhỏ không nhất thiết tiếp tục hiệu quả khi quy mô thay đổi.
Trong Software Engineering, một hệ thống đơn giản có thể hoạt động rất tốt khi chỉ có một số lượng nhỏ người sử dụng.
Nhưng khi tải tăng, những giả định ban đầu có thể không còn phù hợp.
Một thành phần từng xử lý tốt mọi yêu cầu bắt đầu trở thành nút thắt.
Một cơ chế đồng bộ từng rất tiện lợi bắt đầu tạo ra hàng đợi.
Một thiết kế tập trung từng giúp hệ thống đơn giản hơn bắt đầu giới hạn khả năng mở rộng.
Trong doanh nghiệp, điều tương tự có thể xảy ra với founder.
Ở giai đoạn đầu, founder là người giải quyết vấn đề tốt nhất.
Ở giai đoạn tiếp theo, founder trở thành người được hỏi nhiều nhất.
Và nếu không thay đổi kiến trúc, đến một thời điểm founder có thể trở thành người mà tất cả các quyết định quan trọng phải chờ đợi.
Điều đáng chú ý là sự chuyển đổi ấy không xảy ra vì founder đột nhiên trở nên kém năng lực.
Nó xảy ra chính vì tổ chức đã phát triển nhờ năng lực của founder.
The architecture that creates early advantage can become the architecture that limits later growth.
Đây là một trong những nghịch lý quan trọng nhất của quá trình scale.
Thứ đã giúp doanh nghiệp thành công trong quá khứ có thể trở thành thứ ngăn doanh nghiệp tiếp tục phát triển.
Và điều khó nhất là nhận ra thời điểm cần thay đổi.
Bởi vì mô hình cũ vẫn đang hoạt động.
Chỉ là ngày càng đắt đỏ.
02. Càng giải quyết giỏi, càng khó được thay thế.
Hãy tưởng tượng một nhân viên gặp vấn đề.
Họ đã thử tìm cách xử lý nhưng chưa có giải pháp.
Họ hỏi founder.
Founder nhìn vào tình huống.
Đưa ra câu trả lời.
Vấn đề được giải quyết trong vài phút.
Người nhân viên rất hài lòng.
Lần sau, một vấn đề tương tự xuất hiện.
Họ lại hỏi founder.
Lần này còn nhanh hơn.
Bởi vì cả hai đều đã biết ai có khả năng đưa ra quyết định.
Sau nhiều lần, một thói quen hình thành.
Gặp vấn đề khó thì hỏi founder.
Một cơ chế cực kỳ hiệu quả trong ngắn hạn.
Nhưng hãy nhìn kỹ hơn.
Mỗi lần nhân viên hỏi và nhận được câu trả lời, họ có thể học được một điều.
Rằng founder biết cách giải quyết.
Nhưng họ chưa chắc học được cách founder tạo ra câu trả lời.
Điều này tạo ra một sự khác biệt rất lớn.
Một người có thể ghi nhớ hàng trăm quyết định đúng mà vẫn không đủ khả năng xử lý một tình huống mới.
Bởi vì họ chỉ nhìn thấy kết quả.
Không nhìn thấy những giả định, nguyên lý và ràng buộc đứng sau kết quả ấy.
Một founder giỏi thường sử dụng rất nhiều tri thức ngầm khi ra quyết định.
Kinh nghiệm thị trường.
Hiểu biết về khách hàng.
Cấu trúc lợi nhuận.
Khả năng vận hành.
Những rủi ro đã từng xảy ra.
Và những mối quan hệ giữa các yếu tố mà người khác chưa nhận diện được.
Trong đầu founder, quá trình đánh giá có thể diễn ra rất nhanh.
Nhanh đến mức chính người đó đôi khi cũng không diễn đạt đầy đủ được mình vừa sử dụng những nguyên lý nào.
Họ chỉ biết:
"Trường hợp này không nên làm."
Hoặc:
"Cái này được, nhưng phải thay đổi một điều kiện."
Hoặc:
"Đừng sửa chỗ đó. Vấn đề nằm ở cấu trúc phía trước."
Những quyết định ấy có thể hoàn toàn chính xác.
Nhưng nếu chúng chỉ tồn tại trong đầu một người, tổ chức đang tích lũy một khoản nợ.
Tôi gọi đó là Cognitive Dependency.
Sự phụ thuộc vào năng lực nhận thức của một cá nhân.
Nó khác với việc phụ thuộc vào một phần mềm hoặc một quy trình.
Bởi vì thứ được phụ thuộc không chỉ là kiến thức.
Mà còn là khả năng kết nối kiến thức để tạo ra phán đoán.
Và loại năng lực đó khó chuyển giao hơn nhiều so với một danh sách hướng dẫn.
The better the founder is at solving problems, the easier it becomes for everyone else to stop learning how to solve them.
Không phải vì nhân viên lười biếng.
Mà vì tổ chức đang cung cấp một con đường ngắn hơn, nhanh hơn và ít rủi ro hơn.
Nếu hỏi founder mất ba phút.
Còn tự phân tích mất ba giờ và vẫn có nguy cơ sai.
Tại sao nhân viên phải chọn cách thứ hai?
Đặc biệt khi quyết định sai có thể khiến họ bị phê bình.
Một người hoàn toàn hợp lý sẽ lựa chọn cách an toàn hơn.
Và nếu cách an toàn nhất luôn là hỏi founder, chính hệ thống đã dạy mọi người phải phụ thuộc.
Đây là điều khiến tôi khó chịu.
Bởi vì người tạo ra sự phụ thuộc có thể không hề có ý định đó.
Anh ta chỉ đang cố gắng giúp mọi người làm việc tốt hơn.
Và làm quá tốt.
03. The Founder Queue — Hàng đợi đắt nhất doanh nghiệp.
Hãy xem founder như một tài nguyên xử lý quyết định.
Đây chỉ là một phép ẩn dụ kỹ thuật.
Con người không phải CPU.
Nhưng một số nguyên lý về năng lực xử lý và hàng đợi vẫn rất hữu ích để suy nghĩ.
Giả sử người sáng lập phải xem xét nhiều loại yêu cầu.
Một yêu cầu điều chỉnh chính sách.
Một vấn đề nhân sự.
Một quyết định đầu tư.
Một ngoại lệ trong giao dịch.
Một chức năng phần mềm cần đánh giá.
Một đề xuất phát triển thị trường.
Mỗi yêu cầu có độ phức tạp khác nhau.
Có những yêu cầu chỉ cần vài phút.
Có những quyết định cần nhiều giờ.
Và có những vấn đề phải được suy nghĩ qua nhiều ngày.
Nếu tất cả đều đi qua cùng một người, năng lực xử lý của hệ thống sẽ bị giới hạn bởi thời gian và khả năng tập trung của người đó.
Điều nguy hiểm là hàng đợi không nhất thiết xuất hiện rõ ràng.
Không có một màn hình ghi:
"Founder Queue: 37 pending decisions."
Thay vào đó, nó tồn tại dưới những hình thức quen thuộc hơn.
Một nhân viên đang chờ phản hồi.
Một quản lý chưa dám quyết định.
Một dự án chưa được phê duyệt.
Một chức năng đã hoàn thành nhưng chưa được kiểm chứng.
Một đề xuất bị trì hoãn.
Và một nhóm người đang làm những công việc ít quan trọng hơn trong khi chờ quyết định chính.
Nếu chỉ nhìn vào founder, chúng ta có thể thấy một người làm việc cực kỳ hiệu quả.
Họ liên tục xử lý vấn đề.
Trả lời tin nhắn.
Tham gia họp.
Đưa ra quyết định.
Và có rất ít thời gian rảnh.
Một hình ảnh thường được xem là biểu tượng của sự tận tâm.
Nhưng từ góc độ toàn hệ thống, mức sử dụng công suất quá cao của một tài nguyên trung tâm có thể khiến thời gian chờ tăng mạnh khi nhu cầu biến động.
Những yêu cầu quan trọng phải cạnh tranh với những yêu cầu nhỏ.
Những công việc có thể hoàn thành nhanh bị trì hoãn vì một quyết định phức tạp.
Và mỗi sự gián đoạn lại có thể làm giảm khả năng tập trung vào những vấn đề dài hạn.
A busy founder is not necessarily a productive organization.
Một founder bận rộn không tự động chứng minh tổ chức đang hoạt động hiệu quả.
Đôi khi nó chứng minh điều ngược lại.
Rằng quá nhiều công việc cần được đưa đến cùng một người trước khi có thể tiếp tục.
Tôi muốn đo lường những điều khác.
Bao nhiêu quyết định thực sự cần năng lực đặc biệt của founder?
Bao nhiêu quyết định đã có nguyên lý rõ ràng nhưng vẫn phải đưa lên?
Bao nhiêu công việc bị trì hoãn vì chờ phê duyệt?
Và bao nhiêu vấn đề có thể được xử lý ở cấp thấp hơn nếu thông tin, quyền hạn và trách nhiệm được thiết kế tốt hơn?
Nếu không đặt những câu hỏi ấy, chúng ta có thể tiếp tục tối ưu tốc độ làm việc của founder.
Trong khi nút thắt thực sự là số lượng quyết định không cần thiết đang được chuyển đến anh ta.
Một hệ thống có thể được cải thiện bằng cách tăng tốc độ xử lý.
Nhưng đôi khi giải pháp tốt hơn là giảm số lượng yêu cầu phải đi qua tài nguyên đang bị quá tải.
Đây là nguyên lý rất quen thuộc trong kỹ thuật.
Khá kỳ lạ là khi áp dụng vào quản trị, nhiều người lại xem đó là dấu hiệu người lãnh đạo đang buông lỏng kiểm soát.
04. Founder không chỉ là nút thắt quyết định. Founder còn là nút thắt abstraction.
Đây mới là vấn đề tôi quan tâm nhất.
Một doanh nghiệp có thể giải quyết sự phụ thuộc vào quyết định thường ngày bằng cách phân quyền.
Những giao dịch đã hiểu rõ được xử lý theo chính sách.
Những ngoại lệ có điều kiện được giao cho người có thẩm quyền.
Những thao tác lặp lại được tự động hóa.
Và những bộ phận có người chịu trách nhiệm vận hành.
Tốt.
Nhưng điều gì xảy ra khi một vấn đề hoàn toàn mới xuất hiện?
Một mâu thuẫn chưa từng được nhận diện giữa hai quy trình.
Một nhóm khách hàng có hành vi khác với những giả định hiện tại.
Một giới hạn mới xuất hiện khi doanh nghiệp tăng quy mô.
Một thay đổi công nghệ tạo ra những khả năng kinh doanh chưa từng tồn tại.
Hoặc một loạt sự cố tưởng chừng độc lập bắt đầu cho thấy một cấu trúc chung.
Ai sẽ nhận diện điều đó?
Ai sẽ phân tích?
Ai sẽ đưa ra một abstraction mới?
Và ai có đủ hiểu biết về cả công nghệ lẫn kinh doanh để chuyển abstraction ấy thành kiến trúc vận hành?
Nếu câu trả lời vẫn luôn là founder, chúng ta mới chỉ giải quyết được một phần bài toán.
Decision delegation does not automatically create distributed architectural thinking.
Phân quyền quyết định không tự động tạo ra khả năng tư duy kiến trúc phân tán.
Một người quản lý có thể thực thi rất tốt những quy trình đã được thiết kế.
Nhưng chưa chắc có khả năng nhận diện khi chính quy trình đó đã trở nên không phù hợp.
Một nhân viên có thể vận hành thành thạo hệ thống.
Nhưng chưa chắc biết cách thiết kế một cơ chế mới khi xuất hiện vấn đề chưa có trong tài liệu.
Và một người có nhiều kinh nghiệm thực tế chưa chắc có khả năng chuyển kinh nghiệm thành một abstraction có thể tái sử dụng.
Đây không phải sự xúc phạm đối với họ.
Đó là những loại năng lực khác nhau.
Tôi không kỳ vọng mọi nhân viên phải trở thành Software Architect.
Nhưng nếu toàn bộ khả năng tạo ra những nguyên lý mới đều tập trung vào một người, tổ chức vẫn có một dependency rất lớn.
Đặc biệt khi founder liên tục phát triển hệ thống nhanh hơn những người khác có thể hiểu.
Hãy tưởng tượng người sáng lập nhìn thấy mối liên hệ giữa ba vấn đề.
Chỉ sau một cuộc trao đổi, anh ta đã hình thành một mô hình mới.
Ngày hôm sau, mô hình được chuyển thành một cơ chế.
Vài ngày sau, cơ chế đã xuất hiện trong phần mềm.
Đối với founder, quá trình đó rất rõ ràng.
Nhưng nhân viên chỉ nhìn thấy một hệ thống vừa thay đổi.
Họ không đi qua những bước quan sát, phân tích và loại bỏ giả thuyết đã diễn ra trong đầu người thiết kế.
Vì vậy, họ có thể biết phải làm gì với chức năng mới.
Nhưng không hiểu đầy đủ tại sao chức năng đó được tạo ra.
Đến khi một tình huống chưa được mô hình hóa xuất hiện, họ lại quay về hỏi founder.
Và vòng lặp tiếp tục.
The founder can transfer a solution much faster than the organization can absorb the reasoning behind it.
Đây là một giới hạn rất khác với thiếu năng lực triển khai.
Nó là giới hạn của việc chuyển giao mô hình tư duy.
Và không thể giải quyết chỉ bằng cách viết thêm tài liệu hướng dẫn sử dụng.
05. Deployment không đồng nghĩa với Adoption. Adoption cũng chưa phải Capability.
Trong Chapter 7, tôi đã đề cập đến ba khái niệm.
Deployment. Adoption. Capability.
Tôi muốn quay lại với chúng.
Bởi vì đây là nơi tốc độ phát triển của founder có thể tạo ra một ảo giác nguy hiểm.
Một chức năng mới được triển khai.
Về mặt kỹ thuật, dự án đã hoàn thành.
Nhưng nhân viên chưa chắc đã sử dụng đúng.
Sau một thời gian, nhân viên bắt đầu sử dụng.
Tỷ lệ adoption tăng.
Nhưng điều đó vẫn chưa chứng minh rằng chức năng mới đã trở thành một năng lực ổn định của tổ chức.
Một nhân viên có thể sử dụng phần mềm mà không hiểu nguyên lý.
Một quản lý có thể theo dõi dashboard mà không thay đổi cách ra quyết định.
Một bộ phận có thể thực hiện quy trình mới nhưng vẫn cần founder giải quyết những tình huống nằm ngoài kịch bản.
Một công cụ có thể được sử dụng thường xuyên nhưng chỉ vì quy trình bắt buộc, không phải vì nó đang tạo ra kết quả tốt hơn.
Tôi muốn một tiêu chuẩn cao hơn.
Một năng lực chỉ thực sự trưởng thành khi những người chịu trách nhiệm có khả năng sử dụng, kiểm chứng, duy trì và cải thiện nó trong phạm vi được giao.
Không cần phải hiểu mọi chi tiết kỹ thuật.
Nhưng phải đủ hiểu để nhận diện khi công cụ không còn phản ánh đúng thực tế.
Phải biết ai chịu trách nhiệm.
Phải biết cách xử lý những ngoại lệ phù hợp.
Và phải có khả năng vận hành mà không cần tác giả ban đầu liên tục can thiệp.
Đây là một chu kỳ dài hơn việc triển khai phần mềm.
Một ý tưởng được thiết kế trong đầu founder có thể hình thành rất nhanh.
Nhưng để một đội ngũ hiểu và sử dụng nó một cách đáng tin cậy, tổ chức cần thời gian.
Đào tạo.
Thực hành.
Phản hồi.
Điều chỉnh.
Và đôi khi thay đổi cả những thói quen đã tồn tại nhiều năm.
Nếu founder liên tục đưa ra thêm những thay đổi trước khi quá trình ấy hoàn tất, tổ chức có thể rơi vào một trạng thái rất kỳ lạ.
Nó sở hữu ngày càng nhiều công cụ.
Nhưng khả năng sử dụng thực tế không tăng tương ứng.
Nhân viên liên tục học cái mới.
Quản lý liên tục cập nhật quy trình.
Và những năng lực chưa kịp ổn định đã phải thích nghi với một phiên bản khác.
The organization is not necessarily resisting change. It may simply be unable to absorb change at the rate it is being produced.
Tôi không muốn gọi mọi sự chậm trễ là sự chống đối.
Đôi khi đó là một giới hạn rất thực tế về năng lực học hỏi và triển khai.
Và nếu người thiết kế không nhìn thấy giới hạn ấy, anh ta có thể tiếp tục tạo ra thêm thay đổi.
Với thiện chí hoàn toàn tốt.
Để giải quyết những vấn đề do chính tốc độ thay đổi trước đó góp phần tạo ra.
Một vòng lặp khá khó chịu.
Đặc biệt khi người tạo ra nó rất giỏi viết code.
06. Một hệ thống tốt phải có nhịp độ mà tổ chức có thể hấp thụ.
Tôi không cho rằng giải pháp là founder phải chậm lại trong mọi việc.
Đôi khi tốc độ phát triển công nghệ là lợi thế cạnh tranh quan trọng.
Và có những cơ hội thị trường không thể đợi đến khi toàn bộ tổ chức cảm thấy hoàn toàn sẵn sàng.
Nhưng phải phân biệt tốc độ tạo ra thay đổi với tốc độ đưa thay đổi vào hoạt động thực tế.
Một ý tưởng có thể được phát triển nhanh.
Một prototype có thể được thử nghiệm sớm.
Một capability mới có thể được xây dựng trên nền tảng chung.
Nhưng không nhất thiết mọi thứ đều phải lập tức thay đổi cách toàn bộ doanh nghiệp vận hành.
Tôi muốn nghĩ đến hai nhịp độ khác nhau.
Exploration — Khám phá.
Nơi những ý tưởng mới được tạo ra, thử nghiệm và kiểm chứng trong phạm vi phù hợp.
Exploitation — Khai thác.
Nơi những năng lực đã được kiểm chứng được đưa vào hoạt động đáng tin cậy để tạo ra kết quả kinh doanh.
Hai hoạt động cần những điều kiện khác nhau.
Khám phá cần tốc độ, sự linh hoạt và khả năng chấp nhận những giả thuyết sai.
Vận hành cần sự ổn định, tính nhất quán và trách nhiệm rõ ràng.
Nếu áp dụng toàn bộ nguyên tắc vận hành nghiêm ngặt cho mọi thử nghiệm nhỏ, chúng ta có thể làm chết khả năng sáng tạo.
Nhưng nếu đưa mọi thử nghiệm vào production với tinh thần "cứ làm rồi sửa", chúng ta có thể gây ra hỗn loạn không cần thiết.
Tôi muốn một cơ chế có thể kết nối hai thế giới.
Một ý tưởng được thử nghiệm.
Nếu có giá trị, nó được chuẩn bị để đưa vào vận hành.
Những người chịu trách nhiệm được xác định.
Những quy trình liên quan được điều chỉnh.
Những dữ liệu cần thiết được bảo đảm.
Và khả năng sử dụng thực tế được kiểm chứng trước khi mở rộng.
The speed of invention and the speed of institutionalization do not have to be identical.
Tốc độ phát minh và tốc độ thể chế hóa năng lực không nhất thiết phải giống nhau.
Một founder có thể tiếp tục khám phá rất nhanh.
Nhưng tổ chức cần cơ chế lựa chọn những gì đáng được hấp thụ, trong thứ tự và phạm vi phù hợp.
Không phải mọi tính năng được xây dựng đều đáng trở thành quy trình chung.
Không phải mọi prototype đều cần triển khai cho tất cả nhân viên.
Và không phải mọi ý tưởng của founder đều phải được xem là ưu tiên cao nhất chỉ vì người đưa ra nó là founder.
Tôi nghĩ đây là một sự thay đổi rất quan trọng.
Người sáng lập không chỉ phải học cách tạo ra ý tưởng tốt.
Anh ta còn phải học cách chấp nhận rằng một ý tưởng tốt vẫn có thể chưa đáng được triển khai ngay.
Điều đó nghe khá đơn giản.
Cho đến khi chính mình vừa nghĩ ra một ý tưởng cực kỳ thú vị.
Và có đủ khả năng viết xong nó trước bữa tối.
07. Learned Helplessness — Khi tổ chức học cách không tự quyết định.
Có một hiện tượng mà tôi nghĩ người lãnh đạo phải đặc biệt cảnh giác.
Một nhân viên ban đầu có khả năng tự giải quyết vấn đề.
Họ đưa ra quyết định.
Quyết định chưa hoàn hảo.
Người quản lý can thiệp.
Chỉ ra sai sót.
Và trực tiếp đưa ra cách làm đúng.
Lần sau, nhân viên cẩn thận hơn.
Họ hỏi trước khi quyết định.
Người quản lý hài lòng vì không còn xảy ra lỗi.
Sau một thời gian, nhân viên bắt đầu hỏi về ngày càng nhiều tình huống.
Một số rất đơn giản.
Một số đã có thể tự xử lý.
Nhưng hỏi trước vẫn an toàn hơn.
Bởi vì quyết định do cấp trên đưa ra thường giúp giảm rủi ro trách nhiệm cá nhân.
Và nếu người quản lý có xu hướng chỉnh sửa mọi phương án khác với cách mình sẽ làm, nhân viên càng có ít động lực để tự quyết.
Đến một ngày, người quản lý nhìn vào đội ngũ và cảm thấy thất vọng.
"Tại sao cái gì cũng phải hỏi?"
Tôi muốn đặt lại câu hỏi ấy.
Tổ chức đã tạo ra những điều kiện gì khiến việc hỏi trở thành lựa chọn hợp lý hơn việc tự quyết?
Có thể nhân viên thiếu năng lực.
Có thể quyền hạn chưa rõ.
Có thể dữ liệu không đủ.
Có thể rủi ro của một quyết định sai không tương xứng với quyền lợi của việc quyết định đúng.
Và có thể người quản lý đã vô tình dạy nhân viên rằng cách an toàn nhất là không chủ động.
Tôi không cho rằng mọi sự phụ thuộc đều là kết quả của môi trường.
Có những người thực sự không muốn nhận trách nhiệm lớn hơn.
Có những người chưa đủ khả năng phán đoán.
Và có những vị trí không yêu cầu mức độ tự chủ cao.
Nhưng một tổ chức trưởng thành phải phân biệt được những nguyên nhân đó.
Nếu không, chúng ta có thể tiếp tục phàn nàn về thái độ của nhân viên trong khi chính kiến trúc quyền hạn đang khuyến khích thái độ ấy.
People adapt to the decision environment we create, not merely to the values we announce.
Một tổ chức có thể treo khẩu hiệu Ownership trên tường.
Nhưng nếu mọi quyết định quan trọng đều phải xin phép, nhân viên sẽ học theo cấu trúc quyền lực thực tế.
Không phải theo khẩu hiệu.
Một người lãnh đạo có thể nói rằng mình rất thích phản biện.
Nhưng nếu mọi lập luận trái ý đều bị bác bỏ chỉ vì không giống cách suy nghĩ của người lãnh đạo, nhân viên sẽ học cách đồng ý.
Một doanh nghiệp có thể khuyến khích thử nghiệm.
Nhưng nếu mọi thử nghiệm không thành công đều bị xem là sai lầm cần quy trách nhiệm, con người sẽ chọn những phương án an toàn nhất.
Và đến một thời điểm, người lãnh đạo có thể phát hiện mình đang điều hành một tổ chức rất biết nghe lời.
Nhưng không có nhiều người biết suy nghĩ độc lập.
Một kết quả có thể dự đoán được.
Chỉ là hơi khó chịu khi phải thừa nhận ai đã góp phần tạo ra nó.
08. Founder không thể chỉ chuyển giao câu trả lời. Phải chuyển giao khả năng tạo ra câu trả lời.
Có một cách đào tạo mà tôi nghĩ rất phổ biến.
Người có kinh nghiệm giải thích cách xử lý một tình huống.
Nhân viên ghi nhớ.
Sau đó thực hiện.
Cách này phù hợp với những công việc đã có quy tắc rõ ràng.
Nhưng nếu mục tiêu là phát triển khả năng phán đoán, nó chưa đủ.
Tôi muốn nhân viên học cách xác định vấn đề.
Phân biệt dữ liệu với giả định.
Nhận diện những ràng buộc quan trọng.
Xem xét những phương án.
Và giải thích tại sao lựa chọn một phương án thay vì những phương án còn lại.
Hãy tưởng tượng một nhân viên hỏi:
"Trường hợp này mình có nên hỗ trợ khách không?"
Thay vì trả lời ngay, người quản lý có thể hỏi:
"Em nghĩ sao?"
Nhân viên đưa ra phương án.
Người quản lý tiếp tục:
"Em đang dựa trên những dữ liệu nào?"
"Rủi ro lớn nhất của quyết định này là gì?"
"Nếu khách hàng khác yêu cầu tương tự, nguyên tắc này có còn hợp lý không?"
"Và điều gì có thể khiến em thay đổi quyết định?"
Những câu hỏi ấy không nhằm làm khó nhân viên.
Chúng giúp người đó tiếp xúc với cấu trúc tư duy đứng sau quyết định.
Tất nhiên, không phải tình huống nào cũng có thời gian để đào tạo theo cách này.
Một sự cố khẩn cấp có thể cần quyết định nhanh.
Một giao dịch đơn giản có thể đã có quy tắc đầy đủ.
Và một người chưa có kiến thức nền tảng cần được cung cấp kiến thức trước khi có thể phân tích độc lập.
Nhưng với những người có tiềm năng, tôi muốn tạo ra những cơ hội thực hành phán đoán có kiểm soát.
Không chỉ hỏi họ sẽ làm gì.
Mà hỏi tại sao.
Sau đó quan sát kết quả thực tế.
Nếu nhận định sai, phải hiểu sai ở đâu.
Thiếu dữ liệu?
Sai giả định?
Đánh giá rủi ro chưa đầy đủ?
Hay mô hình ra quyết định chưa phản ánh đúng bối cảnh?
Đây là một dạng đào tạo khó hơn việc truyền đạt quy trình.
Nhưng nó có thể tạo ra giá trị lớn hơn.
Teaching someone what to decide transfers an answer. Teaching them how to reason transfers the possibility of future answers.
Tôi không kỳ vọng mọi người phải đạt đến cùng một trình độ phán đoán.
Nhưng những người được giao trách nhiệm ngày càng lớn phải có cơ hội phát triển năng lực tương ứng.
Và khi họ đã chứng minh được năng lực, tổ chức phải thực sự trao quyền.
Không thể yêu cầu một người phát triển khả năng ra quyết định rồi liên tục phủ quyết mọi quyết định khác với cách mình sẽ làm.
Nếu kết quả nằm trong phạm vi chấp nhận được, những phương pháp khác nhau có thể cùng tồn tại.
Đó là một điều người giỏi thiết kế thường khó chấp nhận.
Bởi vì họ có thể nhìn thấy một phương án tốt hơn.
Và muốn mọi người sử dụng nó.
Nhưng nếu mỗi lần nhìn thấy phương án tốt hơn đều trực tiếp can thiệp, chúng ta có thể vô tình ngăn người khác phát triển khả năng tìm ra phương án của chính họ.
Một cái giá không nhỏ.
Đặc biệt khi mục tiêu dài hạn là xây dựng một tổ chức không cần founder quyết định mọi thứ.
09. Người thay thế founder không nhất thiết phải là một founder thứ hai.
Khi doanh nghiệp gặp giới hạn vận hành, một giải pháp thường được đề xuất là tuyển người quản lý giỏi hơn.
Một COO.
Một Operation Head.
Một người có khả năng tổ chức nhân sự và xử lý hoạt động thường ngày.
Tôi nghĩ đây có thể là một quyết định rất quan trọng.
Nhưng tôi không tin chỉ cần tuyển một người đủ giỏi là mọi vấn đề sẽ biến mất.
Bởi vì nếu người mới được kỳ vọng phải hiểu toàn bộ hệ thống như founder, đưa ra quyết định nhanh như founder, có khả năng abstraction như founder và đồng thời điều hành con người tốt hơn founder, chúng ta đang tìm kiếm một tổ hợp năng lực rất hiếm.
Và có thể không cần thiết.
Tôi muốn phân biệt hai vai trò.
System Architect — Người thiết kế cấu trúc và những năng lực nền tảng.
Operational Leader — Người chịu trách nhiệm chuyển cấu trúc thành hoạt động ổn định và kết quả có thể lặp lại.
Hai vai trò có vùng giao nhau.
Nhưng không đồng nhất.
Một người có thể rất giỏi nhận diện những nguyên lý mới.
Giỏi thiết kế phần mềm.
Giỏi giải quyết những vấn đề chưa từng xuất hiện.
Nhưng không nhất thiết là người tốt nhất để tổ chức một đội ngũ lớn, xây dựng thói quen vận hành, phát triển quản lý cấp trung và duy trì kỷ luật hằng ngày.
Ngược lại, một người có năng lực vận hành xuất sắc không nhất thiết phải tự thiết kế lại toàn bộ kiến trúc công nghệ.
Họ cần hiểu đủ về hệ thống để sử dụng, kiểm chứng và cải thiện hoạt động trong phạm vi trách nhiệm.
Không cần trở thành tác giả của mọi abstraction.
Tôi không muốn tuyển một người có khả năng suy nghĩ giống hệt mình.
Tôi muốn tìm một người có năng lực bổ sung vào những gì tổ chức đang thiếu.
The purpose of an operational leader is not to replicate the founder's mind. It is to build an organization that no longer requires that mind for ordinary execution.
Đây là một khác biệt rất lớn.
Nếu một Operation Head phải liên tục hỏi founder về mọi quyết định, họ chưa thực sự sở hữu trách nhiệm vận hành.
Nếu founder vẫn trực tiếp chỉ đạo nhân viên bên dưới, bỏ qua người quản lý mới mỗi khi muốn giải quyết vấn đề nhanh hơn, quyền hạn của người đó sẽ trở nên thiếu nhất quán.
Và nếu tổ chức không hiểu ai thực sự có quyền quyết định, chúng ta có thể tạo ra hai hệ thống chỉ huy.
Một hệ thống trên sơ đồ.
Và một hệ thống trong thực tế.
Kết quả rất dễ đoán.
Nhân viên sẽ tìm đến người có quyền lực cuối cùng.
Thường là founder.
Và người quản lý mới trở thành một tầng trung gian không đủ thẩm quyền.
Một mô hình vừa tốn thêm chi phí quản lý, vừa không giải quyết được nút thắt ban đầu.
Không phải một cải tiến đáng tự hào.
10. Bổ nhiệm một người quản lý không tự động tạo ra quyền lực quản lý.
Tôi nghĩ có một sự khác biệt giữa chức danh và quyền lực thực tế.
Một người được bổ nhiệm làm trưởng bộ phận.
Trên giấy tờ, họ có trách nhiệm quản lý.
Nhưng nếu nhân viên vẫn có thể bỏ qua họ để hỏi CEO, quyền hạn đó sẽ khó được thực thi nhất quán.
Nếu mọi quyết định quan trọng vẫn phải được CEO xác nhận, người quản lý có thể chịu trách nhiệm mà không thực sự có quyền.
Và nếu CEO thường xuyên thay đổi quyết định của họ trước mặt đội ngũ mà không có cơ chế giải thích hoặc điều chỉnh phù hợp, nhân viên sẽ nhanh chóng học được rằng người quản lý mới không phải người quyết định cuối cùng.
Không nhất thiết vì họ thiếu năng lực.
Mà vì hệ thống quyền lực thực tế chưa thay đổi.
Tôi không cho rằng founder phải tuyệt đối không can thiệp.
Người lãnh đạo cao nhất vẫn có trách nhiệm bảo vệ những nguyên tắc quan trọng.
Có những quyết định vượt khỏi phạm vi phân quyền.
Và có những tình huống cần can thiệp khi rủi ro nghiêm trọng xuất hiện.
Nhưng nếu mọi khác biệt trong phương pháp đều trở thành lý do để founder trực tiếp sửa, người được bổ nhiệm sẽ không có đủ không gian để hình thành năng lực lãnh đạo.
Tôi muốn một quá trình chuyển giao có cấu trúc.
Ban đầu, người quản lý hiểu hoạt động thực tế.
Quan sát những quy trình.
Nhận diện những vấn đề.
Làm việc với các nhóm.
Và xây dựng sự hiểu biết về hệ thống.
Sau đó, họ được giao những phạm vi trách nhiệm rõ ràng.
Có quyền quyết định tương ứng.
Có các mục tiêu và ràng buộc.
Có dữ liệu để đánh giá kết quả.
Và có cơ chế trao đổi với founder khi xuất hiện những vấn đề vượt khỏi thẩm quyền.
Không phải bổ nhiệm một chức danh rồi hy vọng mọi người tự động chấp nhận.
Tôi đặc biệt quan tâm đến những tổ chức đã có đội ngũ lâu năm.
Một người từ bên ngoài xuất hiện với chức danh cao có thể tạo ra phản ứng phòng thủ.
Những người cũ có kinh nghiệm thực tế.
Họ biết những khó khăn trong hoạt động.
Và có thể nghi ngờ người mới chưa hiểu doanh nghiệp.
Không phải sự nghi ngờ nào cũng vô lý.
Một Operation Head mới có thể đưa ra những đề xuất nghe rất chuyên nghiệp nhưng không phù hợp với những ràng buộc thực tế.
Nếu người đó được trao quyền quá lớn trước khi hiểu đủ hệ thống, những sai lầm ban đầu có thể khiến niềm tin suy giảm nghiêm trọng.
Nhưng nếu vì sợ phản ứng nội bộ mà không trao quyền thực sự, người mới cũng không có cơ hội chứng minh năng lực.
Tôi muốn một quá trình khác.
Authority should expand with demonstrated understanding and operational credibility.
Quyền hạn tăng cùng với hiểu biết và năng lực vận hành đã được chứng minh.
Không chỉ vì thời gian làm việc.
Cũng không chỉ vì chức danh.
Người mới cần cơ hội quan sát, phân tích và tạo ra những kết quả thực tế.
Đội ngũ cũ cần thấy năng lực ấy qua cách người đó giải quyết những vấn đề có thật.
Và founder phải có khả năng chuyển giao quyền quyết định một cách nhất quán khi các điều kiện đã được đáp ứng.
Không thể vừa bổ nhiệm người quản lý, vừa tiếp tục là đường tắt cho mọi vấn đề trong bộ phận.
Bởi vì nếu có hai người cùng được xem là người quyết định, nhân viên sẽ học cách lựa chọn người có câu trả lời thuận lợi hơn.
Và lúc ấy, thay vì giải quyết bottleneck, chúng ta vừa tạo ra một hệ thống cạnh tranh quyền lực.
Một dạng chaos rất giàu tính nhân văn.
Nhưng không đặc biệt tốt cho vận hành.
11. Trao quyền thật nghĩa là chấp nhận người khác không làm giống mình.
Tôi nghĩ đây là phần khó nhất với một founder có năng lực thiết kế mạnh.
Một người quản lý được giao trách nhiệm.
Họ phân tích vấn đề.
Đưa ra phương án.
Phương án đó không giống cách founder sẽ làm.
Founder nhìn vào và nhanh chóng nhận ra một cách có vẻ tốt hơn.
Phải làm gì?
Can thiệp?
Giải thích?
Hay để người quản lý thực hiện?
Tôi không nghĩ có một câu trả lời đúng cho tất cả tình huống.
Nếu phương án vi phạm những ràng buộc quan trọng, cần can thiệp.
Nếu có rủi ro không chấp nhận được, cần xử lý.
Nếu người quản lý đang sử dụng thông tin sai, cần cung cấp thông tin.
Nhưng nếu phương án nằm trong giới hạn hợp lý, có khả năng tạo ra kết quả tốt và rủi ro có thể kiểm soát, tôi nghĩ phải cân nhắc một điều.
Có phải sự khác biệt thực sự là vấn đề, hay chỉ vì phương án ấy không giống cách mình sẽ thực hiện?
Đây là một câu hỏi khó.
Bởi vì người có kinh nghiệm thường có lý do tốt để tin vào cách làm của mình.
Họ đã gặp nhiều tình huống.
Đã nhìn thấy nhiều sai lầm.
Và có thể dự đoán những tác dụng phụ mà người khác chưa nhận ra.
Nhưng năng lực dự đoán tốt không tự động có nghĩa mọi phương án khác đều không thể chấp nhận.
Một phương án có thể chưa tối ưu nhưng vẫn đủ tốt.
Một người quản lý có thể học được rất nhiều khi tự chịu trách nhiệm với quyết định của mình.
Và một cách làm khác có thể tạo ra những kết quả mà founder chưa từng dự đoán.
Nếu founder liên tục can thiệp để tối ưu mọi quyết định, tổ chức có thể đạt kết quả tốt hơn trong ngắn hạn.
Nhưng mất đi cơ hội phát triển năng lực phán đoán độc lập.
Đây là một trade-off thực sự.
Không thể chỉ giải quyết bằng khẩu hiệu trao quyền.
Delegation requires tolerating acceptable imperfection, not accepting unacceptable risk.
Trao quyền đòi hỏi chấp nhận những khác biệt và sai sót trong phạm vi có thể kiểm soát.
Không phải chấp nhận mọi rủi ro.
Tôi muốn thiết kế ranh giới đủ rõ để phân biệt hai thứ đó.
Những điều kiện nào bắt buộc phải đúng?
Những kết quả nào được xem là chấp nhận được?
Những quyết định nào có thể đảo ngược?
Và khi nào người quản lý có quyền lựa chọn phương pháp riêng?
Nếu không xác định được, founder sẽ liên tục phải dựa vào cảm giác cá nhân để quyết định có nên can thiệp hay không.
Mà cảm giác cá nhân của một người rất giỏi có thể trở thành một cơ chế kiểm soát cực kỳ khó vượt qua.
Bởi vì gần như lúc nào anh ta cũng nhìn thấy một cách tốt hơn.
Và nếu chỉ có cách tốt nhất trong đầu founder mới được chấp nhận, tổ chức sẽ không bao giờ thực sự có nhiều người ra quyết định.
Nó chỉ có nhiều người chuẩn bị phương án để founder lựa chọn.
Một dạng phân quyền khá hài hước.
12. Đừng xây một lớp quản lý chỉ để chuyển thông tin lên founder.
Khi doanh nghiệp lớn lên, người sáng lập thường bắt đầu tuyển hoặc bổ nhiệm các cấp quản lý trung gian.
Điều đó có thể giúp phân phối trách nhiệm.
Nhưng cũng có thể tạo ra một cấu trúc không hiệu quả.
Nhân viên báo vấn đề cho trưởng nhóm.
Trưởng nhóm tổng hợp.
Chuyển cho trưởng bộ phận.
Trưởng bộ phận xem xét.
Sau đó chuyển cho founder.
Founder ra quyết định.
Thông tin được truyền ngược xuống.
Đến nhân viên.
Công việc tiếp tục.
Nếu mục tiêu ban đầu là giảm thời gian founder phải xử lý vấn đề, cấu trúc này có thể chưa giải quyết được gì.
Nó chỉ bổ sung thêm nhiều bước truyền đạt.
Và mỗi bước có nguy cơ làm mất một phần ngữ cảnh.
Tôi không muốn các cấp quản lý chỉ trở thành hệ thống định tuyến yêu cầu.
Một người quản lý phải sở hữu một phạm vi kết quả.
Không chỉ sở hữu quyền chuyển thông tin.
Họ phải biết mình được phép quyết định điều gì.
Phải có những nguồn lực cần thiết trong phạm vi trách nhiệm.
Phải có khả năng tổ chức con người.
Và phải chịu trách nhiệm về chất lượng vận hành.
Điều này không có nghĩa mọi quản lý đều cần toàn quyền.
Một số quyết định vẫn phải được đưa lên cấp cao hơn.
Nhưng những trường hợp đó phải có lý do rõ ràng.
Tôi thích phân biệt ba tình huống.
Escalation vì thiếu quyền hạn.
Đây có thể là một ranh giới được thiết kế đúng, hoặc là một cơ hội cần xem xét phân quyền.
Escalation vì thiếu thông tin hoặc năng lực.
Đây có thể là vấn đề dữ liệu, đào tạo hoặc sự phù hợp của vai trò.
Escalation vì tình huống thực sự mới hoặc có rủi ro vượt ngưỡng.
Đây là nơi năng lực phán đoán ở cấp cao hơn có thể tạo ra giá trị.
Ba tình huống không nên được đối xử giống nhau.
Nếu mọi yêu cầu đều được chuyển lên vì "cho chắc", founder vẫn sẽ là người quyết định mọi thứ.
Nếu mọi yêu cầu đều bị buộc xử lý ở cấp thấp để chứng minh đã phân quyền, những tình huống rủi ro cao có thể không được xử lý phù hợp.
Tôi muốn một đường escalation có ý nghĩa.
Không phải một đường ống đưa tất cả vấn đề lên người có chức danh cao nhất.
A management layer should absorb decisions, not merely relay them.
Một tầng quản lý tốt phải hấp thụ được một phần trách nhiệm ra quyết định.
Không chỉ chuyển tiếp trách nhiệm đó.
Và khi một loại vấn đề liên tục bị đưa lên cùng một cấp, chúng ta cần xem xét liệu cơ chế hiện tại có phù hợp không.
Có thể cần mở rộng quyền hạn.
Có thể cần đào tạo.
Có thể cần thay đổi quy tắc.
Hoặc có thể phải thừa nhận rằng người đang giữ vai trò đó chưa có đủ năng lực.
Không phải giải pháp nào cũng là phần mềm.
Không phải giải pháp nào cũng là tuyển dụng.
Và không phải mọi vấn đề đều cần thêm một cấp quản lý.
Đôi khi, loại bỏ một tầng trung gian lại giúp tổ chức hoạt động tốt hơn.
Một ý tưởng khá nguy hiểm nếu được đề xuất trong cuộc họp có mặt toàn bộ tầng trung gian ấy.
13. Founder phải học cách phân biệt quyền kiểm soát và sự hiện diện.
Có một sự nhầm lẫn mà tôi nghĩ khá phổ biến.
Người lãnh đạo tin rằng mình đang kiểm soát tốt vì mọi quyết định quan trọng đều đi qua mình.
Mọi thông tin được báo cáo.
Mọi ngoại lệ được xin phép.
Mọi thay đổi đều được biết đến.
Và mọi vấn đề khó đều có thể được trực tiếp xử lý.
Nhưng sự hiện diện trong mọi hoạt động không đồng nghĩa với khả năng kiểm soát thực sự.
Một người có thể tham gia rất nhiều quyết định mà vẫn không hiểu được những nguyên nhân cấu trúc đang khiến vấn đề liên tục xuất hiện.
Ngược lại, một người có thể không trực tiếp tham gia vào từng giao dịch nhưng vẫn có khả năng kiểm soát những rủi ro quan trọng thông qua kiến trúc.
Dữ liệu đáng tin cậy.
Quyền hạn rõ ràng.
Ràng buộc được thực thi.
Những quyết định có khả năng truy vết.
Và cơ chế phát hiện kết quả bất thường.
Tôi muốn một loại quyền kiểm soát không phụ thuộc quá nhiều vào sự hiện diện liên tục của người lãnh đạo.
Không phải vì founder nên rời xa hoạt động kinh doanh.
Mà vì thời gian và sự chú ý của họ là những nguồn lực có giới hạn.
Tôi thích tiếp xúc với thực tế.
Nhìn cách nhân viên làm việc.
Quan sát khách hàng.
Phát hiện những điểm bất hợp lý trong quy trình.
Và trực tiếp kiểm chứng những giả định quan trọng.
Nhưng tôi muốn những lần tham gia đó có mục đích.
Observation is different from dependency.
Quan sát để học hỏi khác với phải có mặt để công việc tiếp tục.
Một founder bước vào kho để hiểu vì sao một quy trình thường xuyên chậm có thể tạo ra giá trị lớn.
Một founder phải trực tiếp giải quyết cùng một loại lỗi trong kho mỗi ngày có thể đang cho thấy một thiếu sót trong cấu trúc vận hành.
Hai tình huống có thể trông giống nhau.
Nhưng ý nghĩa hoàn toàn khác.
Tôi muốn có quyền truy cập vào thực tế.
Không muốn trở thành điều kiện để thực tế tiếp tục diễn ra.
Đây là một dạng kiểm soát trưởng thành hơn.
Và cũng khó đạt được hơn.
Bởi vì nó đòi hỏi người lãnh đạo phải tin vào những cơ chế đã được kiểm chứng, thay vì chỉ tin vào khả năng tự mình kiểm tra mọi thứ.
14. Một tổ chức không thể trưởng thành nếu mọi năng lực mới đều làm founder bận hơn.
Tôi nghĩ đây là một phép thử khá hữu ích.
Mỗi khi doanh nghiệp tạo ra một năng lực mới, hãy xem điều gì xảy ra với mức độ phụ thuộc vào founder.
Một nhóm bán hàng mới được hình thành.
Founder có phải trực tiếp quản lý thêm nhiều tình huống không?
Một công cụ mới được triển khai.
Founder có phải tiếp tục giải thích và xử lý ngoại lệ không?
Một micro-product được nhân viên xây dựng.
Founder có phải trở thành người hỗ trợ kỹ thuật mặc định không?
Một người quản lý được bổ nhiệm.
Founder có phải dành nhiều thời gian hơn để giải quyết mâu thuẫn quyền hạn không?
Một quy trình mới được đưa vào sử dụng.
Founder có phải tiếp tục kiểm tra từng trường hợp để bảo đảm mọi người thực hiện đúng không?
Không phải mọi câu trả lời "có" đều là tín hiệu xấu.
Ở giai đoạn chuyển đổi, mức độ tham gia của founder có thể tạm thời tăng.
Một hệ thống mới cần được kiểm chứng.
Một người quản lý mới cần được hỗ trợ.
Một nhóm mới cần thời gian phát triển.
Nhưng nếu sau khi năng lực đã trưởng thành mà mức độ phụ thuộc vẫn không giảm, chúng ta nên xem lại thiết kế.
Bởi vì một tổ chức có khả năng mở rộng phải tạo ra những năng lực có thể tiếp tục vận hành mà không liên tục tiêu thụ thêm thời gian của một người duy nhất.
A new capability that permanently increases founder dependency may not be genuine organizational leverage.
Đây là một tiêu chuẩn khá khó.
Nó không cho phép chúng ta chỉ đếm số lượng công cụ mới.
Không cho phép lấy sự phát triển của hệ thống làm bằng chứng rằng tổ chức đã phát triển tương ứng.
Và không cho phép nhầm việc founder có thể xử lý nhiều vấn đề hơn với việc doanh nghiệp đã có khả năng tự xử lý nhiều vấn đề hơn.
Tôi muốn quan sát những tín hiệu khác.
Tỷ lệ quyết định cần founder can thiệp có thay đổi không?
Những quyết định được phân quyền có duy trì chất lượng không?
Người quản lý có tự giải quyết được những vấn đề thuộc phạm vi trách nhiệm không?
Những ngoại lệ đã được hiểu có còn tiếp tục xuất hiện không?
Và khi founder không tham gia một thời gian, hoạt động thường ngày có tiếp tục đáng tin cậy không?
Nhưng cũng phải cẩn thận.
Giảm số lần hỏi founder bằng cách nhân viên âm thầm tự xử lý sai không phải thành công.
Giảm escalation bằng cách ngăn mọi người báo cáo vấn đề cũng không phải thành công.
Và một tổ chức không bao giờ làm phiền founder có thể đơn giản là một tổ chức đã ngừng chia sẻ những thông tin quan trọng.
Vì vậy, sự độc lập phải được đo cùng chất lượng.
Không chỉ số lượng yêu cầu.
Independence without accountability is not maturity. It is disconnection.
Tôi không muốn tổ chức ngừng hỏi tôi chỉ để chứng minh rằng nó đã trưởng thành.
Tôi muốn nó thực sự có khả năng đưa ra những quyết định tốt hơn mà không cần tôi trực tiếp tham gia.
Hai điều đó khác nhau.
15. Những gì founder làm tốt nhất cũng cần được đặt dưới sự kiểm chứng.
Tôi muốn nói đến một rủi ro khác.
Khi một founder đã giải quyết thành công rất nhiều vấn đề, tổ chức có thể bắt đầu hình thành niềm tin rằng anh ta thường đúng.
Điều đó có thể có cơ sở.
Kinh nghiệm.
Khả năng phân tích.
Hiểu biết về hệ thống.
Và những kết quả đã được chứng minh.
Nhưng có một khoảng cách giữa "thường đúng" và "không cần kiểm chứng".
Nếu một người có khả năng abstraction rất mạnh, họ có thể nhận diện những quy luật mà người khác chưa nhìn thấy.
Nhưng họ cũng có thể mắc những sai lầm ở cấp độ mô hình.
Và khi những mô hình đó được chuyển thành quy tắc, phần mềm hoặc cấu trúc tổ chức, ảnh hưởng của sai lầm có thể rất lớn.
Một nhân viên đưa ra quyết định sai có thể ảnh hưởng đến một giao dịch.
Một founder đưa ra một abstraction sai có thể khiến hàng nghìn giao dịch được xử lý theo cùng một logic không phù hợp.
Điều nguy hiểm là hệ thống vẫn có thể hoạt động rất ổn định.
Không có bug.
Không có lỗi thao tác.
Không có vi phạm quy trình.
Chỉ có một mô hình sai đang được thực thi rất nhất quán.
Tôi nghĩ người có quyền thiết kế càng lớn càng cần những cơ chế kiểm chứng tốt.
Không phải để hạn chế khả năng tạo ra ý tưởng.
Mà để bảo vệ tổ chức khỏi những giả định chưa được chứng minh.
Tôi muốn nhân viên có thể phản biện những quyết định trong phạm vi họ hiểu.
Người quản lý có thể chỉ ra những tác động vận hành mà người thiết kế chưa đánh giá đầy đủ.
Những người có chuyên môn sâu có thể đưa ra những thông tin khiến mô hình chung cần được điều chỉnh.
Và kết quả thực tế phải có quyền phủ quyết những niềm tin không còn phù hợp.
The architect's confidence is not a substitute for evidence.
Tôi không cho rằng mọi quyết định đều cần một cuộc biểu quyết tập thể.
Có những thời điểm người lãnh đạo phải đưa ra quyết định nhanh.
Có những vấn đề mà không phải ai cũng có đủ thông tin để đánh giá.
Và một tổ chức không thể vận hành bằng cách yêu cầu sự đồng thuận tuyệt đối cho mọi thay đổi.
Nhưng quyền quyết định cuối cùng không nên đồng nghĩa với quyền miễn kiểm chứng.
Một người có thể chịu trách nhiệm ra quyết định.
Đồng thời phải chấp nhận rằng quyết định ấy có thể sai.
Điều đó không làm suy giảm năng lực lãnh đạo.
Nó giúp quyền lực được sử dụng có trách nhiệm hơn.
Và có lẽ quan trọng hơn, nó tạo ra một môi trường nơi những người khác có cơ hội phát triển khả năng tư duy độc lập.
Nếu mọi phản biện đều bị xem là chống đối, tổ chức sẽ sớm có rất nhiều người đồng ý.
Không chắc có nhiều người thực sự suy nghĩ.
Một thành tựu đáng buồn.
Đặc biệt nếu founder luôn phàn nàn rằng mình thiếu người có khả năng connecting the dots.
16. Đừng biến người quản lý thành bản sao của founder.
Khi muốn phát triển đội ngũ lãnh đạo, người sáng lập có thể vô tình tìm kiếm những người suy nghĩ giống mình.
Cùng cách đánh giá vấn đề.
Cùng cách tổ chức công việc.
Cùng mức độ quyết liệt.
Cùng khả năng nhìn toàn cục.
Và cùng phong cách ra quyết định.
Tôi hiểu sức hấp dẫn của điều đó.
Làm việc với người có cách tư duy tương tự thường dễ dàng hơn.
Ít phải giải thích.
Ít mâu thuẫn.
Ít mất thời gian thống nhất.
Nhưng tôi không nghĩ một tổ chức mạnh nên được xây dựng từ những bản sao của một con người.
Bởi vì founder cũng có những giới hạn.
Một người rất giỏi thiết kế hệ thống có thể không phải người tốt nhất để phát triển quan hệ nhân sự.
Một người ra quyết định rất nhanh có thể chưa dành đủ thời gian giúp người khác hiểu quá trình ra quyết định.
Một người có khả năng phân tích rất sâu có thể mất kiên nhẫn với những người cần nhiều thời gian hơn để tiếp nhận.
Và một người thích thay đổi liên tục có thể không phải người phù hợp nhất để duy trì sự ổn định vận hành hằng ngày.
Tôi không xem những khác biệt đó là khuyết điểm tuyệt đối.
Chúng là những đặc điểm tạo ra lợi thế trong một số vai trò và giới hạn trong những vai trò khác.
Tôi muốn những người quản lý có thể bổ sung năng lực cho tổ chức.
Không chỉ làm cho founder cảm thấy dễ chịu khi làm việc cùng.
Một Operation Head có thể không giỏi viết code.
Không giỏi abstraction ở cấp độ kiến trúc phần mềm.
Nhưng họ có thể rất giỏi xây dựng kỷ luật vận hành.
Phát triển quản lý cấp trung.
Phân bổ nguồn lực.
Giải quyết xung đột.
Và biến những nguyên tắc đã được thiết kế thành thói quen tập thể.
Đó là những năng lực rất có giá trị.
Một người như vậy không nhất thiết phải hiểu mọi thứ nhanh bằng founder.
Nhưng phải có khả năng sở hữu kết quả trong phạm vi trách nhiệm.
Và khi gặp vấn đề mới, phải biết phân tích, huy động chuyên môn và đưa ra quyết định phù hợp.
The goal is complementary leadership, not cognitive cloning.
Tôi không muốn có thêm một founder thứ hai.
Tôi muốn một tổ chức ngày càng ít phụ thuộc vào sự hiện diện của founder thứ nhất.
Hai mục tiêu đó không giống nhau.
17. Không thể trao quyền cho một người chưa có đủ năng lực rồi gọi đó là phát triển tổ chức.
Tôi đã nói khá nhiều về sự cần thiết phải phân quyền.
Nhưng tôi muốn nhấn mạnh điều ngược lại.
Một tổ chức không trở nên trưởng thành chỉ vì founder quyết định rút lui khỏi hoạt động.
Nếu người nhận trách nhiệm chưa đủ năng lực, việc chuyển giao có thể làm chất lượng vận hành suy giảm.
Một người quản lý chưa hiểu đủ kinh tế đơn hàng có thể đưa ra những quyết định thương mại thiếu phù hợp.
Một người chưa có khả năng điều phối kho và vận chuyển có thể làm mất sự ổn định của hoạt động giao nhận.
Một người thiếu năng lực đánh giá rủi ro có thể phê duyệt những ngoại lệ vượt khỏi khả năng kiểm soát.
Và một người chưa đủ trưởng thành về trách nhiệm có thể sử dụng quyền hạn mới theo cách không phù hợp.
Tôi không muốn lý tưởng hóa việc ủy quyền.
Delegation is not a substitute for competence.
Trao quyền không thay thế được năng lực.
Nhưng cũng có một nghịch lý.
Nếu không bao giờ trao quyền, con người không có đủ cơ hội để phát triển năng lực ra quyết định.
Vậy phải làm sao?
Tôi muốn thiết kế một quá trình phát triển có giới hạn rủi ro.
Ban đầu, người được đào tạo có thể phân tích tình huống và đề xuất phương án.
Sau đó, họ được quyền quyết định trong những trường hợp có khả năng đảo ngược và mức độ rủi ro thấp.
Khi chứng minh được chất lượng phán đoán, phạm vi quyền hạn được mở rộng.
Những quyết định phức tạp hơn được giao cùng dữ liệu, công cụ và trách nhiệm tương ứng.
Và những ràng buộc quan trọng vẫn được bảo vệ ở tầng hệ thống.
Một người không cần phải sẵn sàng điều hành toàn bộ bộ phận mới có thể được giao một nhóm quyết định cụ thể.
Nhưng cũng không nên được giao toàn bộ bộ phận chỉ vì họ đã thực hiện tốt một nhóm quyết định nhỏ.
Năng lực phải được chứng minh theo phạm vi trách nhiệm.
Authority should expand at the pace of demonstrated judgment, not at the pace of the founder's impatience.
Đây là một nguyên lý tôi nghĩ đặc biệt quan trọng.
Bởi vì founder có thể rất muốn chuyển giao nhanh.
Họ đã quá bận.
Có quá nhiều vấn đề mới cần giải quyết.
Và rất muốn tìm một người có thể thay thế mình trong vận hành.
Nhưng sự thiếu kiên nhẫn của founder không khiến năng lực của người khác tự nhiên tăng nhanh hơn.
Một người có thể trung thực, tận tâm và có thái độ rất tốt.
Nhưng chưa đủ khả năng điều hành một hệ thống phức tạp.
Điều đó không biến họ thành người kém giá trị.
Nó chỉ có nghĩa tổ chức phải xác định đúng phạm vi trách nhiệm phù hợp.
Tôi không muốn trao một vai trò quá lớn cho một người chỉ vì họ là người đáng tin cậy nhất hiện tại.
Rồi đặt họ vào một tình huống vượt khỏi năng lực.
Sau đó thất vọng khi kết quả không tốt.
Nếu làm như vậy, có thể người quản lý chưa phải là người duy nhất đưa ra quyết định sai.
Người bổ nhiệm cũng cần xem lại mô hình đánh giá của mình.
Một kết luận không dễ chịu.
Nhưng cần thiết.
18. Founder phải quyết định những gì thực sự chỉ mình nên quyết định.
Tôi không nghĩ mục tiêu của một tổ chức trưởng thành là founder không cần ra quyết định nữa.
Điều đó không thực tế.
Người sáng lập vẫn có thể giữ những trách nhiệm rất quan trọng.
Định hướng chiến lược.
Những lựa chọn về mô hình kinh doanh.
Những quyết định đầu tư lớn.
Các nguyên tắc quản trị cốt lõi.
Những thay đổi kiến trúc có phạm vi ảnh hưởng rộng.
Và những vấn đề thực sự mới mà tổ chức chưa có đủ năng lực giải quyết.
Tôi muốn phân biệt những quyết định cần authority với những quyết định cần expertise.
Một quyết định có thể đòi hỏi thẩm quyền cao vì mức độ ảnh hưởng.
Nhưng không nhất thiết cần founder trực tiếp phân tích mọi chi tiết.
Ngược lại, một vấn đề kỹ thuật rất phức tạp có thể cần chuyên gia sâu nhưng không cần CEO là người giải quyết.
Nếu không phân biệt, chúng ta sẽ liên tục chuyển mọi thứ khó đến người có quyền lực cao nhất.
Dù người đó không phải người sở hữu chuyên môn phù hợp nhất.
Tôi muốn những quyết định được đưa đến nơi có đủ thông tin, năng lực và thẩm quyền.
Không mặc định đưa lên trên.
Một người quản lý vận hành có thể xử lý những quyết định thuộc phạm vi hoạt động.
Một chuyên gia kỹ thuật có thể đề xuất những thay đổi chuyên môn.
Một người phụ trách sản phẩm có thể chịu trách nhiệm về kết quả của micro-product.
Và founder tập trung vào những lựa chọn có tính hệ thống, chiến lược hoặc vượt khỏi ranh giới đã được phân quyền.
The founder should remain accountable for the architecture of the organization, not personally responsible for every operation inside it.
Tôi nghĩ đây là một bước chuyển quan trọng.
Từ người giải quyết vấn đề.
Sang người thiết kế khả năng giải quyết vấn đề.
Từ người trực tiếp tối ưu từng quyết định.
Sang người xây dựng những điều kiện để các quyết định có chất lượng được đưa ra ở nhiều nơi.
Và từ người sở hữu phần lớn tri thức quan trọng.
Sang người bảo đảm tổ chức có thể tích lũy, phân phối và phát triển tri thức ấy.
Không phải mất quyền kiểm soát.
Mà là thay đổi cách quyền kiểm soát được thực thi.
Một cách khó hơn việc trực tiếp chỉ đạo.
Nhưng có khả năng mở rộng lớn hơn nhiều.
19. Nút thắt nguy hiểm nhất có thể là niềm tin rằng mình vẫn đang giúp đỡ.
Tôi nghĩ không phải founder nào cũng muốn kiểm soát mọi thứ vì quyền lực.
Nhiều người đơn giản chỉ muốn doanh nghiệp vận hành tốt.
Họ nhìn thấy vấn đề.
Họ biết cách giải quyết.
Và họ can thiệp.
Một hành động hoàn toàn hợp lý ở cấp độ sự kiện.
Nhưng nếu lặp lại liên tục, nó có thể tạo ra một cấu trúc phụ thuộc.
Một nhân viên gặp vấn đề.
Founder giải quyết.
Một quản lý gặp khó khăn.
Founder hỗ trợ.
Một quy trình có lỗi.
Founder sửa.
Một dự án chậm tiến độ.
Founder trực tiếp tham gia.
Mỗi lần can thiệp đều có thể tạo ra giá trị ngay lập tức.
Nhưng tổ chức có học được cách xử lý vấn đề tương tự mà không cần can thiệp lần sau không?
Đây là câu hỏi tôi muốn tự đặt ra thường xuyên hơn.
Không phải:
"Hôm nay tôi đã giải quyết được bao nhiêu vấn đề?"
Mà là:
"Sau những vấn đề tôi đã giải quyết, tổ chức có giảm được bao nhiêu sự phụ thuộc vào chính tôi?"
Nếu câu trả lời liên tục là không, có thể tôi đang làm rất tốt công việc của một người xử lý ngoại lệ.
Nhưng chưa làm đủ tốt công việc của một người thiết kế tổ chức.
Đây là một sự khác biệt khá khó chịu.
Bởi vì giải quyết vấn đề thường tạo ra cảm giác thành tựu ngay lập tức.
Một việc được hoàn tất.
Một người cảm ơn.
Một rủi ro được xử lý.
Một chức năng được triển khai.
Nhưng phát triển năng lực tổ chức thường chậm hơn.
Phải đào tạo.
Phải quan sát.
Phải cho người khác thử.
Phải chấp nhận những phương án chưa tối ưu.
Và đôi khi phải kiềm chế sự thôi thúc tự mình nhảy vào giải quyết.
Một người có khả năng giải quyết vấn đề rất nhanh có thể thấy quá trình đó cực kỳ khó chịu.
Họ nhìn thấy lời giải.
Nhưng phải dành thời gian giúp người khác hiểu.
Hoặc để người khác tự đi đến một lời giải đủ tốt.
Về mặt cảm xúc, việc tự làm có thể hấp dẫn hơn nhiều.
Về mặt kiến trúc dài hạn, nó có thể là lựa chọn sai.
The founder's most productive action is not always the action that produces the fastest immediate result.
Tôi nghĩ đây là một trong những bài học khó nhất của việc chuyển từ Software Engineer sang Organizational Architect.
Bởi vì trong phần mềm, tôi có thể sửa một lỗi bằng code.
Trong tổ chức, đôi khi tôi phải sửa chính cách mình phản ứng khi thấy người khác mắc lỗi.
Một công việc ít thú vị hơn.
Và khó debug hơn nhiều.
20. Một người giỏi có thể tạo ra lợi thế. Một tổ chức giỏi phải biết giữ lợi thế ấy mà không phụ thuộc vào người đó.
Tôi muốn trở lại với câu hỏi lớn nhất của chương này.
Điều gì tạo ra lợi thế cạnh tranh cho một doanh nghiệp?
Có thể là công nghệ.
Sản phẩm.
Quan hệ khách hàng.
Vận hành.
Khả năng phân phối.
Hoặc một người sáng lập có năng lực đặc biệt trong việc kết nối những yếu tố đó.
Tôi không phủ nhận vai trò của cá nhân.
Trong nhiều giai đoạn, một founder có thể là nguồn tạo ra sự khác biệt lớn nhất.
Nhưng có một khoảng cách giữa năng lực của founder và năng lực của tổ chức.
Nếu một người có khả năng giải quyết những vấn đề rất phức tạp, đó là năng lực cá nhân.
Nếu người đó chuyển một phần hiểu biết thành hệ thống giúp nhiều người xử lý công việc tốt hơn, đó bắt đầu là năng lực tổ chức.
Nếu tổ chức có thể duy trì, kiểm chứng và cải thiện những cơ chế đó mà không cần người thiết kế trực tiếp tham gia, năng lực ấy đã trưởng thành hơn.
Và nếu những người khác bắt đầu có khả năng phát hiện vấn đề mới, tạo abstraction mới và phát triển những giải pháp mới, tổ chức đang tiến đến một cấp độ khác.
Nó không còn chỉ sử dụng những gì founder đã tạo ra.
Nó bắt đầu có khả năng tiếp tục tạo ra những điều mới.
Tôi nghĩ đây là một chuyển đổi rất quan trọng.
From founder-generated capability to organization-generated capability.
Không phải founder ngừng sáng tạo.
Mà là khả năng sáng tạo và phát triển năng lực không còn tập trung hoàn toàn ở founder.
Một số người có thể phát triển chuyên môn.
Một số người có thể thiết kế quy trình.
Một số người có thể xây dựng sản phẩm.
Một số người có thể điều hành những đơn vị kinh doanh.
Và những người có khả năng tư duy kiến trúc có thể tiếp tục phát triển những cấu trúc giúp tất cả những năng lực đó kết hợp hiệu quả.
Tôi muốn tổ chức có khả năng tạo ra những con người như vậy.
Không nhất thiết với số lượng lớn ngay lập tức.
Không nhất thiết tất cả đều có khả năng như người sáng lập.
Nhưng phải có một quá trình phát triển rõ ràng.
Một người có tiềm năng được phát hiện.
Được giao trách nhiệm phù hợp.
Được tiếp xúc với những vấn đề khó hơn.
Được phản biện.
Được kiểm chứng.
Và nếu chứng minh được năng lực, được trao thêm quyền hạn và nguồn lực.
Theo thời gian, một số người có thể trở thành những người lãnh đạo hoặc kiến trúc sư trong phạm vi chuyên môn của mình.
Đó là một dạng tăng trưởng khác với việc chỉ tuyển thêm nhân viên.
A scalable organization does not merely add people. It develops new centers of capability.
Tôi không muốn mọi con đường quyết định đều dẫn về một trung tâm.
Tôi muốn nhiều trung tâm năng lực có thể tồn tại trong một kiến trúc trách nhiệm chung.
Và nếu chúng được thiết kế tốt, tổng khả năng của tổ chức có thể vượt xa khả năng xử lý của bất kỳ cá nhân nào.
Kể cả founder.
Đó mới là mục tiêu đáng theo đuổi.
21. The Architect Must Become Replaceable — Nhưng không theo cách nhiều người nghĩ.
Có một câu nói thường xuất hiện khi bàn về xây dựng doanh nghiệp.
"Người lãnh đạo giỏi là người có thể nghỉ mà công ty vẫn hoạt động."
Tôi đồng ý một phần.
Nhưng tôi không cho rằng đó là tiêu chuẩn đầy đủ.
Một doanh nghiệp có thể tiếp tục xử lý đơn hàng trong hai tuần không có founder.
Kho vẫn xuất hàng.
Nhân viên vẫn bán hàng.
Kế toán vẫn kiểm soát tài chính.
Vận chuyển vẫn hoạt động.
Điều đó là một tín hiệu tốt về tính ổn định vận hành.
Nhưng chưa chắc chứng minh doanh nghiệp có khả năng tiếp tục phát triển.
Có thể mọi hoạt động thường ngày vẫn diễn ra.
Nhưng những quyết định chiến lược bị trì hoãn.
Những vấn đề mới không được phân tích.
Những cơ hội không được khai thác.
Và những thay đổi kiến trúc quan trọng vẫn phải chờ founder quay lại.
Vì vậy, tôi muốn phân biệt hai cấp độ.
Operational Independence — Độc lập vận hành.
Những hoạt động đã được hiểu rõ có thể tiếp tục đáng tin cậy khi founder không trực tiếp tham gia.
Evolutionary Independence — Độc lập phát triển.
Tổ chức có khả năng phát hiện những thay đổi, giải quyết một phần vấn đề mới và tiếp tục cải thiện những năng lực của mình mà không cần mọi sáng kiến đều xuất phát từ founder.
Cấp độ thứ nhất đã rất đáng giá.
Nhưng cấp độ thứ hai mới là nơi khả năng mở rộng dài hạn trở nên thực sự thú vị.
Tôi không nghĩ founder phải hoàn toàn có thể bị thay thế trong mọi lĩnh vực ngay lập tức.
Có những năng lực chiến lược và kiến trúc có thể tiếp tục cần người sáng lập trong thời gian dài.
Đặc biệt ở những doanh nghiệp phát triển dựa trên năng lực đặc biệt của người đó.
Nhưng mức độ phụ thuộc phải được nhận diện và quản lý có chủ đích.
Không nên mặc định rằng vì founder đang giỏi nhất nên mọi quyết định quan trọng phải mãi mãi phụ thuộc vào founder.
Một hệ thống có thể phát triển theo từng bước.
Đầu tiên, giảm phụ thuộc vào những quyết định lặp lại.
Sau đó, xây dựng đội ngũ vận hành có khả năng sở hữu kết quả.
Tiếp theo, phát triển những người có khả năng phân tích và xử lý các vấn đề mới trong phạm vi chuyên môn.
Và cuối cùng, tạo ra một kiến trúc cho phép những năng lực mới được xây dựng mà không phải liên tục đi qua người sáng lập.
Tôi thích nghĩ rằng mục tiêu không phải khiến founder trở nên không còn giá trị.
Mà là khiến giá trị của founder không còn bị tiêu hao vào những việc đã có thể được người khác hoặc hệ thống thực hiện tốt.
The architect should become less necessary for what has already been built, so he can remain valuable for what has yet to be imagined.
Đây là một dạng tự thay thế rất khác.
Không phải rời bỏ tổ chức.
Mà là liên tục đưa những năng lực đã trưởng thành ra khỏi phạm vi phụ thuộc trực tiếp vào mình.
Sau đó, tiếp tục giải quyết những vấn đề mới.
Nếu một ngày tổ chức có thể tự làm được những điều mà trước đây chỉ mình tôi có khả năng thực hiện, tôi không xem đó là sự suy giảm vai trò.
Tôi xem đó là bằng chứng của một kiến trúc đang trưởng thành.
Và nếu những người khác bắt đầu tạo ra những điều mà chính tôi chưa từng nghĩ đến?
Tôi nghĩ đó còn là một thành tựu lớn hơn.
Bởi vì lúc ấy, doanh nghiệp không chỉ có khả năng sử dụng những gì tôi đã xây dựng.
Nó đã bắt đầu phát triển vượt khỏi giới hạn của người xây dựng ban đầu.
Lời kết: The Founder's Bottleneck.
Tôi không ghét việc giải quyết vấn đề.
Tôi thích nó.
Đó là một trong những lý do tôi đến với Software Engineering.
Và cũng là một trong những điều khiến việc điều hành doanh nghiệp trở nên thú vị.
Một vấn đề phức tạp xuất hiện.
Tôi muốn hiểu nguyên nhân.
Nhìn thấy cấu trúc.
Tìm những điểm bất biến.
Thiết kế một cơ chế.
Và kiểm chứng xem cơ chế đó có thực sự tạo ra kết quả tốt hơn không.
Tôi không nghĩ niềm yêu thích ấy sẽ thay đổi.
Nhưng tôi bắt đầu hiểu rằng giải quyết được nhiều vấn đề không nhất thiết đồng nghĩa với việc xây dựng được một tổ chức có khả năng giải quyết vấn đề tốt hơn.
Một founder có thể làm việc rất nhiều.
Đưa ra rất nhiều quyết định đúng.
Tạo ra rất nhiều công cụ.
Và xây dựng những hệ thống kỹ thuật rất mạnh.
Nhưng nếu sau tất cả, mọi vấn đề khó vẫn phải đưa về anh ta, doanh nghiệp chưa thực sự thoát khỏi một giới hạn quan trọng.
Giới hạn của một con người.
Tôi không cho rằng vấn đề đó có thể được giải quyết bằng một quyết định bổ nhiệm.
Cũng không phải bằng một dự án phần mềm.
Nó đòi hỏi thay đổi kiến trúc quyền lực.
Thay đổi cách phát triển con người.
Thay đổi cách tri thức được chuyển giao.
Thay đổi cách những quyết định được phân phối.
Và có lẽ khó nhất, thay đổi cách founder định nghĩa giá trị của chính mình.
Trước đây, tôi có thể đánh giá một ngày làm việc tốt bằng số lượng vấn đề đã giải quyết.
Một lỗi được sửa.
Một cơ chế được triển khai.
Một quyết định được đưa ra.
Một dự án được thúc đẩy.
Những kết quả đó vẫn quan trọng.
Nhưng tôi muốn có thêm một tiêu chuẩn.
Hôm nay, tôi đã khiến tổ chức ít cần đến sự can thiệp của mình hơn ở những vấn đề nào?
Một nhân viên có thể tự xử lý một nhóm tình huống.
Một quản lý có thể sở hữu một phạm vi kết quả.
Một quy trình không còn cần người có kinh nghiệm giám sát liên tục.
Một micro-product có thể được xây dựng và kiểm chứng mà không cần founder trực tiếp viết code.
Một bộ phận có khả năng nhận diện và giải quyết những giới hạn vận hành của chính mình.
Và một người có tiềm năng bắt đầu phát triển thành một trung tâm năng lực mới.
Những điều đó có thể không tạo ra cảm giác thành tựu tức thì như việc tự mình giải quyết một vấn đề khó.
Nhưng chúng có khả năng tạo ra giá trị lâu dài hơn.
Bởi vì một vấn đề được giải quyết có thể giúp doanh nghiệp tiến thêm một bước.
Một năng lực được chuyển giao có thể giúp tổ chức tiếp tục tiến lên qua rất nhiều bước mà không cần người tạo ra nó phải trực tiếp tham gia.
Tôi nghĩ đó là sự khác biệt giữa một người giải quyết vấn đề xuất sắc và một người kiến trúc sư tổ chức.
Người đầu tiên tạo ra những câu trả lời.
Người thứ hai tạo ra những điều kiện để nhiều người có thể tiếp tục tìm ra câu trả lời.
Và để làm được điều đó, người kiến trúc sư phải chấp nhận một sự thật khá khó chịu.
Không phải mọi quyết định đều cần mình.
Không phải mọi vấn đề đều đáng để mình trực tiếp giải quyết.
Không phải mọi phương án khác với cách mình nghĩ đều sai.
Và không phải mọi thứ được mình xây dựng đều nên tiếp tục phụ thuộc vào mình.
Một số năng lực phải được chuyển thành quy trình.
Một số phải được chuyển thành phần mềm.
Một số phải được chuyển thành quyền hạn của người khác.
Và một số phải được phát triển thông qua những con người có khả năng hiểu, kiểm chứng và cải thiện chúng.
Tôi không muốn xây dựng một doanh nghiệp chỉ hoạt động tốt khi có một founder rất giỏi.
Tôi muốn xây dựng một doanh nghiệp mà năng lực của founder có thể trở thành nền tảng để những người khác tiếp tục phát triển.
The founder is a competitive advantage only until the organization becomes dependent on his presence rather than his judgment.
Một người sáng lập có thể là lợi thế cạnh tranh rất lớn.
Nhưng nếu tổ chức không thể vận hành và phát triển nếu thiếu sự hiện diện liên tục của anh ta, lợi thế ấy đang mang theo một giới hạn.
Tôi không nghĩ giới hạn đó tự động biến mất khi doanh nghiệp lớn hơn.
Nó có thể trở nên nghiêm trọng hơn.
Bởi vì số lượng nhân viên tăng.
Số lượng vấn đề tăng.
Số lượng quyết định tăng.
Và những sự phụ thuộc không được thiết kế lại sẽ tiếp tục tích tụ.
Đến một thời điểm, founder có thể cảm thấy mình đang làm việc chăm chỉ hơn bao giờ hết.
Công nghệ mạnh hơn bao giờ hết.
Đội ngũ đông hơn bao giờ hết.
Nhưng tốc độ phát triển của tổ chức không còn tương xứng.
Không phải vì founder đột nhiên kém đi.
Không phải vì mọi nhân viên đều thiếu năng lực.
Và cũng không nhất thiết vì công nghệ chưa đủ tốt.
Có thể đơn giản vì kiến trúc từng giúp doanh nghiệp thành công đã đạt đến giới hạn.
Một kiến trúc mà quá nhiều quyết định quan trọng vẫn phải đi qua cùng một người.
Một người có khả năng nhìn thấy cấu trúc trong hỗn loạn.
Có thể thiết kế abstraction.
Có thể xây dựng phần mềm.
Có thể giải quyết những ngoại lệ khó.
Và có thể đưa ra những quyết định mà người khác chưa đủ khả năng thực hiện.
Một người rất hữu ích.
Cho đến khi sự hữu ích ấy trở thành điều kiện bắt buộc để mọi thứ tiếp tục vận hành.
Tôi không muốn trở thành người như vậy mãi mãi.
Không phải vì tôi muốn nghỉ việc.
Mà vì tôi muốn doanh nghiệp có khả năng đi xa hơn những gì một mình tôi có thể tạo ra.
Nếu tôi thực sự tin vào triết lý mà mình đã theo đuổi từ đầu cuốn sách — rằng những vấn đề lặp lại cần được giải quyết bằng cách thay đổi cấu trúc tạo ra chúng — thì tôi không thể tiếp tục xem bản thân là một ngoại lệ.
Tôi cũng phải được đưa vào mô hình.
Năng lực của tôi.
Giới hạn của tôi.
Những quyết định đang phụ thuộc vào tôi.
Những cơ chế mà tôi chưa chuyển giao.
Và những hành vi của chính tôi đang khiến tổ chức tiếp tục quay về tìm mình.
Nếu một trăm vấn đề xuất hiện và tất cả đều cần đến cùng một người, tôi không thể chỉ hỏi tại sao một trăm con người khác chưa đủ giỏi.
Tôi phải hỏi:
Tại sao tôi lại thiết kế một tổ chức mà một trăm vấn đề ấy đều phải đi qua mình?
Có thể một phần vì những người khác chưa đủ năng lực.
Có thể một phần vì những vấn đề thực sự phức tạp.
Có thể một phần vì tổ chức đang phát triển quá nhanh.
Nhưng cũng có thể vì tôi đã liên tục tối ưu hệ thống xung quanh khả năng giải quyết vấn đề của chính mình.
Và bây giờ, chính khả năng ấy đang trở thành giới hạn.
Một kết luận khá khó chịu.
Đặc biệt với một người luôn thích tìm ra nguyên nhân cấu trúc của mọi thứ.
Bởi vì lần này, sau rất nhiều phân tích, tất cả những đường nối bắt đầu quay về cùng một điểm.
Không phải nhân viên.
Không phải phần mềm.
Không phải khách hàng.
Không phải thị trường.
Mà là một con người đã dành nhiều năm để thiết kế hệ thống.
Và chưa thiết kế đầy đủ cách hệ thống có thể phát triển mà không cần sự can thiệp liên tục của chính mình.
Tôi nghĩ đây là lúc người kiến trúc sư phải thực hiện một abstraction quan trọng hơn tất cả những abstraction trước đó.
Biến chính năng lực thiết kế, ra quyết định và phát triển hệ thống của mình thành những năng lực mà tổ chức có thể từng bước phân phối, kế thừa và tiếp tục cải thiện.
Không phải nhân bản bộ não.
Không phải tìm một người giống hệt mình.
Mà là thiết kế những điều kiện để ngày càng nhiều người có thể làm tốt những phần công việc từng phụ thuộc vào mình.
Và tiếp tục tạo ra những năng lực mới.
Bởi vì nếu một ngày doanh nghiệp thực sự có thể phát triển vượt khỏi những gì người sáng lập đã hình dung, đó mới là thành tựu lớn nhất của kiến trúc tổ chức.
Không phải tạo ra một công trình mà không ai khác có thể hiểu.
Mà là tạo ra một công trình có khả năng được những người khác tiếp tục xây dựng.
Tôi không muốn trở thành người không thể thay thế.
Tôi muốn xây dựng một thứ đủ tốt để sự hiện diện của mình ngày càng ít cần thiết cho những gì đã được hiểu rõ.
Và ngày càng có giá trị cho những gì chưa được khám phá.
Nhưng trước khi đạt đến điều đó, tôi phải chấp nhận một sự thật.
Có thể tôi đang là người giải quyết vấn đề nhanh nhất.
Có thể tôi đang hiểu hệ thống sâu nhất.
Có thể tôi vẫn là người có khả năng tạo ra những abstraction mới tốt nhất trong tổ chức.
Tất cả những điều đó có thể đúng.
Nhưng chúng không tự động chứng minh rằng tôi đã xây dựng được một tổ chức tốt.
Chúng chỉ chứng minh rằng tôi là một thành phần rất mạnh.
And a powerful component is not the same as a scalable architecture.
Chết tiệt.
Sau từng ấy năm viết phần mềm, cuối cùng tôi lại gặp một vấn đề rất quen thuộc.
Một hệ thống phụ thuộc quá nhiều vào một thành phần trung tâm.
Thành phần đó xử lý rất nhanh.
Có nhiều logic nghiệp vụ.
Có quyền truy cập gần như mọi thứ.
Được rất nhiều service khác gọi đến.
Và mỗi lần muốn thay đổi kiến trúc, người ta lại phát hiện mọi thứ đều đang phụ thuộc vào nó.
Trong Software Engineering, chúng ta có một số cách gọi cho những thành phần như vậy.
God Object.
God Service.
Single Point of Failure.
Một kiến trúc chứa quá nhiều trách nhiệm trong một nơi duy nhất.
Thường rất khó thay đổi.
Rất khó kiểm thử độc lập.
Và cực kỳ nguy hiểm khi phát triển đến một quy mô nhất định.
Tôi đã từng dành nhiều năm để tránh tạo ra những cấu trúc như vậy trong phần mềm.
Vậy mà khi xây dựng doanh nghiệp...
I accidentally became the God Object.
Một God Object có khả năng viết code.
Biết kinh doanh.
Có quyền phê duyệt.
Và thỉnh thoảng còn chửi nhân viên vì sao cái gì cũng phải hỏi.
Fucking brilliant.
Tôi nghĩ mình vừa tìm thấy một bài toán kiến trúc rất đáng để giải quyết.
Và lần này, giải pháp không thể chỉ là viết thêm một framework.
The Architect must redesign himself out of the critical path.
NEXT CHAPTER — BUILD A SYSTEM THAT OUTGROWS YOU
Đỉnh cao của người thiết kế không phải xây dựng một hệ thống không thể hoạt động nếu thiếu mình. Mà là một hệ thống có khả năng phát triển vượt khỏi giới hạn của chính người tạo ra nó.
The Architect of Chaos — Ông Chú Hay Chửi