Điều hành, OKR và bước chuyển từ nhà sáng lập sang CEO

Đăng ngày 23/10/2026

Tóm tắt

• Điều hành là giúp nhiều người cùng tạo kết quả có ý nghĩa, với ưu tiên, quyền quyết định và phản hồi rõ.
• OKR có thể tổ chức mục tiêu và kết quả then chốt; tên phương pháp không thay được việc chọn đúng điều cần thay đổi.
• Nhịp họp nên phục vụ cập nhật, quyết định hoặc học từ vấn đề; không phải mọi nội dung đều cần mọi người cùng có mặt.
• Chuyển từ tự làm sang dẫn dắt đòi hỏi giao cả bối cảnh và quyền, cùng giới hạn để biết khi nào phải báo lại.
• Khi giao một phần việc cho AI, tổ chức vẫn cần biết ai nhận trách nhiệm, bằng chứng nào được giữ và cách ngừng hành động sai.

Công việc đổi trước khi chức danh đổi

Ở giai đoạn đầu, nhà sáng lập có thể vừa viết sản phẩm, trả lời khách và tự quyết phần lớn ngoại lệ. Sau đó, mỗi việc làm tốt lại kéo thêm yêu cầu tới chính người ấy. Khi mọi người phải chờ một câu trả lời, làm nhanh hơn một chút không còn giải quyết được. Công việc điều hành bắt đầu từ việc làm cho người khác hiểu và quyết được trong phạm vi của họ, thay vì mở rộng lịch làm cá nhân vô hạn.

Ali Rowghani trong bài về công việc thứ hai của CEO startup phân biệt xây sản phẩm với xây công ty để đáp ứng cơ hội sản phẩm đã bộc lộ. Ông nhấn mạnh đội ngũ lãnh đạo, sự thống nhất mục đích và văn hóa khi chuyển vai trò. Đây là cách nhìn thực hành của Y Combinator, không phải mô hình xác nhận rằng mọi công ty phải chuyển ở cùng số nhân viên hoặc người sáng lập cần rời mọi chi tiết ngay lập tức [1].

Một cách tự quan sát là xem những quyết định nào luôn quay lại bàn mình. Chúng quay lại vì người làm thiếu năng lực, thiếu dữ liệu hay chưa được giao quyền? Nếu thiếu dữ liệu, thay người chưa giải quyết tận gốc. Nếu thiếu quyền, tổ chức cần xác định ranh giới. Nếu thiếu năng lực ở một việc mới, có thể cần hỗ trợ sát hơn trong một thời gian. Những nguyên nhân khác nhau không nên nhận cùng một lời nhắc hãy chủ động hơn.

Tôi đề xuất lập bản đồ quyết định, bắt đầu ở một luồng hay bị nghẽn. Bản đồ chỉ cần tên quyết định, người đề xuất, người quyết, người cần biết và điều kiện phải chuyển cấp. Không cần liệt kê toàn bộ hành động của mọi nhân viên. Mục tiêu là giảm vùng mọi người tưởng người khác sẽ xử lý, đồng thời giúp nhà sáng lập nhận ra phần nào mình đang giữ vì thói quen thay vì vì rủi ro thực.

Đặt mục tiêu để biết điều gì phải thay đổi

OKR được hiểu ở đây là cách diễn đạt mục tiêu cùng kết quả then chốt để kiểm tiến triển. Một mục tiêu cần nói hướng thay đổi có giá trị, còn kết quả then chốt cần giúp biết hướng ấy đã chuyển biến ra sao. Danh sách việc làm vẫn cần, nhưng không nên lẫn nó với kết quả. Hoàn thành một khóa đào tạo chưa tự chứng minh đội xử lý tốt hơn; phát hành một tính năng chưa tự chứng minh khách dùng được nó.

Locke và Latham năm 2002 tổng hợp nghiên cứu về đặt mục tiêu, trong đó nêu vai trò phản hồi, cam kết và độ phức tạp của tác vụ. Phần đã đọc phân biệt bài toán cần khám phá cách làm với bài toán đã có kỹ năng quen thuộc; mục tiêu học có thể cần thiết khi phương pháp chưa rõ. Đây là nghiên cứu về đặt mục tiêu, không phải thử nghiệm chứng minh toàn bộ một chương trình OKR cụ thể sẽ có tác dụng [2].

