祝融说。

When you flip to the last page of this book, your mind may be filled with all kinds of "norms," "processes," "best practices," and "playbooks."

From the communication philosophy of "async-first," to "one task, one branch" for code management; from the "SBI-I" feedback model to "blameless postmortem" meeting rituals; from building a "second brain" for knowledge retention to "meta-collaboration" for regularly iterating on how we work together... It seems we have spent thirteen chapters carefully weaving a vast and intricate "web of collaboration."

This web aims to capture every elusive piece of "uncertainty" in remote collaboration. It tries to provide a clear, followable "optimal solution" for every collaboration scenario. It promises that as long as you follow this "map" strictly, you will safely arrive at the shore called "efficiency" and "harmony."

And yet, here at the end of the book, I want to invite you to do something that seems "self-contradictory":

Maintain a deep, never-fading "skepticism" toward everything you have just learned.

Remember that the ultimate, highest value of all the "norms" we have built in this book is precisely that they "can be broken" and "need to be broken again and again."

The best norms are those that can be broken again and again.

This sounds like a paradox. But it contains the deepest secret about organizational evolution and human creativity.

The First Half of Norms: From Chaos to Order

Let us first return to the "positive value" of norms.

A team in its "childhood" is most notably characterized by "chaos."

Communication is casual.

Decisions are intuitive.

Processes are non-existent.

Knowledge is scattered across individual minds.

When a team has only three or five people, this "chaos" can even take on a charming quality. It is filled with the warmth of "brotherhood" and "family workshop." Everyone relies on a high degree of tacit understanding and frequent, informal communication to miraculously get things done.

However, as the team grows and business complexity increases, this "chaos" quickly turns into a disaster.

Communication costs rise rapidly, out of proportion to the growth in size.

Decision quality plummets.

The same mistakes happen over and over.

Newcomers struggle to integrate.

At this stage, introducing "norms" is a necessary "rite of passage" from "chaos" to "order."

It is like conducting the first "urban planning" for a city that is growing wildly.

We build roads (communication channels) so that the traffic of information can flow smoothly across every corner of the city.

We set up traffic lights (collaboration processes) so that different tasks can meet, cross, and pass through intersections in an orderly manner without colliding.

We build libraries and museums (knowledge bases) to deposit the city's history, culture, and wisdom for future generations to learn from and admire.

This "from zero to one" process is crucial. It provides an organization with the foundation for "scalability" and "predictability." It frees the team from reliance on "individual heroism" and shifts it toward trust in a "robust system."

Most of this book provides you with detailed "blueprints" and "construction manuals" for completing this "urban planning."

But if we stop here, if we regard this meticulously planned "city of order" as our ultimate "utopia," then a new, more insidious enemy will quietly breed in the city's shadows.

This enemy is called "rigidity."

The Second Half of Norms: Beware the Tyranny of Order

Once any "order" loses its "elasticity," it transforms from an "enabling" tool into a "shackling" cage.

Once any set of "norms" is enshrined as unshakable "scripture," it degenerates from "best practice" into a breeding ground for "bureaucracy."

We call this "the tyranny of order."

Under this "tyranny":

"Following the norms" becomes a more important goal than "solving the problem."

People will spend a great deal of time arguing over whether the format of a Commit Message fully complies with the norms, while forgetting to think about whether the Commit itself is creating real value for the user.

When an urgent online incident occurs, people might miss the best window to "stop the bleeding" because they are afraid of "violating" the established "emergency fix process."

"Norms" become a "refuge" for "intellectual laziness."

When faced with a new, unprecedented challenge, the first reaction is no longer "How can we creatively solve this problem?" but "Which existing process from the knowledge base should we apply?"

Norms should be the "starting point" for our thinking, but under the "tyranny of order," they become the "end point."

"Challenging the norms" is seen as "heresy" and "offense."

If a new member, based on experience from a previous company, questions a "sacred" process currently in use, they may receive not curiosity and discussion, but a cold, defensive response: "We have always done it this way."

In such an atmosphere, the organization loses its most important "metabolic" ability to absorb new ideas and energy from the "outside" and the "margins."

A team ruled by the "tyranny of order" may still appear orderly and methodical on the surface.

But inside, it has lost its "vitality."

It is no longer a "living" organism that can adapt to change.

It has become a rigid "fossil," slowly weathering away.

So, how can we enjoy the "efficiency" and "stability" brought by "order" while avoiding falling into the abyss of "rigidity"?

The answer lies in the title of this epilogue:

We must embed "breaking norms" as a "norm" itself into our "collaboration operating system."

Meta-Norms: Institutionalizing "Breaking"

A truly "living" organization, in addition to a set of "operational norms" about "how to do things," must also possess a higher-order "meta-norm" about "how to treat norms."

This "meta-norm" can be expressed as three core principles:

Principle One: All norms must be "conditional," not "absolute"

This means that when writing and understanding any norm, we must mentally attach a "contextual" qualifier to it.

That qualifier is: "Under the conditions of..., we believe this is the current optimal solution."

For example, our norm that "code review must be approved by at least two people" should be fully expressed as:

