Introduction

A handbook-first approach to documentation is sneakily vital to a well-run business. While it feels skippable — inefficient, even — the outsized benefits of intentionally writing down and organizing process, culture, and solutions are staggering. Conversely, avoiding structured documentation is the best way to instill a low-level sense of chaos and confusion that hampers growth across the board.

Roivant IT is intentional about documenting in a manner that creates a single source of truth. It operates handbook-first, and in valuing transparency, makes its handbook publicly accessible to the entire enterprise.

Why handbook first

In a scaling and frequently changing environment, tribal knowledge, undocumented processes and simple undeclared habits can generate tremendous risk to the stability of an organization. Silos build around isolated knowledge, stealth habits and single points of failure. By committing to maintain a holistic body of material that represents an entire organization and how it functions, the organization’s processes and work is made transparent and accessible to the entire company.

This process is not unlike writing tests for software, which are commonly done before the software is even written. Only communicate a (proposed) change via a change to the handbook; don’t use a presentation, email, chat message, or another medium to communicate the components of the change. These other forms of communication might be more convenient for the presenter, but they make it harder for the audience to understand the context and the implications for other potentially affected processes.

Having a “handbook first” mentality ensures there is no duplication; the handbook is always up to date, and others are better able to contribute.

Documenting in the handbook before taking an action may require more time initially because you have to think about where to make the change, integrate it with the existing content, and then possibly add to or refactor the handbook to have a proper foundation. But, it saves time in the long run, and this communication is essential to our ability to continue scaling and adapting our organization.

Terminology (documentation, handbook-first, single source of truth)

While the term documentation often refers to the process of writing something down after a given event, this page details a more meaningful approach. Documentation should occur first, in a structured and organized way, before being disseminated. (E.g. Document the solution first, then announce via Slack or email.)

The goal isn’t to create a culture of documenting for the sake of documenting; rather, to create an environment where net new solutions are documented in a universally accessible handbook before dissemination, and iterations are made to the organizationally recognized single source of truth. Each team member must approach documentation the same way, much like an editorial team adheres to a style guide.

Why does handbook-first documentation matter?

In early-stage startups, it’s particularly tempting to avoid a documentation strategy. With only a few team members, it’s feasible to keep everyone informed via meetings, Slack, or email threads. Long-term, this oversight becomes increasingly harmful.

As a team scales, the need for documentation increases in parallel with the cost of not doing it. Said another way, implementing a documentation strategy becomes more difficult — yet more vital — as a company ages and matures.

Documentation is rarely placed on the same pedestal with metrics such as sales and client retention during a company’s formative years, but it deserves to be. The difference between a well-documented company and one that eschews a handbook is stark.

A handbook-first organization is home to team members who benefit from having a single source of truth to lean on. This type of organization is able to operate with almost supernatural efficiency. An organization that does not put concerted effort into structured documentation has no choice but to watch its team members ask and re-ask for the same bits of data in perpetuity, creating a torturous loop of interruptions, meetings, and suboptimal knowledge transfers.

Start now

It’s important not to let hindsight thwart progress in the here and now. While an ideal time to begin a company handbook is at inception, the next best time is today.

Don’t get overwhelmed

There’s a very real fear that committing to a handbook, and instilling a culture of documentation, is too tall a task to actually accomplish. The goal should not be to complete the handbook before ever announcing its existence to the company.

For established organizations, the trick is to apply iteration to the challenge of standing up a handbook within a company. Put the proper infrastructure in place (which we’ll cover below), and begin documenting process after process, one at a time. Building a handbook well after a firm’s infancy is tough, as you’re changing both process and culture while operating a business at scale. However, leaders can manage expectations to make the handbook’s insertion easier to grok.

Documentation is never finished

Handbooks, and the documentation that creates them, are never finished. They are evolving, living entities, and it may take months or years to feel even remotely comprehensive.

Resist the urge to abandon documentation plans when crisis hits. The most powerful documentation is that which is derived from failure. A lesson learned provides a vital roadmap of what to avoid, and how to operate better, in the future.

Tools for building a handbook

A common belief is that a company wiki can serve as a handbook, but the reality is that internal wikis are dead.

• Content frequently falls out of date, which triggers a orgwide belief that the information cannot be trusted without personally confirming with another human (and in turn, injecting inefficiency into the * process of self-learning).

• Wikis are highly siloed - They do not support proposals which touch or update multiple parts of multiple pages. This is like a field of thousands of tiny silos, each with its own history and its own versioning.

• Wikis are feature-constrained - in terms of look, feel, behavior and content, teams are bound by the features of the app, or must spend undue amounts of time working around these constraints.

• Almanac is an excellent tool for organizations building their first handbook. It allows you to pull in expert guides from other companies (GitLab included) and modify to suit your company. This shortens the time between acknowledging that a handbook is necessary and having a minimum viable product available for your team to reference and iterate on.

Empower the entire team to evolve the handbook

One critical function of treating a handbook as code is that we split the role of submitter and approver. Anyone can propose changes, but the owner of the specific page must approve and adopt these changes. There is no harm in opening your handbook up to proposals, as code owners and DRIs (directly responsible individual) are ultimately responsible for reviewing each proposal and merging or editing and merging.

This enables anyone in the organization, even those who have just joined, to propose changes and feel immediately invested in a organization’s culture of documentation.

Creating a home for a single source of truth (SSoT)

The beauty of using source code techniques to build and evolve an organization handbook is that it prepares a framework for company-wide adoption, but you don’t have to have the full table of contents mapped out in advance. There is no better technique to driving adoption of processes in an enterprise than by demonstrating them, and their effectiveness - but one can prepare for adopters.

Make handbook-first documentation a value

The trick to ensuring a handbook grows continually is to instill it as a value. Team members should recognize that any answer or solution that isn’t yet documented, should be documented immediately.

Write things down is a sub-value of Efficiency in Roivant IT.

Empowering the entire organization to propose changes creates widespread autonomy and agency. This generates a shared responsibility to maintain the pace of documentation through a pay-it-forward mentality.