Trong tình huống giả định, đội muốn giảm việc khách phải gọi lại để bổ sung hồ sơ. Một kết quả có thể liên quan tới hồ sơ được tiếp nhận đủ ngay lần đầu, nhưng phải biết loại hồ sơ, khoảng quan sát và cách ghi ngoại lệ. Nếu chỉ đặt số cuộc gọi phải giảm, nhân viên có thể tránh liên lạc ngay cả khi cần làm rõ. Chỉ số cần được đọc cùng chất lượng công việc, không tách khỏi nghĩa vụ với khách.

Tôi đề xuất mỗi kết quả có định nghĩa, dữ liệu gốc, người cập nhật và cách kiểm. Nếu còn chưa biết yếu tố nào chi phối, có thể đặt mục tiêu học: thử cách hướng dẫn mới và xác định điểm khiến khách hiểu nhầm. Điều này không cho phép biến mọi mục tiêu không đạt thành một bài học để khỏi chịu trách nhiệm. Nó yêu cầu phân biệt ngay từ đầu phần cam kết tạo kết quả với phần còn phải khám phá.

Ra quyết định nhanh không đồng nghĩa bỏ thông tin

Trong bài năm 1990 về tốc độ lựa chọn chiến lược, Eisenhardt mô tả việc dùng thông tin vận hành kịp thời, so sánh nhanh các phương án, xử lý bất đồng và hỏi cố vấn có kinh nghiệm. Phạm vi đọc ở đây là tóm tắt của California Management Review. Những chiến thuật ấy không chứng minh cứ rút ngắn cuộc họp là quyết định tốt hơn, cũng không phải thử nghiệm về mọi startup trong môi trường hiện nay [3].

Một quyết định có thể nhanh hơn khi câu hỏi được giới hạn đúng. Đội có đang chọn một nhà cung cấp cho phép thử, hay đang khóa kiến trúc nhiều năm? Phần nào có thể hoàn tác và phần nào tạo nghĩa vụ khó đổi? Một lựa chọn thử nhỏ có thể cần ít thông tin hơn lựa chọn có hậu quả lâu dài. Cách phân biệt này là đề xuất của bài để phân bổ công sức phân tích theo tác động thực.

Cũng cần đặt một hạn cho việc tìm thông tin. Nếu thiếu dữ liệu quan trọng, ai tìm, lấy từ đâu và khi nào quay lại? Nếu tới hạn vẫn thiếu thì người quyết phải thấy điều chưa biết thay vì nhận một kết luận có vẻ hoàn chỉnh. Một văn bản ngắn ghi phương án, bằng chứng và điều kiện xét lại có thể giúp đội không mở lại cùng tranh luận chỉ vì thành viên khác nhớ một phần khác nhau.

Bất đồng nên được xử lý ở nội dung: ai đang giả định điều gì, thông tin nào có thể làm đổi kết luận và cái giá của việc chờ là gì. Không nên dùng sự tự tin hay thâm niên làm thay cho giải thích. Có thể nghe nhiều ý kiến mà vẫn chỉ có một người chốt; điều cần rõ là cơ chế đã được thống nhất trước và quyết định cuối được truyền đạt cùng lý do đủ để người thực hiện làm tiếp.

Từ bảng mục tiêu tới việc được nhận

Tài liệu AMIS Mục tiêu của MISA mô tả tạo mục tiêu theo các loại MBO, KPI, OKR và BSC, xem danh sách, nhắc cập nhật hoặc điều chỉnh mục tiêu và kỳ thực hiện. Qua trường hợp sản phẩm Việt Nam này, có thể hình dung cách lưu nội dung và theo dõi thay đổi. Nó chưa chứng minh mục tiêu được nhập đã phù hợp chiến lược, dữ liệu chính xác hay công ty áp dụng thành công [4].

Khi một mục tiêu cần nhiều đội phối hợp, phải đọc các phụ thuộc. Đội bán cần nội dung từ sản phẩm; đội sản phẩm cần thông tin từ khách; bộ phận tài chính cần dữ liệu nghiệm thu. Nếu mỗi nhóm tự tối ưu phần của mình, kết quả cuối có thể vẫn mắc lại. Người điều hành nên xác định chỗ cần quyết liên phòng ban và cơ chế giải quyết, thay vì chỉ yêu cầu cập nhật phần trăm hoàn thành thường xuyên hơn.

