When you run a fully remote company, the office hallway disappears. There is no one to lean over to and ask, "How do we handle this again?" Every answer that lives only in someone's head becomes a bottleneck, a Slack ping, or a mistake waiting to happen.
I learned this the hard way. As a partner, I helped grow a software consulting company from about $6M to $60M in under three years. Later, I founded and scaled a fully remote software consultancy. In both cases, the thing that separated smooth growth from chaos was not talent or tools. It was whether we wrote things down.
Over time I settled on a simple habit I call the Three-Times Rule. It has shaped how I build teams ever since.
What the Three-Times Rule Is
The rule is simple: if you explain, do, or answer something three times, you write it down.
The first time, you are figuring it out. The second time, you are noticing a pattern. The third time, you are wasting everyone's time, including your own. At that point it stops being a question and becomes a process, and processes belong in a playbook.
It is not a rule about documenting everything. Most teams that try to document everything up front end up with a wiki nobody reads. The Three-Times Rule is a filter. It lets real, repeated work tell you what is worth writing.
Why Remote Companies Need It More
In an office, a lot of knowledge moves by osmosis. New hires overhear how senior people handle a tricky client. Managers catch problems in passing. Context leaks into the room whether anyone plans it or not.
Remote teams do not get that for free. Knowledge only moves when someone deliberately moves it. Add time zones and the cost rises further: a question asked at the end of one person's day may not get answered until the next morning. One unanswered question can stall a task for a full day.
A written playbook turns those blocking questions into self-serve answers. It lets people make good decisions without waiting for permission, which is the whole point of hiring capable people in the first place.
What Belongs in the Playbook
When we started applying the rule seriously, the playbook filled up with a few predictable categories:
- Onboarding. Accounts to set up, people to meet, what "done" looks like in week one. This was the first thing we wrote, because we repeated it with every hire.
- Client delivery. How we kick off engagements, run status updates, handle scope changes, and escalate risk.
- Communication norms. Which channel for what, expected response times, when to write a doc instead of starting a call.
- Hiring. Interview stages, scorecards, and what a strong answer looks like, so every candidate gets a consistent process.
- Decision records. Short notes on why we chose something, so nobody has to relitigate it six months later.
Notice what is missing: long policy manuals and theory. A good playbook is practical. Each page should answer a question someone actually asked.
How to Write Pages People Actually Use
The format matters as much as the content. A few habits made our playbook useful instead of decorative:
Lead with the answer. Put the action at the top. Context and edge cases go below.
Keep pages short. If a page takes more than a few minutes to read, split it.
Use checklists for repeatable work. Checklists are easy to follow, easy to audit, and easy to improve.
Name an owner. Every page has someone responsible for keeping it current. Unowned pages rot.
Link instead of repeating. One source of truth per topic. Duplicates drift apart and create confusion.
Write for the newest person on the team. If a new hire can follow it without asking for help, it is good enough.
Making It a Habit, Not a Project
The biggest mistake I see is treating documentation as a one-time project. Someone spends a month writing a beautiful wiki, then it slowly goes stale because nobody's daily work touches it.
The Three-Times Rule avoids that by making documentation part of the work itself. A few practices helped:
- Answer with a link. When someone asks a question that is already documented, reply with the link, not a retyped answer. This trains everyone to check the playbook first.
- Turn the third answer into a page. When you catch yourself answering something for the third time, write it up right then, even roughly. A rough page beats no page.
- Review during onboarding. New hires are your best editors. Ask them to flag anything confusing or outdated in their first two weeks.
- Make updates part of retros. When a project goes wrong, ask whether a playbook page would have prevented it, and write or fix it.
What It Did for Growth
During fast growth, the number of people who need to know how things work grows faster than the number of people who already know. Without a playbook, your most experienced people spend their days answering the same questions, and they become the ceiling on how fast you can grow.
With a playbook, new people get productive faster, quality stays consistent across teams, and leaders get their time back for the work only they can do. In a remote company especially, I have come to see the playbook as part of the infrastructure, as important as the tools you use to ship code.
It also changes culture in a quiet way. When the rules are written down, they are visible and fair. People can see how decisions are made, challenge what no longer makes sense, and propose improvements. That transparency builds trust across a team that rarely shares a room.
Start This Week
You do not need a big initiative to begin. Try this:
- Open a shared doc called "Playbook."
- For the next two weeks, keep a tally of questions you answer more than once.
- Every time a question hits three, write a short page with the answer at the top.
- Assign an owner and link it everywhere it is relevant.
In a month you will have a playbook built entirely from real needs, and a team that spends less time waiting and more time doing.
If you lead a remote team, I would love to hear what made it into your playbook first. And if you want to talk about building remote engineering teams that scale, you can find me at https://tdzpro.com.
Ashkan