"Under the current conditions where our team size is 30 (an example) and we prioritize high-quality delivery over extreme speed, we believe that 'code review must be approved by at least two people' is the optimal solution for preventing individual mistakes and ensuring code quality."

When we view norms with this "conditional" mindset, we naturally gain the legitimacy to "break" them.

Because once the "condition" that served as the "premise" changes, the norm should be reexamined and challenged.

If one day our team needs to incubate a new, fast-iterating innovation project measured in "weeks," then under this new "condition," does the "two-person review" norm become an unnecessary "bottleneck"? Could we establish a temporary "exemption clause" for this small team, such as "one-person review is sufficient for merging"?

Principle Two: Encourage "constructive destruction" based on "first principles"

"Breaking norms" does not equal arbitrary "anarchy."

It must be a disciplined, responsible "constructive destruction" aimed at "creating a better new norm."

And this "constructiveness" comes from returning to "first principles."

When you want to "break" an existing norm, you cannot simply say, "I think this norm is too troublesome."

You must, like a scientist, return to the original "problem" and "goal" that gave rise to this norm, and then use more rigorous logic and sufficient data to argue why your "new method" can better achieve that "original goal" than the "old method."

Scenario: The team has always had a norm: "All technical decisions must go through a written RFC process."

A "disruptor" appears: They find that for moderately complex decisions with tight time windows, going through the full RFC process is too slow.

Their "constructive destruction" plan:

1. Return to first principles: They first think about what the "first principle" of establishing the RFC process was -- to make the decision-making process "transparent, traceable, and able to gather enough collective wisdom."
2. Propose a new hypothesis: They then propose a new hypothesis: "For tasks that affect no more than three services and have a development cycle within two weeks, can we adopt a lighter 'mini-RFC' process?"
3. Design a new experiment: They concretely design the template and process for this "mini-RFC." It might only require a brief document and a 24-hour, small-scope asynchronous comment period.
4. Initiate a system change: Finally, they write up their proposal itself as an RFC, requesting comments from the entire team. If the proposal ultimately gains consensus, the team's "Technical Decision-Making Norms" document gets updated. A new, more flexible "branch" has grown from the old "trunk."

This is the power of "constructive destruction."

It is not a negation of "order."

It is the most powerful "internal engine" driving "order" to evolve and improve itself.

Principle Three: Provide a safe "experimental plot" for "breaking norms"

A good gardener, besides carefully tending the plants in the main garden, also sets aside a small "experimental plot" in a corner.

In this plot, they can try entirely new, unproven, even somewhat "crazy" cultivation methods.

They can graft a variety that has never existed before.

They can test a brand-new fertilizer formula.

They can break all traditional rules about "plant spacing" and "row spacing."

The existence of this "experimental plot" is crucial.

Because it provides a space for "safe failure" for innovation.

Failure in the "experimental plot" is cheap, even worth celebrating. Because each failure eliminates one wrong answer, bringing us one step closer to the potentially better "new method."

In team collaboration, we must also consciously create such "experimental plots."

Small-scale piloting: When someone proposes a disruptive "new idea" for an existing collaboration process, do not rush to roll it out to the entire team. First, pilot it in a small team or an independent project for a month.

Hackathon culture: Regularly hold hackathons, not just to create new "product prototypes," but also to "hack" our existing "collaboration processes." You can set a theme: "In the next 48 hours, organize your team in whatever way you think is most efficient and cool to complete a challenge. You can ignore all existing company processes and norms."

Failure celebration: We should hold celebrations not only for "successful" projects, but also for those "experiments" that made a brave attempt but ultimately "failed gloriously." What we celebrate is not the result of "failure," but the courage of the team to "try" and "take risks" itself.

Conclusion: Become a Dancer Who Dances Gracefully on the Edge of "Order" and "Chaos"

Writing this, we seem to have come full circle.

We started from "chaos," used "norms" to reach "order."

Then, at the boundary of "order," we re-embraced the uncertainty of "chaos" and the infinite "possibility" it contains.

This is perhaps the ultimate, most fascinating form of remote collaboration, and indeed all human creative activities.

It is not a static, perfect "endpoint."

It is a dynamic, never-ending "process" of finding the best balance between the two poles of "order" and "chaos."

A great remote team is like a highly skilled "dancer."

Their body has internalized thousands of hours of rigorous "norm" training in "basic steps" and "classic routines." This is the foundation of their "order."

But on stage, when the music starts, they forget all the "norms." They surrender their mind and body to the "chaos" of the present moment, improvising unprecedented, breathtaking movements.

This book, we hope, can be a useful "textbook" for you as you learn those "basic steps."

But we hope even more that when you close this book and return to your own "stage," you will have the courage and wisdom to completely "forget" it.

Go create your own unique "dance steps" with your team.

Go boldly break those "old norms" that no longer serve you.

Go bravely explore the "new continents" on the edge of "chaos" that have yet to be discovered.

Because the future of remote collaboration — no, the future of all human collaboration — is not in any book already written.

It exists only in the never-ending, creative "dance steps" of you, the brave "dancers."

Go dance.