Hướng dẫn Base Wework sửa tháng 4/2025 mô tả một công việc có một người thực hiện chính, còn phối hợp có thể dùng người theo dõi hoặc chia công việc con. Các cách đó ghi nhận trách nhiệm và báo cáo khác nhau. Đây là thiết kế của một sản phẩm tại Việt Nam, không phải kết quả nghiên cứu khẳng định mọi tổ chức cần dùng đúng cấu trúc ấy [5]. Nó gợi câu hỏi ai thực sự nhận đầu ra cuối cùng.

Ví dụ giả định, một hồ sơ bàn giao có người viết, người kiểm và người gửi cho khách. Đánh dấu phần viết xong chưa bằng bàn giao xong. Đội cần biết sự kiện nào xác nhận bước cuối và ai nhìn phần còn tồn. Nếu tách thành nhiều công việc, quan hệ giữa chúng phải còn nhìn thấy được. Một phần mềm giúp chia nhỏ nhưng cách chia vẫn là quyết định của người hiểu công việc.

Tạo nhịp họp theo loại thông tin

Một cuộc họp cập nhật khác cuộc họp quyết định, và cả hai khác cuộc trao đổi riêng về hỗ trợ người làm. Khi trộn các mục đích, người tham dự dễ mang báo cáo dài vào nơi cần chọn phương án, hoặc yêu cầu quyết ngay khi người khác chỉ định báo một rủi ro. Có thể ghi loại cuộc họp và câu hỏi cần giải quyết từ trước để mọi người chuẩn bị đúng phần của mình.

Thông tin trạng thái ổn định thường có thể đọc trước nếu định nghĩa rõ và có chỗ hỏi lại. Thời gian cùng có mặt nên dành cho ngoại lệ, phụ thuộc hoặc lựa chọn đang mắc. Tuy nhiên, gửi một tài liệu không chứng minh người nhận đã hiểu. Đội có thể cần kiểm vài quyết định thực sau cuộc họp: người làm có biết ưu tiên và giới hạn không, hay vẫn phải hỏi lại từng trường hợp như cũ.

Keith Rabois trong bài giảng How to Operate dùng hình ảnh người biên tập để nói về làm rõ, đơn giản hóa, phân bổ nguồn lực và giao việc theo mức quen thuộc của người nhận với tác vụ. Đây là lời khuyên vận hành trong bài giảng lịch sử. Bài này không dùng các tỷ lệ cải thiện được kể hoặc giờ làm việc dài trong nguồn làm chuẩn năng suất, cũng không đồng nhất tất cả người lao động với một mô hình máy móc [6].

Từ góc nhìn ấy, điều hành không phải mang mọi chi tiết lên cuộc họp chung. Người chủ trì có thể hỏi phần nào không còn cần làm, phần nào cần một người quyết và phần nào cần thêm chứng cứ. Kết thúc nên có lựa chọn đã chốt, người nhận, hạn phù hợp và điều kiện báo lại. Nếu nội dung vẫn chưa đủ để quyết, bản ghi nên nói rõ đang chờ gì thay vì đặt một nhãn hoàn tất để làm lịch họp trông gọn.

Giao quyền cùng khả năng hỗ trợ

Một người được giao kết quả nhưng phải xin phép mọi bước chưa thực sự nhận quyền thực hiện. Ngược lại, lời nhắn cứ tự xử lý mọi thứ có thể để người nhận gánh rủi ro vượt kinh nghiệm hoặc thẩm quyền. Cần thỏa thuận những quyết định được tự làm, phần nào phải hỏi và lúc nào phải báo ngay. Có thể tăng phạm vi sau khi nhìn được cách người ấy xử lý những tình huống cụ thể.

Aaron Epstein trong Advice for new managers nhấn mạnh làm rõ kết quả, hỗ trợ người mới, điều chỉnh cách quản lý theo người và trao đổi riêng đều đặn. Ông cũng lưu ý chuyển từ làm chuyên môn sang quản lý là thay đổi kỹ năng. Bài này sử dụng lời khuyên thực hành ấy, không coi lịch họp cụ thể, câu khẩu hiệu về nghỉ việc hay cách chấm năng suất trong nguồn là quy luật đã kiểm định [7].

