About the Handbook

Nikki Munson



The Cantilever handbook is a living library that explains how we do things at Cantilever. It is our “Operating System” at Cantilever.

If an alien species of talented designers and developers found our handbook, they should be able to run a great remote agency.

The handbook is public and shared at handbook.cantilever.co. This is to make it easy for anyone to learn about our company, and promote our belief of “trust and independence.”

We want our philosophies to be publicly accessible in the hopes that other people will find and learn from them. We would be honored to be a part of changing the culture of work.

Updating The Handbook

The handbook is a living document and we should expect to change it often during our day-to-day workflow. At the same time, our processes are shared by many people, and when significant changes are made, it is important for those changes to have backing from the team and visibility to everyone affected.

Ultimately the Handbook is an artifact that codifies underlying practices and philosophies that exist at Cantilever. It can fall behind if those practices and philosophies change.

If you notice a difference between the Handbook and our actual existing behaviors/philosophies, we should update the handbook.

Quick Updates

Please make an immediate change to the handbook if…

  • You notice something wrong (typo, information that is obviously obsolete, etc)
  • You notice something missing that you are positive is a consensus approach at Cantilever (for example, if a page mentions a tool we no longer use, please update it to the new tool we use instead)
  • You are the owner of a particular company function (Finance, Sales, etc.) and you notice that there is something inaccurate about the handbook section for that function. This might allow you to make a larger update without passing it through a process change proposal.

Major Updates

If the change is more significant, please add it as a task to the Handbook Asana project and ask the PM of that project to get it into the queue.

Any significant Handbook-related work (>30 minutes) should be approved by Ops, assigned and tracked in the Handbook Asana project for visibility, even if you are assigning it to yourself.

When we are missing a page to cover a significant aspect of how we work or a function we fulfill, we need a new entry. These are rare, as we have had the handbook for several years. If you are working on a totally new entry, please ensure that it is clearly marked as “WIP”, and get approval from the relevant internal team members before removing that tag.

Formatting Standards

Pages should generally be 10 minutes of reading maximum.

They should use standard notion formatting and spacing. Please avoid unusual styling or design that does not appear anywhere else in the handbook.

Time Usage

Handbook writing time is super important but we have to avoid using too much of our time on non-billable work so we remain financially healthy. We try to be careful to ensure that our % of time spent on internal work is in a happy space, between 20 and 30%. If you have any doubt as to whether the company can afford for you to take on an internal project, please ask your manager.

Process Change Proposals

If you want to make a change that goes beyond simply better reflecting existing processes/decisions, you will need to suggest the policy change to the team.

Anyone who works at Cantilever can suggest changes to how we do things. If you have an idea or notice a problem with how we operate, you can suggest a change to the group. We are currently experimenting with using the table for this.

To make a proposal, fill out a new document in that table and tell the team about it in Slack. Proposals should have some kind of experiment/testing period associated with them, during which we try the proposed change out and see how we like it. The proposal document should read like a handbook entry, but specifically outlining the changes to be made. It should be like a Pull Request, but for company process.

Give the team some time to provide feedback and react to it. If we have general consensus around moving forward, we can start implementing the change.