祝融说。

In the first eleven chapters of this book, we depicted a collaboration landscape completely different from the traditional office model. It is a world of high autonomy, high trust, async first, and default public.

In this world:

• Team members are no longer "soldiers" waiting for orders, but "special forces" capable of independent decision-making and self-drive.
• Workflows no longer rely on top-down "approvals," but on distributed, consensus-based "protocols."
• Information is no longer "classified" material to be transmitted layer by layer, but a "public resource" open to everyone by default.

As an organization begins to evolve in this direction, a fundamental question confronts every manager: In this "decentralized" collaboration system, what is "my" role? Where is "my" value?

Traditional "commander"-style leadership, based on "industrial era" management thinking, is rapidly becoming obsolete, even an "obstacle" to team development.

• The "commander" leads by issuing orders. They believe they are the smartest and most experienced person in the team, and their duty is to create the perfect "battle plan" for the team.
• The "commander" maintains authority by controlling information. They believe "information is power" and key decisions must be kept in the hands of a few.
• The "commander" ensures execution by supervising the process. They believe "employees are lazy" and must be continuously supervised and assessed to keep them on track.

This leadership model is outright "poison" in a remote team composed of "knowledge workers" that needs continuous innovation and rapid adaptation. It:

• Kills autonomy: When members are used to waiting for orders, they lose the ability to think and solve problems independently.
• Hinders information flow: When information is centrally controlled, it creates decision bottlenecks and communication barriers.
• Destroys intrinsic motivation: When members feel they are not trusted and are constantly under supervision, their work degenerates from a "creative endeavor" into "passive labor."

Therefore, leadership in the remote era needs a complete paradigm shift from "commander" to "gardener."

• The "gardener" does not directly "control" the growth of plants. They know that plants have a powerful, intrinsic vitality.
• The "gardener's" duty is to create the most suitable "environment" for plant growth.
• They set boundaries (the garden fence), ensuring plants don't grow in the wrong places.
• They provide nutrients (sunlight, soil, water), ensuring plants have enough resources to thrive.
• They remove weeds and pests, ensuring plants are not disturbed by the external environment.

The "gardener"-type leader does not pursue personal "heroism." Their highest achievement is not "I led the team to victory," but "I created an environment in which the team achieved victory on its own."

Their work is to "enable," not to "command." Their value is reflected in the team's "growth," not in their own "merits."

In this chapter, we will deconstruct this new type of "gardener" leadership from three levels. We will explore how to "empower" every team member by "weakening" our own decision-making power; we will redefine the three most core and essential responsibilities of a leader in daily work; and finally, we will touch on the soul of a "gardener's" work -- how to create a "psychologically safe space" where trust and innovation can grow freely.

Weakening the Design Group: Empowering Every Member

In many technical teams, there exists an unwritten but deeply ingrained "invisible hierarchy." Within this hierarchy, there are usually one or several senior engineers or architects who form an informal "design group" or "core decision circle."

Members of this "design group," due to their extensive experience and deep technical knowledge, naturally take on the design and review of all important technical solutions. Other team members play more of an "executor" role.

This model has its rationale and efficiency in the early stages of team development, or when dealing with extremely complex problems that require top experts.

However, if this model becomes permanent and the team's only "decision-making paradigm," it becomes like a tree that has grown too large, blocking out all sunlight, preventing other plants underneath from growing healthily.

It creates a "decision bottleneck": All important decisions must wait for the "approval" of those few "core people." Their time and energy become the "ceiling" for the entire team's speed.

It stifles "collective intelligence": Other team members gradually lose the ability to think independently and design complex systems. They become accustomed to "kicking problems upstairs" to the "design group" instead of proactively finding solutions themselves.

It creates "knowledge silos": The most core, complex system knowledge is locked in the minds of a few people. If these people are unavailable due to vacation, illness, or resignation, the entire team may face the risk of "paralysis."

It undermines "ownership": When an engineer can only execute plans designed by others for a long time, they can hardly develop a true sense of "ownership" for the system. To them, it's just "someone else's code," not "our product."

A "gardener"-type leader keenly recognizes the long-term harm of this model. One of their core tasks is to consciously and systematically "weaken" the centralized power of this "design group" and "empower" the ability to "design" and "make decisions" to every team member.

