How to write a user manual for the folks you work with

Write the manual, skip the guesswork

Every job comes with an unofficial manual for how your colleagues like to work, and nobody hands it to you. You learn it by getting things slightly wrong for a few months. A user manual flips that: you write down how you work best, and the people you work with get to read it on day one.

I wrote mine while I was at Google and shared it with my teammates. User manuals were a somewhat-common practice inside of the company. Since it was such a large organization, you would often find yourself working closely and/or intensely with a completely new group of people. A user manual was a helpful shortcut, especially among a lot of folks who have a very particular set of skills and needs.

A user manual isn't a list of demands or a diagnosis in disguise. It's a short, practical doc that answers the questions people are already wondering about: how to reach you, how you like to get information, what you're great at, and where communication tends to break down for you.

Why it works

Most friction at work isn't about an actual conflict. It's often about two people with different preferences or ways of working who never compared notes (or didn't have the time to). A manual compares notes ahead of time, in writing, when nobody is stressed.

• It moves the “how do I work with you?” conversation out of the moment and into a doc people can read on their own time
• It frames your needs as working preferences, the same way a teammate might say they do their best deep work in the morning
• It saves you from re-explaining yourself to every new manager, teammate, and partner team
• It gives people permission to ask. Once your preferences are written down, adjusting to them feels normal instead of awkward.
• It gives your colleagues an opportunity to communicate their own working and communication preferences
• It presents everything framed as a need you have, instead of a request you're making for someone else to change their behavior

Decide what you want to share

Before you write a word, decide who the manual is for. A doc for your manager can be more personal than one linked from your chat profile, and what you include should follow suit.

• Disclosure is optional. You can describe exactly what you need without naming a diagnosis. “Context switching is hard for me, so I keep meetings to a minimum” works on its own.
• Write for your widest likely audience. Assume the doc will be forwarded at some point, and leave out anything you wouldn't want a stranger to read.
• Share more when it's helpful. If something about how you work is often misread, explaining it can prevent some of that upfront.

What to put in it

A good manual is short enough to read in five minutes and specific enough to act on. These sections do most of the work:

• The basics: your name, pronouns, role, how to reach you, and a last-updated date
• Introduction: two or three sentences on why you made the doc and what you hope it does
• About me: a few true things about how you come across, especially the ones people tend to misread
• How to work with me: the handful of practices that matter most, in priority order
• How I'd like to work with you: what you value from colleagues, and what you'll offer in return
• Communication preferences: chat, email, docs, meetings, and presentations, each with its own short list
• Strengths: what people should bring to you
• Let me know how I'm doing: a way to give you feedback, ideally anonymous

Add optional sections only if they help someone work with you. That might be your background, your working principles, how you recharge, what motivates you, or warnings about things that might go poorly if nobody knows, such as sensory limits or physical boundaries.

Write it so people actually use it

The manuals that work best read like instructions, not autobiographies. A colleague should be able to skim yours before a meeting and know exactly what to do differently.

• Lead with the request, then the reason. “Please put long updates in a doc, so I can comment and reformat it” tells people what to do before it tells them why.
• Be concrete. “Send an agenda with every invite” is easier to act on than “I like to be prepared.”
• Pair your needs with what you give in return. If you ask people not to message you after hours, state that you don't expect them to reply if you message them outside of office hours, as well.
• Keep it scannable, with a table of contents, quick links, and short bullets under clear headings
• Write the way you talk. A manual that sounds like you is easier to trust than one that sounds like HR.

Here's what that looks like in practice. Each pair turns a vague line into one a colleague can act on:

Before: “I process information differently.” After: “If you have a lot to share at once, please put it in a doc, so I can comment, ask questions, and read it at my own pace.”

Before: “I need time to prepare for meetings.” After: “Please send invites at least a day in advance and include an agenda.”

Share it with the right context

How you introduce the manual matters as much as what's in it. Treat it like any other useful doc, not a confession.

• Share it at a natural moment; as an attachment and a line item during your first one-on-one with a new colleague, or drop it in your Slack group during your first week on a new team. Try not to share it in the middle of a tense situation.
• Put the link where people already look, like your chat profile, your email signature, or your calendar booking page
• Invite others to write their own. A manual lands best when it's an exchange, not an exception.

I had some colleagues who asked for a user manual during our first interaction, which is why I wrote one in the first place. I came to understand it as a type of accommodation you can preemptively give to your coworkers that really serves both you and them, especially if you are being evaluated for teamwork and cross-functional collaboration. It can be a great avenue to discuss a commonality you might have with someone, or to even work out some process differences you might have across teams or organizations, or even among different people.

Keep it current

Put a last-updated date at the top and revisit the doc whenever something changes, like a new role, a new team, or a new need. An outdated manual isn't very helpful to anyone.

Start with the template below. It has every section, with prompts to answer, so you're filling in blanks instead of staring at zero.