Có một hiện tượng khá thú vị trong quản trị doanh nghiệp.
Khi một nhân viên mắc lỗi, chúng ta thường biết chính xác phải tìm ai.
Khi mười nhân viên mắc cùng một lỗi, chúng ta bắt đầu nghi ngờ chất lượng tuyển dụng.
Khi một trăm nhân viên mắc cùng một lỗi, chúng ta tổ chức một chương trình đào tạo quy mô lớn, bổ sung quy trình, tăng cường giám sát và yêu cầu các cấp quản lý nâng cao tinh thần trách nhiệm.
Một trăm con người được đưa vào diện cần cải thiện.
Còn hệ thống tạo ra điều kiện để cả một trăm người đó mắc lỗi?
Nó vẫn bình an vô sự.
Tôi luôn thấy điều này hơi buồn cười.
Chúng ta sẵn sàng đặt câu hỏi về năng lực của hàng trăm con người, nhưng lại khá miễn cưỡng khi đặt câu hỏi về năng lực của một người đã thiết kế cách họ làm việc.
Đặc biệt khi người đó là chính mình.
01. Một lỗi giao hàng và cuộc điều tra nhầm nghi phạm.
Hãy tưởng tượng một doanh nghiệp phân phối hàng hóa với hàng trăm đơn hàng mỗi ngày.
Một khách hàng đặt hàng và yêu cầu giao trước 10 giờ sáng vì cửa hàng cần nguyên liệu để bắt đầu kinh doanh.
Nhân viên bán hàng xác nhận với khách.
Thông tin được ghi trong cuộc trò chuyện.
Đơn hàng chuyển sang bộ phận xử lý.
Kho chuẩn bị hàng.
Bộ phận vận chuyển lên tuyến giao.
Đến 11 giờ, khách gọi điện phàn nàn vì chưa nhận được hàng.
Cuộc điều tra bắt đầu.
Nhân viên bán hàng nói mình đã ghi chú.
Bộ phận xử lý nói không thấy yêu cầu đặc biệt.
Kho khẳng định đã chuẩn bị đúng thời gian.
Bộ phận vận chuyển giải thích rằng tuyến giao hàng được tối ưu theo khu vực, không theo những lời hứa nằm trong cuộc trò chuyện riêng giữa khách và nhân viên bán hàng.
Và thế là chúng ta có một cuộc họp.
Mọi người được yêu cầu phối hợp tốt hơn.
Nhân viên bán hàng phải chú ý hơn.
Bộ phận xử lý cần kiểm tra kỹ hơn.
Kho cần chủ động hơn.
Vận chuyển cần linh hoạt hơn.
Tất cả đều hợp lý.
Chỉ có một vấn đề nhỏ:
Không ai trả lời được tại sao một cam kết quan trọng với khách hàng lại không trở thành một dữ liệu bắt buộc trong quy trình thực hiện đơn hàng.
Không có cơ chế kiểm tra khả năng đáp ứng trước khi cam kết.
Không có trường dữ liệu đủ rõ để phân biệt thời gian khách mong muốn với thời gian doanh nghiệp đã chấp thuận.
Không có tín hiệu cảnh báo khi lịch giao dự kiến xung đột với cam kết.
Không có người chịu trách nhiệm giải quyết xung đột đó trước khi nó trở thành một lời phàn nàn.
Nói cách khác, chúng ta đã yêu cầu một nhóm người phối hợp hoàn hảo bên trong một quy trình không được thiết kế để bảo đảm sự phối hợp ấy.
Rồi khi họ thất bại, chúng ta kết luận rằng họ cần có trách nhiệm hơn.
Thật tiện lợi.
02. Con người không vận hành bằng những giả định hoàn hảo.
Trong Software Engineering, chúng ta không thiết kế một hệ thống đáng tin cậy bằng cách giả định rằng tất cả thành phần đều hoạt động hoàn hảo mãi mãi.
Network có thể mất kết nối.
Database có thể phản hồi chậm.
Một request có thể được gửi hai lần.
Một service có thể ngừng hoạt động giữa chừng.
Một dữ liệu có thể đến sai thứ tự.
Chúng ta biết những điều đó sẽ xảy ra, dù không biết chính xác khi nào.
Vì vậy, những hệ thống được thiết kế tốt thường phải tính đến timeout, retry, idempotency, validation, transaction boundary và failure recovery.
Không phải vì chúng ta ghét các thành phần của hệ thống.
Mà vì chúng ta hiểu giới hạn của chúng.
Nhưng khi chuyển sang thiết kế tổ chức, nhiều người đột nhiên trở nên lạc quan một cách khó hiểu.
Chúng ta kỳ vọng nhân viên phải nhớ mọi quy định.
Hiểu mọi ngoại lệ.
Không bao giờ bỏ sót thông tin.
Luôn đánh giá đúng mức độ ưu tiên.
Phối hợp chính xác với những người khác.
Và đưa ra quyết định đúng ngay cả khi dữ liệu không đầy đủ.
Nếu họ không làm được?
Thiếu trách nhiệm.
Tôi thấy đây là một sự bất công về mặt thiết kế.
Chúng ta chấp nhận rằng máy móc có giới hạn, nhưng lại thường thiết kế công việc như thể con người không có giới hạn.
Trong khi con người còn phức tạp hơn máy móc rất nhiều.
Họ có trí nhớ hữu hạn, khả năng tập trung dao động, kinh nghiệm khác nhau và cách diễn giải thông tin không hoàn toàn giống nhau.
Họ còn có những vấn đề cá nhân, cảm xúc, áp lực thời gian và hàng trăm yếu tố mà một bản mô tả công việc không thể liệt kê hết.
Một quy trình chỉ hoạt động khi mọi người luôn nhớ đúng, hiểu đúng và làm đúng không phải một quy trình đáng tin cậy.
Nó là một lời cầu nguyện được viết bằng ngôn ngữ hành chính.
03. Đừng nhầm sự tận tâm với độ tin cậy của hệ thống.
Tôi từng thấy nhiều tổ chức vận hành khá tốt nhờ một vài cá nhân cực kỳ xuất sắc.
Họ nhớ được sở thích của từng khách hàng.
Biết đơn hàng nào cần ưu tiên.
Biết nhà cung cấp nào thường giao trễ.
Biết nhân viên nào cần được nhắc.
Biết khi nào phải gọi điện, khi nào phải kiểm tra và khi nào cần tự mình can thiệp.
Những người như vậy thường được xem là không thể thay thế.
Và trong nhiều trường hợp, nhận định đó hoàn toàn chính xác.
Nhưng tôi luôn muốn đặt thêm một câu hỏi:
Tại sao những thông tin quan trọng đến mức quyết định chất lượng vận hành lại chỉ tồn tại trong đầu một con người?
Nếu người đó nghỉ phép thì sao?
Nếu họ chuyển sang một vị trí khác?
Nếu doanh nghiệp tăng quy mô gấp ba lần?
Nếu số lượng khách hàng vượt quá khả năng ghi nhớ và xử lý của họ?
Một cá nhân xuất sắc có thể bù đắp cho rất nhiều khiếm khuyết trong tổ chức.
Nhưng chính khả năng đó đôi khi khiến các khiếm khuyết tồn tại lâu hơn.
Bởi vì khi kết quả vẫn tốt, không ai có đủ động lực để thay đổi cách vận hành.
Doanh nghiệp bắt đầu phụ thuộc vào năng lực cá nhân mà không nhận ra rằng mình đang tích lũy một khoản nợ kiến trúc.
Trong phần mềm, chúng ta gọi một số dạng vấn đề tương tự là technical debt.
Trong tổ chức, tôi thích gọi nó là organizational debt.
Khoản nợ này không nhất thiết xuất hiện trên bảng cân đối kế toán.
Nó được thanh toán bằng thời gian của những người giỏi nhất, bằng sự phụ thuộc giữa các bộ phận và bằng khả năng mở rộng ngày càng hạn chế.
Điều đáng nói là người giỏi thường không phải người tạo ra khoản nợ đó.
Họ chỉ là những người đang âm thầm trả lãi mỗi ngày.
04. Trách nhiệm cá nhân và trách nhiệm hệ thống không loại trừ nhau.
Đến đây, một câu hỏi hợp lý sẽ xuất hiện.
Nếu lỗi nào cũng có thể quy về thiết kế hệ thống, vậy con người còn phải chịu trách nhiệm về điều gì?
Đây là chỗ tôi muốn phân biệt thật rõ.
Tôi không tin mọi sai lầm đều có nguyên nhân từ hệ thống.
Và tôi càng không tin một tổ chức nên trở thành nơi mọi cá nhân đều có thể viện lý do quy trình để trốn tránh trách nhiệm.
Một nhân viên đã được cung cấp thông tin chính xác, được đào tạo đầy đủ, có đủ công cụ và quyền hạn, nhưng vẫn cố tình bỏ qua quy định thì phải chịu trách nhiệm về quyết định của mình.
Một người liên tục không đáp ứng yêu cầu năng lực tối thiểu của vị trí cũng không thể mặc nhiên xem mình là nạn nhân của kiến trúc tổ chức.
Nhưng điều ngược lại cũng đúng.
Nếu thông tin không có sẵn, quyền hạn không rõ ràng, quy trình mâu thuẫn hoặc công cụ khiến thao tác sai quá dễ xảy ra, thì việc chỉ kỷ luật người thực hiện không giải quyết được vấn đề.
Chúng ta đang nói về hai loại trách nhiệm khác nhau.
Individual Accountability: Cá nhân có thực hiện đúng trách nhiệm trong những điều kiện được cung cấp hay không?
System Accountability: Tổ chức có thiết kế những điều kiện hợp lý để trách nhiệm đó có thể được thực hiện một cách nhất quán hay không?
Một tổ chức trưởng thành phải đánh giá cả hai.
Thử tưởng tượng một nhân viên được giao trách nhiệm kiểm soát công nợ trước khi xác nhận đơn hàng.
Nhưng dữ liệu công nợ nằm trong một hệ thống khác.
Nhân viên không được quyền truy cập trực tiếp.
Thông tin cập nhật chậm.
Và áp lực xử lý đơn hàng yêu cầu họ hoàn tất giao dịch trong vài phút.
Nếu người đó bỏ qua bước kiểm tra, họ có thể đã vi phạm quy trình.
Nhưng nếu tình trạng tương tự liên tục xảy ra, người quản lý cũng phải trả lời được vì sao quy trình được thiết kế theo cách khiến việc tuân thủ trở nên khó khăn như vậy.
Một giải pháp có thể là đưa trạng thái công nợ trực tiếp vào luồng tạo đơn, tự động chặn giao dịch không đủ điều kiện và thiết kế cơ chế phê duyệt ngoại lệ.
Khi đó, chúng ta không xóa bỏ trách nhiệm cá nhân.
Chúng ta làm cho trách nhiệm trở nên rõ ràng và có thể thực thi.
Một hệ thống tốt không thay thế trách nhiệm. Nó xác định chính xác trách nhiệm bắt đầu và kết thúc ở đâu.
Và khi ai đó cố tình vượt qua những giới hạn đã rõ ràng?
Lúc ấy không cần thêm một cuộc hội thảo về kiến trúc.
Chúng ta cần một quyết định quản trị.
05. Khi quy trình tạo ra chính những hành vi mà nó muốn ngăn chặn.
Có một hiện tượng tinh vi hơn lỗi thao tác.
Đó là khi con người hành động hoàn toàn hợp lý trong phạm vi trách nhiệm của mình, nhưng kết quả chung của tổ chức lại trở nên tồi tệ.
Một nhân viên bán hàng được đánh giá chủ yếu bằng số lượng đơn hàng.
Họ cố gắng tạo thêm nhiều đơn.
Bộ phận kho được đánh giá bằng tốc độ xử lý.
Họ ưu tiên xuất hàng thật nhanh.
Bộ phận vận chuyển được đánh giá bằng chi phí giao hàng.
Họ cố gắng gom tuyến để tối ưu chi phí.
Bộ phận chăm sóc khách hàng được đánh giá bằng thời gian phản hồi.
Họ cố gắng đóng các yêu cầu càng nhanh càng tốt.
Từng bộ phận đều có thể hoàn thành KPI của mình.
Nhưng khách hàng vẫn nhận hàng trễ.
Chi phí xử lý ngoại lệ tăng.
Lợi nhuận trên mỗi giao dịch giảm.
Và tỷ lệ khách quay lại có thể đi xuống.
Không nhất thiết có ai lười biếng.
Không nhất thiết có ai thiếu trách nhiệm.
Mọi người chỉ đang tối ưu những gì hệ thống yêu cầu họ tối ưu.
Local Optimization. Global Dysfunction.
Đây là một trong những dạng vấn đề khiến tôi đặc biệt hứng thú.
Bởi vì chúng không thể được giải quyết đơn giản bằng cách yêu cầu từng cá nhân cố gắng hơn.
Nếu cấu trúc khuyến khích không thay đổi, việc cố gắng hơn thậm chí có thể làm vấn đề nghiêm trọng hơn.
Một nhân viên bán hàng càng giỏi tăng số đơn nhỏ, bộ phận vận chuyển càng phải xử lý nhiều điểm giao.
Một bộ phận vận chuyển càng quyết liệt tối ưu chi phí, thời gian giao hàng có thể càng khó đáp ứng những cam kết riêng.
Và khi từng phòng ban bảo vệ thành tích của mình, không ai thực sự sở hữu kết quả cuối cùng.
Khách hàng không quan tâm doanh nghiệp có bao nhiêu bộ phận đạt KPI.
Họ quan tâm mình có nhận được đúng thứ đã được hứa hay không.
Do đó, thiết kế tổ chức không đơn thuần là phân chia công việc.
Nó còn là thiết kế cách các quyết định riêng lẻ kết hợp thành một kết quả chung.
Nếu bỏ qua điều này, chúng ta có thể xây dựng một doanh nghiệp nơi tất cả mọi người đều hoàn thành nhiệm vụ, ngoại trừ chính doanh nghiệp.
Một thành tích khá ấn tượng, theo hướng không ai mong muốn.
06. Guardrails không phải nhà tù.
Có người cho rằng xây dựng quá nhiều cơ chế kiểm soát sẽ khiến nhân viên mất khả năng tư duy.
Tôi đồng ý một phần.
Một tổ chức được điều hành bằng hàng trăm quy định cứng nhắc, nơi mọi quyết định đều cần xin phép, sẽ khó có khả năng nuôi dưỡng sự chủ động.
Nhưng tôi không cho rằng sự tự chủ đồng nghĩa với việc mọi người được tự do đưa ra mọi quyết định.
Tôi phân biệt hai khái niệm.
Freedom of Execution: Tự chủ trong cách đạt được mục tiêu.
Freedom of Constraint Violation: Tự ý phá bỏ những giới hạn mà tổ chức đã xác định là cần thiết.
Đó không phải cùng một thứ.
Một nhân viên có thể được tự do tìm kiếm khách hàng, xây dựng chuyên môn, đề xuất giải pháp và phát triển thị trường riêng.
Nhưng họ không nhất thiết phải được tự ý bỏ qua kiểm soát công nợ, thay đổi chính sách giá hoặc cam kết những điều mà hệ thống vận hành không có khả năng đáp ứng.
Những giới hạn đó tồn tại để bảo vệ cả doanh nghiệp lẫn người ra quyết định.
Trong Software Engineering, chúng ta thường thiết kế các interface và contract để các thành phần có thể hoạt động tương đối độc lập mà không phá vỡ toàn bộ hệ thống.
Tôi thích áp dụng tư duy tương tự vào tổ chức.
Xác định rõ những gì không được phép phá vỡ.
Tự động hóa những kiểm soát có thể tự động hóa.
Tạo cơ chế ngoại lệ cho những tình huống thực sự cần phán đoán.
Và để con người tự do sáng tạo trong phần không gian còn lại.
Guardrails should protect autonomy, not replace it.
Một hệ thống tốt phải khiến quyết định đúng trở nên dễ thực hiện, quyết định sai vô tình trở nên khó xảy ra, và quyết định ngoại lệ được xử lý minh bạch.
Không phải biến nhân viên thành những cỗ máy chỉ biết làm theo hướng dẫn.
Bởi vì nếu mục tiêu cuối cùng là có một tổ chức không ai cần suy nghĩ, thì tôi có một tin không vui:
Chúng ta vừa dành rất nhiều tiền để tuyển dụng con người làm công việc của một phần mềm.
07. Khi nào nên đào tạo, khi nào nên thiết kế lại?
Đây mới là câu hỏi thực sự khó.
Không có một công thức duy nhất để phân biệt vấn đề năng lực với vấn đề hệ thống.
Nhưng có vài câu hỏi mà tôi luôn thấy hữu ích.
Nếu thay một nhân viên bằng người có kinh nghiệm hơn, vấn đề có biến mất không?
Nếu có, liệu nó biến mất vì người mới hiểu công việc tốt hơn, hay vì họ đủ giỏi để tự mình bù đắp những thiếu sót của quy trình?
Nếu chuyển cùng một nhiệm vụ cho mười người khác nhau, kết quả có ổn định không?
Nếu không, sự khác biệt đến từ năng lực, thông tin, quyền hạn hay những điều kiện vận hành không nhất quán?
Nếu buộc phải xử lý gấp đôi số lượng công việc, cấu trúc hiện tại có còn hoạt động được không?
Và nếu một nhân viên phải ghi nhớ hai mươi ngoại lệ mới hoàn thành đúng một quy trình, liệu vấn đề có thực sự nằm ở trí nhớ của họ?
Những câu hỏi này không cung cấp câu trả lời ngay lập tức.
Chúng giúp chúng ta tránh một sai lầm nguy hiểm hơn: quyết định giải pháp trước khi xác định nguyên nhân.
Đào tạo là cần thiết khi con người thiếu kiến thức hoặc kỹ năng.
Kỷ luật là cần thiết khi có sự vi phạm trách nhiệm rõ ràng.
Thiết kế lại là cần thiết khi cấu trúc công việc liên tục tạo ra những kết quả không mong muốn.
Và có những tình huống cần cả ba.
Một tổ chức đủ trưởng thành phải có khả năng chấp nhận điều đó, thay vì cố gắng sử dụng một phương pháp quản trị duy nhất để xử lý mọi vấn đề.
08. Người giỏi không nên là điều kiện để hệ thống tồn tại.
Tôi tin rằng những cá nhân xuất sắc có vai trò đặc biệt quan trọng trong sự phát triển của một doanh nghiệp.
Họ nhìn thấy những điều người khác chưa nhìn thấy.
Đưa ra quyết định trong điều kiện thiếu thông tin.
Khám phá cơ hội mới.
Xử lý những tình huống chưa từng có tiền lệ.
Và đôi khi tạo ra những bước tiến mà không một quy trình có sẵn nào có thể dự đoán được.
Nhưng tôi không muốn sử dụng phần lớn năng lực của họ để duy trì những công việc đã trở nên lặp lại.
Tôi muốn những gì họ khám phá được có thể trở thành năng lực chung của tổ chức.
Một nhân viên giỏi phát hiện cách xử lý một nhóm khách hàng đặc biệt.
Tốt.
Liệu chúng ta có thể chuyển hiểu biết đó thành dữ liệu, công cụ hoặc phương pháp mà người khác có thể sử dụng?
Một quản lý xây dựng được cơ chế phối hợp hiệu quả.
Tuyệt vời.
Liệu cơ chế đó có thể hoạt động khi người quản lý đi vắng?
Một nhân viên phát hiện một loại ngoại lệ mà quy trình chưa xử lý.
Rất đáng giá.
Liệu tổ chức có thể học từ phát hiện đó trước khi mười người khác gặp lại cùng một tình huống?
Tôi không muốn xóa bỏ sự khác biệt giữa những con người.
Tôi muốn những khác biệt xuất sắc có khả năng tạo ra giá trị vượt khỏi phạm vi của chính cá nhân đó.
Đó là một trong những cách tôi nhìn nhận việc xây dựng tổ chức.
Người giỏi mở ra những giới hạn mới. Hệ thống biến một phần những khám phá đó thành năng lực có thể nhân rộng.
Sau đó, người giỏi lại tiếp tục đi xa hơn.
Một vòng tiến hóa liên tục.
09. Nhưng còn một vấn đề lớn hơn: Ai thiết kế người thiết kế?
Đến đây, chúng ta đã dành khá nhiều thời gian để phân tích những khiếm khuyết trong cấu trúc tổ chức.
Nhưng có một câu hỏi không thể né tránh.
Nếu hệ thống được thiết kế tồi, ai chịu trách nhiệm?
Người thiết kế.
Nếu người thiết kế tiếp tục đưa ra những quyết định sai lầm?
Ai sẽ phát hiện và sửa chữa?
Một người thiết kế khác?
Và ai sẽ kiểm soát người đó?
Nếu tiếp tục lập luận theo cách này, chúng ta có thể xây dựng một chuỗi trách nhiệm dài vô tận.
May mắn là chúng ta không cần làm vậy.
Điều một hệ thống thực sự cần không phải một người thiết kế hoàn hảo.
Nó cần cơ chế để những giả định của người thiết kế có thể bị kiểm chứng.
Một quy định được đưa ra phải có lý do tồn tại.
Một quyết định quan trọng phải có dữ liệu hoặc lập luận hỗ trợ.
Một cơ chế mới phải có khả năng được đánh giá sau khi triển khai.
Và một giả định sai phải có cơ hội bị phát hiện, ngay cả khi giả định đó đến từ người có quyền lực cao nhất trong tổ chức.
Tôi đặc biệt quan tâm đến điều này.
Bởi vì quyền lực càng lớn, một sai lầm trong tư duy thiết kế càng có khả năng ảnh hưởng đến nhiều người.
Một nhân viên đưa ra quyết định sai có thể khiến một giao dịch gặp vấn đề.
Một người thiết kế quy trình đưa ra quyết định sai có thể khiến hàng nghìn giao dịch gặp cùng một vấn đề.
Quyền lực thiết kế càng lớn, trách nhiệm kiểm chứng càng phải cao.
Đó cũng là lý do tôi thích những cuộc tranh luận có dữ liệu, những lập luận có thể phản biện và những người đủ khả năng chỉ ra điều tôi chưa nhìn thấy.
Tôi không cần một tổ chức luôn đồng ý với người lãnh đạo.
Tôi cần một tổ chức có thể phát hiện khi người lãnh đạo đang sai.
Bởi vì một hệ thống mà không ai dám chất vấn kiến trúc sư sẽ rất dễ trở thành một công trình kỳ vĩ.
Kỳ vĩ đến mức khi sụp đổ, mọi người đều có mặt để chứng kiến.
10. Con người không phải hệ thống. Nhưng hệ thống cũng không thể tồn tại nếu thiếu con người.
Sau tất cả, tôi không cho rằng tổ chức nên được nhìn nhận như một cỗ máy nơi nhân viên chỉ là những linh kiện có thể thay thế.
Con người không phải những thành phần đồng nhất.
Họ có tham vọng, khả năng học hỏi, động lực và những tiềm năng mà ngay cả bản thân họ đôi khi cũng chưa nhận ra.
Một kiến trúc tổ chức tốt không nên cố gắng loại bỏ những khác biệt đó.
Nó phải tạo ra điều kiện để những khác biệt ấy phát triển mà không khiến toàn bộ hệ thống mất ổn định.
Điều này có nghĩa là thiết kế những giới hạn đủ rõ để bảo vệ hoạt động chung, đồng thời dành đủ không gian cho cá nhân thử nghiệm những cách làm mới.
Người chưa có nhiều kinh nghiệm cần được bảo vệ khỏi những sai lầm không đáng có.
Người đã trưởng thành cần được trao thêm quyền tự chủ.
Người xuất sắc cần có cơ hội giải quyết những bài toán vượt khỏi công việc thường ngày.
Và người có khả năng thiết kế, tổ chức, phát triển một đơn vị kinh doanh phải được phép chứng minh năng lực đó bằng kết quả thực tế.
Không phải ai cũng sẽ đạt đến cùng một trình độ.
Cũng không cần phải như vậy.
Tôi không có tham vọng biến mọi nhân viên thành thiên tài.
Tôi muốn xây dựng một tổ chức nơi một người bình thường có thể làm việc tốt, một người có năng lực có thể phát triển, và một người thực sự xuất sắc không bị mắc kẹt trong những giới hạn do chính tổ chức tạo ra.
The system should raise the floor without lowering the ceiling.
Nâng cao năng lực tối thiểu mà không giới hạn tiềm năng tối đa.
Với tôi, đó mới là một trong những mục tiêu đáng theo đuổi của Organizational Design.
Lời kết: Đừng sửa nhầm thứ.
Lần tới, khi một nhân viên mắc lỗi, có lẽ câu hỏi đầu tiên không nên là:
"Ai chịu trách nhiệm?"
Câu hỏi đầu tiên nên là:
"Điều gì đã xảy ra, và tại sao?"
Sau khi hiểu rõ nguyên nhân, chúng ta mới có đủ cơ sở để xác định trách nhiệm.
Đôi khi câu trả lời nằm ở năng lực cá nhân.
Đôi khi nằm ở hành vi.
Đôi khi nằm ở cách phân quyền, cấu trúc thông tin, cơ chế khuyến khích hoặc thiết kế quy trình.
Và đôi khi nó nằm ở một giả định sai lầm đã tồn tại quá lâu đến mức không còn ai nhớ tại sao tổ chức lại làm việc theo cách đó.
Tôi không nghĩ một nhà quản lý giỏi là người luôn biết phải trách ai.
Tôi nghĩ đó là người có khả năng phân biệt khi nào cần thay đổi một con người, khi nào cần thay đổi điều kiện làm việc, và khi nào cần thừa nhận chính mình đã thiết kế sai.
Ba quyết định đó có thể dẫn đến những kết quả hoàn toàn khác nhau.
Một tổ chức không thể trưởng thành nếu mọi thất bại đều được giải thích bằng lỗi nhân viên.
Nhưng nó cũng không thể trưởng thành nếu mọi cá nhân đều được miễn trách nhiệm dưới danh nghĩa lỗi hệ thống.
Chúng ta cần cả hai: trách nhiệm cá nhân và trách nhiệm kiến trúc.
Và có lẽ, thay vì tiếp tục hỏi tại sao nhân viên không thể làm việc hoàn hảo, chúng ta nên dành nhiều thời gian hơn để hỏi:
Tại sao doanh nghiệp của mình lại cần con người phải hoàn hảo mới có thể vận hành tốt?
Nếu câu trả lời là vì hệ thống chưa đủ tốt, chúng ta vừa tìm thấy một công việc quan trọng.
Còn nếu câu trả lời là vì người lãnh đạo muốn mọi nhân viên phải vừa thông minh, vừa chăm chỉ, vừa trung thành, vừa chủ động, vừa không bao giờ mắc lỗi...
Thì tôi có một đề xuất đơn giản.
Đừng tuyển nhân viên nữa.
Hãy thử tuyển một vị thần.
Biết đâu đỡ phải họp rút kinh nghiệm.
NEXT CHAPTER — THE HIDDEN COST OF EXCEPTIONS
Những ngoại lệ nhỏ, những chi phí vô hình và cách một tổ chức âm thầm đánh mất năng lực vận hành.
The Architect of Chaos — Ông Chú Hay Chửi