祝融说。

Imagine you are a 19th-century factory owner. How do you measure a worker's value? The answer is simple and straightforward: see how long they worked, and how many standardized parts they produced in that time. Time is the input; parts are the output. There is an almost perfect linear relationship between the two. Work 8 hours, produce 80 parts. Work 10 hours, produce 100.

This "hours-output" model has been deeply imprinted on management thinking for over a hundred years. It gave rise to time clocks, KPIs (Key Performance Indicators), and the familiar nine-to-five work schedule. One of the core functions of the office, this physical space, was to conveniently "monitor" hours as the most basic input. Managers see employees sitting at their desks, keyboards clattering, and feel a sense of "everything is under control."

However, we are long past the era where hammering and banging created value.

We are in an era of the knowledge economy and the creativity economy. Most of our work is no longer repetitive manual labor, but complex, nonlinear intellectual work. A programmer might spend three days agonizing over a bug without finding the root cause, then have a flash of insight while showering and solve it in five minutes. A designer might try a dozen unsatisfactory approaches over a week, then conceive a brilliant idea on a weekend trip, inspired by a falling leaf.

In this work model, the linear relationship between "hours input" and "value output" is completely broken. Five hours of "flow" state can create far more value than fifty hours of "ineffective online presence."

Remote collaboration acts like a merciless magnifying glass, exposing the absurdity of this "hours illusion" in full. When managers lose their ability to "see" and monitor hours, they fall into tremendous anxiety. This anxiety gives rise to distorted online "monitoring" methods: requiring employees to keep their cameras on all day, using software to track mouse movement, counting keyboard strokes...

These behaviors are not only legally and ethically controversial, but fundamentally misunderstand the nature of knowledge work. They try to manage "minds" like managing "machines," and measure "merit" with the yardstick of "effort." The result is inevitably killing creativity, destroying trust, and breeding a sick culture where everyone fears for themselves and focuses on performing "busyness."

To escape this predicament, we must make a complete mental shift, firmly turning the team's value yardstick from "online"-oriented to "output"-oriented.

This means we no longer care how long someone has "worked" or how "hard" they appear to be. We care about only one thing: whether they are consistently creating measurable value for the team and users, with high quality.

This shift is easy to say but extremely difficult to do. It requires us to redefine "output," rethink "results," and recalibrate an individual's "value coordinates" within the team. In this chapter, we will delve into how to build a truly "output-oriented" culture from three levels.

Escaping the "Hours Illusion": Measuring Contribution, Not Time

"I worked 60 hours this week, I'm exhausted." "My team has been working until after 10 PM every night for a month to hit this project deadline."

In many corporate cultures, such statements are often seen as symbols of "dedication" and "striving," even publicly praised. This worship of "hours" is what we call the "hours illusion." It is based on a dangerous, unexamined assumption: level of effort (measured by hours) = size of contribution.

Why Is This Assumption Dangerous?

It punishes efficiency and rewards inefficiency

Imagine two engineers, A and B, given the same task.

Engineer A, experienced and clear-thinking, takes one hour to write clean, efficient, bug-free code, then spends the rest of the time learning new technologies or with family.

Engineer B, less skilled and using an inefficient approach, takes eight hours to write bloated, complex, barely functional code, and then posts a late-night photo of themselves working overtime on social media.

In a culture that worships "hours," who gets praised? Most likely B. A might even be criticized as "not fully loaded." This sends a disastrous signal to the whole team: if you want recognition, make simple things complicated, and drag efficient work into a "protracted war."

It breeds "performative work," not real output

When "looking busy" is more important than "doing good work," people will expend a lot of energy on "performing busyness." They will deliberately delay replying to emails to show they are swamped. They will forward an industry article to the group late at night to prove they are still learning. They will fill their calendar with irrelevant meetings to create the illusion of being "indispensable."

These "pseudo-work" not only create no value, but also act as noise that disturbs those who are truly creating value.

It damages physical and mental health, leading to unsustainable burnout