Khi nhận vai trò quản lý, một nhân viên có thể vẫn cố hoàn thành toàn bộ việc chuyên môn cũ. Người điều hành cần quyết phần nào được chuyển, phần nào giữ và ai hỗ trợ việc mới. Nếu chỉ thêm chức danh mà giữ nguyên khối lượng, việc quản lý dễ trở thành công việc làm vào thời gian còn lại. Sau đó tổ chức có thể nhầm thiếu điều kiện với thiếu năng lực của chính người vừa được đề bạt.

Phản hồi cũng nên theo hành vi và tác động. Thay vì nói chưa đủ tầm quản lý, có thể chỉ ra một quyết định chưa thông báo khiến đội khác chờ, rồi thống nhất cách cập nhật lần sau. Người nhận cần cơ hội giải thích bối cảnh; có khi vấn đề là hai ưu tiên mâu thuẫn do cấp trên giao. Cuộc trao đổi có ích khi dẫn tới điều có thể sửa, không chỉ một kết luận về tính cách.

Nhà sáng lập có nhất thiết giữ mọi vai trò

Wasserman năm 2003 nghiên cứu việc thay CEO sáng lập qua nghiên cứu hiện trường và phân tích lịch sử sự kiện của 202 công ty Internet. Tóm tắt nêu các mốc hoàn thành sản phẩm và nhận vốn bên ngoài gắn với thay đổi khả năng kế nhiệm. Đây là bối cảnh và thiết kế nghiên cứu cụ thể; không thể suy rằng đạt một mốc đồng nghĩa nhà sáng lập kém đi hoặc mọi doanh nghiệp cần thay CEO sau gọi vốn [8].

Câu hỏi thích hợp hơn là công việc điều hành hiện tại cần gì và người sáng lập muốn, có thể đáp ứng phần nào. Có người muốn tiếp tục dẫn toàn công ty; có người phù hợp tập trung sản phẩm hoặc khách hàng. Các lựa chọn ấy liên quan quyền sở hữu, thỏa thuận và nhu cầu tổ chức thực, không thể quyết chỉ bằng một bài viết. Điều có thể làm trước là mô tả công việc hiện có mà không gắn nó chặt với một người.

Trong cuộc trò chuyện với Adora Cheung, Patrick Collison kể cách ông và John phối hợp dựa trên niềm tin lâu dài, lĩnh vực tập trung và một cơ chế giải quyết bất đồng phù hợp quan hệ của họ. Chính lời kể cũng xác định hoàn cảnh ấy khá đặc biệt. Bài dùng trường hợp này để nhắc cần hiểu cơ chế phối hợp thực, không lấy cách hai anh em điều hành Stripe làm công thức cho mọi nhóm đồng sáng lập [9].

Một cuộc trao đổi chuyển vai trò nên giữ danh dự cá nhân tách khỏi mô tả nhu cầu công việc. Có thể nhìn các việc đang bị chậm, quyết định nào thiếu người chịu trách nhiệm và mức hỗ trợ cần có. Nếu phải thay đổi, cần lộ trình bàn giao tri thức cùng đường truyền đạt cho đội. Tránh để khoảng trống thông tin khiến nhân viên tự suy đoán ai mất quyền hoặc chiến lược đã đổi mà chưa có ai giải thích.

Kiểm nhịp điều hành bằng kết quả thực

Sau một kỳ áp dụng, đừng chỉ đếm số mục tiêu đã tạo hoặc cuộc họp đã diễn ra. Có thể theo một số quyết định quan trọng từ lúc nêu vấn đề tới lúc kết quả được xác nhận. Phần nào chờ dữ liệu, phần nào chờ quyền và phần nào bị đổi sau khi đã thực hiện? Dữ liệu ít vẫn có thể cho bài học cụ thể, nhưng không nên biến vài trường hợp thành tỷ lệ hiệu quả chung của hệ thống.

