祝融说。

"How can I trust that my employees are working hard?"

In discussions about remote work, this is the most frequent and anxious question managers ask. Hidden behind this question is a deeply ingrained management paradigm: trust must be guaranteed through supervision.

In the office, this supervision is implicit, based on physical presence. Managers gain a false but reassuring "sense of trust" by "seeing" employees sitting at their desks. But when the physical space disappears, this cheap sense of trust collapses. So managers frantically seek digital "eyes" -- software that can monitor employees' online hours, keyboard strokes, screen content.

This behavior, we call it the "externalization of trust." It is an attempt to replace internal, spontaneous trust relationships with external, coercive technical means. This is not only futile but destructive. It fundamentally places managers and employees in an adversarial relationship of "cops and robbers." In such a relationship, you can never expect employees to exercise initiative and creativity. What you get is only a minimum level of "compliance" output produced to deal with the monitoring.

A truly efficient, future-ready team must go in a completely opposite direction: build a trust that requires no monitoring -- an endogenous trust.

This trust does not come from what managers "see," but from the team collectively building a clear, reliable, self-regulating collaboration "protocol." Under this protocol, everyone clearly knows their own and others' rights and obligations. Everyone is confident that the other will follow the shared agreement as they do.

This state is what we call "rapport."

Rapport is the most distinctive feature of a high-trust team. It means the team's operation no longer relies on the continuous supervision and commands of a centralized node, but works like a precision mechanical watch, where every gear knows its position and role, meshing perfectly with others, spontaneously and synchronously driving the hands forward accurately.

This rapport is neither innate nor accidental. It is a team capability that can be deliberately designed and carefully cultivated. It is built on three key practices: ex-ante expectation alignment, in-process responsibility sharing, and ex-post record keeping. In this chapter, we will delve into these three core projects for building "rapport without monitoring."

Aligning Expectations: Why Voting and Understanding Work Habits Matter So Much?

A large share of conflicts and disappointments in team collaboration stem from a common but often overlooked root: unspoken, inconsistent expectations.

You expect a colleague to reply within half an hour, but they think asynchronous communication means a reply within half a day is fine. So you feel "ignored," and they feel "harassed."

You consider a task "done" when the code is deployed, but they think it's "done" as soon as the code is committed. So you have a heated argument at the last minute of the project release.

You prefer working late at night, enjoying uninterrupted peace, but the team always schedules urgent all-hands meetings at 9 AM. So you feel "disrespected," and the team feels "you are hard to work with."

These conflicts have nothing to do with anyone's ability or character. They merely expose a brutal truth: each of us carries a unique "collaboration default setting" shaped by our past experiences. If we do not proactively and consciously pull out these "default settings" to align and calibrate, the collaboration process will be like two incompatible computer systems, constantly crashing and glitching.

In the office, this "expectation alignment" process is vague and subtle. Through long-term shared work and informal observation, we can roughly "sense" everyone's work rhythm and preferences. But in a remote environment, we lose this opportunity to "read the room." Therefore, turning implicit expectations into explicit consensus becomes the first and most important step in building trust.

This process is called "expectation alignment." It is not a one-time event but an ongoing effort. Among the tools available, "voting" and "publicly sharing personal work habits" are two extremely effective but often underestimated methods.

Voting: From "I Thought" to "We Agreed"

Many teams, when formulating collaboration norms, often fall into an "expert trap" or "leadership trap." That is, a few people (usually leaders or senior employees) create a set of rules based on their own experience and then require everyone to follow them.

This top-down approach seems efficient but plants huge hidden risks. Because it ignores the diversity of team members and makes it hard to gain genuine buy-in. There is a world of difference in enforceability between rules that are passively accepted and rules that are actively co-created.

Voting is the fairest and most efficient democratic tool for turning "individual preferences" into "collective consensus." Its value lies not only in the final "majority rules" outcome, but also in the "discussion" before the vote and the "expression" during the vote.

What kinds of things should we vote on?

The answer: all questions related to team collaboration habits that have no single right answer -- "gray zone" issues.