Creative intellectual work requires a rhythm of tension and relaxation. It needs focused work, but it also needs adequate rest, recreation, and idle daydreaming. Long-term high-intensity work does not lead to sustained high output; instead, it exhausts creativity and leads to "burnout." An organization that keeps its employees "burning" will eventually have nothing left but ashes devoid of creativity.

Therefore, a mature remote collaboration team must clearly and repeatedly declare to all members: the only standard by which we measure your value is your contribution, not your hours.

How to Define and Measure "Contribution"?

This is precisely the most difficult part of shifting from "online"-oriented to "output"-oriented. Measuring hours is easy -- just a time clock. But measuring "contribution" is a complex, multi-dimensional problem. There is no universal formula, but we can build a relatively fair and comprehensive evaluation framework from the following aspects.

Delivered Results

This is the most direct contribution. It refers to which specific, valuable work you have completed.

For engineers: What features did you launch? What bugs did you fix? What performance optimizations did you make? Are these results running stably and with high quality in production?

For designers: What design solutions did you produce? Did these solutions improve user experience or solve a specific business problem?

For product managers: What product iterations did you plan and drive? Did these iterations lead to user growth, retention improvement, or revenue increase?

Key point: Measuring results means focusing on "outcomes," not "outputs." Delivering a feature (output) is not the same as contributing. Whether this feature achieved the expected business effect (outcome) after launch is the genuine contribution. This requires tightly binding work evaluation to ultimate user value and business goals.

Created Knowledge

In a knowledge-based organization, creating and sharing knowledge is as important a contribution as delivering results.

Did you write a high-quality technical design document that allows future colleagues to quickly understand a complex system?

Did you, after a failure postmortem, produce a detailed SOP (Standard Operating Procedure) that prevents the team from repeating the same mistake?

Did you share a new technology, tool, or method internally that improved the entire team's productivity?

Did you leave clear, understandable comments in your code, reducing future maintenance costs?

Key point: The value of knowledge contribution lies in its "leverage effect." A good document you spend a day writing might save dozens of colleagues hundreds of hours of duplicated effort over the coming years. This kind of contribution, though not directly reflected in business reports, has enormous long-term value.

Influence

Contribution is not only about what "you" did, but also about how you "influence" others and the team.

Help given to others: Did you patiently mentor a new member? Did you provide professional help and advice in your area of expertise? Did you give constructive feedback during a code review that helped the author improve code quality?

Process improvements: Did you identify and drive the improvement of an inefficient collaboration process? Did you introduce a new tool that increased the team's automation level?

Culture shaping: Did you demonstrate candor and respect in a difficult discussion? Did you take the initiative to do some "dirty work" that is outside your scope but beneficial to the team?

Key point: Influence contribution measures a person's "team multiplier effect." An excellent team member not only shines themselves but also lights up those around them. Their presence makes the team's output achieve "1+1 > 2."

From "Measuring" to "Showing" Contribution

In an output-oriented culture, responsibility is bidirectional. The team and management have a responsibility to build a fair, contribution-based evaluation system. And every individual also has the responsibility to proactively and structurally demonstrate their contribution.

In a remote environment, "keeping a low profile" is a dangerous quality. Because if your efforts and results cannot be effectively "seen," they may as well not exist. "Being seen" here does not mean performative showmanship, but a professional, fact-based self-presentation.

How to Professionally Demonstrate Your Contribution?

Weekly structured summaries

Develop the habit of writing a "weekly report" or "work log." But this weekly report should not be a simple list of tasks. It should be a "contribution report." Try using an "OKR" or "STAR" framework to organize content:

Objective: What was my core goal this week? Which team goal does it relate to?

Key Results: What specific, measurable outcomes did I complete to support this goal? (e.g., Launched the user login feature, increasing new user registration rate by 5%.)

Other Contributions: What else did I contribute in terms of knowledge or influence this week? (e.g., Completed a new API Interface Document and organized a team sharing session.)

Challenges and Learnings: What challenges did I encounter? What did I learn from them?

This weekly report is first for yourself, to help you review and reflect. Second, it is an excellent tool for "asynchronous alignment" with your manager and team.

Make your deliverables "self-explanatory"

Every delivery should be a complete "contribution package."