Nếu nhịp họp làm đội bận hơn mà vấn đề vẫn quay lại, có thể mục đích họp đang sai hoặc thiếu quyền ở bước quyết. Nếu báo cáo luôn tốt nhưng khách vẫn gặp lỗi, cần đối chiếu định nghĩa hoàn thành với trải nghiệm thực. Nếu ai cũng đạt mục tiêu cá nhân nhưng đầu ra chung kém, cần xem phụ thuộc và cơ chế thưởng. Cả ba trường hợp đòi hỏi nhìn hệ thống thay vì chỉ yêu cầu người làm cố thêm.

Tôi đề xuất giữ một sổ xét lại nhỏ với quyết định, bằng chứng lúc chốt, kết quả sau đó và điều cần sửa trong cách điều hành. Sổ không dùng để chứng minh ai đã dự đoán đúng nhiều hơn; nó giúp đội thấy giả định nào thường thiếu. Khi có người mới, họ cũng hiểu vì sao quy tắc hiện tại tồn tại và trường hợp nào nên mở lại, thay vì chỉ nhận một tập hướng dẫn không có lịch sử.

AI trong quy trình điều hành cần ranh giới nào

Một tác tử AI có thể đọc báo cáo, chuẩn bị bản tóm tắt hoặc đề xuất công việc tiếp theo. Nếu được nối với công cụ hành động, nó còn có thể gửi thông báo hoặc đổi dữ liệu. Hai mức đó có hậu quả khác nhau. Trước khi giao quyền, tổ chức cần xác định việc nào chỉ là nháp và việc nào tạo tác động mà người khác sẽ dựa vào để làm việc.

NIST AI 600-1, công bố năm 2024, đặt ra các nhóm rủi ro khi tạo sinh nội dung, như thông tin sai, dữ liệu riêng tư và phụ thuộc giữa những thành phần. Bài dùng khung ấy để đặt câu hỏi trong bối cảnh điều hành, không xác nhận một phần mềm đã an toàn hoặc một quy trình đã tuân thủ đủ quy định [10]. Một bản tổng hợp có vẻ nhất quán vẫn có thể bỏ sót ý kiến khác hoặc thêm lý do chưa ai nêu.

Ví dụ giả định, AI tổng hợp cuộc họp và ghi một việc như đã thống nhất trong khi nhóm mới đang thảo luận. Nếu bản tóm tắt tự đẩy việc tới hệ thống, người nhận có thể thực hiện một quyết định chưa có. Quy trình cần cách phân biệt đề xuất với quyết định, người xác nhận và đường quay về ghi chép gốc được phép truy cập. Không nên xem việc văn bản được tạo tự động là dấu hiệu đã có thẩm quyền.

Với công cụ hành động, phạm vi nên nêu đối tượng, loại thao tác, giới hạn và trường hợp phải dừng. Người phụ trách cần biết cách thu hồi quyền, sửa kết quả và báo cho bên bị ảnh hưởng khi có sai lệch. Đây là đề xuất thiết kế của tác giả, chưa phải báo cáo thử nghiệm. Đo hiệu quả phải tính cả phần người kiểm và xử lý hậu quả, thay vì chỉ số bản báo cáo hoặc nhiệm vụ được tạo.

AI cũng không nhận trách nhiệm tổ chức thay cho người được giao. Nếu quyết định sai, đội cần tìm dữ liệu, hướng dẫn, quyền và bước kiểm nào góp phần gây sai để sửa hệ thống. Việc ghi nhật ký có ích khi giúp truy được chuỗi ấy với quyền truy cập phù hợp. Nó không nên biến thành kho lưu mọi thông tin riêng tư chỉ vì có thể thu thập, hay thành cách đẩy trách nhiệm sang người cuối cùng bấm nút.

Nguồn và phương pháp

Nội dung có hỗ trợ bởi AI, không phải bản dịch; kiểm nguồn ngày 24/10/2026. Nghiên cứu đặt mục tiêu được dùng trong phần phản hồi và tác vụ phức tạp, không coi là kiểm định riêng của OKR. Eisenhardt và Wasserman theo phạm vi tóm tắt, tư liệu Y Combinator là thực hành và lời kể. Hai tài liệu Việt Nam chỉ xác nhận tính năng công bố, hiệu quả thực tế chưa kiểm chứng. Các khung, ví dụ giả định và hình là phần tác giả xây dựng; bài không tư vấn thay lãnh đạo hoặc quyết định quyền pháp lý trong một công ty cụ thể.