Có một câu nói mà tôi nghĩ hầu hết những người điều hành doanh nghiệp đều từng sử dụng.
"Các em phải chủ động lên."
Nghe rất hợp lý.
Một tổ chức muốn phát triển không thể phụ thuộc vào việc người quản lý phải liên tục hướng dẫn từng công việc nhỏ.
Nhân viên cần biết tự giải quyết vấn đề.
Biết đưa ra quyết định.
Biết chịu trách nhiệm.
Và biết tìm những cách làm tốt hơn thay vì chỉ thực hiện những gì được giao.
Tôi hoàn toàn đồng ý.
Nhưng hãy tưởng tượng điều gì xảy ra tiếp theo.
Một nhân viên chủ động giảm giá để giữ khách hàng.
Quản lý không hài lòng vì biên lợi nhuận quá thấp.
Một nhân viên khác chủ động hỗ trợ phí vận chuyển.
Kế toán phản đối vì giao dịch không đáp ứng chính sách.
Một người chủ động cam kết thời gian giao hàng để chốt đơn.
Bộ phận vận chuyển không thể thực hiện.
Và một nhân viên khác chủ động thay đổi cách xử lý đơn hàng để tăng tốc độ phục vụ.
Kết quả là một bước kiểm soát quan trọng bị bỏ qua.
Sau một loạt sự cố, công ty bắt đầu bổ sung quy định.
Giảm giá phải xin phép.
Hỗ trợ vận chuyển phải xin phép.
Cam kết giao hàng đặc biệt phải xin phép.
Thay đổi quy trình phải xin phép.
Những tình huống chưa có trong tài liệu cũng phải xin phép.
Rồi một ngày, người lãnh đạo nhìn vào tổ chức và tự hỏi:
"Tại sao đám nhân viên này cái gì cũng phải hỏi?"
Tôi nghĩ đây là một trong những nghịch lý hài hước nhất của quản trị.
Chúng ta yêu cầu con người chủ động, sau đó thiết kế một hệ thống khiến sự chủ động trở thành hành vi nguy hiểm.
Và khi họ học được cách an toàn nhất là không tự quyết định điều gì, chúng ta lại kết luận rằng họ thiếu năng lực.
Thật tuyệt vời.
Chúng ta vừa đào tạo thành công một đội ngũ chuyên nghiệp trong nghệ thuật chờ chỉ đạo.
01. Autonomy không phải là muốn làm gì thì làm.
Tôi thích quyền tự chủ.
Tôi muốn nhân viên có khả năng phát triển khách hàng, xây dựng chuyên môn, thử nghiệm ý tưởng và thậm chí điều hành những đơn vị kinh doanh nhỏ bên trong một tổ chức lớn.
Nhưng tôi không nghĩ quyền tự chủ đồng nghĩa với quyền làm bất cứ điều gì.
Một nhân viên bán hàng không thể tự do đưa ra mọi cam kết tài chính thay mặt doanh nghiệp.
Một người phụ trách vận hành không thể tùy ý bỏ qua những tiêu chuẩn an toàn quan trọng.
Một lập trình viên không thể sửa dữ liệu production chỉ vì tin rằng mình có một ý tưởng rất hay.
Một người quản lý không thể sử dụng nguồn lực của tổ chức cho những thử nghiệm không có giới hạn rủi ro.
Đó không phải tự chủ.
Đó là sự thiếu vắng kiến trúc kiểm soát.
Nhưng điều ngược lại cũng nguy hiểm.
Nếu mọi quyết định đều cần phê duyệt, nhân viên không còn thực sự sở hữu công việc.
Họ chỉ đang thực hiện từng bước của một quy trình được quyết định bởi người khác.
Và nếu người quản lý phải chấp thuận tất cả, thì dù sơ đồ tổ chức có bao nhiêu phòng ban, quyền ra quyết định thực tế vẫn tập trung vào một người.
Tôi muốn phân biệt hai khái niệm.
Autonomy — Quyền chủ động đưa ra quyết định trong một phạm vi trách nhiệm đã được xác định.
Unrestricted Authority — Quyền đưa ra quyết định mà không chịu những giới hạn tương ứng.
Hai thứ đó hoàn toàn khác nhau.
Một người có thể sở hữu mức độ tự chủ rất cao mà không có quyền tùy ý sử dụng tài sản của doanh nghiệp.
Họ có thể tự quyết định cách phát triển khách hàng, cách tổ chức công việc, cách xây dựng chuyên môn và cách thử nghiệm những phương pháp mới.
Nhưng những quyết định làm thay đổi rủi ro tài chính, nghĩa vụ pháp lý hoặc cam kết vận hành của toàn tổ chức vẫn phải tuân thủ những giới hạn thích hợp.
Freedom without boundaries is not autonomy. It is unmanaged risk.
Tự do không có giới hạn không phải tự chủ.
Nó là rủi ro chưa được quản lý.
Và một hệ thống tốt phải giải quyết được câu hỏi: làm sao bảo vệ tổ chức khỏi những rủi ro không chấp nhận được mà không bóp nghẹt những quyền tự chủ có giá trị?
Đó là bài toán của guardrails.
02. Guardrails không phải những quy định được viết đẹp hơn.
Khi nghe đến kiểm soát, nhiều người nghĩ đến nội quy.
Những tài liệu quy định nhân viên được phép hoặc không được phép làm gì.
Những biểu mẫu phê duyệt.
Những hướng dẫn xử lý.
Những chế tài khi vi phạm.
Tất cả đều có thể cần thiết.
Nhưng tôi không xem đó là bản chất của guardrails.
Hãy tưởng tượng một con đường đèo.
Nếu muốn hạn chế tai nạn, chúng ta có nhiều lựa chọn.
Có thể dựng biển báo yêu cầu tài xế cẩn thận.
Có thể tổ chức các khóa đào tạo về kỹ năng lái xe.
Có thể yêu cầu tài xế ký cam kết tuân thủ tốc độ.
Có thể tăng cường xử phạt.
Những biện pháp đó đều có vai trò nhất định.
Nhưng tại những đoạn đường nguy hiểm, chúng ta còn xây dựng lan can bảo vệ.
Lan can không yêu cầu tài xế phải nhớ thêm một điều gì.
Nó không cần một người quản lý đứng bên đường để phê duyệt từng cú đánh lái.
Và nó không ngăn tài xế tiếp tục di chuyển trên con đường hợp lệ.
Nó tồn tại để hạn chế hậu quả khi phương tiện đi vượt khỏi một ranh giới nguy hiểm.
Tôi thích tư duy đó.
Một guardrail tốt không cố gắng quyết định mọi hành động của con người. Nó xác định những giới hạn quan trọng và bảo vệ chúng một cách đáng tin cậy.
Trong doanh nghiệp, điều này có thể mang nhiều hình thức.
Một đơn hàng không đủ điều kiện miễn phí vận chuyển sẽ tự động được tính phí theo chính sách.
Một giao dịch vượt hạn mức công nợ không thể hoàn tất nếu chưa có phê duyệt hợp lệ.
Một nhân viên chỉ có thể điều chỉnh giá trong phạm vi được phân quyền.
Một cam kết giao hàng phải được kiểm tra với khả năng thực hiện trước khi được xác nhận.
Một thay đổi ảnh hưởng đến dữ liệu quan trọng cần được ghi nhận và có khả năng truy vết.
Điểm chung của những cơ chế này không phải sự cứng nhắc.
Mà là chúng giúp tổ chức bảo vệ những ràng buộc quan trọng mà không cần liên tục dựa vào trí nhớ và sự cẩn thận của từng cá nhân.
Nhân viên không cần phải nhớ hàng chục điều kiện rồi tự kiểm tra thủ công trong mỗi giao dịch.
Hệ thống có thể thực hiện phần kiểm soát đã được hiểu rõ.
Và để con người dành năng lực phán đoán cho những tình huống thực sự cần nó.
The best guardrails make the safe path the easiest path.
Một hệ thống tốt nên khiến con đường an toàn trở thành con đường dễ đi nhất.
Không phải con đường duy nhất.
Nhưng là con đường tự nhiên nhất đối với phần lớn hoạt động thông thường.
03. Kiểm soát cái gì mới là câu hỏi khó.
Tôi từng thấy nhiều quy trình kiểm soát được thiết kế từ nỗi sợ.
Một nhân viên mắc lỗi.
Công ty bổ sung một bước xác nhận.
Một sự cố khác xảy ra.
Thêm một chữ ký.
Một trường hợp ngoại lệ xuất hiện.
Thêm một cấp phê duyệt.
Sau vài năm, một giao dịch đơn giản có thể phải đi qua rất nhiều người.
Tất cả những bước đó đều có lý do lịch sử.
Đáng tiếc, không phải lý do nào cũng còn hợp lý.
Đôi khi rủi ro ban đầu đã biến mất.
Đôi khi công nghệ đã thay đổi.
Đôi khi chi phí kiểm soát lớn hơn nhiều so với tổn thất mà nó có khả năng ngăn chặn.
Nhưng quy trình vẫn tồn tại vì không ai muốn chịu trách nhiệm loại bỏ nó.
Tôi nghĩ đây là một vấn đề nghiêm trọng.
Bởi vì kiểm soát không miễn phí.
Nó tiêu tốn thời gian.
Tạo ra độ trễ.
Làm tăng số điểm phụ thuộc.
Và đôi khi khiến những người có năng lực cảm thấy mình không được tin tưởng.
Một tổ chức muốn kiểm soát mọi thứ có thể cuối cùng không còn đủ năng lực để kiểm soát những gì thực sự quan trọng.
Vì vậy, trước khi thiết kế một guardrail, tôi muốn biết:
Chúng ta đang bảo vệ điều gì?
Rủi ro cụ thể là gì?
Hậu quả nếu rủi ro xảy ra?
Khả năng phát hiện và khắc phục ra sao?
Và chi phí của việc kiểm soát có tương xứng với mức độ rủi ro không?
Một quyết định có thể đảo ngược dễ dàng không nên mặc nhiên phải chịu cùng quy trình với một quyết định có hậu quả nghiêm trọng và khó phục hồi.
Thay đổi cách trình bày một nội dung marketing và thay đổi hạn mức công nợ không phải cùng một loại quyết định.
Thử nghiệm một trang giới thiệu sản phẩm và thay đổi logic tính giá cho toàn bộ khách hàng cũng không phải cùng một loại rủi ro.
Nếu tất cả đều cần ba cấp phê duyệt, chúng ta chưa chắc đã xây dựng được một hệ thống an toàn.
Có thể chúng ta chỉ đang xây dựng một hệ thống không biết phân biệt.
Governance is not about maximizing control. It is about allocating control where it creates the most value.
Quản trị không phải tối đa hóa kiểm soát.
Nó là phân bổ năng lực kiểm soát vào những nơi tạo ra giá trị lớn nhất.
Đây là một bài toán kinh tế.
Không chỉ là một bài toán kỷ luật.
04. Không phải quyết định nào cũng cần cùng một mức quyền hạn.
Hãy tưởng tượng ba tình huống.
Một nhân viên muốn thay đổi cách sắp xếp danh sách khách hàng để làm việc hiệu quả hơn.
Một nhân viên muốn hỗ trợ phí giao hàng cho một đơn không đáp ứng chính sách thông thường.
Một nhân viên muốn thay đổi điều kiện thanh toán của một khách hàng có công nợ lớn.
Cả ba đều là quyết định.
Nhưng hậu quả tiềm năng của chúng hoàn toàn khác nhau.
Tình huống đầu tiên có thể chủ yếu ảnh hưởng đến cách làm việc cá nhân.
Tình huống thứ hai ảnh hưởng đến chi phí của một giao dịch.
Tình huống thứ ba có thể ảnh hưởng đến rủi ro tài chính của doanh nghiệp.
Nếu cả ba đều phải xin phép CEO, hệ thống đang sử dụng cùng một cơ chế kiểm soát cho những loại rủi ro khác nhau.
Nếu cả ba đều được tự quyết, hệ thống lại bỏ qua những khác biệt quan trọng về trách nhiệm.
Tôi muốn thiết kế quyền quyết định theo nhiều tầng.
Tầng thứ nhất: Protected Constraints.
Những ràng buộc bắt buộc phải được bảo vệ.
Chẳng hạn quyền truy cập dữ liệu nhạy cảm, giới hạn tín dụng, những yêu cầu pháp lý hoặc các điều kiện an toàn quan trọng.
Không ai được tự ý phá vỡ chúng chỉ vì cho rằng trường hợp của mình đặc biệt.
Tầng thứ hai: Conditional Authority.
Những quyết định có thể được thực hiện khi đáp ứng các điều kiện xác định.
Nhân viên có thể được trao quyền hỗ trợ một loại chi phí trong phạm vi nhất định, với những điều kiện và giới hạn rõ ràng.
Tầng thứ ba: Discretionary Space.
Những lĩnh vực nơi nhân viên có quyền lựa chọn phương pháp thực hiện.
Cách tìm kiếm khách hàng, phát triển nội dung, tổ chức công việc hoặc xây dựng chuyên môn có thể thuộc phạm vi này.
Tầng thứ tư: Exception Path.
Những trường hợp vượt khỏi quyền hạn thông thường nhưng có lý do hợp lý để xem xét.
Chúng cần được chuyển đến đúng người có thẩm quyền, với đủ thông tin để quyết định.
Bốn tầng này không nhất thiết phải được triển khai như bốn lớp phần mềm.
Chúng là một cách tư duy.
Điều tôi muốn là mọi người hiểu được ranh giới giữa những điều được bảo vệ tuyệt đối, những điều được quyết định có điều kiện, những không gian tự chủ và những tình huống cần đưa ra khỏi luồng thông thường.
Một tổ chức trưởng thành không chỉ định nghĩa ai được phép làm gì. Nó còn định nghĩa trong điều kiện nào quyền đó có hiệu lực.
Đây là khác biệt giữa phân quyền theo chức danh và phân quyền theo cấu trúc quyết định.
Chức danh có thể là một đầu vào.
Nhưng không nên là toàn bộ logic.
Một người có chức danh rất cao vẫn có thể không đủ chuyên môn để quyết định trong một lĩnh vực cụ thể.
Và một nhân viên không giữ chức vụ quản lý vẫn có thể đủ năng lực để tự quyết một nhóm vấn đề mà họ hiểu rất sâu.
Quyền hạn nên phản ánh trách nhiệm, năng lực, rủi ro và bối cảnh.
Không đơn thuần là vị trí trên sơ đồ tổ chức.
05. Tự chủ phải đi cùng thông tin.
Có một sai lầm rất phổ biến trong việc trao quyền.
Người quản lý tuyên bố:
"Từ nay em tự quyết định."
Nghe rất tích cực.
Nhưng nhân viên không có đủ dữ liệu.
Không biết chi phí thực tế.
Không biết giới hạn lợi nhuận.
Không biết trạng thái công nợ.
Không biết khả năng vận hành của các bộ phận liên quan.
Và không biết quyết định của mình có thể ảnh hưởng đến điều gì ngoài phạm vi công việc trực tiếp.
Vậy họ phải tự quyết định bằng cách nào?
Dựa vào cảm giác?
Dựa vào kinh nghiệm?
Hay dựa vào khả năng đoán xem người quản lý sẽ quyết định thế nào nếu có mặt?
Tôi không xem đó là trao quyền.
Đó là chuyển trách nhiệm xuống dưới mà chưa chuyển năng lực ra quyết định xuống cùng.
Một quyết định có chất lượng cần ít nhất ba yếu tố.
Authority — Quyền được quyết định.
Information — Thông tin cần thiết để quyết định.
Accountability — Trách nhiệm với kết quả.
Nếu thiếu một trong ba, quyền tự chủ trở nên thiếu cân bằng.
Có thông tin và trách nhiệm nhưng không có quyền hạn, nhân viên sẽ phải liên tục xin phép.
Có quyền hạn và trách nhiệm nhưng thiếu thông tin, nhân viên phải ra quyết định trong trạng thái mù mờ.
Có quyền hạn và thông tin nhưng không có trách nhiệm, hệ thống có nguy cơ khuyến khích những quyết định thiếu thận trọng.
Tôi thích xem ba yếu tố này như một contract giữa tổ chức và người được trao quyền.
Doanh nghiệp cam kết cung cấp đủ thông tin và quyền hạn trong phạm vi xác định.
Người được trao quyền cam kết đưa ra quyết định phù hợp và chịu trách nhiệm về quá trình cũng như kết quả.
Và cả hai đều có nghĩa vụ xem xét lại contract khi thực tế thay đổi.
Delegation without information is abandonment. Delegation without accountability is negligence.
Trao quyền mà không cung cấp thông tin là bỏ mặc.
Trao quyền mà không thiết kế trách nhiệm là cẩu thả.
Một tổ chức không trở nên trưởng thành chỉ vì người lãnh đạo quyết định ít can thiệp hơn.
Nó trưởng thành khi những người khác thực sự có đủ điều kiện để đưa ra các quyết định tốt.
06. Một voucher có thể nói lên triết lý quản trị của cả doanh nghiệp.
Hãy tưởng tượng một khách hàng yêu cầu được hỗ trợ phí giao hàng.
Đơn hàng không đáp ứng điều kiện miễn phí vận chuyển.
Nhân viên bán hàng cho rằng nên hỗ trợ để giữ quan hệ với khách.
Đây là một tình huống rất bình thường.
Nhưng cách doanh nghiệp xử lý nó có thể bộc lộ nhiều điều về kiến trúc quản trị.
Ở mô hình thứ nhất, nhân viên được tự quyết hoàn toàn.
Họ có thể miễn phí giao hàng cho bất cứ khách hàng nào nếu cảm thấy cần thiết.
Cách này rất nhanh.
Nhưng nếu cơ chế đánh giá và trách nhiệm không phù hợp, nhân viên có thể có động cơ sử dụng ưu đãi để đạt chỉ tiêu bán hàng, trong khi chi phí được chuyển sang doanh nghiệp.
Ở mô hình thứ hai, mọi yêu cầu đều phải xin phép quản lý.
Cách này tạo ra khả năng kiểm soát trực tiếp.
Nhưng khi số lượng giao dịch tăng, người quản lý có thể trở thành nút thắt cổ chai.
Thời gian chờ kéo dài.
Nhân viên giảm khả năng phản ứng nhanh với khách hàng.
Và một quyết định nhỏ tiếp tục tiêu tốn nguồn lực của người có thẩm quyền cao hơn.
Tôi thích một hướng thứ ba.
Hệ thống tự xác định điều kiện áp dụng phí giao hàng thông thường.
Nếu giao dịch không đáp ứng chính sách miễn phí, phí được tính theo quy tắc đang có hiệu lực.
Nhân viên không cần tự ghi nhớ hay tính toán.
Nếu muốn đề xuất hỗ trợ, họ có một luồng yêu cầu ngoại lệ.
Luồng đó yêu cầu lý do.
Có thể cung cấp dữ liệu về lịch sử khách hàng, giá trị giao dịch, chi phí dự kiến và những yếu tố liên quan.
Những trường hợp nằm trong phạm vi đã được phân quyền có thể được giải quyết ngay.
Những trường hợp vượt giới hạn được chuyển đến người có thẩm quyền.
Quyết định được ghi nhận.
Và dữ liệu về những ngoại lệ đó được sử dụng để đánh giá chính sách về sau.
Điều thú vị là phương án này không nhất thiết phải trao ít quyền hơn.
Nó có thể trao nhiều quyền hơn cho nhân viên, bởi vì hệ thống đã xác định được những trường hợp nào họ có thể tự quyết một cách an toàn.
Người quản lý không cần phê duyệt mọi thứ.
Họ tập trung vào những tình huống có mức độ rủi ro hoặc sự bất thường cao hơn.
Và nhân viên không cần phải vận dụng quan hệ cá nhân để được giải quyết một yêu cầu hợp lý.
Họ sử dụng một cơ chế đã được thiết kế.
A good guardrail does not say no to everything. It knows when to say yes without asking the boss.
Một guardrail tốt không phải cỗ máy chuyên từ chối.
Nó phải biết khi nào có thể chấp thuận mà không cần hỏi sếp.
Và nếu một loại yêu cầu xuất hiện đủ thường xuyên, tổ chức cần xem xét liệu nó có nên tiếp tục được coi là ngoại lệ hay không.
Đó là lúc guardrails kết nối với khả năng học hỏi của hệ thống.
07. Approval không phải dấu hiệu của kiểm soát tốt.
Có một hiện tượng khiến tôi khá khó chịu.
Một tổ chức đánh giá mức độ kiểm soát bằng số lượng quyết định cần được phê duyệt.
Càng nhiều chữ ký, càng an toàn.
Càng nhiều cấp xét duyệt, càng chặt chẽ.
Càng ít người có quyền quyết định, càng dễ quản lý.
Tôi không đồng ý.
Một cơ chế phê duyệt có thể cần thiết.
Nhưng sự tồn tại của approval không chứng minh rằng rủi ro đang được kiểm soát hiệu quả.
Hãy xem một quản lý phải phê duyệt hàng trăm yêu cầu mỗi ngày.
Ban đầu, họ đọc rất kỹ.
Sau một thời gian, những tình huống quen thuộc xuất hiện liên tục.
Họ bắt đầu nhận diện các mẫu hình.
Rồi tốc độ phê duyệt tăng lên.
Những yêu cầu thông thường được xử lý gần như theo phản xạ.
Đến một thời điểm, approval có nguy cơ trở thành một thao tác xác nhận mang tính hình thức.
Và khi một trường hợp thực sự bất thường xuất hiện, nó có thể bị lẫn vào hàng chục yêu cầu bình thường khác.
Đây không phải vì người quản lý thiếu trách nhiệm.
Mà vì hệ thống đang sử dụng năng lực phán đoán của con người để xử lý quá nhiều quyết định đã có thể cấu trúc hóa.
Tôi thích tự hỏi:
Nếu một người quản lý thường xuyên chấp thuận một loại yêu cầu mà gần như không cần cân nhắc, tại sao chúng ta chưa chuyển logic đó thành cơ chế?
Nếu họ thường xuyên từ chối một loại yêu cầu, tại sao hệ thống vẫn cho phép những yêu cầu không hợp lệ được gửi lên?
Và nếu có những tình huống mà họ phải suy nghĩ rất lâu, liệu hệ thống đã cung cấp đủ thông tin để hỗ trợ quyết định chưa?
Không phải approval nào cũng nên bị loại bỏ.
Nhưng mỗi approval nên tồn tại vì một lý do cụ thể.
The purpose of approval is not to transfer responsibility upward. It is to apply judgment where judgment is actually required.
Mục tiêu của phê duyệt không phải đẩy trách nhiệm lên cấp trên.
Nó là sử dụng năng lực phán đoán ở những nơi thực sự cần thiết.
Nếu người quản lý chỉ đóng vai trò một nút bấm có mức lương cao, chúng ta nên xem lại cách thiết kế.
08. Guardrails không được biến thành công cụ duy trì quyền lực.
Đây là phần tôi nghĩ những người lãnh đạo nên nghiêm túc xem xét.
Không phải mọi cơ chế kiểm soát đều được tạo ra để bảo vệ doanh nghiệp.
Đôi khi, một phần trong đó tồn tại vì người có quyền lực không muốn đánh mất quyền quyết định.
Một nhân viên đủ khả năng xử lý công việc nhưng vẫn phải xin phép.
Một quản lý có trách nhiệm về kết quả nhưng không được quyền phân bổ nguồn lực cần thiết.
Một bộ phận được yêu cầu chủ động phát triển nhưng mọi thay đổi quan trọng đều phải chờ cấp trên chấp thuận.
Những cơ chế đó có thể được giải thích bằng nhiều lý do.
Đảm bảo nhất quán.
Kiểm soát rủi ro.
Bảo vệ lợi ích doanh nghiệp.
Duy trì chất lượng.
Và có thể một số lý do hoàn toàn chính đáng.
Nhưng tôi muốn đặt thêm một câu hỏi.
Nếu một người đã chứng minh đủ năng lực để đưa ra một nhóm quyết định, tại sao tổ chức vẫn cần họ phải xin phép?
Nếu câu trả lời là vì rủi ro chưa được kiểm soát đầy đủ, chúng ta cần cải thiện cơ chế.
Nếu câu trả lời là vì thông tin chưa đủ, chúng ta cần cải thiện dữ liệu.
Nếu câu trả lời là vì năng lực chưa được chứng minh, chúng ta cần xác định cách đánh giá.
Nhưng nếu câu trả lời thực sự chỉ là vì người lãnh đạo muốn giữ quyền quyết định, thì vấn đề không còn nằm ở nhân viên.
Nó nằm ở thiết kế quyền lực.
Tôi không cho rằng phân quyền tối đa luôn là mục tiêu đúng.
Có những quyết định chiến lược, những ràng buộc quan trọng và những giai đoạn tổ chức cần sự tập trung quyền lực để bảo đảm tính nhất quán.
Nhưng sự tập trung ấy phải có lý do vận hành rõ ràng.
Không nên trở thành trạng thái mặc định vĩnh viễn.
Bởi vì quyền quyết định và khả năng phát triển năng lực có mối quan hệ rất gần.
Một người không có cơ hội ra quyết định sẽ khó tích lũy kinh nghiệm ra quyết định.
Một người luôn phải chờ cấp trên xác nhận sẽ học cách dự đoán ý muốn của cấp trên, thay vì phát triển mô hình phán đoán độc lập.
Và một tổ chức không cho phép sai lầm trong phạm vi có thể kiểm soát sẽ rất khó đào tạo những người có khả năng xử lý các vấn đề mới.
Nếu muốn con người trưởng thành, chúng ta phải thiết kế một không gian nơi họ có thể thực sự chịu trách nhiệm cho quyết định của mình.
Không phải mọi sai lầm đều đáng được khoan dung.
Nhưng không phải mọi quyết định không hoàn hảo đều là lý do để thu hồi quyền tự chủ.
Nếu mỗi sai sót nhỏ đều dẫn đến một quy định mới, tổ chức sẽ dần dần mất khả năng thử nghiệm.
Cuối cùng, những người có tư duy độc lập có thể lựa chọn rời đi.
Những người ở lại học được cách an toàn nhất để tồn tại.
Không làm gì nếu chưa được yêu cầu.
Và người lãnh đạo lại tiếp tục phàn nàn rằng tổ chức thiếu người có khả năng dẫn dắt.
Có lẽ họ đã từng có.
Chỉ là hệ thống không cho những người đó đủ không gian để phát triển.
09. Quyền tự chủ không phải một phần thưởng vĩnh viễn.
Tôi không xem quyền hạn là thứ chỉ cần được trao một lần rồi tồn tại mãi mãi.
Năng lực có thể phát triển.
Vai trò có thể thay đổi.
Mức độ rủi ro của một hoạt động có thể tăng lên.
Và một người từng đưa ra quyết định tốt trong phạm vi nhỏ chưa chắc đã sẵn sàng xử lý những quyết định có tác động lớn hơn.
Vì vậy, quyền tự chủ cần có khả năng được mở rộng, đánh giá lại và điều chỉnh.
Một nhân viên mới có thể bắt đầu với phạm vi quyết định tương đối hẹp.
Sau khi chứng minh được năng lực, họ được trao thêm quyền hạn.
Khi hiểu sâu một lĩnh vực, họ có thể tự xử lý những tình huống phức tạp hơn.
Khi đủ khả năng quản lý cả nguồn lực, mục tiêu và kết quả, họ có thể tiến đến việc điều hành một business unit.
Tôi thích quá trình phát triển đó.
Nhưng tôi không muốn việc tăng quyền hạn chỉ phụ thuộc vào cảm giác của người lãnh đạo.
Nó cần những bằng chứng phù hợp.
Chất lượng quyết định.
Khả năng đánh giá rủi ro.
Kết quả kinh doanh.
Cách xử lý ngoại lệ.
Khả năng phối hợp.
Và mức độ đáng tin cậy trong việc tuân thủ những ràng buộc quan trọng.
Ngược lại, khi quyền hạn bị sử dụng sai, tổ chức phải có cơ chế xem xét.
Đôi khi cần đào tạo lại.
Đôi khi cần điều chỉnh phạm vi quyết định.
Và khi có sự vi phạm cố ý đối với những nguyên tắc nghiêm trọng, việc thu hồi quyền hạn hoặc chấm dứt quan hệ làm việc có thể là cần thiết.
Tôi không thích dùng những hình phạt nhỏ nhặt để tạo cảm giác quản lý chặt chẽ.
Nhưng tôi cũng không tin một tổ chức có thể vận hành tốt nếu những ranh giới quan trọng liên tục bị vi phạm mà không có hậu quả tương xứng.
Autonomy is earned through demonstrated judgment, and sustained through accountability.
Quyền tự chủ được mở rộng bằng năng lực phán đoán đã được chứng minh.
Và được duy trì bằng trách nhiệm.
Tuy nhiên, trách nhiệm phải gắn với những điều người được trao quyền thực sự có thể kiểm soát.
Không thể yêu cầu nhân viên chịu trách nhiệm hoàn toàn cho một kết quả nếu những quyết định quan trọng nhất vẫn nằm trong tay người khác.
Một tổ chức không nên vừa giữ toàn bộ quyền lực ở cấp trên, vừa phân bổ toàn bộ trách nhiệm xuống cấp dưới.
Đó không phải phân quyền.
Đó là một thiết kế khá hiệu quả để tạo ra sự bất mãn.
10. Những gì đo được có thể trở thành thứ bị thao túng.
Khi bắt đầu thiết kế guardrails, chúng ta thường nghĩ đến việc ngăn những hành động không hợp lệ.
Nhưng có một loại rủi ro tinh vi hơn.
Con người có thể làm mọi thứ đúng quy định mà vẫn tạo ra kết quả không mong muốn.
Hãy tưởng tượng nhân viên bán hàng được đánh giá chủ yếu theo số lượng đơn.
Hệ thống không cho phép giảm giá tùy tiện.
Không cho phép bỏ qua phí vận chuyển.
Không cho phép giao dịch vượt hạn mức công nợ.
Tất cả những kiểm soát đó đều hoạt động tốt.
Nhưng nhân viên vẫn có thể tập trung vào những đơn hàng dễ tạo, trong khi bỏ qua những khách hàng có tiềm năng dài hạn nhưng cần nhiều công sức chăm sóc hơn.
Hoặc họ có thể tối ưu doanh thu ngắn hạn bằng cách khai thác quá mức một nhóm khách hàng, làm suy giảm khả năng mua lại trong tương lai.
Mọi giao dịch đều hợp lệ.
Không ai phá vỡ guardrails.
Nhưng hành vi tổng thể không nhất thiết phù hợp với mục tiêu kinh doanh.
Đây là lý do kiểm soát giao dịch và thiết kế động cơ không thể được xem là hai vấn đề hoàn toàn độc lập.
Một hệ thống có thể ngăn nhân viên thực hiện những hành động bị cấm.
Nhưng chưa chắc khiến họ lựa chọn những hành động tốt nhất trong số những hành động được phép.
Guardrails bảo vệ ranh giới.
Incentives định hình cách con người di chuyển bên trong ranh giới đó.
Nếu cơ chế thưởng khuyến khích một loại hành vi không phù hợp, việc bổ sung thêm nhiều quy định có thể không giải quyết được nguyên nhân.
Chúng ta phải xem lại mục tiêu.
Doanh thu có đi cùng lợi nhuận không?
Số lượng đơn có đi cùng hiệu quả phục vụ không?
Tốc độ giao hàng có đi cùng độ tin cậy không?
Số khách hàng mới có đi cùng khả năng duy trì quan hệ không?
Một hệ thống tốt cần quan sát cả những kết quả mà chúng ta muốn đạt được và những tác dụng phụ của cách đạt được kết quả đó.
Đây cũng là lý do tôi không thích những KPI chỉ khiến báo cáo đẹp hơn.
Tôi muốn các chỉ số giúp tổ chức đưa ra quyết định tốt hơn.
Bởi vì một tổ chức có thể hoàn thành tất cả KPI và vẫn thất bại trong mục tiêu kinh doanh thực sự.
Nếu điều đó xảy ra, chúng ta không nên vội trách nhân viên.
Có thể họ đã làm chính xác những gì hệ thống khuyến khích.
Và người cần xem lại thiết kế là người đã định nghĩa KPI.
11. Guardrails phải có cơ chế thay đổi chính guardrails.
Một quy định có thể đúng hôm nay và sai vào năm sau.
Một chính sách giá có thể phù hợp với cấu trúc lợi nhuận hiện tại nhưng không còn phù hợp khi thị trường thay đổi.
Một giới hạn công nợ có thể hợp lý với nhóm khách hàng này nhưng không phản ánh đầy đủ rủi ro của nhóm khách hàng khác.
Một cơ chế phê duyệt có thể cần thiết khi nhân viên còn ít kinh nghiệm, nhưng trở thành nút thắt khi đội ngũ đã trưởng thành.
Nếu không có cơ chế đánh giá lại, guardrails sẽ dần tích tụ giống như những quy trình cũ.
Tôi không muốn một tổ chức phải tuân thủ vĩnh viễn những quy tắc chỉ vì không ai nhớ ai đã tạo ra chúng.
Mỗi guardrail quan trọng nên có thể trả lời những câu hỏi cơ bản.
Nó bảo vệ ràng buộc nào?
Tại sao ràng buộc đó quan trọng?
Ai chịu trách nhiệm duy trì?
Ai có quyền sửa đổi?
Bằng chứng nào cho thấy nó còn hiệu quả?
Và nếu nó trở nên không phù hợp, chúng ta thay đổi bằng cách nào?
Tôi thích ý tưởng xem những chính sách quan trọng như những thành phần có vòng đời.
Chúng được thiết kế.
Được triển khai.
Được quan sát.
Được đánh giá.
Được điều chỉnh.
Và đôi khi được loại bỏ.
Một guardrail tồn tại quá lâu không tự động là guardrail tốt.
Nó có thể chỉ là thứ chưa ai dám đụng vào.
A rule that cannot be challenged eventually becomes a belief. A belief that cannot be tested eventually becomes dogma.
Một quy tắc không thể bị chất vấn dần trở thành niềm tin.
Một niềm tin không thể bị kiểm chứng dần trở thành giáo điều.
Tôi không muốn điều hành doanh nghiệp bằng giáo điều.
Tôi muốn những nguyên tắc đủ vững để tạo ra sự ổn định, nhưng đủ minh bạch để được đánh giá khi điều kiện thay đổi.
Điều này không có nghĩa bất cứ nhân viên nào cũng có thể tùy ý sửa quy định.
Quyền thay đổi phải được thiết kế rõ.
Nhưng quyền đặt câu hỏi về tính hợp lý của quy định nên rộng hơn nhiều so với quyền trực tiếp thay đổi nó.
Một người chưa đủ thẩm quyền để sửa chính sách vẫn có thể là người phát hiện ra chính sách đó đang tạo ra hậu quả không mong muốn.
Nếu tổ chức không có cơ chế tiếp nhận thông tin ấy, nó đang tự làm giảm khả năng học hỏi của mình.
12. Một hệ thống quá chặt sẽ tạo ra hệ thống ngầm.
Tôi không tin chúng ta có thể kiểm soát toàn bộ hành vi của con người chỉ bằng cách viết thêm quy định.
Nếu một quy trình quá chậm, người ta sẽ tìm cách đi vòng.
Nếu một bước phê duyệt quá bất hợp lý, người ta sẽ tìm cách tránh nó.
Nếu công cụ chính thức không đáp ứng nhu cầu công việc, người ta sẽ sử dụng công cụ khác.
Và nếu hệ thống không hỗ trợ những tình huống thực tế, nhân viên có thể bắt đầu tạo ra những phương pháp xử lý không chính thức.
Đây là một phản ứng có thể dự đoán được.
Không phải mọi trường hợp đều có động cơ xấu.
Đôi khi con người chỉ đang cố gắng hoàn thành công việc.
Một nhân viên lưu dữ liệu trong file riêng vì hệ thống không cung cấp được báo cáo cần thiết.
Một nhóm sử dụng chat cá nhân vì luồng phối hợp chính thức quá chậm.
Một người quản lý duy trì danh sách phê duyệt bên ngoài phần mềm vì cơ chế hiện tại không đủ linh hoạt.
Theo thời gian, tổ chức bắt đầu có hai hệ thống.
Hệ thống chính thức.
Và hệ thống thực sự được sử dụng.
Đó là thời điểm guardrails mất dần ý nghĩa.
Không phải vì chúng đã bị xóa bỏ.
Mà vì hoạt động thực tế đang diễn ra bên ngoài phạm vi mà chúng có khả năng kiểm soát.
Tôi nghĩ đây là một tín hiệu quan trọng.
Khi người dùng liên tục tìm cách đi vòng một quy trình, chúng ta cần phân biệt hai khả năng.
Họ đang cố tình vượt qua một ràng buộc cần thiết.
Hay ràng buộc đó đã được thiết kế không phù hợp với nhu cầu vận hành?
Hai tình huống đòi hỏi hai phản ứng khác nhau.
Trường hợp thứ nhất cần kiểm soát và trách nhiệm.
Trường hợp thứ hai cần cải tiến kiến trúc.
Nếu chỉ sử dụng kỷ luật để xử lý cả hai, tổ chức có thể tạm thời giảm được những hành vi bị phát hiện.
Nhưng nhu cầu thực tế không biến mất.
Nó chỉ chuyển sang những phương thức khó quan sát hơn.
When the official system becomes harder than the workaround, shadow systems become inevitable.
Khi hệ thống chính thức khó sử dụng hơn cách đi vòng, những hệ thống ngầm sẽ có đất để phát triển.
Một guardrail tốt phải đủ mạnh để bảo vệ điều quan trọng.
Nhưng cũng phải đủ hợp lý để người dùng không xem việc tuân thủ là một trở ngại vô nghĩa.
13. AI có thể giúp thực thi guardrails. Nhưng đừng giao toàn bộ quyền phán xét cho AI.
Tôi đặc biệt quan tâm đến vai trò của AI trong việc hỗ trợ ra quyết định.
Một hệ thống AI có thể đọc yêu cầu của khách hàng.
Phân loại tình huống.
Tóm tắt bối cảnh.
Đề xuất những chính sách có liên quan.
Phát hiện thông tin chưa đầy đủ.
Và hỗ trợ nhân viên lựa chọn hướng xử lý.
Đó là những ứng dụng rất hấp dẫn.
Nhưng tôi không cho rằng việc có AI đồng nghĩa chúng ta có thể bỏ qua thiết kế quyền hạn và kiểm soát.
Ngược lại.
AI càng có khả năng đề xuất hoặc thực hiện nhiều hành động, ranh giới quyền hạn càng cần rõ ràng.
Hãy tưởng tượng một AI assistant hỗ trợ nhân viên bán hàng.
Khách hàng yêu cầu giảm giá.
AI phân tích lịch sử giao dịch và cho rằng việc giảm giá có thể hợp lý.
Nhưng liệu AI có quyền trực tiếp thay đổi giá không?
Nó có biết đầy đủ chính sách đang có hiệu lực không?
Nó có kiểm tra các ràng buộc bắt buộc không?
Và nếu nhận định sai, cơ chế nào sẽ ngăn quyết định gây ra hậu quả?
Tôi thích một kiến trúc phân biệt rõ hai loại năng lực.
Reasoning — Phân tích và đề xuất.
AI có thể hỗ trợ hiểu ngữ cảnh, nhận diện tình huống và đưa ra phương án.
Enforcement — Thực thi những ràng buộc bắt buộc.
Các cơ chế đáng tin cậy kiểm tra quyền hạn, điều kiện và giới hạn trước khi một hành động được thực hiện.
AI không nên tự ý vượt qua những ràng buộc quan trọng chỉ vì nó đưa ra một lời giải thích rất thuyết phục.
Một đề xuất có thể thông minh.
Nhưng sự thông minh không tự động tạo ra thẩm quyền.
Đây là điểm mà tôi cho rằng các hệ thống sử dụng AI trong doanh nghiệp cần đặc biệt thận trọng.
Một mô hình ngôn ngữ có thể rất giỏi giải thích tại sao một ngoại lệ đáng được xem xét.
Nhưng việc quyết định có cho phép ngoại lệ đó hay không vẫn phải tuân theo kiến trúc quyền hạn đã được thiết kế.
Intelligence proposes. Authority decides. Constraints protect.
Trí tuệ đề xuất.
Thẩm quyền quyết định.
Ràng buộc bảo vệ.
Nếu làm đúng, AI có thể giúp nhân viên đưa ra quyết định tốt hơn mà không cần tập trung mọi câu hỏi về người quản lý.
Nếu làm sai, chúng ta có thể tạo ra một hệ thống mà AI vừa đề xuất, vừa phê duyệt, vừa thực thi, vừa tự giải thích rằng mọi việc đều hợp lý.
Một nhân viên quá tự tin đã đủ nguy hiểm.
Tôi không nghĩ chúng ta cần thêm một cỗ máy có thể tạo ra sự tự tin đó với tốc độ hàng nghìn request mỗi phút.
14. Freedom to Build — Tại sao tôi muốn nhân viên được phép xây dựng?
Đến đây, chúng ta đã dành nhiều thời gian để nói về kiểm soát.
Nhưng kiểm soát không phải mục tiêu cuối cùng của tôi.
Tôi muốn xây dựng một tổ chức nơi con người có thể phát triển những năng lực mà ban đầu chính họ chưa chắc đã nhận ra.
Một nhân viên bán hàng có thể bắt đầu bằng việc chăm sóc khách hàng.
Sau một thời gian, họ hiểu sâu về một nhóm sản phẩm.
Họ nhận ra nhu cầu của một phân khúc khách hàng.
Họ phát triển kiến thức chuyên môn.
Tạo nội dung.
Đề xuất một phương pháp bán hàng mới.
Rồi dần dần có khả năng tự xây dựng một đơn vị kinh doanh nhỏ.
Một người như vậy không còn chỉ thực hiện công việc được giao.
Họ đang tạo ra năng lực kinh doanh mới cho tổ chức.
Tôi muốn có nhiều người như thế.
Nhưng không phải bằng cách yêu cầu mọi nhân viên phải trở thành doanh nhân.
Cũng không phải bằng cách giao cho họ toàn bộ rủi ro của việc kinh doanh độc lập.
Tôi muốn tạo ra một nền tảng nơi họ có thể thử nghiệm trong một phạm vi được bảo vệ.
Hệ thống chung cung cấp những năng lực mà một cá nhân khó có thể tự xây dựng đầy đủ.
Dữ liệu.
Khách hàng.
Sản phẩm.
Quy trình giao dịch.
Thanh toán.
Kho bãi.
Logistics.
Những cơ chế kiểm soát tài chính và vận hành.
Trên nền tảng đó, người có năng lực có thể phát triển cách làm riêng.
Một phương pháp tư vấn.
Một công cụ hỗ trợ bán hàng.
Một bộ nội dung chuyên môn.
Một giải pháp cho một phân khúc khách hàng.
Hoặc một micro-product phục vụ nhu cầu mà tổ chức chưa từng khai thác.
Nhưng quyền sáng tạo không đồng nghĩa với quyền phá vỡ toàn bộ hạ tầng chung.
Một nhân viên có thể được tạo ra công cụ mới mà không được tùy ý sửa dữ liệu của người khác.
Một nhóm có thể thử nghiệm luồng bán hàng mới mà không được vượt qua chính sách tín dụng.
Một người có thể xây dựng giao diện và logic riêng cho lĩnh vực phụ trách mà không được tự ý thay đổi những contract quan trọng của hệ thống.
Đây là lúc guardrails trở thành nền tảng của tự do.
Bởi vì nếu những ràng buộc chung đã được bảo vệ tốt, chúng ta có thể mở rộng đáng kể không gian thử nghiệm mà không phải quản lý từng hành động.
The stronger the foundation, the greater the freedom to build upon it.
Nền móng càng vững, con người càng có nhiều không gian để xây dựng bên trên.
Tôi không muốn một tổ chức nơi mười người làm cùng một công việc theo đúng một phương pháp do tôi quy định.
Tôi muốn một tổ chức nơi mười người có thể phát triển mười phương pháp khác nhau, miễn là những phương pháp đó tôn trọng các ràng buộc chung và tạo ra kết quả có giá trị.
Một số phương pháp sẽ thất bại.
Một số chỉ tạo ra cải thiện nhỏ.
Và một số có thể mở ra những cơ hội kinh doanh mà bản thân tôi chưa từng nghĩ đến.
Nếu mọi ý tưởng đều phải được tôi hiểu đầy đủ trước khi có thể thử nghiệm, tổ chức sẽ mãi bị giới hạn bởi khả năng tưởng tượng của một người.
Tôi không muốn điều đó.
Tôi muốn thiết kế một hệ thống có khả năng tạo ra những điều mà ngay cả người thiết kế ban đầu cũng không dự đoán hết.
Không phải sự hỗn loạn vô tổ chức.
Mà là sự sáng tạo có cấu trúc.
Controlled risk. Distributed initiative. Shared infrastructure.
Rủi ro được giới hạn.
Sáng kiến được phân tán.
Hạ tầng được chia sẻ.
Đó là một hình thái tổ chức mà tôi thấy đáng để theo đuổi.
15. Đỉnh cao của kiểm soát là không cần can thiệp.
Có một nghịch lý cuối cùng mà tôi muốn nói đến.
Chúng ta thường đánh giá quyền lực quản lý thông qua khả năng can thiệp.
Người lãnh đạo có thể quyết định điều gì.
Có thể phê duyệt điều gì.
Có thể ngăn chặn điều gì.
Và có thể yêu cầu ai phải làm theo ý mình.
Nhưng tôi nghĩ có một dạng năng lực quản trị cao hơn.
Đó là khả năng thiết kế một tổ chức vận hành đúng mà không cần liên tục sử dụng quyền lực trực tiếp.
Một đơn hàng hợp lệ được xử lý mà không cần phê duyệt.
Một giao dịch có rủi ro được chặn đúng thời điểm.
Một ngoại lệ được chuyển đến đúng người có thẩm quyền.
Một nhân viên có đủ dữ liệu để tự ra quyết định.
Một nhóm có khả năng thử nghiệm phương pháp mới mà không phá vỡ những ràng buộc chung.
Và một người quản lý chỉ cần tham gia khi thực sự có vấn đề đòi hỏi năng lực của họ.
Khi đó, quyền lực không biến mất.
Nó được chuyển hóa thành kiến trúc.
Những nguyên tắc quan trọng vẫn được thực thi.
Nhưng không cần người tạo ra chúng phải xuất hiện trong từng giao dịch.
Tôi thích điều này hơn nhiều so với hình ảnh một CEO làm việc mười sáu giờ mỗi ngày, có mặt trong mọi cuộc họp và giải quyết mọi vấn đề.
Hình ảnh đó có thể rất ấn tượng.
Nhưng tôi không chắc nó phản ánh một tổ chức khỏe mạnh.
Một người lãnh đạo có thể rất giỏi giải quyết vấn đề.
Nhưng nếu tất cả mọi người đều cần người đó để tiếp tục công việc, doanh nghiệp đang sở hữu một điểm phụ thuộc rất lớn.
Và nếu điểm phụ thuộc đó còn tự hào rằng không ai có thể thay thế mình, chúng ta đang gặp một vấn đề khá thú vị.
The highest form of control is not constant intervention. It is reliable behavior without constant intervention.
Đỉnh cao của kiểm soát không phải can thiệp liên tục.
Mà là thiết kế được những điều kiện để hệ thống hoạt động đáng tin cậy ngay cả khi người có quyền lực không trực tiếp tham gia.
Tất nhiên, không có hệ thống nào hoàn hảo.
Con người vẫn sẽ mắc lỗi.
Chính sách vẫn cần thay đổi.
Thị trường vẫn tạo ra những tình huống mới.
Và có những quyết định quan trọng mà người lãnh đạo không thể hoặc không nên ủy quyền.
Nhưng đó không phải lý do để giữ mọi quyền quyết định ở trung tâm.
Nó là lý do để phân biệt tốt hơn những việc nào cần can thiệp và những việc nào nên được xử lý bằng năng lực của hệ thống.
Tôi muốn dành quyền lực trực tiếp cho những quyết định thực sự cần quyền lực đó.
Không phải sử dụng nó để duy trì cảm giác mình vẫn là người quan trọng nhất trong mọi hoạt động.
Lời kết: Guardrails, Not Handcuffs.
Tôi không tin một tổ chức có thể phát triển bền vững nếu thiếu kỷ luật.
Nhưng tôi cũng không tin một tổ chức có thể trở nên xuất sắc nếu mọi con người bên trong đều bị giới hạn bởi những quy trình không cho phép họ suy nghĩ độc lập.
Chúng ta cần cả hai.
Những ràng buộc đủ mạnh để bảo vệ doanh nghiệp.
Và những không gian đủ rộng để con người phát triển.
Một hệ thống tốt không nên yêu cầu nhân viên phải hoàn hảo.
Nó phải được thiết kế để những sai sót thông thường không dễ trở thành thảm họa.
Một hệ thống tốt cũng không nên giả định nhân viên không có khả năng tư duy.
Nó phải cung cấp thông tin, quyền hạn và trách nhiệm để họ có cơ hội sử dụng năng lực của mình.
Tôi không muốn dành cả đời để quyết định xem một nhân viên có được phép hỗ trợ một khoản phí giao hàng hay không.
Tôi muốn hệ thống có thể xử lý những tình huống đã hiểu rõ.
Tôi không muốn phải kiểm tra mọi hành động của một người đã chứng minh được năng lực.
Tôi muốn họ có đủ không gian để tạo ra giá trị mới.
Và tôi không muốn mọi ý tưởng trong doanh nghiệp phải bắt đầu từ chính mình.
Tôi muốn xây dựng một kiến trúc đủ tốt để những người khác có thể tạo ra những điều vượt khỏi giới hạn tưởng tượng của người thiết kế ban đầu.
Để đạt được điều đó, chúng ta phải chấp nhận một sự thật.
Trao quyền không đơn thuần là thay đổi thái độ của người lãnh đạo. Nó đòi hỏi thiết kế lại cách quyền lực, thông tin và trách nhiệm được phân phối trong tổ chức.
Một lời tuyên bố rằng "từ nay mọi người được chủ động" không tạo ra quyền tự chủ.
Một workshop về tinh thần ownership cũng không đủ.
Và một tấm poster với dòng chữ Empowerment treo trên tường càng không.
Quyền tự chủ thực sự phải tồn tại trong cấu trúc vận hành.
Trong những quyền hạn được định nghĩa.
Trong dữ liệu mà nhân viên có thể sử dụng.
Trong những quyết định họ có thể tự thực hiện.
Trong những ngoại lệ mà họ có thể đề xuất.
Trong trách nhiệm họ thực sự sở hữu.
Và trong những cơ chế bảo vệ để một sai lầm không cần thiết không phá hủy toàn bộ nỗ lực của họ.
Tôi nghĩ đó mới là điều một người thiết kế tổ chức nên theo đuổi.
Không phải một đội ngũ luôn làm đúng ý mình.
Mà là một đội ngũ có thể đưa ra những quyết định tốt ngay cả khi mình không có mặt.
Guardrails should make people more capable, not more obedient.
Guardrails phải khiến con người có năng lực hơn.
Không phải chỉ khiến họ biết phục tùng hơn.
Và nếu một ngày tôi nhận ra nhân viên đã có đủ dữ liệu, đủ quyền hạn, đủ năng lực, nhưng vẫn phải hỏi tôi trước khi đưa ra một quyết định đơn giản?
Tôi sẽ không vội kết luận họ thiếu chủ động.
Tôi sẽ kiểm tra xem hệ thống đã thực sự trao quyền cho họ chưa.
Bởi vì đôi khi, thứ ngăn cản con người trưởng thành không phải là năng lực của họ.
Mà là quyền lực của người chưa sẵn sàng để họ trưởng thành.
Đây là một kết luận khá khó chịu.
Đặc biệt nếu người đó là founder.
Nhưng tôi nghĩ nó đáng được nhìn thẳng.
Nếu muốn xây dựng một tổ chức có thể phát triển vượt khỏi giới hạn của người sáng lập, người sáng lập phải sẵn sàng từ bỏ vị trí là lời giải mặc định cho mọi vấn đề.
Không phải từ bỏ trách nhiệm.
Không phải từ bỏ quyền lãnh đạo.
Mà là chuyển một phần quyền lực cá nhân thành năng lực của kiến trúc.
Để những con người bên trong hệ thống có thể tự do phát triển mà không khiến tổ chức đánh mất sự ổn định.
Đó là điều tôi gọi là Freedom to Build.
Và nếu sau khi thiết kế xong, hệ thống vẫn yêu cầu mọi nhân viên phải xin phép CEO trước khi đưa ra bất kỳ quyết định nào...
Thì có lẽ chúng ta đã hiểu sai một từ rất quan trọng.
Freedom.
Chúng ta không xây dựng guardrails.
Chúng ta vừa xây một nhà tù.
Có dashboard.
Có AI.
Có workflow automation.
Có cả KPI đánh giá mức độ chủ động của tù nhân.
Congratulations.
Welcome to the world's most technologically advanced prison.
NEXT CHAPTER — THE BUSINESS OPERATING SYSTEM
Khi những nguyên tắc, quyền hạn, dữ liệu và quy trình được kết nối thành một kiến trúc thống nhất: doanh nghiệp có thể được thiết kế như một hệ thống có khả năng vận hành, học hỏi và tiến hóa hay không?
The Architect of Chaos — Ông Chú Hay Chửi