Có một kiểu câu hỏi mà tôi rất thích nghe từ nhân viên.
"Anh ơi, em nghĩ mình có thể làm cái này tốt hơn."
Thông thường, câu chuyện bắt đầu từ một vấn đề khá nhỏ.
Một nhân viên bán hàng nhận thấy khách hàng thường xuyên hỏi cùng một nhóm câu hỏi.
Một người phụ trách in ấn nhận ra nhiều khách chưa hiểu sự khác biệt giữa những phương pháp in.
Một nhân viên chăm sóc khách hàng phát hiện một nhóm khách có nhu cầu đặc biệt mà quy trình hiện tại chưa phục vụ tốt.
Hoặc một người có ý tưởng về một công cụ giúp khách hàng lựa chọn sản phẩm dễ dàng hơn.
Những ý tưởng đó thường không quá hoành tráng.
Không có chiến lược chuyển đổi số.
Không có một dự án trị giá hàng tỷ đồng.
Không có slide trình bày về tương lai của ngành.
Chỉ là một người đang trực tiếp làm việc, nhìn thấy một vấn đề và nghĩ rằng có lẽ tồn tại cách giải quyết tốt hơn.
Tôi đặc biệt thích những khoảnh khắc như vậy.
Bởi vì chúng cho thấy người đó đã bắt đầu đi xa hơn việc thực hiện những nhiệm vụ được giao.
Họ không chỉ nhìn thấy công việc.
Họ bắt đầu nhìn thấy khả năng thay đổi cách công việc được thực hiện.
Nhưng trong phần lớn doanh nghiệp, điều gì xảy ra tiếp theo?
Nhân viên trình bày ý tưởng với quản lý.
Quản lý đánh giá.
Nếu thấy hợp lý, họ chuyển yêu cầu cho bộ phận kỹ thuật.
Bộ phận kỹ thuật cần làm rõ nghiệp vụ.
Ý tưởng được viết lại thành một tài liệu.
Tài liệu được ưu tiên so với những yêu cầu khác.
Sau đó, nếu đủ may mắn, nó được đưa vào kế hoạch phát triển.
Một tháng.
Hai tháng.
Có thể lâu hơn.
Trong khoảng thời gian đó, nhân viên tiếp tục công việc thường ngày.
Vấn đề vẫn tồn tại.
Và ý tưởng ban đầu dần mất đi sự hào hứng.
Đến một ngày, hệ thống mới được triển khai.
Nhân viên nhìn vào và nói:
"Không phải cái em muốn làm."
Tôi không nghĩ đây nhất thiết là lỗi của bộ phận kỹ thuật.
Họ có thể đã thực hiện rất tốt những yêu cầu được cung cấp.
Vấn đề nằm ở khoảng cách giữa người hiểu nhu cầu thực tế và người có khả năng biến nhu cầu đó thành công cụ.
Một khoảng cách chứa đầy những cuộc họp, tài liệu, sự diễn giải và những giả định không được kiểm chứng.
Tôi đã dành nhiều năm làm Software Engineer.
Tôi hiểu khoảng cách đó có thể đắt đỏ đến mức nào.
Và tôi cũng hiểu một điều khác.
Người có khả năng viết phần mềm không nhất thiết là người hiểu vấn đề kinh doanh sâu nhất.
Ngược lại, người hiểu vấn đề kinh doanh sâu nhất chưa chắc có khả năng xây dựng phần mềm.
Trong mô hình truyền thống, hai người phải liên tục trao đổi để chuyển kiến thức từ bên này sang bên kia.
Nhưng điều gì xảy ra nếu một ngày, người hiểu vấn đề có thể tự xây dựng một phần giải pháp?
Không cần trở thành Software Engineer chuyên nghiệp.
Không cần hiểu toàn bộ kiến trúc doanh nghiệp.
Và không cần đợi người sáng lập trực tiếp thiết kế mọi thứ.
Điều gì xảy ra nếu chúng ta có thể xây dựng một môi trường nơi những ý tưởng nhỏ được thử nghiệm ngay tại nơi chúng xuất hiện?
Tôi nghĩ đây là một câu hỏi đáng để theo đuổi.
Nhưng nó cũng đặt ra một vấn đề lớn hơn.
Nếu bất cứ ai cũng có khả năng tạo ra công cụ mới, làm sao ngăn tổ chức trở thành một khu rừng những công cụ không ai kiểm soát?
Bởi vì tôi muốn nhân viên có khả năng xây dựng.
Nhưng tôi không muốn mỗi sáng thức dậy và phát hiện ba mươi người vừa triển khai ba mươi phiên bản khác nhau của hệ thống quản lý khách hàng.
Với ba mươi cách tính giá.
Ba mươi database.
Và ba mươi người đều tin rằng phiên bản của mình tốt nhất.
Đó không phải Freedom to Build.
Đó là một cuộc nội chiến công nghệ.
Và rất có thể tôi là thằng phải dọn dẹp chiến trường.
01. Freedom to Execute và Freedom to Build là hai cấp độ hoàn toàn khác nhau.
Trong Chapter 6, tôi đã bàn về Guardrails.
Cách thiết kế những giới hạn để con người có thể tự chủ mà không phá vỡ những ràng buộc quan trọng của doanh nghiệp.
Một nhân viên có thể tự quyết định trong phạm vi quyền hạn.
Có thể phát triển khách hàng theo phương pháp riêng.
Có thể xử lý những tình huống đã được phân quyền.
Và có thể chịu trách nhiệm về kết quả mà không cần người quản lý can thiệp liên tục.
Tôi gọi đó là Freedom to Execute.
Quyền tự chủ trong một cấu trúc đã tồn tại.
Nhưng có một cấp độ khác.
Một nhân viên không chỉ muốn sử dụng tốt hơn những công cụ hiện tại.
Họ nhận thấy một năng lực mới cần được xây dựng.
Một cách tư vấn mới.
Một phương pháp phân loại khách hàng mới.
Một công cụ hỗ trợ lựa chọn sản phẩm.
Một quy trình giúp một nhóm khách hàng được phục vụ tốt hơn.
Hoặc một micro-product mà doanh nghiệp chưa từng sở hữu.
Lúc này, người đó không chỉ muốn được quyền ra quyết định bên trong hệ thống.
Họ muốn được quyền đề xuất và tạo ra một thành phần mới của hệ thống.
Đây là Freedom to Build.
Sự khác biệt rất lớn.
Freedom to Execute trả lời câu hỏi:
"Tôi được phép làm gì trong những giới hạn đã được xác định?"
Freedom to Build đặt một câu hỏi khác:
"Tôi có thể tạo ra điều gì mới mà vẫn tôn trọng những giới hạn chung?"
Một tổ chức có thể rất tốt ở cấp độ thứ nhất nhưng hoàn toàn yếu ở cấp độ thứ hai.
Nhân viên được tự chủ chăm sóc khách hàng.
Nhưng không được thay đổi công cụ.
Được quyền đề xuất cải tiến.
Nhưng không có khả năng thử nghiệm.
Được khuyến khích sáng tạo.
Nhưng mọi ý tưởng đều phải đợi sự chấp thuận và năng lực triển khai của một bộ phận trung tâm.
Cuối cùng, tự chủ chỉ tồn tại trong phạm vi những khả năng mà người thiết kế ban đầu đã dự đoán.
Tôi không muốn dừng ở đó.
Bởi vì nếu mọi năng lực mới đều phải được founder nghĩ ra, toàn bộ tổ chức sẽ bị giới hạn bởi khả năng tưởng tượng của founder.
Một giới hạn có thể rất cao.
Nhưng vẫn là một giới hạn.
Freedom to Execute creates independent operators. Freedom to Build creates the possibility of new builders.
Tôi muốn có cả hai.
Nhưng điều đó không có nghĩa mọi người phải trở thành builder.
Một tổ chức cần những người vận hành xuất sắc.
Cần những người có chuyên môn sâu.
Cần những người làm việc ổn định, chính xác và đáng tin cậy.
Và cần những người có khả năng nhìn thấy những cơ hội chưa tồn tại trong cấu trúc hiện tại.
Tôi không muốn ép tất cả phải giống nhau.
Tôi chỉ không muốn những người có khả năng xây dựng bị mắc kẹt trong vai trò của người thực thi.
02. Những ý tưởng tốt thường xuất hiện ở rìa hệ thống.
Hãy tưởng tượng một nhân viên bán hàng chuyên phục vụ những cửa hàng bánh mì.
Người đó tiếp xúc với khách hàng mỗi ngày.
Biết loại túi giấy nào được mua nhiều.
Biết những kích thước thường được sử dụng.
Biết khách hàng mới thường gặp khó khăn ở đâu.
Biết những yêu cầu in ấn phổ biến.
Và biết những trường hợp nào khách hàng thường mua sai vì không hiểu rõ sản phẩm.
Sau vài tháng, nhân viên bắt đầu nhận thấy một mẫu hình.
Rất nhiều khách mới không thực sự biết mình cần mua loại túi nào.
Họ không hiểu sự khác biệt giữa các chất liệu.
Không chắc nên chọn kích thước nào.
Không biết khi nào nên dùng túi in sẵn và khi nào nên đặt in theo yêu cầu.
Và thường phải trao đổi khá lâu trước khi đưa ra quyết định.
Người nhân viên nghĩ:
"Nếu có một công cụ hỏi khách vài câu, rồi gợi ý nhóm sản phẩm phù hợp thì tốt."
Đây không phải một ý tưởng đặc biệt phức tạp.
Nhưng nó đến từ sự hiểu biết thực tế.
Người xây dựng nền tảng thương mại điện tử có thể không nhận ra nhu cầu ấy ngay lập tức.
Họ đang quan tâm đến kiến trúc sản phẩm, hiệu suất website, dữ liệu, quy trình giao dịch và hàng trăm vấn đề khác.
Người phụ trách marketing có thể nhận ra nhu cầu tìm kiếm.
Nhưng chưa chắc hiểu đủ sâu những khác biệt kỹ thuật giữa từng loại bao bì.
Người phụ trách kho biết quy cách hàng hóa.
Nhưng không nhất thiết hiểu cách khách hàng diễn đạt vấn đề của họ.
Trong khi đó, người nhân viên trực tiếp tư vấn đang đứng ở nơi những tri thức ấy giao nhau.
Đây là một lợi thế mà tôi gọi là Domain Proximity.
Khoảng cách giữa người quan sát và vấn đề thực tế.
Người càng gần vấn đề có thể càng dễ nhận thấy những chi tiết mà hệ thống trung tâm chưa biết.
Tất nhiên, ở gần vấn đề không tự động khiến họ hiểu đúng nguyên nhân.
Một nhân viên có thể rất hiểu khách hàng của mình nhưng không nhận ra những ràng buộc kinh tế hoặc vận hành ở cấp toàn doanh nghiệp.
Một ý tưởng tốt tại một cửa hàng chưa chắc có giá trị khi áp dụng cho toàn bộ hệ thống.
Nhưng điều đó không làm mất đi giá trị của những quan sát từ tuyến đầu.
Tôi muốn những quan sát ấy có cơ hội trở thành giả thuyết.
Và những giả thuyết có cơ hội được thử nghiệm.
Không phải ý tưởng nào cũng cần CEO đánh giá trước khi có thể tạo ra một bản thử nghiệm nhỏ.
Innovation often begins where reality meets the limitations of the existing system.
Đổi mới thường bắt đầu tại nơi thực tế va chạm với những giới hạn của hệ thống hiện tại.
Và trong một doanh nghiệp có hàng chục con người tiếp xúc với những nhóm khách hàng khác nhau, số lượng điểm va chạm ấy có thể lớn hơn rất nhiều so với những gì người sáng lập trực tiếp nhìn thấy.
Nếu mọi tín hiệu đều phải đi qua một người để được nhận diện và diễn giải, tổ chức đang lãng phí một phần rất lớn khả năng quan sát của chính mình.
03. Vấn đề không phải tổ chức thiếu ý tưởng. Mà là chi phí để kiểm chứng ý tưởng quá cao.
Tôi không tin doanh nghiệp thiếu ý tưởng.
Những ý tưởng xuất hiện mỗi ngày.
Một cách bán hàng mới.
Một nhóm sản phẩm mới.
Một quy trình tốt hơn.
Một tính năng nhỏ.
Một công cụ hỗ trợ khách hàng.
Nhưng từ ý tưởng đến kết quả thực tế là một khoảng cách rất lớn.
Trong nhiều tổ chức, mỗi ý tưởng phải cạnh tranh nguồn lực với hàng chục dự án khác.
Cần người phân tích.
Cần người thiết kế.
Cần người phát triển.
Cần người kiểm thử.
Và cần người chịu trách nhiệm triển khai.
Nếu chi phí để kiểm chứng một ý tưởng quá cao, tổ chức sẽ có xu hướng chỉ lựa chọn những ý tưởng mà người có quyền lực tin tưởng nhất.
Điều đó không hoàn toàn vô lý.
Nguồn lực có giới hạn.
Doanh nghiệp không thể triển khai mọi thứ.
Nhưng nó tạo ra một hệ quả.
Khả năng đổi mới của toàn tổ chức bị giới hạn bởi khả năng lựa chọn ý tưởng của một nhóm nhỏ.
Những cơ hội không được họ nhận diện có thể không bao giờ được thử nghiệm.
Những ý tưởng chưa đủ rõ để trình bày thành một dự án lớn sẽ bị bỏ qua.
Và những vấn đề nhỏ nhưng có giá trị thực tế có thể tiếp tục tồn tại vì không đáng chiếm dụng nguồn lực của bộ phận kỹ thuật trung tâm.
Tôi muốn thay đổi cấu trúc chi phí này.
Không phải mọi ý tưởng đều cần trở thành một dự án.
Một số chỉ cần một bản thử nghiệm.
Một công cụ nhỏ.
Một trang tư vấn.
Một bảng phân tích.
Một luồng tương tác mới.
Một prototype có thể được sử dụng bởi vài người trước khi quyết định có nên phát triển xa hơn hay không.
Nếu chi phí thử nghiệm đủ thấp và rủi ro được giới hạn, chúng ta có thể cho phép nhiều ý tưởng được kiểm chứng hơn.
Những ý tưởng không phù hợp bị loại bỏ sớm.
Những ý tưởng có tín hiệu tốt được phát triển thêm.
Và những ý tưởng thực sự tạo ra giá trị có cơ hội được tích hợp vào năng lực chung của tổ chức.
Đây là một mô hình học hỏi khác với việc lập kế hoạch phát triển phần mềm hoàn toàn từ trung tâm.
The objective is not to fund more ideas. It is to make learning from ideas cheaper.
Tôi không muốn doanh nghiệp đầu tư vào nhiều ý tưởng chỉ vì nhân viên thích sáng tạo.
Tôi muốn chi phí phát hiện ý tưởng sai giảm xuống.
Và khả năng nhận diện ý tưởng có giá trị tăng lên.
Điều đó có thể tạo ra một lợi thế rất lớn theo thời gian.
Bởi vì trong kinh doanh, không phải lúc nào người có tầm nhìn tốt nhất cũng có thể dự đoán chính xác những cơ hội sẽ thành công.
Đôi khi chúng ta chỉ có thể hiểu chúng sau khi được tiếp xúc với thực tế.
04. AI thay đổi chi phí xây dựng. Nhưng không thay đổi bản chất của trách nhiệm.
Trong quá khứ, phần mềm là một loại năng lực tương đối khan hiếm.
Muốn xây dựng ứng dụng, chúng ta cần người có kỹ năng lập trình.
Cần hiểu ngôn ngữ.
Framework.
Database.
API.
Deployment.
Và rất nhiều vấn đề kỹ thuật khác.
Một nhân viên bán hàng có thể hiểu vấn đề kinh doanh rất sâu nhưng không có khả năng tự tạo công cụ để giải quyết.
Điều đó khiến họ phải phụ thuộc vào bộ phận kỹ thuật.
AI-assisted development bắt đầu thay đổi một phần sự phụ thuộc ấy.
Một người không phải lập trình viên có thể mô tả nhu cầu, nhận được mã nguồn, tạo giao diện và thử nghiệm những chức năng mà trước đây họ rất khó tự xây dựng.
Tôi nghĩ đây là một thay đổi quan trọng.
Nhưng tôi muốn đặt nó vào đúng vị trí.
AI làm giảm chi phí chuyển một ý tưởng thành phần mềm. Nó không tự động làm giảm chi phí của một ý tưởng sai.
Một người có thể sử dụng AI để xây dựng một ứng dụng trong vài giờ.
Ứng dụng trông rất đẹp.
Có giao diện.
Có database.
Có biểu đồ.
Có cả một AI assistant.
Nhưng nếu nó giải quyết sai vấn đề, giá trị kinh doanh vẫn có thể bằng không.
Nếu dữ liệu được sử dụng không chính xác, kết quả vẫn sai.
Nếu mô hình quyền hạn không phù hợp, ứng dụng vẫn có thể tạo ra rủi ro.
Nếu không có ai chịu trách nhiệm bảo trì, ứng dụng vẫn có thể trở thành một gánh nặng.
Và nếu một công cụ được xây dựng chỉ vì người tạo ra nó cảm thấy thú vị, không có nghĩa tổ chức nên tiếp tục duy trì nó.
AI có thể làm việc viết code trở nên dễ tiếp cận hơn.
Nhưng nó không thay thế được khả năng xác định vấn đề.
Không thay thế được kiến thức nghiệp vụ.
Không thay thế được trách nhiệm kinh doanh.
Và không thay thế được những cơ chế bảo vệ dữ liệu và tài nguyên chung.
Tôi thích nghĩ về AI như một loại đòn bẩy.
Nó cho phép một người có hiểu biết thực tế tạo ra nhiều thứ hơn với ít rào cản kỹ thuật hơn.
Nhưng giá trị của đòn bẩy vẫn phụ thuộc vào người sử dụng đang cố gắng thực hiện điều gì.
AI makes it cheaper to build. It does not make everything worth building.
Và đây là lý do tôi không muốn đánh giá thành công của một chương trình Freedom to Build bằng số lượng nhân viên đã sử dụng AI để viết phần mềm.
Một trăm ứng dụng không có giá trị không tốt hơn mười ứng dụng có giá trị.
Thậm chí có thể tệ hơn.
Bởi vì một trăm ứng dụng đó vẫn có khả năng tạo ra chi phí bảo trì, dữ liệu phân mảnh và những phụ thuộc mới.
Tôi muốn những người có khả năng xây dựng.
Nhưng trước hết, tôi muốn họ học cách xác định điều gì đáng được xây dựng.
05. Micro-product — Một đơn vị nhỏ của năng lực kinh doanh.
Tôi thích khái niệm micro-product.
Không phải vì nó nghe hiện đại.
Mà vì nó giúp chúng ta giới hạn phạm vi của một ý tưởng.
Một micro-product không nhất thiết phải là một ứng dụng hoàn chỉnh với hàng chục chức năng.
Nó có thể là một công cụ giải quyết một nhóm vấn đề cụ thể.
Một bộ chọn bao bì cho tiệm bánh.
Một công cụ tính định lượng nguyên liệu.
Một hệ thống giúp khách hàng ước lượng nhu cầu sản phẩm theo số lượng bán dự kiến.
Một trợ lý giải thích những lựa chọn in ấn.
Hoặc một giao diện giúp nhân viên xử lý một loại công việc chuyên biệt.
Điều quan trọng không phải kích thước phần mềm.
Mà là nó có một mục đích rõ ràng.
Một nhóm người sử dụng xác định.
Một vấn đề cụ thể.
Một giả thuyết về giá trị.
Và một người chịu trách nhiệm đánh giá kết quả.
Hãy quay lại với nhân viên chuyên về túi giấy bánh mì.
Người đó có thể bắt đầu bằng một công cụ rất đơn giản.
Khách hàng trả lời một vài câu hỏi.
Loại sản phẩm cần đựng?
Kích thước ước tính?
Số lượng sử dụng?
Có nhu cầu in thương hiệu không?
Công cụ sử dụng những dữ liệu đã được xác minh để gợi ý các nhóm bao bì phù hợp.
Không cần tự phát minh hệ thống sản phẩm mới.
Không cần tự quyết giá bán.
Không cần tự xử lý công nợ.
Không cần tạo một quy trình giao dịch riêng.
Nó chỉ làm một việc.
Giúp khách hàng và nhân viên thu hẹp những lựa chọn phù hợp trước khi đi vào giao dịch.
Nếu công cụ không ai sử dụng, giả thuyết ban đầu có thể chưa đúng.
Nếu khách hàng sử dụng nhưng vẫn cần tư vấn lại toàn bộ, có thể công cụ chưa giải quyết được vấn đề.
Nếu nó giúp rút ngắn quá trình lựa chọn mà không làm tăng tỷ lệ mua sai, đó là một tín hiệu đáng xem xét.
Nếu nó được nhiều nhân viên sử dụng và tạo ra kết quả ổn định, tổ chức có thể cân nhắc phát triển thành một năng lực chung.
Tôi thích quá trình đó.
Một vấn đề nhỏ.
Một giải pháp nhỏ.
Một thử nghiệm có kiểm soát.
Một kết quả có thể quan sát.
Và một quyết định phát triển dựa trên bằng chứng.
A micro-product is not a small piece of software. It is a small, testable unit of business capability.
Tôi nghĩ đây là cách tiếp cận quan trọng.
Bởi vì nếu xem micro-product chỉ là phần mềm nhỏ, chúng ta sẽ dễ dàng tạo ra hàng trăm công cụ.
Nhưng nếu xem nó là một đơn vị năng lực kinh doanh, chúng ta buộc phải trả lời câu hỏi nó tạo ra giá trị gì.
Và ai thực sự chịu trách nhiệm về giá trị ấy.
06. Shared Core, Distributed Innovation.
Nếu mỗi nhân viên có thể xây dựng micro-product, tổ chức phải quyết định những gì được phép xây dựng độc lập và những gì phải được giữ nhất quán.
Tôi không muốn mỗi ứng dụng có một cách định danh khách hàng.
Không muốn mỗi công cụ tự tính giá theo logic riêng.
Không muốn từng nhóm tự tạo chính sách tín dụng.
Không muốn dữ liệu sản phẩm quan trọng bị sao chép thành nhiều phiên bản không đồng bộ.
Và không muốn một công cụ nhỏ có khả năng vô tình làm thay đổi những trạng thái quan trọng của toàn doanh nghiệp.
Nhưng tôi cũng không muốn tất cả ứng dụng phải được phát triển bởi cùng một nhóm kỹ thuật.
Hai mục tiêu ấy có vẻ mâu thuẫn.
Tôi nghĩ lời giải nằm ở việc phân biệt năng lực nền tảng với năng lực chuyên biệt.
Một số năng lực nên được cung cấp bởi hệ thống chung.
Định danh khách hàng.
Thông tin sản phẩm.
Điều kiện thương mại.
Quy trình giao dịch.
Quyền hạn.
Trạng thái công nợ.
Và các cơ chế kiểm soát quan trọng.
Những năng lực này cần có contract rõ ràng.
Nhưng trên nền tảng đó, từng nhóm có thể phát triển những cách sử dụng khác nhau.
Một nhóm tạo công cụ tư vấn cho quán cà phê.
Một nhóm xây dựng giải pháp cho tiệm bánh.
Một nhóm thử nghiệm phương pháp chăm sóc khách hàng.
Một nhóm phát triển nội dung hoặc công cụ hỗ trợ những sản phẩm in theo yêu cầu.
Không nhất thiết phải có cùng giao diện.
Không nhất thiết phải sử dụng cùng logic tư vấn.
Và không nhất thiết phải theo đuổi cùng một phương pháp tiếp cận khách hàng.
Nhưng khi tạo giao dịch, họ vẫn sử dụng những năng lực giao dịch có thẩm quyền.
Khi cần giá, họ truy cập nguồn giá phù hợp.
Khi cần dữ liệu sản phẩm, họ sử dụng những thông tin được quản lý chung.
Và khi cần thực hiện hành động có rủi ro, họ phải tuân thủ những cơ chế quyền hạn đã được thiết kế.
Shared Core. Distributed Innovation.
Lõi chung bảo vệ tính nhất quán.
Những thành phần chuyên biệt được phép phát triển theo nhu cầu thực tế.
Đây không phải lựa chọn giữa tập trung và phân tán.
Nó là việc tập trung những gì cần tập trung, để có thể phân tán những gì đáng được phân tán.
Một hệ thống như vậy có thể vừa tạo ra kỷ luật, vừa tạo ra khả năng thử nghiệm.
Nhưng nó đòi hỏi một kiến trúc nền tảng đủ trưởng thành.
Nếu không, mỗi micro-product sẽ bắt đầu tự xây dựng những năng lực mà doanh nghiệp vốn đã có.
Và sau một thời gian, chúng ta sẽ phát hiện mình vừa tạo ra một đội quân những mini-ERP.
Mỗi hệ thống có một tác giả.
Một triết lý.
Một database.
Và một danh sách lý do tại sao nó không thể tích hợp với những hệ thống khác.
Tôi từng là Software Engineer.
Tôi biết những câu chuyện ấy thường kết thúc như thế nào.
Không đẹp lắm.
07. Sandbox là nơi được phép sai. Production không phải sân chơi.
Tôi muốn con người được quyền thử nghiệm.
Nhưng tôi không muốn thử nghiệm bằng cách đưa những giả định chưa được kiểm chứng trực tiếp vào hoạt động thực tế.
Một người có thể sử dụng AI để tạo ứng dụng.
Có thể viết code chưa tối ưu.
Có thể chọn một cách thiết kế không phù hợp.
Có thể thử nghiệm một ý tưởng rồi phát hiện nó không có giá trị.
Tôi không có vấn đề gì với những sai lầm đó nếu phạm vi ảnh hưởng được giới hạn phù hợp.
Ngược lại, chúng là một phần của quá trình học hỏi.
Nhưng nếu một ứng dụng thử nghiệm có quyền sửa dữ liệu khách hàng thật, thay đổi chính sách giá hoặc tạo những giao dịch có hiệu lực, rủi ro đã chuyển sang một cấp độ khác.
Đây là lý do tôi thích khái niệm Sandbox Isolation.
Một môi trường cho phép xây dựng mà không tự động trao quyền can thiệp vào những tài nguyên quan trọng.
Trong môi trường đó, một người có thể tạo giao diện.
Thử nghiệm logic.
Sử dụng dữ liệu mô phỏng hoặc dữ liệu đã được xử lý phù hợp.
Kiểm tra những tình huống nghiệp vụ.
Và điều chỉnh sản phẩm trước khi đề xuất triển khai thực tế.
Nhưng sandbox không phải production thu nhỏ với toàn bộ quyền truy cập được sao chép nguyên vẹn.
Quyền dữ liệu phải được giới hạn.
Khả năng kết nối phải được kiểm soát.
Tài nguyên cần có hạn mức.
Và những hành động có thể tạo ra hậu quả thực tế không nên được phép chỉ vì người phát triển muốn thử nghiệm nhanh.
Điều tôi muốn bảo vệ không chỉ là dữ liệu.
Mà còn là sự tự tin của những người được trao quyền xây dựng.
Nếu một nhân viên biết rằng thử nghiệm của mình không thể vô tình phá hủy hoạt động kinh doanh, họ có thể mạnh dạn khám phá hơn.
Nếu mọi sai sót kỹ thuật đều có khả năng trở thành sự cố production, việc thử nghiệm sẽ nhanh chóng trở thành một hoạt động đáng sợ.
A safe sandbox does not reduce creativity. It makes experimentation economically and operationally possible.
Tôi muốn sai lầm nhỏ được phép xảy ra trong phạm vi nhỏ.
Không phải ngăn mọi sai lầm.
Mà là ngăn những sai lầm chưa được kiểm chứng trở thành tổn thất lớn.
Và có một sự khác biệt mà tôi nghĩ phải làm thật rõ.
Permission to Build không đồng nghĩa với Permission to Deploy.
Quyền tạo ra phần mềm không tự động tạo ra quyền đưa phần mềm đó vào hệ thống vận hành chính thức.
Một nhân viên có thể tự do phát triển công cụ trong phạm vi thử nghiệm.
Nhưng khi công cụ bắt đầu truy cập dữ liệu thật, tiếp xúc với khách hàng hoặc tạo ra cam kết kinh doanh, mức độ trách nhiệm đã thay đổi.
Đó là lúc cần những cơ chế kiểm chứng tương ứng.
Không phải để giết chết ý tưởng.
Mà để bảo đảm rằng khi một ý tưởng rời khỏi phòng thí nghiệm, nó không trở thành một vấn đề mới cho cả doanh nghiệp.
08. Capability API — Quyền tạo ra công cụ không đồng nghĩa với quyền sở hữu hệ thống lõi.
Trong một kiến trúc phần mềm thông thường, chúng ta có thể cung cấp API để các ứng dụng tương tác với nhau.
Nhưng tôi muốn đi xa hơn việc chỉ cung cấp endpoint kỹ thuật.
Tôi muốn các năng lực quan trọng của doanh nghiệp được biểu diễn như những capability có thẩm quyền và ràng buộc rõ ràng.
Một ứng dụng có thể cần lấy thông tin sản phẩm.
Một công cụ có thể cần tạo giỏ hàng.
Một micro-product có thể cần xác định điều kiện giao dịch.
Một hệ thống tư vấn có thể cần gửi yêu cầu hỗ trợ đến đúng nhân viên.
Những hành động đó không có cùng mức rủi ro.
Đọc thông tin sản phẩm công khai khác với truy cập dữ liệu khách hàng.
Tạo một bản nháp giỏ hàng khác với xác nhận một đơn hàng.
Gợi ý mức giá khác với thay đổi chính sách giá.
Và gửi một yêu cầu tư vấn khác với thay đổi người sở hữu quan hệ khách hàng trong CRM.
Vì vậy, tôi không muốn mọi công cụ đều được cung cấp một quyền truy cập database tổng quát.
Tôi muốn hệ thống xác định:
Ai đang yêu cầu?
Công cụ nào đang thực hiện?
Hành động gì được yêu cầu?
Phạm vi dữ liệu nào được phép sử dụng?
Những ràng buộc nào phải được kiểm tra?
Và kết quả cần được ghi nhận thế nào?
Đây là một lớp Permissioned Capability Architecture.
Một micro-product không cần hiểu toàn bộ cách hệ thống lõi hoạt động.
Nó sử dụng những năng lực đã được cung cấp qua interface phù hợp.
Nhưng interface đó không chỉ kiểm tra dữ liệu đầu vào.
Nó còn bảo vệ những giới hạn mà hoạt động kinh doanh yêu cầu.
Một công cụ tư vấn có thể tạo đề xuất.
Nhưng không được tự ý vượt qua chính sách tín dụng.
Một ứng dụng của nhân viên có thể yêu cầu thông tin khách hàng trong phạm vi được phép.
Nhưng không được xem toàn bộ dữ liệu của những nhóm khác chỉ vì đã biết cách gọi API.
Một micro-product có thể sử dụng năng lực tạo đơn.
Nhưng những điều kiện quan trọng của giao dịch vẫn phải được hệ thống có thẩm quyền kiểm tra.
Build whatever you can imagine within your domain. Execute only what your capabilities authorize.
Tôi thích nguyên lý này.
Nó tạo ra ranh giới giữa sáng tạo và thẩm quyền.
Một người có thể tạo ra những trải nghiệm mới.
Những luồng tư vấn mới.
Những cách tiếp cận khách hàng mới.
Nhưng không được phép âm thầm phát minh lại những ràng buộc mà toàn tổ chức đã cam kết bảo vệ.
Đây là cách tôi muốn biến guardrails từ một tập hợp quy định thành cơ sở hạ tầng cho sự sáng tạo.
Nếu nền tảng đủ tốt, những người xây dựng không cần phải hiểu tất cả rủi ro của hệ thống lõi.
Họ chỉ cần sử dụng những capability phù hợp và tuân thủ contract của chúng.
Điều đó không loại bỏ mọi rủi ro.
Nhưng nó có thể làm giảm đáng kể phạm vi mà một sai lầm trong micro-product có khả năng ảnh hưởng.
Và khi người không phải lập trình viên bắt đầu có khả năng tạo ứng dụng thông qua AI, những ranh giới đó càng trở nên quan trọng.
Bởi vì AI có thể giúp họ viết một đoạn code rất nhanh.
Nhưng không có lý do gì để một đoạn code vừa được tạo ra tự động sở hữu quyền thay đổi toàn bộ hoạt động kinh doanh.
Một nguyên tắc khá đơn giản.
Đáng tiếc, phải được thực thi bằng kiến trúc.
Không phải bằng lời nhắc:
"Nhớ cẩn thận nha em."
09. Từ Prototype đến Production là một bước chuyển trách nhiệm.
Một prototype có thể được đánh giá bằng khả năng chứng minh một ý tưởng.
Nó có hoạt động không?
Người dùng có hiểu không?
Có giải quyết đúng vấn đề không?
Và giả thuyết ban đầu có đáng tiếp tục nghiên cứu không?
Nhưng khi một công cụ được đưa vào hoạt động chính thức, tiêu chuẩn thay đổi.
Nó phải đủ đáng tin cậy trong phạm vi sử dụng dự kiến.
Dữ liệu phải được bảo vệ phù hợp.
Quyền hạn phải rõ ràng.
Những tình huống thất bại phải có cách xử lý.
Và phải có người chịu trách nhiệm khi người sử dụng gặp vấn đề.
Đây là sự khác biệt giữa building something that works và operating something people depend on.
Một ứng dụng được tạo ra trong vài giờ có thể rất ấn tượng.
Nhưng điều đó không có nghĩa nó đã sẵn sàng để hàng trăm khách hàng sử dụng.
Một người có thể viết được một công cụ tốt.
Nhưng chưa chắc có khả năng duy trì nó khi nhu cầu thay đổi.
Và một micro-product có thể tạo ra giá trị trong thử nghiệm nhưng trở nên không hiệu quả khi chi phí vận hành tăng lên.
Tôi muốn quá trình đưa sản phẩm vào sử dụng phản ánh mức độ rủi ro.
Một công cụ nội bộ chỉ đọc dữ liệu không nhạy cảm và không tạo tác động có thể cần quy trình tương đối đơn giản.
Một ứng dụng truy cập thông tin khách hàng cần được đánh giá nghiêm ngặt hơn.
Một công cụ có khả năng tạo giao dịch hoặc thay đổi trạng thái quan trọng cần mức kiểm soát tương ứng.
Không nhất thiết mọi thay đổi đều phải đi qua CEO.
Không nhất thiết mọi ứng dụng đều cần cùng một bộ kiểm thử.
Nhưng phải có tiêu chí để phân biệt.
Review should be proportional to risk, not proportional to organizational hierarchy.
Tôi không muốn một nhân viên phải chờ ba tuần để đưa một công cụ tính toán đơn giản vào sử dụng chỉ vì người phê duyệt đang bận.
Nhưng cũng không muốn một ứng dụng mới được kết nối trực tiếp với dữ liệu khách hàng chỉ vì tác giả đã demo thành công.
Tôi muốn hệ thống có một con đường rõ ràng.
Thử nghiệm.
Kiểm chứng nghiệp vụ.
Đánh giá những rủi ro phù hợp.
Triển khai trong phạm vi giới hạn nếu cần.
Theo dõi kết quả.
Và mở rộng khi có đủ bằng chứng.
Nhưng cũng phải có đường quay lại.
Nếu một ứng dụng tạo ra tác dụng phụ, có thể vô hiệu hóa hoặc khôi phục những phần bị ảnh hưởng không?
Nếu tác giả không còn làm việc tại doanh nghiệp, ai tiếp tục chịu trách nhiệm?
Nếu capability bên dưới thay đổi, ai biết những ứng dụng nào đang phụ thuộc vào nó?
Đây không phải những câu hỏi hấp dẫn như việc xây dựng sản phẩm mới.
Nhưng chúng là sự khác biệt giữa một sân chơi thử nghiệm và một nền tảng có thể vận hành lâu dài.
10. Người xây dựng phải sở hữu kết quả, không chỉ sở hữu ý tưởng.
Tôi không thích một mô hình trong đó nhân viên được khuyến khích đề xuất thật nhiều ý tưởng, rồi những người khác phải chịu trách nhiệm biến chúng thành kết quả.
Một ý tưởng tốt có giá trị.
Nhưng một ý tưởng được kiểm chứng và triển khai thành công có giá trị lớn hơn nhiều.
Tôi muốn những người xây dựng học cách đi qua toàn bộ vòng đời của một micro-product.
Không nhất thiết tự làm mọi công việc kỹ thuật.
Nhưng phải hiểu đủ để chịu trách nhiệm về mục đích và kết quả.
Người sử dụng là ai?
Vấn đề được giải quyết là gì?
Tại sao phương pháp hiện tại chưa đủ tốt?
Giải pháp mới dự kiến tạo ra giá trị thế nào?
Chi phí phát triển và duy trì có hợp lý không?
Khi nào chúng ta xem thử nghiệm là thành công?
Và khi nào nên dừng lại?
Tôi không muốn nhân viên chỉ trình bày một giao diện đẹp.
Tôi muốn họ hiểu điều gì khiến giao diện đó đáng tồn tại.
Một công cụ có thể được hàng nghìn người truy cập.
Nhưng nếu không giúp họ giải quyết được vấn đề, số lượt truy cập chưa chắc có giá trị.
Một bài viết có thể thu hút nhiều sự chú ý.
Nhưng chưa chắc tạo ra hiểu biết chính xác hoặc quan hệ khách hàng có ý nghĩa.
Một micro-product có thể tiết kiệm vài phút thao tác.
Nhưng nếu chi phí bảo trì quá cao, tổng giá trị có thể không tương xứng.
Và một công cụ tư vấn có thể khiến tỷ lệ chốt đơn tăng, nhưng nếu nó tạo ra nhiều giao dịch sai hoặc kém hiệu quả, kết quả chưa chắc tích cực.
Tôi muốn đo lường những điều có ý nghĩa.
Chất lượng giải pháp.
Mức độ sử dụng thực tế.
Khả năng tái sử dụng.
Hiệu quả kinh tế.
Tỷ lệ sai sót.
Và những năng lực mới mà tổ chức đã hình thành.
Nhưng cũng cần cẩn thận với chính những chỉ số đó.
Nếu biến số lượng micro-product thành KPI, nhân viên sẽ có động cơ tạo ra nhiều micro-product.
Nếu biến số lượt xem thành mục tiêu chính, họ sẽ tối ưu lượt xem.
Nếu thưởng chỉ dựa trên số lượng tính năng, chúng ta sẽ sớm sở hữu một bộ sưu tập tính năng rất phong phú.
Tôi không muốn tổ chức trở thành một cuộc thi sản xuất phần mềm.
Builder ownership is not about claiming credit for an idea. It is about accepting responsibility for the value that idea creates.
Một người xây dựng thực sự phải có khả năng nhìn vào sản phẩm của mình và trả lời:
Nó có làm thế giới thực tốt hơn không?
Nếu có, bằng chứng là gì?
Nếu chưa, chúng ta cần thay đổi điều gì?
Và nếu không đáng tiếp tục, có đủ can đảm để dừng lại không?
Tôi nghĩ đó là những câu hỏi giúp một nhân viên bắt đầu phát triển tư duy sản phẩm.
Không phải việc biết sử dụng một công cụ AI để tạo code.
11. Một tổ chức cần quyền được thất bại trong phạm vi có kiểm soát.
Nếu muốn nhiều người có khả năng thử nghiệm ý tưởng, chúng ta phải chấp nhận rằng phần lớn ý tưởng chưa chắc tạo ra kết quả như kỳ vọng.
Một số giải quyết những vấn đề không đủ quan trọng.
Một số đánh giá sai nhu cầu.
Một số có cách triển khai không phù hợp.
Một số tạo ra giá trị nhưng chi phí vận hành quá cao.
Và một số đơn giản là được xây dựng quá sớm.
Tôi không muốn xem mọi thử nghiệm không thành công là thất bại của nhân viên.
Nhưng tôi cũng không muốn sử dụng khẩu hiệu "thất bại là mẹ thành công" để biện minh cho việc tiêu tốn nguồn lực thiếu kỷ luật.
Điều quan trọng là phân biệt controlled experimentation với unaccountable execution.
Một thử nghiệm có mục tiêu rõ ràng.
Phạm vi rủi ro giới hạn.
Chi phí được chấp thuận.
Giả thuyết có thể kiểm chứng.
Và cơ chế đánh giá kết quả.
Nếu giả thuyết sai, tổ chức có thể học được điều có giá trị.
Nhưng một dự án tiêu tốn nguồn lực liên tục mà không có khả năng giải thích giá trị, không có giới hạn và không có người chịu trách nhiệm thì không thể được xem là đổi mới chỉ vì tác giả của nó rất nhiệt tình.
Tôi thích những thử nghiệm nhỏ, có khả năng đảo ngược và có thời gian học hỏi ngắn.
Không phải vì mọi ý tưởng lớn đều nên được chia nhỏ một cách máy móc.
Mà vì chúng giúp chúng ta kiểm chứng những giả định quan trọng trước khi cam kết quá nhiều nguồn lực.
Một công cụ tư vấn có thể bắt đầu với một nhóm khách hàng nhỏ.
Một phương pháp chăm sóc có thể được thử nghiệm trong một phân khúc.
Một bộ sản phẩm mới có thể được kiểm chứng bằng nhu cầu thực tế trước khi xây dựng quá nhiều chức năng hỗ trợ.
Nếu kết quả tốt, chúng ta mở rộng.
Nếu không, chúng ta điều chỉnh hoặc dừng.
The freedom to build must include the freedom to stop building.
Tôi nghĩ đây là một nguyên lý rất quan trọng.
Một tổ chức không thể tiến hóa tốt nếu mọi sản phẩm đã được tạo ra đều phải tiếp tục tồn tại.
Đôi khi, kết quả giá trị nhất của một thử nghiệm là biết rằng ý tưởng đó không đáng đầu tư thêm.
Và nếu nhân viên có thể thừa nhận điều đó mà không phải tìm cách làm đẹp kết quả, chúng ta đã xây dựng được một phần văn hóa học hỏi đáng giá.
Tất nhiên, phải phân biệt giả thuyết không thành công với việc vi phạm những ràng buộc đã được thống nhất.
Một thử nghiệm thất bại trong phạm vi được phép là một chuyện.
Tự ý sử dụng dữ liệu không được cấp quyền hoặc tạo ra rủi ro vượt giới hạn là chuyện khác.
Tôi muốn tự do thử nghiệm.
Không muốn miễn trách nhiệm cho những hành vi tùy tiện.
12. Sáng tạo phân tán không có nghĩa chiến lược phân tán vô hạn.
Hãy tưởng tượng mỗi nhóm kinh doanh được quyền phát triển micro-product.
Một nhóm tạo công cụ cho quán cà phê.
Một nhóm phát triển giải pháp cho tiệm bánh.
Một nhóm xây dựng hệ thống tư vấn in ấn.
Một nhóm phát triển công cụ hỗ trợ khách hàng doanh nghiệp.
Mọi thứ có vẻ rất tốt.
Nhưng rồi những câu hỏi khó xuất hiện.
Nếu hai nhóm cùng phục vụ một nhóm khách hàng, ai chịu trách nhiệm về quan hệ khách hàng?
Nếu một micro-product tạo ra lead cho một nhóm khác, kết quả được ghi nhận thế nào?
Nếu một nhân viên phát triển công cụ sử dụng dữ liệu chung, ai sở hữu sản phẩm?
Nếu một nhóm muốn đưa ra chính sách thương mại khác với hệ thống hiện tại, quyền quyết định thuộc về ai?
Và nếu hai micro-product cạnh tranh trực tiếp trong cùng một lĩnh vực, doanh nghiệp có nên cho cả hai tiếp tục tồn tại?
Đây không còn chỉ là vấn đề phần mềm.
Nó là vấn đề thiết kế tổ chức.
Tôi không cho rằng sự phân tán sáng tạo phải đồng nghĩa với việc mọi nhóm đều sở hữu chiến lược kinh doanh độc lập.
Một tổ chức vẫn cần những nguyên tắc chung.
Định hướng thị trường.
Những giới hạn kinh tế.
Quyền sở hữu dữ liệu.
Trách nhiệm đối với khách hàng.
Và những ràng buộc quan trọng của thương hiệu và hoạt động kinh doanh.
Nhưng trong những phạm vi đó, các nhóm có thể thử nghiệm cách tạo ra giá trị khác nhau.
Tôi thích nguyên lý:
Decentralize discovery. Centralize the constraints that protect the whole.
Phân tán khả năng khám phá.
Tập trung những ràng buộc cần thiết để bảo vệ toàn tổ chức.
Một nhóm có thể tự tìm hiểu phân khúc khách hàng mới.
Nhưng không tự ý chiếm quyền sở hữu khách hàng của nhóm khác ngoài cơ chế đã được định nghĩa.
Một nhóm có thể tạo công cụ tư vấn riêng.
Nhưng không phát minh một nguồn dữ liệu giá mới không được kiểm soát.
Một nhân viên có thể xây dựng chuyên môn cá nhân.
Nhưng những tuyên bố về năng lực đã được xác minh phải dựa trên bằng chứng.
Một người có thể phát triển micro-product.
Nhưng việc sản phẩm được tích hợp vào hạ tầng chung phải có trách nhiệm và thẩm quyền rõ ràng.
Những giới hạn này không tồn tại để khiến con người bớt sáng tạo.
Chúng tồn tại để những sáng tạo độc lập không tự triệt tiêu giá trị của nhau.
Bởi vì một tổ chức có thể rất sáng tạo ở cấp cá nhân.
Nhưng hoàn toàn hỗn loạn ở cấp toàn hệ thống.
Và nếu mỗi người đều tối ưu lợi ích của micro-product do mình tạo ra, không có gì bảo đảm lợi ích của doanh nghiệp cũng được tối ưu.
Chúng ta đã gặp vấn đề này trong KPI.
Không có lý do gì nó không xuất hiện trong đổi mới.
13. Quyền xây dựng phải đi cùng quyền được ghi nhận.
Tôi nghĩ một tổ chức muốn nhân viên tự phát triển năng lực phải giải quyết một vấn đề khá nhạy cảm.
Ai được ghi nhận khi một ý tưởng tạo ra giá trị?
Một nhân viên nhận diện vấn đề.
Họ xây dựng prototype.
Bộ phận kỹ thuật hỗ trợ triển khai.
Người quản lý giúp kiểm chứng nghiệp vụ.
Một nhóm khác bắt đầu sử dụng.
Và cuối cùng công cụ trở thành một năng lực chung.
Vậy thành tựu thuộc về ai?
Câu trả lời không nên chỉ là một người.
Nhưng cũng không nên là một câu chung chung:
"Đây là thành quả của tập thể."
Tôi không phản đối tinh thần tập thể.
Tôi chỉ nghĩ chúng ta nên biết cách ghi nhận những đóng góp cụ thể.
Người phát hiện nhu cầu có đóng góp khác với người thiết kế kiến trúc.
Người xây dựng sản phẩm có đóng góp khác với người vận hành.
Và người đưa một ý tưởng từ thử nghiệm thành một năng lực ổn định có thể tạo ra giá trị khác với người đề xuất ban đầu.
Tôi muốn những đóng góp ấy được thể hiện một cách hợp lý.
Không phải để mọi người tranh nhau quyền sở hữu.
Mà để tổ chức nhìn thấy ai đang tạo ra loại giá trị nào.
Một nhân viên phát triển một công cụ thành công có thể được ghi nhận thành tựu đó trong hồ sơ chuyên môn.
Một người đã viết những tài liệu hoặc nghiên cứu có giá trị có thể tiếp tục được công nhận là tác giả.
Một người có khả năng dẫn dắt dự án có thể được xem xét trao thêm trách nhiệm.
Và những người đã đóng góp vào một năng lực chung có thể được đánh giá dựa trên vai trò thực tế của họ.
Nhưng phải có ranh giới rõ giữa personal recognition và organizational ownership.
Một nhân viên có thể được ghi nhận là người sáng tạo ra một giải pháp.
Điều đó không tự động có nghĩa họ sở hữu quyền truy cập toàn bộ dữ liệu hoặc quyền điều hành vĩnh viễn một phần hạ tầng của doanh nghiệp.
Ngược lại, doanh nghiệp có thể sở hữu và tiếp tục duy trì những tài sản được tạo ra trong phạm vi công việc theo thỏa thuận phù hợp, nhưng không nên xóa bỏ lịch sử đóng góp của người đã tạo ra chúng.
Tôi muốn những nguyên tắc ấy được xác định minh bạch từ đầu.
Không phải đến khi một người nghỉ việc mới bắt đầu tranh luận về quyền sở hữu dữ liệu, sản phẩm và thành tựu.
Recognition should follow contribution. Operational ownership must follow responsibility.
Ghi nhận phải phản ánh đóng góp.
Quyền sở hữu vận hành phải gắn với trách nhiệm.
Nếu làm tốt, một nhân viên có thể tự hào rằng họ đã tạo ra một năng lực được cả tổ chức sử dụng.
Ngay cả khi sau này họ chuyển sang công việc khác.
Hoặc rời khỏi doanh nghiệp.
Đối với tôi, đó mới là một dạng thành tựu nghề nghiệp có ý nghĩa.
Không phải chỉ vì công ty đã sử dụng sản phẩm của họ.
Mà vì họ đã giúp một tổ chức trở nên có năng lực hơn.
14. Đừng biến Freedom to Build thành một KPI mới.
Có một cách rất nhanh để phá hỏng một sân chơi sáng tạo.
Biến nó thành nghĩa vụ.
Mỗi nhân viên phải tạo hai micro-product mỗi quý.
Mỗi nhóm phải đề xuất năm ý tưởng.
Mỗi người phải xuất bản ba công cụ.
Mỗi tháng phải có một sản phẩm mới được triển khai.
Và tất cả những thứ đó được đưa vào bảng xếp hạng.
Tôi có thể tưởng tượng kết quả.
Sau vài tháng, doanh nghiệp sẽ sở hữu một số lượng rất lớn công cụ.
Phần lớn trông tương đối giống nhau.
Nhiều công cụ giải quyết những vấn đề không thực sự tồn tại.
Một số được tạo ra chỉ để hoàn thành chỉ tiêu.
Và những người không có hứng thú xây dựng vẫn phải cố gắng tạo ra thứ gì đó để chứng minh tinh thần đổi mới.
Một chiến thắng tuyệt vời về số lượng.
Không chắc về giá trị.
Tôi không muốn điều đó.
Freedom to Build trước hết phải là một khả năng được mở ra, không phải một nghĩa vụ được áp đặt lên tất cả.
Một người có thể rất giỏi bán hàng nhưng không thích xây dựng phần mềm.
Không sao.
Một người có thể tạo ra những nội dung chuyên môn rất tốt nhưng không muốn phát triển ứng dụng.
Cũng không sao.
Một nhân viên khác có thể cực kỳ hào hứng khi được thử nghiệm những công cụ nhỏ.
Tuyệt vời.
Và một số người có thể dần phát triển khả năng kết hợp kiến thức nghiệp vụ, tư duy sản phẩm và công nghệ.
Đó là nhóm tôi đặc biệt muốn quan sát.
Không phải vì họ có giá trị hơn tất cả những người khác.
Mà vì họ đại diện cho một loại năng lực mà doanh nghiệp có thể chưa sở hữu đầy đủ.
Tôi không muốn ép một nhân viên giỏi chăm sóc khách hàng phải trở thành lập trình viên.
Nhưng tôi muốn nếu một ngày người đó nhận thấy một cơ hội và muốn xây dựng giải pháp, họ không bị chặn lại chỉ vì không có chức danh Developer.
Opportunity should be available. Participation should be voluntary. Contribution should be measurable.
Cơ hội phải được mở ra.
Sự tham gia nên xuất phát từ năng lực và động lực phù hợp.
Và đóng góp phải được đánh giá bằng giá trị thực tế.
Không phải số lượng sản phẩm được tạo ra.
Nếu không, chúng ta sẽ vô tình biến một môi trường phát triển năng lực thành một nhà máy sản xuất thành tích.
Có dashboard realtime.
Có leaderboard.
Và có giải thưởng cho người tạo nhiều ứng dụng không ai sử dụng nhất.
Khá hoành tráng.
Đặc biệt nếu mục tiêu là làm cho bộ phận IT mất ngủ.
15. Một micro-product thành công không nên trở thành con tin của tác giả.
Đây là vấn đề mà tôi nghĩ tổ chức phải tính đến ngay từ đầu.
Một nhân viên tạo ra một công cụ rất hữu ích.
Nhiều người bắt đầu sử dụng.
Sau một thời gian, công cụ trở thành một phần quan trọng trong quy trình kinh doanh.
Mọi thứ rất tốt.
Cho đến khi nhân viên đó chuyển công việc.
Nghỉ phép dài ngày.
Hoặc rời khỏi doanh nghiệp.
Ai sẽ tiếp tục duy trì sản phẩm?
Ai hiểu những ràng buộc nghiệp vụ?
Ai có quyền thay đổi?
Ai xử lý sự cố?
Và nếu một phiên bản mới của hệ thống lõi khiến công cụ không còn hoạt động, ai chịu trách nhiệm?
Nếu không trả lời được, chúng ta vừa tạo ra một điểm phụ thuộc mới.
Trước đây, một quy trình phụ thuộc vào người có kinh nghiệm.
Bây giờ, một ứng dụng phụ thuộc vào người tạo ra nó.
Không chắc đã tiến bộ nhiều.
Vì vậy, tôi muốn phân biệt Creator với Maintainer và Business Owner.
Một người có thể là tác giả ban đầu.
Một người khác chịu trách nhiệm bảo trì kỹ thuật.
Và một người hoặc bộ phận chịu trách nhiệm về giá trị kinh doanh mà sản phẩm tạo ra.
Trong những micro-product nhỏ, cả ba vai trò có thể thuộc về một người.
Không có vấn đề gì.
Nhưng khi sản phẩm trở nên quan trọng, tổ chức phải có khả năng tách các trách nhiệm đó nếu cần.
Một sản phẩm được đưa vào sử dụng chính thức cần có đủ thông tin để người phù hợp có thể tiếp quản.
Mục đích của nó.
Những capability đang sử dụng.
Những dữ liệu quan trọng.
Những giả định nghiệp vụ.
Các giới hạn.
Và cơ chế xử lý khi không còn hoạt động như dự kiến.
Tôi không muốn tài liệu trở thành một gánh nặng hành chính làm chết mọi ý tưởng nhỏ.
Mức độ tài liệu phải tương xứng với mức độ phụ thuộc và rủi ro.
Một prototype không cần quy trình bàn giao như một hệ thống tài chính quan trọng.
Nhưng khi sản phẩm trở thành một phần năng lực chung, khả năng duy trì không thể tiếp tục hoàn toàn dựa trên trí nhớ của tác giả.
The creator may leave. The capability should not disappear with them.
Đây là một nguyên tắc khá quan trọng.
Nó cũng tạo ra một điều tích cực cho chính người xây dựng.
Họ không phải dành cả đời để bảo trì những thứ mình đã tạo ra.
Khi sản phẩm trưởng thành, nó có thể được chuyển giao.
Và họ tiếp tục phát triển những ý tưởng mới.
Nếu không có khả năng chuyển giao, người giỏi nhất có thể lại trở thành người phải chăm sóc nhiều công cụ cũ nhất.
Một phiên bản mới của cái bẫy mà chúng ta đã bàn ở những chương trước.
Chỉ khác là lần này, người đó tự xây nhà tù cho mình.
Bằng code.
16. Nền tảng chung phải được đối xử như một sản phẩm.
Nếu muốn nhiều người có khả năng xây dựng micro-product, tổ chức cần một hạ tầng chung đủ dễ sử dụng.
Nhưng tôi không cho rằng chỉ cần cung cấp database, API và một tài liệu kỹ thuật là xong.
Đối với những người không phải Software Engineer, những khái niệm đó vẫn có thể quá phức tạp.
Một nền tảng tốt phải hiểu người sử dụng của nó.
Những người đó cần tạo ra loại sản phẩm nào?
Họ cần truy cập những năng lực gì?
Những thao tác nào có thể được đơn giản hóa?
Những giới hạn nào phải được bảo vệ tự động?
Và những tình huống nào cần sự hỗ trợ từ bộ phận kỹ thuật?
Tôi muốn Internal Developer Platform được nhìn nhận như một sản phẩm nội bộ.
Có người sử dụng.
Có trải nghiệm.
Có những tiêu chuẩn về độ tin cậy.
Có những capability được quản lý vòng đời.
Và có người chịu trách nhiệm cải thiện nền tảng dựa trên nhu cầu thực tế.
Một API có thể rất tốt về mặt kỹ thuật.
Nhưng nếu mỗi người sử dụng đều cần một Software Architect ngồi bên cạnh để giải thích, mức độ tự chủ mà nó tạo ra vẫn còn giới hạn.
Một môi trường thử nghiệm có thể được cách ly rất an toàn.
Nhưng nếu việc tạo môi trường mới cần nhiều ngày và hàng loạt bước thủ công, chi phí thử nghiệm vẫn cao.
Một quy trình phê duyệt có thể rất chặt chẽ.
Nhưng nếu những thay đổi rủi ro thấp cũng bị xử lý như thay đổi hệ thống cốt lõi, tổ chức sẽ tiếp tục tạo ra nút thắt.
Tôi muốn nền tảng liên tục cải thiện những điểm đó.
Không phải bằng cách bỏ kiểm soát.
Mà bằng cách biến những kiểm soát đã hiểu rõ thành các cơ chế có thể sử dụng thuận tiện.
The platform team's job is not to build every product. It is to make safe product building progressively easier for others.
Vai trò của nhóm nền tảng không phải xây mọi sản phẩm.
Mà là khiến việc xây dựng sản phẩm an toàn trở nên ngày càng dễ dàng hơn cho những người khác.
Đây là một sự thay đổi về tư duy.
Bộ phận kỹ thuật không còn chỉ là nơi nhận yêu cầu.
Nó trở thành nơi cung cấp năng lực.
Tạo hạ tầng.
Bảo vệ những ràng buộc quan trọng.
Hỗ trợ các nhóm xây dựng.
Và phát triển những thành phần chung có thể được tái sử dụng.
Nhưng cũng phải cẩn thận.
Nếu mọi yêu cầu hỗ trợ từ những builder mới đều tiếp tục phải đi qua một vài kỹ sư trung tâm, chúng ta có thể chỉ chuyển nút thắt từ phát triển ứng dụng sang hỗ trợ nền tảng.
Vì vậy, chất lượng nền tảng phải được đánh giá bằng mức độ độc lập mà người sử dụng thực sự đạt được.
Không chỉ số lượng API được cung cấp.
Một nền tảng tốt không phải nền tảng có nhiều chức năng nhất.
Mà là nền tảng khiến một nhóm người có thể tự tạo ra những năng lực có giá trị với mức hỗ trợ, chi phí và rủi ro hợp lý.
17. Những người xây dựng có thể trở thành lớp lãnh đạo mới.
Đây là điều khiến tôi hứng thú nhất.
Một người bắt đầu bằng công việc bán hàng.
Họ hiểu một nhóm khách hàng.
Nhận ra một vấn đề.
Đề xuất giải pháp.
Tự thử nghiệm một công cụ nhỏ.
Quan sát kết quả.
Điều chỉnh.
Và cuối cùng tạo ra một micro-product có giá trị.
Quá trình đó đòi hỏi nhiều hơn kỹ năng sử dụng AI.
Người đó phải học cách xác định nhu cầu.
Phân tích nguyên nhân.
Lựa chọn phạm vi.
Đánh giá chi phí.
Kiểm chứng giả thuyết.
Phối hợp với người khác.
Và chịu trách nhiệm về kết quả.
Đó là những năng lực rất gần với Product Development và Business Ownership.
Không phải ai xây được ứng dụng cũng có khả năng lãnh đạo.
Nhưng quá trình xây dựng một sản phẩm có giá trị có thể làm bộc lộ những năng lực mà công việc thường ngày chưa từng cho phép người đó thể hiện.
Một nhân viên có thể rất bình thường khi được đánh giá bằng số lượng đơn hàng.
Nhưng lại có khả năng đặc biệt trong việc nhận diện nhu cầu chưa được phục vụ.
Một người không nổi bật ở vai trò quản lý nhóm có thể rất giỏi xây dựng giải pháp chuyên môn.
Một nhân viên khác có thể không viết được phần mềm tốt nhưng có năng lực tổ chức người khác để đưa một ý tưởng thành sản phẩm.
Đó là những tín hiệu đáng quan tâm.
Tôi muốn tổ chức có khả năng nhìn thấy chúng.
Không phải thông qua những lời tự nhận.
Mà thông qua quá trình thực hiện công việc.
Một người đã giải quyết vấn đề gì?
Đã tạo ra năng lực nào?
Đã đưa ra những giả thuyết nào?
Kết quả ra sao?
Khi thất bại, họ có khả năng phân tích và điều chỉnh không?
Khi sản phẩm thành công, họ có biết cách duy trì và phát triển nó không?
Và khi quy mô tăng lên, họ có đủ khả năng phối hợp nguồn lực và chịu trách nhiệm về kết quả kinh tế không?
Những câu hỏi ấy có thể giúp chúng ta nhận diện những người có tiềm năng đảm nhiệm trách nhiệm lớn hơn.
Không nhất thiết phải là chức danh quản lý truyền thống.
Một chuyên gia có thể tiếp tục phát triển chuyên môn.
Một người xây dựng sản phẩm có thể trở thành Domain Product Owner.
Một người có năng lực phối hợp và chịu trách nhiệm về hiệu quả kinh doanh có thể dần điều hành một business unit.
Builders are not automatically leaders. But building reveals capabilities that job titles often hide.
Tôi thích điều này.
Bởi vì trong nhiều tổ chức, cơ hội phát triển phụ thuộc khá nhiều vào việc ai được người lãnh đạo chú ý.
Ai có cơ hội trình bày.
Ai được giao một nhiệm vụ quan trọng.
Ai được xem là có tiềm năng.
Tôi muốn bổ sung một cơ chế khác.
Cho con người một không gian để tự thể hiện năng lực thông qua những thứ họ tạo ra.
Nếu một người có khả năng xây dựng, kết quả có thể trở thành bằng chứng.
Nếu một người có khả năng tổ chức, quá trình triển khai sẽ cho thấy điều đó.
Và nếu một người chỉ giỏi trình bày ý tưởng nhưng không có khả năng biến nó thành giá trị, thực tế cũng sẽ dần làm rõ.
Một môi trường như vậy có thể trở thành một hệ thống phát hiện và phát triển nhân tài rất thú vị.
Không phải qua những bài kiểm tra tính cách.
Mà qua những vấn đề thật.
Những quyết định thật.
Và những kết quả thật.
18. Founder không thể tiếp tục là bộ biên dịch cho mọi ý tưởng.
Có một giới hạn mà tôi nghĩ những người sáng lập có nền tảng kỹ thuật mạnh rất dễ gặp.
Ban đầu, họ là người hiểu kinh doanh.
Đồng thời hiểu công nghệ.
Họ có thể nghe nhân viên mô tả một vấn đề, nhanh chóng nhận diện cấu trúc rồi trực tiếp xây dựng giải pháp.
Một lợi thế rất lớn.
Không cần quá nhiều bước trung gian.
Không cần mất nhiều thời gian dịch yêu cầu nghiệp vụ thành thiết kế kỹ thuật.
Không cần giải thích lại toàn bộ bối cảnh cho những người khác.
Founder có thể giải quyết vấn đề từ đầu đến cuối.
Nhưng khi doanh nghiệp phát triển, số lượng vấn đề và ý tưởng tăng lên.
Mỗi nhân viên có một nhóm khách hàng.
Mỗi bộ phận có một loại nhu cầu.
Mỗi lĩnh vực có những cơ hội riêng.
Và mọi người bắt đầu đề xuất ngày càng nhiều cải tiến.
Nếu tất cả đều phải đi qua founder, chúng ta có một vấn đề.
Founder trở thành Universal Translator.
Người phiên dịch mọi nhu cầu kinh doanh thành cấu trúc kỹ thuật.
Một nhân viên có ý tưởng.
Đưa lên founder.
Founder phân tích.
Founder thiết kế.
Founder quyết định có đáng xây dựng hay không.
Và đôi khi founder trực tiếp triển khai.
Kết quả rất tốt khi số lượng ý tưởng còn nhỏ.
Nhưng mô hình ấy không thể mở rộng vô hạn.
Tôi không thể có mặt trong tất cả những cuộc trò chuyện với khách hàng.
Không thể hiểu sâu từng phân khúc hơn những người trực tiếp làm việc với phân khúc đó.
Không thể đánh giá mọi ý tưởng.
Và chắc chắn không thể tiếp tục là người phải thiết kế tất cả micro-product.
Nếu tôi cố gắng làm như vậy, tốc độ phát triển của tổ chức sẽ bị giới hạn bởi khả năng xử lý của chính mình.
Ngay cả khi khả năng ấy rất cao.
Đây là lúc phải thay đổi câu hỏi.
Không phải:
"Làm sao để tôi tiếp tục xây dựng nhanh hơn?"
Mà là:
"Làm sao để nhiều người khác có thể tự chuyển những hiểu biết của mình thành năng lực mới mà không cần tôi trực tiếp tham gia vào mọi bước?"
Tôi muốn cung cấp nền tảng.
Những công cụ.
Những capability.
Những ràng buộc.
Những cơ chế kiểm chứng.
Và những con đường để ý tưởng được thử nghiệm và trưởng thành.
Sau đó, để những người hiểu vấn đề tự bắt đầu quá trình xây dựng.
Điều đó không có nghĩa founder không còn vai trò.
Người sáng lập vẫn phải quyết định những nguyên tắc chiến lược.
Những ràng buộc quan trọng.
Cách phân bổ nguồn lực lớn.
Và những năng lực nền tảng mà tổ chức cần đầu tư.
Nhưng không nên phải quyết định từng giao diện, từng chức năng và từng ý tưởng nhỏ.
The founder should architect the conditions for innovation, not personally implement every innovation.
Tôi nghĩ đây là một bước chuyển rất khó.
Bởi vì đối với người giỏi thiết kế và phát triển phần mềm, tự mình xây dựng thường nhanh hơn việc giải thích cho người khác.
Ít nhất trong ngắn hạn.
Một ý tưởng xuất hiện.
Tôi có thể hiểu.
Có thể thiết kế.
Có thể viết.
Có thể triển khai.
Và có thể cảm thấy rất hài lòng vì vấn đề đã được giải quyết nhanh chóng.
Nhưng nếu lần nào tôi cũng lựa chọn con đường đó, tổ chức sẽ tiếp tục học được một điều.
Khi có vấn đề khó, hãy đưa cho founder.
Một bài học cực kỳ hiệu quả.
Và cực kỳ nguy hiểm cho khả năng mở rộng.
19. Khi khả năng xây dựng được phân tán, quyền lực của founder phải thay đổi hình dạng.
Tôi nghĩ đây là một khía cạnh đáng để suy ngẫm.
Một người sáng lập có thể kiểm soát tổ chức bằng cách giữ quyền quyết định những điều quan trọng.
Nhưng nếu mọi thay đổi phải được người đó trực tiếp phê duyệt, khả năng phát triển của tổ chức bị giới hạn.
Freedom to Build tạo ra một thách thức mới đối với cách phân phối quyền lực.
Nhân viên không còn chỉ làm theo những gì đã được thiết kế.
Họ có thể đề xuất và tạo ra những cách làm mới.
Điều đó có nghĩa họ có khả năng ảnh hưởng đến tương lai của hệ thống.
Và nếu người sáng lập không chấp nhận điều này, Freedom to Build sẽ nhanh chóng trở thành một khẩu hiệu.
Nhân viên được phép thử nghiệm.
Nhưng mọi quyết định quan trọng vẫn phải chờ CEO.
Được phép xây dựng.
Nhưng chỉ được triển khai những gì CEO đã nghĩ đến.
Được khuyến khích sáng tạo.
Nhưng nếu ý tưởng khác với mô hình trong đầu người sáng lập, nó khó có cơ hội tồn tại.
Tôi không muốn một hệ thống như vậy.
Nhưng tôi cũng không tin việc trao quyền xây dựng đồng nghĩa với quyền thay đổi toàn bộ chiến lược doanh nghiệp.
Sự phân quyền phải được thiết kế.
Những nguyên tắc nào không được phá vỡ?
Những phạm vi nào nhóm có thể tự thử nghiệm?
Những loại thay đổi nào cần kiểm chứng tập trung?
Những quyết định nào chỉ cần thông báo?
Và những quyết định nào thực sự cần sự tham gia của người lãnh đạo cao nhất?
Nếu xác định được những ranh giới đó, quyền lực không biến mất.
Nó được chuyển hóa thành cơ chế.
Người lãnh đạo không còn phải trực tiếp đánh giá mọi hành động.
Nhưng vẫn duy trì trách nhiệm đối với kiến trúc chung.
Tôi thích nghĩ rằng người sáng lập nên dành ngày càng nhiều thời gian để trả lời những câu hỏi ở cấp độ cao hơn.
Chúng ta cần những capability nào để các nhóm có thể phát triển độc lập?
Những rủi ro nào phải được kiểm soát tại hạ tầng?
Những loại năng lực nào có thể được phân quyền?
Và làm sao để tổ chức học hỏi từ hàng trăm thử nghiệm mà không cần một người đọc lại toàn bộ từng thử nghiệm?
Đó là một vai trò khác.
Ít trực tiếp hơn.
Nhưng có thể tạo ra đòn bẩy lớn hơn.
The architect does not need to design every room. He needs to design a structure in which good rooms can be built.
Tôi nghĩ đây là một phép ẩn dụ phù hợp.
Một tòa nhà cần kết cấu chịu lực.
Những giới hạn an toàn.
Hệ thống điện.
Cấp thoát nước.
Và những tiêu chuẩn không thể tùy tiện phá vỡ.
Nhưng bên trong những giới hạn đó, không phải tất cả các căn phòng đều phải có cùng một cách bố trí.
Người sử dụng có thể tổ chức không gian theo nhu cầu.
Thay đổi cách sử dụng.
Và tạo ra những môi trường khác nhau trên cùng một hạ tầng đáng tin cậy.
Tôi muốn doanh nghiệp có khả năng tương tự.
Một cấu trúc chung đủ vững.
Và đủ không gian cho những con người khác nhau tạo ra giá trị riêng.
Không phải một công trình mà mọi chi tiết đều phải mang dấu ấn của kiến trúc sư ban đầu.
20. Freedom to Build là một phép thử về mức độ trưởng thành của tổ chức.
Một doanh nghiệp có thể tuyên bố mình khuyến khích đổi mới.
Có thể tổ chức những cuộc thi ý tưởng.
Có thể đầu tư rất nhiều vào AI.
Có thể cung cấp những công cụ phát triển hiện đại.
Nhưng điều đó chưa chứng minh rằng doanh nghiệp thực sự có khả năng phát triển sáng kiến phân tán.
Tôi muốn nhìn vào những kết quả cụ thể hơn.
Một nhân viên có thể tự kiểm chứng một ý tưởng nhỏ mà không phải chờ đợi quá nhiều không?
Một người hiểu sâu lĩnh vực của mình có thể sử dụng những capability chung để tạo công cụ không?
Một micro-product có thể được đưa vào thử nghiệm an toàn mà không tạo ra rủi ro không cần thiết không?
Một sản phẩm có giá trị có thể được chuyển giao và duy trì bởi người khác không?
Những thành tựu cá nhân có được ghi nhận công bằng không?
Và khi một ý tưởng không phù hợp, tổ chức có đủ khả năng dừng nó mà không biến thất bại thành một cuộc tìm kiếm người chịu trách nhiệm mang tính trừng phạt không?
Nếu câu trả lời phần lớn là không, chúng ta có thể đã xây dựng nhiều công cụ.
Nhưng chưa xây dựng được năng lực đổi mới phân tán.
Tôi muốn khả năng xây dựng trở thành một phần của tổ chức.
Không phải một phong trào ngắn hạn.
Không phải một chương trình truyền thông nội bộ.
Và không phải một cuộc thi xem ai dùng AI giỏi hơn.
Tôi muốn những người có năng lực và động lực có thể liên tục nhận diện những nhu cầu mới, tạo giải pháp, kiểm chứng và đóng góp vào năng lực chung.
Một số người sẽ tạo ra công cụ nhỏ.
Một số sẽ phát triển chuyên môn.
Một số sẽ tạo ra sản phẩm có khả năng phục vụ khách hàng.
Và một số có thể đủ năng lực để phát triển thành người sở hữu một lĩnh vực kinh doanh thực sự.
Nếu làm được, doanh nghiệp không còn chỉ phát triển bằng những ý tưởng xuất phát từ người sáng lập.
Nó bắt đầu phát triển bằng năng lực khám phá của nhiều người.
The organization becomes a platform for creating capabilities, not merely a structure for executing instructions.
Đây là điểm mà tôi thấy đặc biệt đáng giá.
Bởi vì một tổ chức chỉ biết thực thi có thể rất hiệu quả.
Nhưng những gì nó có thể làm vẫn bị giới hạn bởi những điều đã được người khác thiết kế.
Một tổ chức có khả năng xây dựng có thể tạo ra những năng lực chưa từng tồn tại.
Và nếu những năng lực đó được kết nối thông qua một kiến trúc chung, giá trị có thể tích lũy theo thời gian.
Một công cụ được tạo ra.
Người khác sử dụng.
Một phương pháp được khám phá.
Nhóm khác học hỏi.
Một chuyên gia phát triển kiến thức.
Kiến thức đó trở thành nguồn lực chung.
Một micro-product thành công.
Nó được mở rộng hoặc tích hợp thành capability mới.
Sau đó, những builder khác tiếp tục sử dụng những năng lực ấy để tạo ra sản phẩm mới.
Đó là một vòng phát triển mà tôi muốn xây dựng.
Không phải chỉ có thêm ứng dụng.
Mà có thêm năng lực.
Và không phải chỉ có thêm năng lực kỹ thuật.
Mà có thêm những con người đủ khả năng nhìn thấy vấn đề, đưa ra giải pháp và chịu trách nhiệm về kết quả.
Lời kết: Freedom to Build.
Tôi không muốn một doanh nghiệp mà mọi ý tưởng đều phải bắt đầu từ CEO.
Tôi không muốn một tổ chức nơi nhân viên chỉ được phép thực hiện những phương pháp đã được thiết kế sẵn.
Và tôi không muốn những người có năng lực phải chờ một chức danh quản lý mới có cơ hội tạo ra giá trị vượt khỏi công việc hiện tại.
Tôi muốn xây dựng một môi trường nơi con người có thể phát triển chuyên môn.
Nhận diện những vấn đề mới.
Đề xuất giải pháp.
Thử nghiệm.
Và khi đủ năng lực, tự xây dựng những công cụ hoặc sản phẩm phục vụ lĩnh vực của mình.
Nhưng tôi không muốn sự tự do ấy trở thành một nguồn hỗn loạn mới.
Một doanh nghiệp vẫn phải bảo vệ dữ liệu.
Bảo vệ những ràng buộc tài chính.
Bảo vệ quyền lợi khách hàng.
Bảo vệ tính nhất quán của những cam kết.
Và bảo đảm những sản phẩm được đưa vào sử dụng chính thức có người chịu trách nhiệm phù hợp.
Tôi nghĩ hai mục tiêu ấy có thể tồn tại cùng nhau.
Nếu kiến trúc được thiết kế tốt.
Một lõi chung đủ vững.
Những capability có quyền hạn rõ ràng.
Những môi trường thử nghiệm được cách ly.
Những cơ chế kiểm chứng phù hợp với rủi ro.
Và những con đường giúp một sản phẩm có giá trị trưởng thành từ một ý tưởng nhỏ thành năng lực chung.
Tôi không cho rằng đây là một bài toán đơn giản.
Nó đòi hỏi kiến trúc phần mềm.
Thiết kế quyền hạn.
Quản trị sản phẩm.
Phát triển con người.
Và khả năng chấp nhận rằng không phải mọi ý tưởng có giá trị đều xuất phát từ người có vị trí cao nhất.
Điều cuối cùng có lẽ khó hơn nhiều so với những phần kỹ thuật.
Bởi vì một founder có thể rất hào hứng khi nhân viên tạo ra sản phẩm.
Cho đến khi nhân viên bắt đầu tạo ra những thứ mà founder chưa nghĩ đến.
Hoặc lựa chọn những phương pháp khác với phương pháp founder vẫn tin là tốt nhất.
Lúc đó, Freedom to Build thực sự được kiểm chứng.
Liệu chúng ta có cho phép những ý tưởng khác biệt được thử nghiệm trong phạm vi an toàn?
Liệu chúng ta có thể đánh giá bằng bằng chứng thay vì bằng mức độ phù hợp với suy nghĩ ban đầu?
Và liệu chúng ta có sẵn sàng để những người khác trở thành người giỏi hơn mình trong những lĩnh vực cụ thể?
Tôi muốn câu trả lời là có.
Không phải vì tôi tin rằng mọi ý tưởng của nhân viên đều đúng.
Mà vì tôi không tin khả năng phát triển của một doanh nghiệp nên bị giới hạn bởi khả năng nhận diện cơ hội của một cá nhân.
Kể cả cá nhân đó là người sáng lập.
Freedom to Build is not the freedom to break the system. It is the freedom to create new value without breaking the foundations that make the system trustworthy.
Tự do xây dựng không phải quyền phá vỡ hệ thống.
Nó là quyền tạo ra giá trị mới mà không phá vỡ những nền tảng khiến hệ thống đáng tin cậy.
Tôi muốn những nhân viên có khả năng phát triển được trao cơ hội thực sự.
Không phải chỉ được yêu cầu sáng tạo trong những cuộc họp.
Không phải chỉ được khuyến khích đóng góp ý tưởng.
Mà được tiếp cận những công cụ, dữ liệu và capability phù hợp để có thể biến hiểu biết của mình thành một giải pháp có khả năng kiểm chứng.
Một nhân viên có thể bắt đầu bằng một công cụ rất nhỏ.
Một công cụ được sử dụng bởi vài người.
Sau đó có thể được nhiều người sử dụng hơn.
Và nếu nó giải quyết một vấn đề có giá trị, tổ chức có thể phát triển nó thành một năng lực chung.
Nhưng ngay cả khi công cụ không thành công, người xây dựng vẫn có thể học được những điều quan trọng.
Cách xác định vấn đề.
Cách kiểm chứng giả thuyết.
Cách quản lý rủi ro.
Cách sử dụng nguồn lực.
Và cách chịu trách nhiệm về kết quả.
Những năng lực đó có thể tiếp tục được sử dụng trong những công việc khác.
Tôi nghĩ đây mới là giá trị dài hạn của Freedom to Build.
Chúng ta không chỉ tạo ra sản phẩm. Chúng ta tạo ra những con người có khả năng tạo ra sản phẩm.
Một sự khác biệt rất lớn.
Một phần mềm có thể được sao chép.
Một tính năng có thể được đối thủ xây dựng lại.
Một công cụ AI có thể ngày càng trở nên phổ biến.
Nhưng một tổ chức có nhiều người hiểu sâu những lĩnh vực khác nhau, có khả năng phát hiện nhu cầu thực tế, tự thử nghiệm và biến hiểu biết thành năng lực kinh doanh đáng tin cậy là một thứ khó hình thành hơn nhiều.
Không phải vì từng cá nhân đều xuất sắc.
Mà vì tổ chức đã thiết kế được điều kiện để những năng lực khác nhau có thể phát triển và kết hợp với nhau.
Tôi không muốn mỗi nhân viên trở thành một Software Engineer.
Tôi không muốn mỗi người đều có một startup riêng bên trong doanh nghiệp.
Và tôi chắc chắn không muốn ba mươi người cùng viết ba mươi hệ thống quản lý đơn hàng.
Tôi muốn một điều đơn giản hơn.
Người hiểu vấn đề phải có cơ hội trở thành người xây dựng giải pháp.
Không phải lúc nào cũng tự viết code.
Không phải lúc nào cũng tự triển khai.
Nhưng phải có khả năng chủ động đưa một hiểu biết từ thực tế đến một kết quả có thể kiểm chứng.
Với sự hỗ trợ của những năng lực chung.
Và trong những giới hạn phù hợp với trách nhiệm của mình.
Nếu làm được, doanh nghiệp bắt đầu có khả năng phát triển vượt khỏi những gì founder trực tiếp tạo ra.
Nhưng tôi biết điều đó sẽ dẫn đến một nghịch lý mới.
Một tổ chức có thể trao quyền xây dựng cho nhân viên.
Có thể mở sandbox.
Có thể cung cấp capability API.
Có thể cho phép tạo micro-product.
Có thể khuyến khích thử nghiệm.
Nhưng nếu mọi sản phẩm muốn trưởng thành đều phải chờ founder hiểu, founder đánh giá, founder phê duyệt và founder giải quyết những xung đột phát sinh...
Thì chúng ta vẫn chưa thực sự giải quyết được bài toán mở rộng.
Chúng ta chỉ vừa tạo ra một hệ thống có khả năng sản xuất ý tưởng nhanh hơn khả năng founder xử lý chúng.
Một thành tựu rất thú vị.
Và cũng là một cách khá hiệu quả để khiến founder chết chìm trong những thứ do chính mình khuyến khích tạo ra.
Tôi có thể tưởng tượng một buổi sáng.
Mười nhân viên vừa tạo ra mười micro-product.
Năm người muốn triển khai.
Ba người cần thêm quyền truy cập.
Hai người có ý tưởng thay đổi hệ thống lõi.
Và tất cả đều đang chờ tôi quyết định.
Freedom to Build đã hoạt động.
Mọi người đều hào hứng.
Sản phẩm mới xuất hiện liên tục.
Nhưng có một vấn đề nhỏ.
The entire organization is now building faster than its founder can approve.
Và nếu không thiết kế thêm một cơ chế mới, khả năng xây dựng phân tán có thể trở thành một dạng tắc nghẽn tập trung.
Tôi sẽ phải tiếp tục giải quyết cùng một câu hỏi.
"Anh ơi, cái này được không?"
Chỉ khác là trước đây họ hỏi về một đơn hàng.
Bây giờ họ hỏi về một ứng dụng.
Một bước tiến đáng kể về mặt công nghệ.
Không chắc về mặt kiến trúc tổ chức.
Và có lẽ, đến lúc này, tôi phải đối diện với một sự thật khó chịu.
Có thể nhân viên không còn là giới hạn lớn nhất.
Có thể phần mềm cũng không còn là giới hạn lớn nhất.
Có thể hạ tầng đã đủ tốt.
Những người có năng lực đã bắt đầu xuất hiện.
Và tổ chức đã có khả năng tạo ra những điều mà trước đây chỉ founder mới thực hiện được.
Nhưng mọi con đường quan trọng vẫn dẫn về cùng một người.
Người đã thiết kế hệ thống.
Người muốn mọi thứ phải chính xác.
Người có khả năng giải quyết những vấn đề khó.
Và người chưa thực sự chuyển giao được quyền quyết định tương ứng với năng lực mà tổ chức đang phát triển.
Một nút thắt cổ chai.
Cực kỳ thông minh.
Có rất nhiều kinh nghiệm.
Hiểu toàn bộ kiến trúc.
Và có quyền quyết định gần như mọi thứ.
Fuck.
Perhaps the most dangerous bottleneck is the one that believes it is the solution.
Có lẽ nút thắt nguy hiểm nhất chính là nút thắt luôn tin rằng mình đang giải quyết vấn đề.
Và điều khó chịu nhất?
Tôi biết rất rõ người đó là ai.
NEXT CHAPTER — THE FOUNDER'S BOTTLENECK
Khi tốc độ phát triển của người sáng lập vượt quá tốc độ hấp thụ của tổ chức: tại sao chính người tạo ra lợi thế cạnh tranh lớn nhất cũng có thể trở thành giới hạn tăng trưởng nguy hiểm nhất?
The Architect of Chaos — Ông Chú Hay Chửi