When submitting code: Follow team norms, write clear Commit Messages explaining "why" this change was made. In the Merge Request description, provide complete context, test screenshots, and usage instructions.

When delivering a document: A good document should have a clear table of contents, background introduction, core conclusions, and action items. Let readers quickly grasp the key points.

When releasing a feature: Write a clear changelog that not only tells users "what we updated" but also explains "what value this brings to you."

Share proactively, don't wait passively

When you complete a valuable piece of work or learn something useful, don't wait for others to discover it. Proactively share in the appropriate public channel.

"Hi all, I just finished a technical research report on [XXX] [link]. It compares the pros and cons of three approaches: A, B, and C. Interested colleagues, please take a look. Feedback is welcome."

"FYI, just launched a small optimization. Page load speed has improved by 30% (figure is illustrative). Thanks to @someone for the help with testing."

This kind of proactive sharing not only demonstrates your contribution but also adds to the team's knowledge base -- a win-win behavior.

Escaping the "hours illusion" is a difficult but necessary revolution. It requires managers to let go of their obsession with "control," instead becoming an "enabler" and "servant," focused on setting clear goals, removing obstacles, and building a fair evaluation system for the team. It also requires every team member to transform from a passive "hours seller" to an active "value creator," taking full responsibility for their own growth and contribution.

At the end of this revolution, we will arrive at a fairer, more efficient, and more humane work world. In this world, our value is no longer measured by how long we are "online," but by how much real, beautiful creation we leave for the world.

The True Meaning of Results Orientation: A Shared Commitment to Final Delivery Quality

"We are a results-oriented team."

This sentence appears in almost every company's job postings and values statements. But ironically, "results-oriented" can mean very different things in different teams.

In some teams, "results-oriented" means achieving goals by any means necessary. User experience can be sacrificed, technical debt can be accumulated, employees' health can be squeezed. "Results" become a fig leaf covering all shortsightedness and unprofessionalism in the process.

In other teams, "results-oriented" means fragmented responsibility. The product manager says, "My result is delivering the PRD on time." The engineer says, "My result is finishing the code on time." The QA says, "My result is filing bugs on time." Everyone "delivers" their own "result," but the final product is a Frankenstein's monster with terrible user experience.

These are all misinterpretations and abuses of "results orientation."

A true "output-oriented" culture must be built on a correct understanding of "results." We believe that the true meaning of results orientation is that every role in the team shares an indivisible responsibility for the high-quality product experience that is ultimately delivered to the user.

The key words here are:

• Ultimately delivered to the user: Our work does not end when the PRD is approved, when code is merged, or even when a feature goes live. It only truly produces a "result" when a user actually uses our product smoothly and joyfully, and their problem is solved, their need is met.
• High quality: "Results" are not just about "whether it exists," but about "how good it is." A feature full of bugs, with poor performance and terrible experience, does not deliver a positive result but a negative one. It does not solve the user's problem but creates new ones.
• Shared, indivisible responsibility: There is no "that's not my job" vacuum in the team. The product's ultimate failure is everyone's failure; its ultimate success is everyone's success.

From "Role Assembly Line" to "Community of Responsibility"

In a traditional, function-based waterfall development process, team members can easily fall into a "role assembly line" mindset. Everyone is like a worker on an assembly line, caring only about their own step in the process, lacking overall awareness and responsibility for the final product.

Remote collaboration amplifies this "role assembly line" risk. Because physical separation makes psychological estrangement easier. If the culture and processes do not deliberately break down these barriers, the team will degenerate into a group of "most familiar strangers."

Therefore, building a "community of responsibility" is a key step in a remote team's maturation.

How to build a "community of responsibility"?

Set shared goals centered on user value

The team's goal should not be "complete 10 features this quarter," but "reduce user churn rate by 5% this quarter."

The former (feature-oriented) traps the team in "doing for the sake of doing." Each role can easily claim they "completed" their task, yet it contributes nothing to the business.

The latter (value-oriented) forces everyone in the team to think about the same question from their own professional perspective: "How can I contribute to the final result of reducing user churn?"

The product manager needs to deeply research why users churn, and design solutions that truly retain them, not just stack features.