Here are some topics our team has voted on (these scenarios are composite examples used to illustrate the voting method; the numbers and outcomes are not records of actual events).

Regarding IM Response Expectations

• Question: For non-urgent IM @mentions, what is the expected default response time?
• Options: A. Within 1 hour B. Within 4 hours (half a working day) C. Within 24 hours
• Discussion: Before voting, we had a thorough discussion. Colleagues who supported A believed remote collaboration requires faster responses to compensate for physical distance. Those who supported B believed this strikes the best balance between timeliness and protecting focus. Very few supported C.
• Result: A majority of colleagues chose B. So "respond within 4 hours" became our team's explicit agreement, written into the Collaboration Norms. From then on, no one felt anxious or dissatisfied because a message was replied to after 2 hours, because we all knew it was well within the "reasonable range we collectively agreed upon."

Regarding Weekly Meeting Format

• Question: What format of weekly meeting do we prefer?
• Options: A. Fixed voice meeting at 10 AM B. Fixed voice meeting at 8 PM C. Cancel fixed meetings, only sync when needed
• Discussion: Supporters of A believed a morning meeting follows the previous day's release, creating a more continuous rhythm for clearer progress and issue communication. Supporters of B felt evening meetings were more controllable and didn't occupy daytime development hours. Supporters of C believed any fixed meeting undermines autonomy.
• Result: B won overwhelmingly. This result profoundly shaped our team's "async first" cultural genes.

Regarding Meeting Time Scheduling

• Question: To accommodate colleagues with different work habits, what time slot should we try to schedule meetings that require multiple participants?
• Options: A. Morning (9:00-12:00) B. Afternoon (14:00-17:00) C. Doesn't matter, anytime
• Discussion: This discussion led everyone to share their personal "peak productivity times." Many said mornings were their "golden hours" for deep work and didn't want to be interrupted by meetings.
• Result: B won by a narrow margin. From then on, we adopted "afternoon first" as a soft principle for scheduling meetings. It's not mandatory but provides a common reference point.

The significance of voting goes far beyond the result. It is a process of "team self-discovery." During this process, we see each other's differences clearly for the first time and understand the reasons behind others' behaviors. That colleague you thought was "cold" might just be protecting their morning "flow." That colleague you thought was "procrastinating" might just be used to bursts of inspiration late at night.

This understanding-based consensus is far more solid than any top-down regulation. It turns the team's collaboration norms from cold "clauses" into a "social contract" we all signed together.

Publicize Your "Personal Work Habits Manual"

Voting solves the problem of "commonality." But team collaboration also involves a lot of "individuality." Everyone has their unique work rhythm, communication preferences, and energy curve. If these "individualities" are not understood and respected by other team members, they become "hidden reefs" in collaboration.

