As I write this title, it is raining outside, and the city is eerily quiet. On my monitor, a cursor blinks behind a file named collaboration-norms.md. This file has no fancy formatting, only plain Markdown syntax. But between its lines are etched all the traces of a team's three-year journey exploring, arguing, trial-and-erroring, and iterating through the uncharted territory of remote collaboration. It is like a weathered nautical chart, recording how we, from our initial storms and lost bearings, gradually found our own course and guiding stars.
This book is the story of that chart.
But please do not misunderstand: this is not a book written only for "remote workers." Remote work has never been the goal; it is a state, a catalyst. It acts like a prism, refracting without reservation all the collaboration "diseases" we took for granted in a traditional office, those hidden by physical space -- vague responsibilities, inefficient meetings, information silos, fake busyness -- leaving them nowhere to hide.
We were forced to think about the most fundamental questions: What is work, really? How is trust built? How do we measure value? Where should a team's "brain" reside?
So, this book truly aims to explore a new way of working. We believe that whether you are in an office, a cafe, or your home study, this model will define the organizational form of the future. It is about autonomy, trust, and a more efficient, more humane way of creating value.
We are not adapting to "remote work." We are embracing the "future" ahead of time.
It is worth clarifying that the work philosophy in this book is not an isolated invention; it is an extension of the RC theoretical system (Process Realism: Observation, Convergence, and the Generation of Determinacy) into the domain of organizational collaboration. The "physical presence" of the office could serve as a cheap substitute for trust and consensus precisely because it converged determinacy through shared observation at a small scale; remote work removes that observational field, so collaboration must explicitly rebuild it -- async-first and default-public are, at their core, moving "observation" from the same time and place into written text and public channels. "Trust is not an emotion but a system of expectations that can be designed, measured, and repaired" corresponds to RC's understanding of trust as a predictable expectation of others' behavior -- a convergent structure that can be recorded and re-examined. And the book's recurring theme, "the best norms are those that can be constantly broken," is the expression, applied to collaboration protocols, of RC's practical principle of "sustainable decision-making -- keeping options present and hedging uncertainty with slack." Readers interested in the philosophical foundation can trace back through this entry point.
The Beginning of the Story: An Internal Collaboration Document That Has Lived for Three Years
It all started in chaos, as all stories do.
Three years ago, our team fully transitioned to remote. At first, we were full of optimistic imagination: no commuting hassles, flexible hours, a free atmosphere. We naively thought that just moving the office workflow online -- replacing hallway chat with instant messaging, and meeting room discussions with video calls -- would make everything run smoothly.
We were wrong. Terribly wrong.
In the first month, problems erupted (the following is a composite narrative, assembled from typical categories of incidents during the team's early transition). A colleague pulled two all-nighters for an urgent feature, only to find that another colleague had already solved the same problem more elegantly two days earlier, just because some "offline catch-up" information was never shared with everyone. A key business decision was "discussed" for three days in a chaotic group chat, eventually fizzling out due to fragmented information and no one following up. An online bug caused a small financial loss. During the postmortem, we discovered that the relevant risk had been mentioned in a private chat window two weeks prior, but that "take a look when you have time" eventually sank into the ocean of messages.
Team morale hit rock bottom. Anxiety spread like a virus. Everyone felt like an island, unable to see others' work, unsure if their own efforts were on the right track. Managers worried about progress, developers about requirements, QA about delivery. We began to miss the office, missed the "security" of being able to confirm something just by turning our heads, missed the atmosphere of everyone sitting together, feeling "present" even in silence.
It was at that breaking point that we made the most simple yet critical decision: say it clearly, then write it down.
We created the first version of collaboration-norms.md. Its initial content was laughably simple, just a few lines:
- All tasks must be created as cards on the board.
- Hold a brief stand-up meeting every Monday morning.
- Self-test before merging any code.
This was less a set of norms and more an act of survival. We were trying, in the most primitive way, to build a few lighthouses in the ocean of information, just so we could see each other's positions.
This document's vitality came precisely from the fact that it was never a "sacred, unchangeable code" from birth, but a "draft" that could be challenged and modified at any time. Every evolution was driven by a real "pain."
The key "commit records" below are composite scenarios distilled from this document's evolution: the dates, people, and details have been typified, but the kinds of "pain" behind each evolution are ones remote teams experience over and over.
"2023-11-16: Added 'Standard Procedure for Production Issue Handling'" The day before this commit, we had suffered a six-hour online outage. Everyone crammed into a single voice channel, information was chaotic, instructions crossed. Some were urgently fixing code, some were pulling data, some were calming customers. Afterward, everyone was exhausted. During the postmortem, we realized the root of the chaos was the lack of a contingency plan. So, we wrote the handling procedure word by word: how to assess the impact scope? Who has permission to modify production code directly? How to sync information after the fix? That procedure was earned through a painful lesson.
"2024-01-03: Clarified 'Role Division' and 'Module Ownership'" As project complexity increased, the classic "too many cooks" dilemma emerged. Some public modules were used by everyone but maintained by no one. A bug in an edge feature was "kicked around" among different people for a week. The discussion was intense; some argued that "everyone responsible equals no one responsible" and ownership must be assigned, while others worried that "module stabilization" would create knowledge silos and single points of failure. Eventually, we reached a compromise, distinguishing between "core modules" and "edge modules," and introducing rotation and review mechanisms. This was our first deep reflection on "ownership" vs. "sharing."
"2024-07-05: Established the 'Everything Gets a Response' communication mechanism" A colleague @mentioned everyone on a document link requiring multi-party confirmation, then went off to other tasks. Two days later, when they remembered, only two people had replied "OK." Others either hadn't seen it or thought "someone else will look." This delayed subsequent tasks. So we agreed: for any request requiring confirmation from others, the initiator is responsible for following it through, and the requested party is obligated to give a clear response (even if it's "busy now, will handle later"). "Everything echoes," these five words later became the cornerstone of our team's collaboration. It represents not a mandate, but a promise: I received your message; I noted your request.
"2024-07-13: Proposed the philosophy of 'Everyone Designs, Everyone Builds'" This was a major leap in our team culture. Before this, we were used to the model where the "design team" produced plans and the "implementation team" wrote code. But an extremely complex project made us realize that this model amplifies communication costs and information loss in a remote setting. Those responsible for implementation didn't understand the trade-offs behind the design; those responsible for design weren't aware of the technical bottlenecks in implementation. So we decided to weaken this division, encouraging everyone to think from a business perspective, to consider "why we do it" and "how we do it." This required everyone to become a "business expert" and also granted everyone greater autonomy.
Like this, the document grew like a tree, constantly sprouting new branches over time. It recorded everything we had ever been confused about, argued over, and eventually reached consensus on: branch management, version releases, commit logs, canary processes, data red lines, task prioritization, boundaries for seeking help... everything.
It was not "decreed" by some high-up manager, but jointly "coded" as a team collaboration system by every soldier in the trenches, line by line, commit by commit, through their contributions. It is "alive" because it acknowledges that chaos is the norm, and provides a set of tools for finding order within it. It does not pursue perfection, only the "good enough" solution for each moment.
This story teaches us: the essence of remote collaboration is not finding the perfect tool, but jointly building an ever-evolving collaboration "protocol." This protocol must be written, public, and maintained by everyone. It is the team's "constitution" in the digital world.
Why Do Office "Best Practices" Fail in Remote Mode?
In the early days of our remote transition, our biggest mistake was trying to rigidly apply the physical metaphors of the office to the digital space. We soon discovered this wasn't just a mismatch; it was like trying to use Newtonian physics to explain the quantum world -- the underlying rules had completely changed.
The office, this workplace we've been familiar with for centuries, relies for its efficiency (or what we thought was efficiency) on a core element: physical presence. Based on "presence," we evolved a set of implicit, fuzzy, yet seemingly effective "best practices." But once the physical space is removed, the foundation of these practices collapses instantly.
The Failure of "Management by Walking Around": From "Presence Sensing" to "Trust Crisis"
In the office, managers like to "walk around." They observe who is working hard, who is in heated discussion, to gauge the team's state and progress. This "presence sensing" provides a fuzzy but reassuring sense of control. Employees also get used to proving their value through "being seen" -- even when they have nothing to do, they stay late at their desks.
In remote mode, this approach completely fails. Managers can't see employees, so their anxiety multiplies. They start inventing digital versions of "walking around": frequently @ing everyone in the group to ask for progress, requiring cameras to be on at all times, even using monitoring software to track mouse and keyboard activity.
This leads to disastrous consequences. Employees feel treated like untrusted "suspects." To deal with the "surveillance," they start performing "being online": frequently sending messages in the group, responding to every message instantly, expending a huge amount of energy proving they are "working" rather than actually working.
The logic of the office: presence ≈ working.
The reality of remote: extending this logic only destroys trust and breeds performative work.
The Illusion of "Information Seepage": From "Water Cooler Consensus" to "Information Silos"
The office has a magical phenomenon we call "information seepage" or "learning by osmosis." You overhear two colleagues discussing a new feature's progress while walking past their desks; you hear about next quarter's plans from a product manager while getting water at the cooler; you learn about a hidden bug in a module from a QA colleague during lunch.
We used to think this was an efficient way of syncing information. But remote collaboration tears off this seemingly warm veil, exposing its true nature: it is an extremely unfair, unreliable, and randomness-prone way of creating information gaps.
In remote mode, there are no corridors, no water coolers. Those communications that relied on "chance" disappear entirely. Information quickly converges on a few core nodes, creating information-rich and information-poor members in the team. Developers who don't know the project background can only execute tasks mechanically; product managers who don't understand technical complexity can only plan requirements in a vacuum. Everyone feels like they're "the last to know."
The logic of the office: consensus can be "naturally" reached through informal communication.
The reality of remote: relying on chance for information sync is the beginning of disaster. Knowledge must be deliberately and structurally recorded and disseminated.
The Trap of "Let's Quick Sync": From "Sync Dependency" to "Efficiency Killer"
"Hey, got a minute? Let's grab a room and quick sync."
This is the "magic bullet" for solving problems in the office. It seems efficient, but hides a huge hidden cost: interrupting others' focus (flow), forcing everyone into the same time rhythm, and reaching conclusions that are often verbal, easily forgotten or distorted.
Bringing this habit online, it becomes "jump on a video call anytime, anywhere." The result: everyone's calendar is shredded by countless "15-minute quick sync" meetings. Most of the day is spent either in meetings or preparing for them. Waiting for half an hour of a key person's time can stall an entire project for half a day.
This over-reliance on "sync" is the biggest killer of remote collaboration efficiency. It assumes everyone's time is a cheap resource that can be interrupted and requisitioned at will.
The logic of the office: the fastest way to solve a problem is to get everyone together.
The reality of remote: sync is expensive, async is the norm. Protecting each member's large, uninterrupted blocks of focused time is the lifeline of the team's overall output.
The Misunderstanding of "Atmosphere" and "Culture": From "Team-Building Driven" to "Co-Creation"
We used to think team culture was built through hotpot dinners, karaoke, and murder mystery games. In the office model, these activities do serve as lubricants, because they are extensions of physical "presence."
In remote mode, we found that online team-building had minimal effect. Awkward online games cannot compensate for the friction and distance in daily collaboration. We gradually realized a brutal truth:
Team culture is not what we do together "when we are not working." It is how we treat each other "when we are working."
Real culture is reflected in:
When you ask a seemingly stupid question, are you encouraged or ridiculed?
When your code has a bug, is the first reaction to assign blame or to solve the problem together?
When you disagree with a decision, do you have a safe channel to express it?
Do we share a common standard for what is "good" vs. "bad," "important" vs. "secondary"?
The answers to these questions form the core of team culture. And these, precisely, need to be shaped through the joint construction of a clear, fair, and transparent "protocol" in daily collaboration.
The logic of the office: culture is a "soft" build outside of work.
The reality of remote: culture IS our way of collaborating, the "collaboration norms" we jointly write and follow.
Therefore, the failure of remote collaboration is often not due to a missing magical software or lack of offline team-building. It is because we stubbornly use the logic of managing "bodies" to manage "minds"; the logic of managing "presence" to manage "output." This is a complete "decoupling" -- work itself is being liberated from physical space. We need a complete "format" of our thinking, a reexamination and refinement of all past "best practices." It is difficult, but it is the only path to the future.
The Promise of This Book: From Chaos to Rapport, From Surveillance to Trust
By now, you might feel a bit heavy, even anxious. Yes, remote collaboration -- or the future way of working -- is no smooth road. It demands far more than we imagine.
But believe me, it is also a path to a higher realm. It leads to a collaborative paradise with less performance, more substance; less friction, more creation; less surveillance, more trust.
This book cannot give you a "one-size-fits-all answer" to copy and paste. Every team's DNA is different, and the problems you face vary widely. If we tried to offer a universal "silver bullet," that would precisely violate the most important lesson we learned in the past three years: the best norms are those that can be constantly broken and reshaped.
So, this book does not promise a perfect map. It gives you the tools and principles to draw your own map. It will help you and your team embark on your own journey of building a "collaboration norms" system.
What will you gain from this book?
A Framework for Mental Shift
We will start from the most fundamental logic, helping you and your team complete the shift from "office thinking" to "future-of-work thinking." We will dive deep into core concepts like async-first, default public, trust as currency, and output orientation. This is not just terminology replacement; it is a complete cognitive upgrade. You will understand why protecting large blocks of focused time is more important than "instant replies," why a detailed document is more valuable than a heated meeting.
A Methodology for Building Three Pillars
We distill the core of this book into three pillars that support the future work model: High Autonomy, High Trust, High-Quality Delivery.
High Autonomy means exploring how to make everyone in the team an engine, not just a screw. We will provide concrete methods for setting clear boundaries, self-managing priorities, and transitioning from executor to responsible owner.
High Trust means exploring how to build unbreakable rapport when you cannot see each other. We will share practical experience in aligning expectations, sharing risks, and keeping effective records, so you understand that trust is not an emotion but a system that can be deliberately designed and maintained.
High-Quality Delivery means exploring the bottom line of freedom -- responsibility. We will share without reservation our painful lessons and valuable experiences regarding "reverence for production," "data red lines," and "failing early," helping you build a system that ensures the quality of final output, even in a fully autonomous environment.
A Ready-to-Use Collaboration Toolkit
Principles must eventually land. In Part Three, we will dissect that collaboration-norms.md file and present a complete collaboration toolkit. There are no software recommendations here, only processes and methods. From the lifecycle management of tasks, to the collaborative language of engineers' code; from anomaly handling in canary environments, to emergency fixes in production; from defining the boundary between business and technology, to getting new members quickly integrated. These are all concrete, proven "methods" tested through practice. You can use them directly or adapt them to your team's situation.
A Continuously Evolving Organizational Capability
Finally, and most importantly, this book hopes to give you and your team a "living" capability -- the ability to continuously diagnose, repair, and evolve yourselves. We will explore how to repair trust when it collapses, how leadership should change in future organizations (from commander to gardener), and how to build a "second brain" (knowledge base) so that organizational wisdom can be deposited and passed on.
What this book does NOT promise?
It does not promise ease. Building a culture of trust and autonomy is much harder than mere supervision. It requires managers to let go of control, and every member to take on greater responsibility. This is a road less traveled, but the views are unique.
It does not promise quick fixes. This is not a "magic book" that will boost your efficiency overnight. Building culture takes time; implementing norms requires adjustment. It is more like a marathon coach than a shot of adrenaline.
It does not promise permanence. All the cases and methods in this book are only our current "optimal solutions." By the time you read this, our internal norms may have already iterated several times. We encourage you to read critically, to challenge, to question, and ultimately find your own answers.
To You in the Future
This book is written for all explorers who are dissatisfied with the status quo and hopeful for the future.
Whether you are a manager struggling with team collaboration, or a professional eager to create value in a freer, more trusted environment; whether you are a founder thinking about how to build your company's cultural moat, or a researcher curious about future organizational forms.
We believe you will find resonance and inspiration in this book.
Three years ago, we embarked on this journey of exploration in utter chaos. We thought we were solving the problem of "remote work," but only now do we realize: we were actually rehearsing a much grander transformation. This transformation is about the nature of work, the form of organizations, and, most of all, about how each individual within it can create with more dignity, more value, and more freedom.
We firmly believe that in the future of work, the core competitive advantage will no longer be strict processes or powerful tools, but a culture based on high autonomy and high trust that attracts and retains the best talent. In such a culture, everyone can unfold more of their potential, and the team's creativity grows with it -- by how much depends on the health of the culture itself, and this book makes no promise about magnitude.
This is what we call the "future."
Now, take a deep breath and turn to the next page. Let us begin this journey to the future, starting with that rough but real collaboration document.
This journey begins in chaos, ends in rapport; begins in surveillance, ends in trust.
Welcome to the future.