The engineer needs to think: is it the poor performance and frequent bugs causing user churn? They will be more proactive in refactoring and optimizing, because this directly relates to achieving the team's goal.

The designer needs to examine: is it the confusing interactions and ugly interface driving users away? They will be more committed to improving every detail of the user experience.

When everyone is guided by the same meaningful "north star metric," role boundaries naturally dissolve. Everyone is no longer working for their own KPIs, but fighting for a shared mission.

Embrace the "Everyone Is a Product Manager" Culture (the Right Way)

The phrase "everyone is a product manager" is often misunderstood as "everyone can meddle in the product." This is, of course, wrong.

Its true meaning is: every member of the team should have "product thinking" -- viewing and understanding their work from the user and business perspective.

Engineers should not just be "code translators": When receiving a requirement, the engineer's duty is not just to translate it into code. They should proactively understand the "why" behind the requirement -- why are we building this feature? What user problem does it solve? What is the expected effect? When they find logical flaws in the requirement or a simpler, more elegant technical solution, they have the responsibility and right to challenge the product manager and make suggestions. Our team has a slogan: "Better to annoy the PM than to crash in production."

Designers should not just be "artists": A designer's value lies not in how beautiful icons they draw, but in how smooth an experience they design. They should deeply participate in early product planning, using their expertise to influence the product's direction. They should also pay attention to post-launch data, using it to validate and iterate their designs.

QA engineers are "the last line of defense for quality" and also "the first line of defense for user experience": An excellent QA engineer not only tests whether the functionality meets the requirements document, but also puts themselves in the shoes of a picky, real user, feeling whether the entire product flow is smooth, the copy is clear, and the interactions are intuitive. They are the closest to the "final delivery quality."

To cultivate this culture, the team needs to deliberately create opportunities for information transparency and cross-learning. For example, regularly hold "product solution co-creation sessions," inviting all roles to brainstorm together; encourage engineers and designers to directly participate in user interviews and listen to real user voices.

Establish "end-to-end" delivery ownership

Instead of having different roles pass work like a relay race, try forming smaller, more flexible "feature teams" or "squads" with end-to-end delivery capability.

A typical feature team might consist of one product manager, one designer, two to three engineers, and one QA engineer. They are collectively responsible for a complete user value stream, from requirement discovery and solution design, to development and testing, and finally to post-launch data monitoring and iteration.

In this model, "responsibility" is no longer dispersed but focused. The success or failure of the group is shared. This greatly stimulates the team's intrinsic drive and sense of ownership. They will spontaneously optimize their collaboration processes and compensate for each other's weaknesses, because they know no external role can "catch" their final result.

Shared Commitment to "Quality": From "Post-hoc Testing" to "Built-in Quality"

In a true "community of responsibility," the understanding of "quality" fundamentally changes.

Quality is no longer seen as the sole responsibility of the "QA engineer," nor as a "horse-locking-the-barn-door" step at the end of the development process. Quality is an attribute that every role must build into every aspect of their work.

The product manager's quality responsibility: The clarity, logical completeness, and consideration of edge cases in requirements are the product manager's "code quality." A vague, loophole-ridden requirement is the biggest source of product defects.

The designer's quality responsibility: Consistency of interactions, usability, and consideration of error states are the designer's "code quality." A design that only considers "sunny day scenarios" and ignores "the side paths" will inevitably result in poor user experience.

The engineer's quality responsibility: Code readability, maintainability, robustness, and sufficient automated testing are the engineer's core commitment to quality. An engineer who only cares about "making it work" is planting mines of "technical debt" for the team's future. We firmly believe that "slow is fast." Taking the time to write high-quality, tested code pays off far more in the long run than sacrificing quality for short-term speed.

To implement this "built-in quality" philosophy, the team needs to establish a jointly adhered-to "Quality Charter" -- which is what we commonly call the "Definition of Done" (DoD). A good DoD clearly defines under what conditions a feature can be considered "truly done." For example:

• Code has been reviewed by at least one colleague (Code Reviewed).
• Unit test coverage is above an agreed threshold (e.g., 80%, decided by the team).
• All interaction details in the design mockups have been implemented.
• Test cases have been passed in the staging environment.
• Relevant user and technical documentation has been updated.