Therefore, we encourage every member of the team to write their own "Personal Work Habits Manual" and place it in a team-shared, easily accessible location (e.g., in everyone's profile page).

This "manual" is like a product's "API documentation." It tells your colleagues how to achieve the most efficient and smoothest "collaboration call" with you.

A good "Personal Work Habits Manual" typically includes the following:

My Working Hours

What are my typical working hours? Do I have fixed lunch breaks or family time? Example: "I'm usually online from 10 AM to 7 PM. 1 PM to 2 PM is my lunch and rest time, during which I may not reply to messages. I'm offline from 5 PM to 6 PM every day to pick up my kids."

My Peak Productivity Time

What time of day is my "golden hour" for deep thinking and creative work? During this time, I would prefer not to be disturbed. Example: "My 'flow' time is usually between 10 AM and 1 PM. During this time, I turn off all IM notifications and focus on coding or design. If it's not urgent, please try to collaborate with me via project management tool comments."

My Communication Preferences

What is the best way to reach me? For different types of things, which communication channel do I prefer? Example: "For urgent production issues, please call me directly. For complex issues requiring in-depth discussion, please schedule a 30-minute video call in advance. For daily work sync and Q&A, Slack is the best. I don't check email often, so please don't send time-sensitive requests via email."

My Feedback Style

How do I give feedback? How do I prefer to receive feedback? Example: "I tend to give direct, candid feedback, but this is never personal. I hope you can give me the same treatment. When receiving feedback, I prefer written feedback based on specific facts and examples, as it helps me understand and improve better."

My Quirks

What are some small characteristics about me that others might not know but would help with collaboration? Example: "I'm a 'visual' thinker, so when discussing complex issues, I heavily rely on whiteboards or mind mapping tools. Also, I like to use lots of emojis when replying to messages -- it's just my personal habit, it doesn't mean I'm not serious :D."

How I Can Help

What areas am I particularly skilled in? What kind of help can you seek from me? Example: "I have some experience with performance optimization and database design. If you're facing issues in these areas, feel free to reach out. I'm also an avid coffee enthusiast. If you want to chat about pour-over coffee, I'm always up for it."

This "manual" has bidirectional value. For the writer, it is a profound process of "self-awareness." It forces you to think about and articulate your work patterns. For the reader, it is a valuable "collaboration guide." Before collaborating with an unfamiliar colleague, spending five minutes reading their "manual" can save you from most of the potential friction caused by misunderstanding.

Expectation alignment is an ongoing "sync" effort. It's not something you do once and forget. New members join the team, projects face new challenges, and personal work habits may change. Therefore, the team should regularly (e.g., quarterly) conduct a "collaboration health check," reexamining and recalibrating shared agreements, and encouraging everyone to update their "Personal Work Habits Manual."

Through these two simple tools -- "voting" and "publicizing work habits" -- we are essentially building a distributed, self-regulating "expectation management system" within the team. This system turns the generation of rapport from an uncontrollable "accident" into a predictable "certainty." The trust it builds is a deeper one, based on understanding and respect.

Shared Responsibility, Shared Risk: There Is No "Not My Problem"

In a high-trust team, there is a very important cultural tenet: problems are the team's problems; risks are the team's risks. There is no such thing as "your problem" or "my problem," and certainly no "this is not my responsibility" vacuum.

This culture of "shared responsibility, shared risk" is the underlying safety net that allows "rapport without monitoring" to function. Because it sends a clear and reassuring signal to every team member: you are not fighting alone. No matter how big the difficulty or how serious the mistake, the entire team has your back. We face it together, solve it together.

Conversely, in a team lacking this culture, you will see:

• A "blame culture" prevails: When a problem occurs, the first reaction is not to solve it but to shift blame and find a scapegoat.
• Severe "silo effects": Each role or group cares only about their own patch, indifferent or even gleeful about the difficulties and risks of upstream and downstream.
• "Hiding problems" becomes the norm: Employees are afraid of being isolated or punished, so they dare not expose difficulties or mistakes they encounter, until the problem becomes too severe to handle.

This state of everyone being defensive and isolated is poison for team collaboration. In a remote environment, due to physical separation, this poison spreads faster and causes more damage.

Therefore, deliberately building a "shared" culture is essential learning for managers and every team member.

Practice One: Establish a "Blameless Postmortem" Culture

No team can avoid mistakes. Systems fail, projects are delayed, decisions go wrong. The key is not avoiding mistakes, but how we learn from them and ensure we don't repeat them.

A "blameless postmortem" is a powerful practice aimed at learning and improving at the system level. Its core philosophy is: we believe that under the conditions at the time, every person made what they believed to be the most reasonable decision based on the information they had. The problem occurred not because of someone's stupidity or malice, but because of undetected flaws in our entire system (processes, tools, knowledge).

An effective "blameless postmortem" typically follows these steps:

Respond Quickly, Solve the Problem

This is the first priority. When an incident occurs, the team's primary goal is to restore service as quickly as possible, not to assign blame.

After a Cooling-off Period, Convene the Postmortem

After the problem is resolved and emotions have settled (usually within 24-48 hours), a neutral facilitator gathers all relevant parties for a postmortem meeting.

Strictly Adhere to "Focus on the Issue, Not the Person"

Focus on "what" and "why," not "who": We discuss "which link in the chain had a problem?" and "why didn't our monitoring alert us in time?" not "who forgot to modify that configuration?"

Use neutral, factual language: Avoid judgmental words like "stupid," "basic," "irresponsible." Use "Engineer A observed slow system response during the operation" instead of "A crashed the system."

Reconstruct the Timeline

Objectively and in detail, list all key events, operations, and communications from before the problem occurred to after it was resolved, in chronological order. This is the basis for analysis.

Dig Deep for Root Causes

Don't be satisfied with surface causes. Peel back the layers like an onion. The classic "5 Whys" method is very effective here.

Problem: Users can't place orders.

• Why? The database connection pool is full.
• Why? A slow query is occupying all connections.
• Why? That query doesn't use an index.
• Why? The newly launched code renders the index ineffective under large data volumes.
• Why? Our pre-launch checklist doesn't include performance testing with large data volumes.

See? The root cause points to a "process" flaw, not an engineer's "mistake."

Produce Actionable Improvement Items

The ultimate goal of the postmortem is improvement. Every root cause found should correspond to one or more specific, actionable improvement items with a clear owner and deadline. For example: "@Owner B, before this Friday, add 'large data volume performance testing' to our pre-launch checklist."

Publish the Postmortem Report

Compile the entire process and conclusions into a document and make it public to the entire team or even the whole company. This not only allows more people to learn from the incident but also demonstrates the team's "transparency" and "shared responsibility" culture through action.

When "blameless postmortems" become the norm, a magical chemical reaction occurs. People are no longer afraid to make mistakes, because they know mistakes are learning opportunities. People become more willing and quicker to expose problems, because they know the team will be their solid support. The initiative and responsibility fostered by this "psychological safety" cannot be bought with any monitoring means.

Practice Two: Promote "Pair Programming" and "Code Review"

In software development, "pair programming" and "code review" are excellent practices that internalize the philosophy of "shared responsibility" into daily work.

Pair programming: Two engineers work together on the same development task at one computer (or sharing a screen through remote collaboration tools). One person codes (driver), while the other observes, thinks, and provides suggestions (navigator).

Its value:

1. Real-time quality assurance: Two brains thinking simultaneously can greatly reduce basic errors and logical flaws. The "navigator" is a real-time, front-loaded "code review."
2. Knowledge transfer: This is the most efficient way to transfer knowledge, standardize coding style, and train new members within the team. A junior engineer pairing with a senior for one day may gain more than a week of solo exploration.
3. Concrete manifestation of shared responsibility: When code is created by two people, "ownership" and "responsibility" are naturally shared. There's no "he wrote this, I don't know" situation.

Code review: Before code is merged into the main branch, it must be reviewed and approved by at least one (or more) other team members.

Its value:

1. Asynchronous quality assurance: It's an asynchronous, lighter-weight alternative to pair programming. The reviewer checks the code's correctness, readability, robustness, and compliance with team norms.
2. Knowledge sharing and context sync: By reading and reviewing others' code, team members can understand the progress and implementation details of other parts of the project, breaking down "knowledge silos."
3. Establishing collective ownership: When a piece of code has been reviewed and approved by you, you bear joint responsibility for its quality. The entire codebase is no longer a collection of "Zhang San's code" and "Li Si's code," but "our team's code."

The core idea of both practices is to shift "quality" and "responsibility" from an isolated, post-hoc individual behavior to a front-loaded, distributed team behavior. They use processes to ensure "no code is not my responsibility."

Practice Three: Encourage "Cross-Boundary Support" and "Coverage Awareness"

In a high-trust team, members do not have rigid "role boundaries." While everyone has their core responsibilities, when the team's overall goal requires you to temporarily play another role, you will step up without hesitation.

When a project faces delays due to a shortage of frontend development resources, a backend engineer who happens to have some frontend experience will proactively offer: "I can help with some of the frontend static page work this week."

When a product manager is sick and cannot attend an important user interview, a designer or QA engineer will take the initiative to conduct the interview and take notes.

When the customer support team is overwhelmed by an unexpected incident, everyone in the team will temporarily set aside their own work to help respond to user inquiries together.

This "coverage awareness" stems from a deep identification with the "community of responsibility." Everyone understands that the team's success is determined not by its longest plank but by its shortest. Helping teammates who are stuck is helping the entire team succeed.

To cultivate this culture, managers need to:

• Emphasize team goals and deemphasize individual KPIs in goal setting.
• Explicitly make "helping others" and "team contribution" an important plus factor in performance evaluation.
• Publicly praise and recognize behaviors that demonstrate "coverage awareness."

"Shared responsibility, shared risk" is not a slogan on the wall. It is a belief that must be internalized into the team's blood through specific, repeated practice. When everyone in the team truly believes from the bottom of their heart that "your failure is my failure, your success is my success," then the indestructible rapport that requires no monitoring will naturally emerge.

Record Keeping: Meeting Minutes and Documents Are the Foundation of Trust

In remote collaboration, most of our interactions occur in digital space. If these interactions are not consciously recorded, they will be like conversations in the wind -- instantly dissipated, leaving no trace.

This "ephemeral nature of information" is one of the biggest corrosive agents of trust.

A heated video meeting results in a series of verbal agreements. Three days later, when everyone starts executing, they find that each person's understanding of the "agreement" is vastly different. Arguments and blame-shifting ensue.

A new member joins the team and wants to understand the historical background and design decisions of a core module. The answer they get is: "Oh, you need to ask Zhang San about that. He built it three years ago." If Zhang San has left, that precious knowledge is lost forever.

You and a colleague have a very valuable discussion about a technical solution in IM. A month later, when you want to review the details of that discussion, it has been buried in the torrent of information, impossible to find.

These scenarios all point to a common problem: most of our knowledge and agreements exist in a fragile, unreliable form of "oral tradition" or "immediate memory."

In remote collaboration, if something is not written down, it is as if it never happened.

Therefore, establishing a rigorous, universally followed "record keeping" mechanism, turning ephemeral "conversations" into permanent "text," is the absolute foundation for building long-term, sustainable trust. The "text" here mainly refers to two forms: meeting minutes and various documents.

They are the team's "second brain" in the digital world. This brain never forgets, never creates ambiguity, and never loses information due to personnel turnover. It is the ultimate accumulation of all the team's consensus, decisions, and wisdom. It is the "single source of truth" we can collectively return to and reference when facing disagreements and uncertainty.

Meeting Minutes: Turning "Sync" Outcomes into "Async" Consensus

In Chapter 1, we mentioned that "synchronous" communication is expensive and should be used judiciously. The way to maximize the lasting value of every expensive synchronous communication is to produce high-quality meeting minutes.

Good meeting minutes are not a verbatim transcript of the meeting. They are a distilled and organized, future-oriented "action plan." They must clearly answer the following core questions:

1. Why did we meet? What is the background of the meeting? What problem or goal did we hope to solve or achieve?
2. What did we discuss? What main points, proposals, and concerns were raised during the meeting? (This part should be concise, not word-for-word.)
3. What consensus did we reach? This is the core part of the minutes. Every decision reached must be clearly listed without ambiguity.
4. What do we need to do next? Every decision must be turned into one or more specific, actionable action items. Each action item must have a clear owner and deadline. This is the key step in turning "consensus" into "action." A meeting without action items is essentially a successful collective waste of time.
5. Who attended? Record attendees for future traceability.

The lifecycle of meeting minutes:

• Before the meeting: Prepare an agenda in advance and create a minutes template. At the start of the meeting, designate a clear "note-taker."
• During the meeting: The note-taker records in real-time. Before the meeting ends, quickly rephrase and confirm the recorded "consensus" and "action items" with all participants to ensure nothing is missed or misunderstood.
• After the meeting: Within a short time after the meeting (e.g., 1 hour), the note-taker organizes the minutes and publishes them in a publicly accessible space (e.g., the team's knowledge base or project management tool). At the same time, @mention all relevant people (including stakeholders who didn't attend) in a public channel to remind them to review.

When "no meeting without minutes" becomes the team's iron rule, you will find that the efficiency and quality of meetings improve dramatically. Because everyone knows that every word they say and every promise they make in a meeting will be recorded in black and white and become the basis for future work. This pressure of "being recorded" encourages everyone to discuss more carefully and responsibly.

Documents: Building the Team's "Knowledge Temple"

If meeting minutes record "point" consensus, then various documents build "surface" knowledge systems. A team's document maturity directly determines the smoothness of its collaboration and the ability to pass on its knowledge.

What should we accumulate as documents? The answer: all information with long-term value that will be repeatedly queried and referenced.

Norms and Process Documents:

1. Team Collaboration Norms: How we communicate, collaborate, and hold meetings.
2. Coding Standards: How we write code, write comments, and conduct reviews.
3. Release Process: How we deploy code to production safely and reliably.
4. Incident Handling SOP: How to respond step by step when an urgent incident occurs.

Design and Decision Documents:

1. Product Requirements Document (PRD): Why a feature is being built, what it should look like, and what the acceptance criteria are.
2. Technical Design Document: What solutions we considered for a complex technical problem, why we chose this one, what the architecture is, and what the potential risks are.
3. Project Postmortem Document: After a project ends, what we did well, what we did poorly, and what lessons can be applied to future projects.

Knowledge and Tutorial Documents:

1. New Member Onboarding Guide: Helps a new member quickly understand the team, set up their environment, and start working.
2. Core Module Deep Dive: In-depth explanations of the principles and implementation of complex, important system modules.
3. FAQ: A collection of frequently asked questions and their standard answers.

The "Document-Driven" Culture:

For documents to truly work, simply "writing" them is not enough. More importantly, they need to be "alive" and serve as the "command center" for daily work. This is what we call the "document-driven" culture.

1. Write documents first, then write code: For any important feature or change, first write a design document to fully discuss and review the thinking process and solution details. The cost of reaching consensus at the document level is far lower than reworking at the code level.
2. Use documents as communication "anchors": In daily discussions, develop the habit of "speaking with document links." Don't say "the plan we discussed last time," but "according to section 3.2 of this design document [link], the plan we agreed upon is..." This ensures all discussions are based on the same, accurate source of information.
3. Maintain documents like code: Documents are not one-off products. They must be continuously updated as the business and system evolve. Outdated, incorrect documents are even more harmful than having no documents. The team should establish a mechanism to make "updating relevant documentation" part of the "Definition of Done" for every task.

Record keeping is an investment. It requires extra time and effort in the present. But in the future, it will repay you and your team tenfold or a hundredfold in the form of "reduced communication costs," "avoided repeated mistakes," and "accelerated new member onboarding."

More importantly, a team with a good record keeping culture has its trust built on solid, traceable "facts," not on fragile, changeable "memory." When disagreements arise, we no longer need to argue about "what did you say then?" We just calmly open the meeting minutes or design document and let the record speak for itself.

This power, based on facts and unspoken, is the most solid ballast of "rapport without monitoring."

Summary: Trust Begins with Agreement, Grows through Shared Responsibility, and Solidifies through Records

In this chapter, we deconstructed the seemingly emotional concept of "high trust" and turned it into a set of actionable engineering methods.

Through ex-ante "expectation alignment" (voting, publicizing work habits), we turned vague individual preferences into clear team consensus, paving the way for rapport to emerge.

Through in-process "shared responsibility" (blameless postmortems, pairing and review), we built a solid team safety net, enabling everyone to dare to expose problems and take responsibility.

Through ex-post "record keeping" (meeting minutes, document-driven culture), we accumulated ephemeral consensus into permanent team wisdom, providing an unshakable foundation for long-term trust maintenance.

These three links interlock to form a positive "trust flywheel." Clear agreements make shared responsibility possible; the practice of shared responsibility continuously generates new consensus and knowledge that need to be recorded; and these solidified records, in turn, reinforce and optimize the initial agreements.

When this flywheel starts spinning, you will find that the anxiety about "monitoring" becomes laughable and unnecessary. Because the team already has a more powerful, endogenous driving system. This system is maintained by every member, guided by clear protocols, and lubricated by deep trust.

In this system, we trust each other not because we can "see" each other, but because we have collectively created and live in a "predictable," "responsible," and "remembered" collaboration world.

This is rapport without monitoring. This is what future teams look like.