祝融说。

32.1 Outcome-Oriented, Not "Online"-Oriented

In remote collaboration, a common pitfall is drifting toward "performative online presence": frequently posting in group chats, replying to every message instantly, and pouring enormous effort into proving you are "working" -- rather than actually doing the work. This is the direct consequence of managers resorting to digital surveillance after "management by walking around" stopped working (frequent @-everyone progress checks, mandatory camera-on policies, monitoring software that tracks mouse and keyboard activity). Employees feel treated as suspects and perform accordingly.

"Outcome-oriented, not online-oriented" means breaking free from the "hours illusion" entirely. We measure output, not time:

• You are online from 10 AM to 7 PM but produce nothing -- that is "low output."
• You finish a critical module at 3 AM and sleep at 4 PM -- as long as the output is verified, that is "high output."

Practicing outcome orientation:

1. Define "output": What does "done" mean for each task? What are the deliverables? Measure in "verifiable results," not "hours invested."
2. Eliminate performance: Management stops the "see-to-trust" mindset; team members stop the "online-means-contributing" act.
3. Communicate by results: Weekly reports, standups, and syncs focus on "what was completed, what is blocked, what is next" -- not "what actions I performed."

Outcome orientation has an important side effect: it naturally dispels the "illusion of busyness." When everyone must report in verifiable outcomes, "faking busyness" loses its purpose.

32.2 Prerequisites for Autonomy: Clear Boundaries and a Shared Blueprint (OKR)

Many people mistakenly believe that "high autonomy" means "anything goes." Quite the opposite -- autonomy without boundaries is dangerous and irresponsible.

Imagine a city-wide "treasure hunt." If we give participants no rules or information, what happens? Chaos -- people run around like headless chickens, or simply give up because they have no idea where to start. If we hand out a step-by-step foolproof guide that tells them exactly how to walk every path, what happens? Boredom -- participants become robots executing instructions.