This "Charter" is the team's shared commitment to final delivery quality. It acts as a quality gate, ensuring no "semi-finished products" or "defective goods" flow to the user.

"Results orientation" is not an empty slogan. It is a deep culture and a rigorous set of mechanisms. It means we are no longer satisfied with being passive "executors," but actively see ourselves as "partners in value creation." What we care about is no longer just "whether I completed my task," but "whether we together created excellent value for the user."

This shift in perspective from "me" to "we" is the great voyage from "role assembly line" to "community of responsibility." On this voyage, what we will gain is not only a better product, but also a more cohesive and capable team.

Independent Problem-Solving vs. Seeking Help: When to Go It Alone and When to Ask for Help

In a culture that promotes "output orientation" and "high autonomy," a common and thorny question arises: as a team member, to what extent should I independently solve the problems I encounter? If I seek help too often, will I be seen as incompetent? If I stubbornly fight alone to prove myself, will I eventually delay the entire team's progress?

This question touches on the delicate balance between individual autonomy and team collaboration. If this balance is not properly managed, it leads to two common forms of "collaborative dysfunction":

• "The helpless dependent": This type of person equates "collaboration" with "dependence." At the slightest obstacle, their first reaction is not to think or search themselves, but to immediately @someone in the group and throw out an unprocessed "raw question." They appear to be actively communicating, but in reality, they are cheaply shifting the thinking responsibility that should be theirs onto others. They frequently interrupt colleagues, consuming the team's valuable focus, and become a "black hole" of team efficiency.
• "The lone hero": This type is the other extreme. They equate "autonomy" with "isolation." They see seeking help as a sign of "weakness" and "incompetence." When encountering a difficult problem, they choose to "carry it all alone," stubbornly fighting in silence. They might spend three days solving a problem that a senior colleague could point out in ten minutes. They appear to be "working hard," but in reality, they are using personal "heroism" to hijack the team's valuable time and hide huge project risks.

Both of these behavior patterns betray "output orientation." Because they ultimately harm the team's overall output efficiency.

A truly mature professional knows how to find the optimal "inflection point" between "independent problem-solving" and "seeking help." They possess both the determination and ability to "get things done," and the humility and wisdom to "leverage the collective intelligence of the team."

The "15-Minute Rule": A Decision Framework for Seeking Help

To help team members better find this "inflection point," we introduce a simple yet effective decision framework, widely circulated in the agile/Extreme Programming (XP) community. We call it the "15-Minute Rule."

The rule is: when you encounter a difficult problem, you should first try to solve it independently for at least 15 minutes. During these 15 minutes, you use all your standard weapons: Google search, consult official documentation, search the team's knowledge base, debug the code...

If after 15 minutes you still have no clue or have made very little progress, you must stop and proactively seek help from the team.

This rule seems simple, but it contains profound wisdom.

What does "at least 15 minutes" of independent effort ensure?

1. Respects others' time: It ensures you are not a "helpless dependent." The question you present to your colleague will no longer be a raw problem like "my computer is broken," but a more valuable question that you have initially diagnosed, such as: "I tried restarting and reinstalling the driver, but my computer still blue-screens with error code XXX. Has anyone encountered this before?" This greatly reduces the communication cost for others who want to help.
2. Exercises personal ability: It forces you to actively think and learn how to locate and solve problems. Most everyday problems can be solved during this 15-minute "struggle." This process itself is the fastest path to personal growth.
3. Protects flow state: It prevents you from easily interrupting your flow state over a trivial issue. Sometimes, the answer emerges on its own during focused thinking.

What does "must stop and ask for help" ensure?

1. Controls sunk cost: It sets a "stop-loss limit" for you. 15 minutes is long enough for a meaningful attempt, but short enough that you don't invest too much sunk cost into one problem. It reminds you that your time, and the team's time, are valuable.
2. Proactive risk exposure: It ensures you don't become a "lone hero." If you're stuck on a problem for 15 minutes, it likely means it's beyond your current ability or is a tough problem that requires collective effort. Promptly exposing it and bringing in the team's collective intelligence is the best risk control measure.
3. Promotes knowledge flow: Every request for help and every answer is a knowledge transfer within the team. The problem you encountered may have been encountered by others too. Through public Q&A, the solution becomes a shared knowledge asset for the team.

