Somewhere in the middle of the 2010s, a handful of distributed software companies did something that looked like a marketing stunt and turned out to be an operating decision: they published their internal handbooks on the public internet. How they hired, how they paid, how decisions were made, how disagreements were resolved, what the onboarding sequence was, what the meeting norms were. Thousands of pages, versioned, editable by employees, and readable by competitors and candidates alike. The companies doing it were remote-first by design rather than by circumstance, and that is the part that explains the behaviour. A co-located organisation transmits its operating model through proximity — you learn how things work by sitting near people who already know. Remove the office and that transmission mechanism disappears. Something has to replace it, and the only thing that scales across time zones and hiring waves is writing. The handbook was not a culture document. It was the substitute for the hallway.
Why writing becomes load-bearing
In a distributed organisation, three things break first, and all three are solved by the same discipline. Onboarding. A new joiner in a co-located team absorbs context by observation over weeks. A new joiner working remotely, possibly seven hours offset from their manager, cannot. Either the context exists in writing or the person spends three months guessing, and the cost of that guessing is paid by everyone who has to answer the same questions repeatedly. Decision-making. Synchronous decision-making requires overlapping hours. When overlap is two hours or zero, decisions must be made asynchronously, which means the proposal, the reasoning, the alternatives considered and the outcome all have to be written down. Teams that skip this default to deciding in whatever meeting the available people could attend, which reintroduces a proximity advantage — now held by whoever shares a time zone with the decision-maker. Consistency. Without a documented process, every manager invents their own, and in a distributed company nobody notices the divergence until compensation, promotion or performance decisions start producing visibly different outcomes for comparable people. The handbook addresses all three by making the operating model an artefact rather than folklore. The public publication is secondary — useful for recruiting and for accountability, but the mechanism works whether or not anyone outside can read it.
What makes a handbook work
Most organisations that try this produce a document that is out of date within a quarter and ignored within two. The ones that persist share a small number of structural choices. Single source of truth, enforced. If a policy exists in the handbook and also in an email, a slide deck and someone's memory, the handbook loses. The discipline is to answer questions with a link rather than with prose, and to fix the handbook when the link is inadequate. This is the behaviour that keeps it alive; everything else is secondary. Anyone can propose a change, through a visible process. The handbooks that stayed current were editable by employees through the same review mechanism the engineering teams used for code. Centralised ownership by a communications or HR function produces a document that is accurate about policy and useless about practice. Named owners per section. Not a committee. A person whose responsibility includes the accuracy of that page. Decisions recorded with their reasoning. The single highest-value content in a mature handbook is not the current policy but the record of why it is what it is — what was tried, what failed, what the trade-off was. This is what prevents the organisation relitigating the same argument every eighteen months as people turn over. Ruthlessness about deletion. A handbook that only grows becomes unnavigable, and an unnavigable handbook is functionally the same as no handbook. Content that describes a process nobody follows is worse than absent, because it destroys trust in everything adjacent to it.
Start with repeated questions
Document real approvals, onboarding and escalation paths.
Own and review the page
Name an accountable editor and allow visible change proposals.
Answer with the record
Link to the page, fix gaps and retain decision reasoning.
Retire stale material
Remove or mark superseded rules and keep policy distinct from practice.
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Practical Guidance for Remote Operating Handbook Design
- Start with the questions people actually ask repeatedly. Onboarding, expenses, leave, approvals, escalation, how to get a decision made. Write those first; the values statement can wait indefinitely.
- Put the handbook where work happens, not in a separate portal. Adoption is a function of proximity to the tools people already have open.
- Give every page a named owner and a review date. Unowned documentation decays silently, and silent decay is what kills the whole artefact.
- Answer questions with links and fix the page when the link falls short. This one habit, practised by managers, is what keeps a handbook current; nothing else substitutes for it.
- Record decisions with the reasoning and the alternatives rejected. Future arguments are settled by this section, and new joiners learn more from it than from any policy page.
- Write for someone with no context and no shared time zone. Assume the reader cannot ask a follow-up question today.
- Delete aggressively and date everything. Stale content is the primary reason people stop trusting internal documentation.
- Separate policy from practice explicitly. Where the real behaviour differs from the written rule, document the real behaviour or change the rule — pretending otherwise teaches everyone to ignore the handbook.
The Regional Dimension
Remote-first operating models arrived in the Gulf with three local constraints that the published handbooks of distributed technology companies do not address. The first is employment structure. Residency is tied to employment and to the entity that sponsors it, which makes "hire anyone anywhere" substantially harder than it is for a company operating through contractor arrangements in liberal labour markets. Regional groups that wanted distributed teams generally ended up with multi-site teams instead — Dubai, Riyadh, Cairo, sometimes Amman or Karachi — each with its own entity, labour rules, payroll mechanics and public holidays. That is a distributed organisation in every operational sense, and it needs the same written operating model, but the handbook has to be explicit about which rules are group-wide and which are entity-specific. Leave entitlements, end-of-service gratuity, working hours and notice periods are not group policy; they are per-entity facts. The second is the calendar. Weekend days differ across the region and have changed within living memory, working hours shorten during Ramadan, and holiday calendars are partly lunar and announced with short notice. A handbook written on an assumption of Monday-to-Friday overlap fails quietly. The organisations that handle this well publish the actual overlap windows per site, define which meetings require synchronous attendance and which do not, and set expectations for response times in local working hours rather than in absolute hours. The third is the channel problem. A very large share of regional business communication happens on consumer messaging apps, which is the exact opposite of a written, searchable, single-source operating model. Decisions made in a group chat are invisible to anyone not in it, unsearchable six months later, and lost entirely when the person who held the context leaves. Given regional turnover rates, that loss is frequent and expensive. The realistic response is not banning the channel but defining which categories of output must land in the handbook or the record — decisions, approvals, process changes — and treating the chat as the conversation rather than the record. Two further local notes. Bilingual documentation is a genuine question rather than a courtesy: where a substantial part of the workforce operates primarily in Arabic, an English-only handbook excludes the people whose work it governs, and partial translation that drifts out of sync is worse than a clear decision about which sections are authoritative in which language. And a large proportion of regional employment is frontline and site-based — retail, logistics, construction, hospitality — where remote work is not the question at all. The handbook discipline still applies to those operations; the delivery format has to be mobile and short rather than a long web document.
The objection worth taking seriously
The strongest criticism is that public handbooks were recruiting marketing dressed as operational transparency, and that the companies best known for them were not straightforwardly better places to work. Some of the published material was aspirational rather than descriptive — a statement of how the organisation wished it behaved, which every employee could see it did not. That gap is corrosive in a way that having no handbook is not, because it makes the written record demonstrably unreliable and gives people a reason to distrust the rest of it. There is also a fair point about written culture as a filter. Heavy documentation norms advantage confident writers in the dominant working language and disadvantage people who think out loud, work in a second language, or come from professional cultures where decisions are made in conversation. "Write it down" is not neutral; it changes who has influence. And over-documentation is a real failure mode. Thousands of pages nobody reads, maintained by people who could be doing the work, is bureaucracy with better formatting. What survives is narrower and still valuable. Organisations with any geographic spread need their operating model in writing, owned, current, and accessible — not because it is fashionable, but because the alternative is folklore that departs with whoever held it. The handbook should be as small as it can be while answering the questions people repeatedly ask, and it should be honest about what actually happens rather than what was intended. Publishing it externally is optional and mostly a recruiting decision; publishing it internally and keeping it true is the part that does the work.
Common Questions
How long should a handbook be?
As short as possible while covering the questions people ask more than once. Length is not the measure of quality; currency and findability are, and both degrade as volume grows.
Who should own it?
Distributed ownership by section, with named individuals accountable for accuracy and a light review process anyone can use to propose changes. Central ownership by a single function produces a document that is correct about policy and disconnected from practice.
Should we publish it publicly?
Only if you are prepared for the written version to be held against you. External publication is a recruiting and accountability tool with real benefits; the operating value comes from having the handbook at all, not from who can read it.
How does AI change handbook practice?
It raises the return on having one and raises the cost of having a bad one. Assistants and internal search retrieve from your written material, which means a current, well-structured handbook makes every AI answer better and a stale one industrialises the propagation of wrong information — confidently, at scale, to people with no way to know. The practical implications are specific: date and own every page, mark superseded content as superseded rather than leaving it in place, and expect that policies buried in chat threads and slide decks will now be found and quoted. AI also lowers the cost of maintenance, drafting, summarising and translating sections, which removes the most common excuse for letting documentation rot.
Remote Operating Handbook Design — the handbook is not a culture artefact, it is the replacement for the hallway, and it only works if managers answer questions with links instead of prose.