A good organizer should do two things: issue a clear "map" (marking boundaries -- which areas are safe game zones, which are off-limits danger zones, and placing a red X at the treasure's final location); provide a set of intriguing but vague "clues" (not revealing the exact path, but offering some guidance). Through the combination of a "clear map" and "intriguing clues," the organizer strikes the perfect balance between "absolute freedom" and "absolute control."

High-autonomy teams follow exactly the same logic: clear boundaries (defining "the scope you can act autonomously in") + a shared blueprint (guiding "the direction of autonomy").

Clear boundaries provide a "safety frame" for team members' autonomous decisions: within this frame, you are free to exercise your full talent. If a decision might touch or cross a boundary, you must pause and seek broader discussion and consensus. Boundaries exist at three levels:

• Values and culture boundaries (the deepest and most resilient): define "as a team member, which behaviors are absolutely encouraged and which are absolutely unacceptable." Principles like "async-first" and "default to public" are culture boundaries and should be explicitly written into the team handbook.
• Role and responsibility boundaries: the RACI model clarifies "who has ultimate responsibility for what" -- R (Responsible: executes), A (Accountable: ultimately answers for it -- every task must have exactly one A), C (Consulted: needs to be consulted), I (Informed: needs to be notified).
• Technical and architecture boundaries: engineers may freely refactor and optimize within their own "code territory," but once a change would affect "public API interfaces," "core database table structures," or "technology selection principles," a formal technical review or RFC process must be initiated.

The shared blueprint answers "where are we heading":

• Mission and vision: the most distant but brightest "North Star" in the blueprint. The mission answers "why we exist"; the vision answers "what the world looks like if we succeed." Leaders must repeatedly articulate and reiterate both, internalizing them as the "supreme principle" members reference in everyday decisions.
• Objectives and Key Results (OKR): the "rocket boosters" built to realize the vision. Objectives are qualitative, inspiring declarations; Key Results are 3--5 quantitative, measurable metrics. A good OKR example: O: Create an ultra-smooth registration experience that makes new users "fall in love at first sight"; KR1: Improve registration success rate from 70% to 90%; KR2: Reduce average time-to-first-login from 5 seconds to under 1 second; KR3: Cut customer service tickets caused by registration issues by 50%.

The value of OKRs is providing the team with an extremely focused "bullseye." When an engineer faces the choice of spending time refactoring legacy code or optimizing login interface performance, a clear OKR acts like a compass, helping them make autonomous decisions that align with the team's overall interests.

In summary: "clear boundaries" grant members the freedom to "act safely" by defining the "rules of the game"; "a shared blueprint" gives members the motivation to "act meaningfully" by stating the "objective of the game." When both are in place, "high autonomy" is no longer a hollow slogan but a powerful "collaboration operating system" that simultaneously unleashes "individual creativity" and unifies "collective momentum."

32.3 From Executor to Owner: "Everyone Designs, Everyone Builds"

Under the traditional "supervision-based" management model, the team is like a "large ship" driven by a single "central engine" -- the manager. Crew members are the "hands" and "feet"; the manager is the "brain." This model was efficient in the "industrial era" when the environment was stable and tasks were well-defined. But today, in the volatile, uncertain, complex, and ambiguous "VUCA era" -- especially in the distributed environment of remote collaboration -- this "centralized" drive model is rapidly becoming fragile and inefficient:

• Decision bottleneck: all information must converge on the "brain," and all instructions must originate from the "brain." When the market demands a response within hours, the "central engine" is still waiting for a perfect report.
• Information degradation: instructions inevitably attenuate and distort as they pass through layers. The "iceberg" spotted by frontline crew may have become "small floes" by the time it reaches the bridge.
• Creativity suffocation: when crew members get used to "waiting for orders," they shut down their own "sensors" and "thinking modules" -- "that is not my responsibility."

Remote collaboration fundamentally requires a "propulsion overhaul": instead of one massive but unwieldy "central engine," we need a "combined fleet" driven by countless small but elegant "distributed engines." Every team member must become an independent "engine" -- equipped with their own "sensors" (perceiving environmental changes), their own "processor" (independent analysis and judgment), and their own "thruster" (self-driven execution and accountability for results).

The role shift from "executor" to "owner" is the core of high-autonomy culture:

• The executor's catchphrase: "Tell me what to do." They care about how to complete the assigned "task point" with high quality. Their responsibility boundary starts at "receiving the task" and ends at "completing the task" -- like a skilled craftsman who can turn a blueprint into a chair, but does not think about "why the chair is needed."
• The owner's catchphrase: "What problem are we solving, and how will I drive it to resolution?" They care about the more fundamental "business problem" or "user pain point" hidden behind the task. Their responsibility boundary starts at "discovering the problem" and ends at "achieving the outcome and verifying its value" -- like an architect who not only knows how to lay bricks but thinks about the building's "purpose," "structure," and "aesthetics."

Three pillars for driving the role shift:

Pillar 1: "Storytelling" tasks -- from "What" to "Why." An executor only needs to know "what to do"; an owner must deeply understand "why we are doing it." The way tasks are assigned must fundamentally change: you can no longer hand over a "task list" containing only technical implementation points like a foreman tossing out a work order. Instead, like a "poet," you must tell a "user story" for every important task. Any requirement that demands more than one day of an engineer's time must be presented as a structured "requirements document" or "task card," and the first section of that document must always be the "Why" explanation.

❌ Poor task description:
[Title] Build a user-labeling feature.
[Description] 1. Add a "Labels" section to the user detail page;
2. Support adding/deleting labels through an input field;
3. Store the data in the user_tags table.

✅ Better task story: rewrite the task as "As a customer-service representative, I want to label users so that I can segment and communicate with them precisely," then provide the background, goal, user scenario, functional requirements, and acceptance criteria. Chapter 30 contains the full worked customer-label example.

Pillar 2: Shifting authority "forward" -- everyone is a "designer." In traditional teams, "design" authority is concentrated in the hands of a few, while the rest are responsible for "implementation." In teams where "everyone is an owner," "design" authority must be deliberately distributed to every executing engineer. "Who builds it, designs it" should become a core principle. After accepting a task story, the engineer's first job is not "writing code" but "writing a design document" -- for simple tasks, a few sentences in the task card's comment section describing the implementation approach; for complex tasks, a formal RFC. The value of this model: drives thinking (forces systematic thinking before hands-on work, surfacing problems at the lowest-cost design stage), empowers growth (the best training ground for developing architecture thinking in junior and mid-level engineers), boosts ownership (a solution you designed yourself comes with unparalleled sense of responsibility).

Pillar 3: Closing the "responsibility loop" -- from "development complete" to "value verified." An executor's responsibility ends the moment "code is merged and successfully deployed"; an owner's responsibility extends to the moment "the business value that this feature was expected to create is ultimately verified." "Who builds it, runs it" -- after a feature goes live, the responsible engineer has primary responsibility for monitoring online metrics, and is the first to respond and fix problems when they arise. At the same time, establish a "data-driven" verification culture (tracking the actual business performance of features after launch) and organize "feature retrospectives" (held some time after launch, answering three questions: Did we achieve what we set out to do? What did we learn? What should we do next?).

When all three pillars are realized, the team no longer needs any external "whip." Every member will radiate a powerful, intrinsic "ownership" drive from deep within -- the desire to "do things well and produce results." They all become true "engines."

32.4 Production Reverence and Data Red Lines

"Any environment that users touch is production." This is the first commandment of high-quality delivery.

In a high-autonomy team, the bottom line of freedom is responsibility. Every release, every line of code that enters users' view, carries actual user data and trust. "Production reverence" means: treat the production environment as something that demands respect, not a sandbox for casual experimentation. Any operation that could affect users (releases, configuration changes, data modifications) must be handled with care, be rollback-capable, and have a contingency plan.

Data is a red line: maintain data consistency, accuracy, and reliability. We discussed data inspection mechanisms in detail in Chapter 24. Here we add the cultural dimension: data red lines are "boundaries that must not be crossed" -- any operation on production data (deletion, bulk modification, migration) must follow strict protocols: back up first, dual-person confirmation, execute in small steps, and ensure rollback capability. Etch the credo "data is a red line" into every engineer's mind, and embed it into every data-related operation.

32.5 Balancing Independent Problem-Solving and Seeking Help (The 15-Minute Rule)

In a high-autonomy environment, a subtle yet critical question arises: when should you dig in on your own, and when should you raise your hand for help?

If you ask for help immediately upon encountering any problem, you become a "help-seeking black hole" that drains others' time. If you always struggle alone, you waste hours on a problem that could have been resolved quickly, and potentially delay the entire project.

The "15-Minute Rule" provides a simple and effective balance:

After trying independently for 15 minutes with no progress, raise your hand for help.

• Within 15 minutes: try independently. Check documentation, search, debug, think it through -- this is what your "autonomy" boundary requires of you.
• After 15 minutes: stop struggling alone and start seeking help. Organize your problem in a structured way (what you tried, what symptoms appeared, where you got stuck), then reach out to the right person or a public channel.

Why 15 minutes? It is an empirical rule of thumb marking the approximate balance point between "the diminishing returns of continuing to struggle" and "the coordination cost of asking for help"; teams can recalibrate it to their own collaboration costs. Beyond this point, the marginal return of struggling alone drops sharply, while the coordination cost of seeking help is far less than the time you would continue wasting.

Ask for help "professionally" -- a professional help request is structured. Here is an npm dependency-installation failure as an example:

[Problem] npm dependency installation fails
[Environment] macOS 14.2, Node 18.17, freshly cloned repository
[Symptom] `npm install` reports an ERESOLVE dependency conflict; attach the complete error log.
[Already tried] Reinstalled after deleting node_modules and the lockfile; ran `npm cache clean --force`; neither worked.
[Request] Has anyone seen this? What might be causing it?

Cultivate a "happy to ask, eager to help" culture: publicly recognize and reward "question askers" (asking a good question is just as valuable as giving a good answer), establish a "hero board" to honor "helper heroes," build a "mentorship program," and have managers lead by "showing vulnerability" (an excellent leader proactively admits in front of the team "I don't know the answer to this either -- let's figure it out together." This kind of "vulnerability" is actually a display of confidence and strength; it sends the team a message: here, not knowing is not shameful -- not asking is).

Finally, let us clarify the most common misconception about "outcome orientation": many people believe that outcome orientation and high autonomy mean working alone in isolation, meaning "atomized" individuals. This is exactly the opposite. The entire reason we break free from the "hours illusion," build a "community of responsibility," and strike the right balance between independence and seeking help is to achieve higher-level, more efficient collaboration. Autonomy is not about making you work alone; it is about giving you the ability to manage your own time and energy without external supervision, so you can fulfill the commitments you made to your team. In a mature outcome-oriented team, everyone is like a professional jazz musician -- with masterful solo technique, but also knowing how to listen and how to blend perfectly with the rest of the band. What they pursue is not individual showmanship, but the harmony and emotional impact of the entire piece. This is the ultimate state of outcome orientation: achieving deep team collaboration through high individual autonomy.