The "15-minute" figure is not absolutely precise. You can adjust it to 30 minutes or 1 hour depending on the complexity of the problem and your experience. The core spirit is: do your best, but also know when to cut your losses.

How to Make a "Professional" Request for Help?

When you decide to seek help, the way you ask also reflects your professionalism. A professional request for help should follow the "saturated information delivery" principle from Chapter 1. It should be like a clear "bug report," not a vague "help!"

A professional request for help should include the following elements:

1. Goal: What was I originally trying to achieve? "I am trying to upgrade my local development environment to the latest Node.js v18."
2. Current state: What specific problem or phenomenon am I encountering? "But after running the npm install command, the terminal throws a compilation error related to node-gyp. The error log is attached."
3. Attempts: What solutions have I already tried, and what were the results? "I have already tried clearing npm cache, reinstalling Python and C++ build tools based on top-voted answers on Google, but the problem persists. Here are the links I referenced: [link1], [link2]."
4. Question: What specific kind of help do I need now? "I'd like to ask if any colleagues encountered similar issues when upgrading to v18? Or are there other troubleshooting approaches for this node-gyp error?"

Compare this with an unprofessional request: "@all Can someone help me? My npm can't install dependencies. What's going on?"

The former shows a professional's rigorous problem-solving process. It allows the helper to quickly get into context and provide precise guidance. The latter only shows the helplessness and laziness of the requester.

Fostering a Culture of "Willing to Ask, Good at Helping"

To keep the balance between "independent problem-solving" and "seeking help" stable, individual awareness alone is not enough. The team also needs to foster a culture that encourages asking and rewards helping.

Publicly recognize and reward "askers"

Managers should repeatedly emphasize: "Asking a good question is as valuable as giving a good answer." When someone asks a deep question that sparks a beneficial team discussion, give them public recognition, just as you would recognize a technical breakthrough. This makes it clear that asking for help is not "incompetence" but "contribution."

Set up a "Hall of Fame" to recognize "helpers"

Team members who frequently and helpfully assist others should receive special recognition. In the team's weekly report or monthly summary, create a "Best Teammate" or "Knowledge Contributor" column. This encourages more people to share their knowledge and experience.

Establish a "mentorship program"

Assign each new member an experienced "mentor." One of the mentor's responsibilities is to proactively check in on the new member's progress, encourage them to ask questions, and provide a "safe," one-on-one channel for help. This helps new members smoothly get through the most difficult "silent period."

Managers should lead by "showing weakness"

If a team leader always acts omniscient and omnipotent, team members will naturally be afraid to expose their "ignorance." An excellent leader proactively admits in front of the team: "I don't understand this problem either. Let's study it together." Or "@someone, you're the expert on this. Can you share your thoughts?" This kind of "showing weakness" is precisely confidence and strength. It sends a signal to the team: here, we are all learners. Not knowing is not shameful; not asking is.

Summary: Autonomy Is for Better Collaboration

At the end of this chapter, we want to clarify a common misunderstanding about "output-oriented" culture. Many people think that output orientation and high autonomy mean going it alone, meaning "atomized" individuals.

This is precisely the opposite.

The reason we need to escape the "hours illusion," build a "community of responsibility," and master the balance between "independence and seeking help" is all for the ultimate goal: achieving higher levels of more effective collaboration.

Autonomy is not about working alone; it's about having the ability to manage your own time and energy without external supervision, to fulfill your commitments to the team.

Output orientation is not about caring only about your own KPIs; it's about tightly connecting your work to the team's shared, ultimate user value.

In a mature output-oriented team, everyone is like a professional jazz musician. They have exquisite solo skills (independent problem-solving ability), but they also know how to listen, improvise, and perfectly harmonize with other members of the band (seeking and providing help). They pursue not individual showmanship, but the harmony and beauty of the entire piece.

This is the ultimate state of output orientation: achieving deep team collaboration through high individual autonomy.