This process is not a one-time "revolution," but a long-lasting "power transfer" that requires patience and wisdom.

Three Strategies for "Empowerment"

Establish a "Design Document" and "Request for Comments" (RFC) Culture

This is the key step to making the "implicit" decision-making process that happens in a few people's minds "explicit" and "democratic."

We have already emphasized the importance of "document-driven" culture. Here, we need to further upgrade it into an "RFC" system.

System requirement: Any change that has a "non-trivial" impact on the system (whether a new feature's technical solution, a plan to refactor an existing system, or a new team collaboration process) must first be written up as a "design document" or "proposal."

Document content: This document must clearly articulate:

• Problem to solve: Why are we making this change?
• Goals and non-goals: What effect do we expect? What is not within the scope of this change?
• Alternatives: What other options did we consider? What are the pros and cons of each?
• Recommended solution: Why do we ultimately recommend this solution? What is its specific design?
• Potential Risks: What known risks might this solution bring?

The RFC process:

1. The document author (anyone on the team, regardless of seniority) publishes the document in the team's public knowledge base.
2. Then, they send an invitation in the team's public channel, @everyone, clearly stating the request for comments: "Hi all, I wrote a technical proposal for the 'New Recommendation System.' Please take some time before [this Friday] to read it and leave your valuable feedback. [Document link]"
3. Over the next few days, all team members are encouraged to engage in async, written discussion and debate in the document's comment section.
4. Ultimately, the author synthesizes all comments, makes the final decision, and records the rationale.

The value of the RFC culture:

1. It shifts decisions from "authority-based" to "argument-based": In the RFC process, the persuasiveness of a viewpoint depends not on who proposed it, but on whether the argument is rigorous and the data sufficient. A junior engineer can completely "challenge" a senior engineer's proposal with a stronger argument.
2. It is large-scale "knowledge transfer": By reading and commenting on others' design documents, team members can learn about the design thinking and trade-offs in other parts of the project. This is an extremely efficient way to break down "knowledge silos."
3. It gives "introverts" and "remote people" a fair chance to "speak up": In traditional meeting discussions, voices are often dominated by those who react quickly or speak well. Written, async RFCs give everyone enough time to think deeply and organize their language, resulting in higher-quality contributions.

Implement "Mentorship" and "Paired Design"

Simply creating a "platform" for everyone to express opinions freely is not enough. For junior and mid-level engineers, they may lack the ability to independently complete a high-quality design document.

The "gardener's" duty is to provide them with "scaffolding" for growth.

Mentorship: Assign each new or junior member an experienced "mentor." The mentor's role is not to "do" the design for them, but to "guide" them in how to do the design.

Before writing the document, the mentor can have a one-on-one "whiteboard discussion" with them to help clarify their thinking.

After the first draft is complete, the mentor can be the "first reader," providing detailed, constructive feedback for improvements.

Paired Design: For more complex projects, try pairing a senior engineer with a junior engineer to "co-design."

They can do the preliminary research and discussion together.

They can co-write and revise the design document.

During this process, the senior engineer can tacitly pass on their thinking process, design principles, and the art of trade-offs to the junior engineer.

Consciously "Delegate" and "Let Go"

This is the most difficult but important test for a "gardener"-type leader: Are you truly willing to "let go"?

Can you tolerate a team member, without your "guidance," making a decision that, while "imperfect," is "good enough"?

Can you tolerate them, in the process of exploration, making some "controllable mistakes" that you yourself once made?

An overly "protective" gardener will cultivate "hothouse flowers" that can never face the wind and rain alone.

Start delegating small: Start with modules or projects that are low risk and have limited scope of impact. Consciously and completely delegate the "final decision-making power" over design to the responsible engineer.

Your role is "advisor," not "approver": In the RFC process, you can and should participate as a regular member, offering your views and suggestions. But you must suppress the urge to use your "positional power" to force through a team consensus.

Publicly "endorse" the team's decision: When the team reaches a consensus through the RFC process, even if this solution differs from your original idea, you must publicly and unequivocally support and defend the "team's decision."

"Weakening the design group" and empowering every member is a slow, long-term "organic" process. Its rewards are also enormous.

What you ultimately get is not a fragile team dependent on a few "heroes."

What you get is a true "living" organization, driven by countless "micro-engines" capable of independent thought and autonomous decision-making, with strong "antifragility" and "collective intelligence."

Your Role: Set Goals, Provide Resources, Remove Obstacles

When a leader has successfully delegated the power of "how to do it" (How) to the team, they can, and must, focus all their energy on three broader, more strategic responsibilities that only they can perform better.

These three responsibilities form the "core three elements" of a "gardener"-type leader's daily work:

1. Set clear, inspiring goals
2. Provide abundant, accessible resources
3. Relentlessly remove obstacles blocking the path forward

Set Goals: Why Are We Climbing This Mountain?

The "gardener" is not responsible for telling every plant "how you should grow." But they must clearly point out "the direction of the sunlight" for the entire garden.

This "direction of the sunlight" is the team's "goal."

A good goal is not a specific "task list," but an inspiring "story" about a "future picture." It answers not "what should we do," but "why should we do these things?" and "what wonderful change will happen in the world when we succeed?"

A bad goal (task list style):

"Our Q4 goal is to: launch feature A, complete the refactoring of system B, and reduce server costs by 15%." (figures are illustrative)

An excellent goal (vision story style):

"In Q3, we successfully enabled 100,000 small and micro businesses to use our product (figure is illustrative). But through user interviews, we deeply felt that they are still struggling with the pain of 'customer churn.'

Therefore, our Q4 mission is to become their 'most trusted growth partner.'

To achieve this mission, we will focus on a North Star metric: 'Help our users reduce their customer churn rate by 10%' (the figure is illustrative).

To achieve this metric, we believe there are three key paths:

1. Through a new 'Smart Retention' feature (Feature A), provide merchants with automated, personalized retention strategies when a customer is about to churn.
2. Through refactoring our 'Customer Profile' system (System B), improve data analysis performance by 5x (figure is illustrative), allowing merchants to understand their customers' real needs in real-time.
3. Through optimizing our infrastructure (reducing costs), we can offer more cost-effective services to small and micro businesses, making 'growth' no longer a luxury for them.

Imagine, at the end of Q4, when we see thousands of merchants retaining their valuable customers through our product and surviving this tough season. How meaningful would that be!"

Compare the difference between these two goal-setting approaches:

The former is a cold, soulless "directive." It only brings "passive execution."

The latter is a warm "calling" full of "meaning" and "imagery." It can ignite the team's "intrinsic motivation" and "creativity."

As a leader, your most important job is to repeatedly polish and calibrate this "goal" with your superiors, your business partners, and your team members. Then, with all your passion and conviction, continuously "preach" and "tell" this "story" in various settings.

When every person in the team has a heartfelt identification with "why we are climbing this mountain," they themselves will come up with a hundred best paths to reach the summit.

Provide Resources: Ensure They Have the Best "Climbing Gear"

Once the goal is set, the leader's second responsibility is to ensure that your "climbers" have all the "gear" and "supplies" they need.

"Resources" here are broadly defined. They include:

Hardware and software resources:

• Do they have powerful enough computers?
• Do they have comfortable ergonomic chairs?
• Can they access all the software and tools they need without barriers?
• For remote teams, does the company provide sufficient "home office setup allowance"?

Information and knowledge resources:

• Is the team's document library well-structured and easy to search?
• Is the new member onboarding process smooth enough for them to quickly obtain all the information needed to start working?
• Do we provide sufficient training and learning opportunities for team members?

People and collaboration resources:

• Is the team's size and role mix reasonable? Are there obvious "people bottlenecks"?
• When the team needs cross-department collaboration, can you help them open doors and build connections?

Time and focus resources:

• This is the most precious and most easily overlooked resource.
• Are you firmly defending the team's "async first" culture, protecting them from unnecessary meetings and instant interruptions?
• Are you helping the team reject the "noise" of irrelevant demands from all directions that do not serve the core goal?

A "gardener"-type leader, like a "quartermaster," always monitors the team's "resource level." They regularly, through one-on-one conversations, proactively ask each of their members: "Is there anything you're missing right now that would help you do your job better and enjoy it more? If so, tell me, and I'll take care of it."

Remove Obstacles: Level the "Boulders" on Their Path Forward

Even with clear goals and sufficient resources, the team will inevitably encounter various "obstacles" on their path forward.

These obstacles might be:

• A complex technical problem that no one internally can solve right now.
• A pending "dependency" with another team.
• A vague, constantly changing "product requirement."
• An unreasonable, rigid "company process."

Or even, an unresolved "interpersonal conflict" between two team members.

The leader's third, and most important, daily task is to become the team's "chief path clearer."

Most of your time should be spent proactively identifying, locating, and removing these "obstacles."

Establish a feedback mechanism for "obstacles":

• In the team's daily stand-up (whether synchronous or async), there should be a fixed segment for members to clearly expose the "obstacles" they are currently facing.
• In one-on-one conversations, you should repeatedly ask: "What is slowing you down? What is frustrating you?"
• Make "resolving obstacles" your highest priority:
  • When a team member throws an "obstacle" your way, it should become the most urgent item in your day.
  • If it's a technical problem, your role is not to solve it yourself, but to help them connect with experts inside or outside the company, or authorize them to seek external commercial solutions.
  • If it's a cross-team dependency issue, your role is to use your "position" and "network" to find the decision-maker on the other team and drive the issue to resolution.
  • If it's a process issue, your role is to escalate to superiors or relevant departments and drive process improvement.

An excellent "gardener"-type leader is obsessed with creating a "flow" experience for their team. They want their team members to be able to focus all their energy on "driving" and "enjoying the scenery," like driving on a well-maintained, obstacle-free "highway," without ever being distracted by "potholes" and "roadblocks" on the way.

Setting goals, providing resources, removing obstacles.

These three things may seem simple, but they contain the deepest understanding of leadership.

It requires the leader to completely abandon their obsession with "micro-control" and position themselves as a "servant."

Your success is no longer measured by "how much you have done," but by "how much your team has succeeded."

This is a more selfless, more challenging, but ultimately more fulfilling realm of leadership.

Creating Psychological Safety: Let the Team Dare to Say "No" and "I Don't Know"

We arrive at the core, softest, yet most powerful part of "gardener"-style leadership -- creating "psychological safety."

"Psychological safety" is a concept proposed by Harvard Business School professor Amy Edmondson. She defines it as: "a shared belief held by members of a team that the team is safe for interpersonal risk-taking. That is, within this team, I will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes."

Psychological safety is the "soil" of a high-trust culture.

Without this fertile, loose, breathable soil, no seeds of "candor," "innovation," or "shared responsibility" can take root and grow.

In a team lacking psychological safety:

• No one dares to say "no" to a seemingly unreasonable plan.
• No one dares to say "I don't know" when encountering technology they don't understand.
• No one dares to be the first to step up and say "this is my responsibility" when a mistake is made.
• Ultimately, the team falls into a terrible "collective silence." On the surface, everything is peaceful, no conflicts. But underneath the silent iceberg, countless risks and problems are breeding wildly.

For remote teams, the importance of psychological safety is multiplied.

When physical distance already makes us lose many "touch points" for building interpersonal connections, if we also lose the "courage" to approach and rely on each other psychologically, then the team truly becomes nothing more than a group of "mercenaries" working independently on their own islands.

So, as a "gardener," how do we sow, water, and protect this precious "psychological safety zone"?

Again, this does not rely on a loud slogan, but on the consistent signals the leader sends through every small word and deed in daily life.

Four Key Behaviors for Creating Psychological Safety

Redefine "Mistakes" as "Learning Opportunities"

This is the most important step. Leaders must, through their own words and actions, repeatedly instill a new "view of mistakes" in the team.

Publicly share your own mistakes and failures:

Leaders must be the first to step down from the "pedestal." Proactively share the mistakes you have made in the past, or even now, in front of the team.

"Team, I want to share a stupid mistake I made last week while planning the Q1 budget. I completely forgot to factor in the increase in cloud service costs, resulting in a big gap in our budget. Fortunately, our finance colleague caught it in time. The lesson I learned from this is..."

When you can so candidly air your own dirty laundry, you send a powerful signal to the team: "Here, making mistakes is normal and allowed. What matters is not avoiding mistakes, but learning from them."

When problems occur, focus on the "system," not the "individual":

The "blameless postmortem" culture we repeatedly emphasized earlier is the best practice to institutionalize this "view of mistakes."

When an online incident occurs, your first reaction must never be "Who did this?" but "Which of our processes or systems allowed this mistake to happen?"

Proactively Show Weakness and Ask for Help

A leader who always appears "all-knowing" and "all-powerful" creates invisible pressure in the team. Members will be afraid to expose their "ignorance" and "vulnerability" in front of them.

Therefore, the "gardener" must learn to proactively show their "imperfection."

Be the first to say "I don't know" in discussions:

When encountering an area you are truly not familiar with, candidly say: "I'm not an expert on this issue. Is there anyone here who knows more than I do? I'd love to hear your thoughts."

Proactively seek the team's help in decisions:

"Regarding our technical direction for next quarter, I have two preliminary ideas, but I'm not sure myself. I want to share both ideas and listen to everyone's, especially the engineers on the front lines, 'feedback.' Please don't hold back. Tell me where my ideas are stupid."

Encourage "Dissent" and Reward "Bad News" Bearers

In a healthy team, "silence" does not mean "agreement." Leaders must, like a tireless "prospector," actively seek out and explore the "different opinions" hidden beneath the silence.

In meetings, directly invite "silent" members to speak:

"Wang Wu, I noticed you haven't spoken on this issue. We would really like to hear your thoughts, especially whether you see any risks we might have missed?"

When someone raises a dissenting opinion, give public, positive affirmation:

"Thank you so much, Li Si, for raising this opposing view! The risk you pointed out is something we completely overlooked. This 'bad news' is incredibly valuable to us. It may have just prevented a major failure."

Establish a "devil's advocate" mechanism: During important decision reviews, designate someone to play the "opposition" role. Their sole task is to attack and challenge the proposal from various tricky angles.

Respond to Team Members' Emotions with "Empathy"

Psychological safety is not just about "work"; it's about "people." Team members are not emotionless "resources." They are "individuals" who get tired, anxious, and frustrated.

A "gardener" must be able to keenly sense the signals of these emotions and respond with warmth and "empathy."

In one-on-one conversations, focus on the "person," not the "task":

Start every one-on-one conversation with an open-ended question: "How have you been lately? Is there anything in your work or life that has made you happy, or troubled?"

When a member shows negative emotions, "empathize" first, then "solve":

When a member complains to you that a project is too stressful:

Bad response (directly offering a solution): "You should manage your time better. Break the tasks down into smaller pieces." Good response (empathize first): "It sounds like you've been under a lot of pressure lately. You must be really tired. I completely understand; this project is indeed very challenging. Can you tell me a bit more about which part is the hardest for you?"

Conclusion: Leadership Is a Never-Ending "Practice"

In this chapter -- the final chapter of this book -- we redefined leadership in the era of remote collaboration.

We see that the role of a leader is transforming from a "commander" standing at the top of the pyramid, issuing orders, to a "gardener" who works humbly within the team.

This transformation is a profound, even painful, "self-revolution" for every manager.

It requires us to let go of our obsession with "control" and embrace a belief in "empowerment."

It requires us to let go of our pursuit of "personal glory" and embrace a commitment to "team growth."

It requires us to drop the disguise of "omnipotence" and embrace the courage of "true vulnerability."

This is a never-ending "practice."

On this path, there are no perfect "gardeners." There are only humble "practitioners" who are always learning, always reflecting, and always striving to create a little bit better soil and a little bit more sunlight for their garden.

And this book, we hope, can be a small, ever-handy "map" and "guide" on your practice path.

The future of remote collaboration it depicts is not an unattainable "utopia."

It is a "new world" that we can reach, as long as we are willing to change our thinking, build our culture, and continuously practice deliberately in every tiny detail of collaboration -- a world that is more efficient, freer, and more humane.

The journey has just begun.

May we all become the brave "builders of the new world" heading into the future.