Writing a User Manual for You

Writing a User Manual for You

How to define the way you operate, for your teammates and for yourself

Mike Stein

Sep 29, 2026

6

8

Share

Photo by

Brett Jordan

on

Unsplash

What would you like your current team to understand about the way you operate best?

Have you told them?

Have you even figured it out for yourself?

A user manual for you

For anyone who works on a team, I’ve seen consistent value in

the exercise of writing, sharing, and occasionally updating a short “user manual” for oneself

, sometimes called a personal “readme” file. It covers how you prefer to manage your time, communications, and how you best work together with others.

The user manual relates to other team onboarding documents and processes we’ve discussed before. In a way, your user manual is your proactive, continuous response to your

team’s productivity & communications survey

, and it’s a complement to

the kind of team operating manual as we explored last week

that a manager might write for their team. But the personal user manual is valuable for everyone on a team to write and share, not just the managers.

It’s a worthwhile investment with three payoffs, in order of

increasing

importance:

Some of your teammates might read it and, if they do so, they might learn about how to interact with you better. (Most won’t, though.)

Really, you yourself are the primary audience

. Writing your needs and wants down helps you identify them, and sharing it holds you accountable to them.

Most important is the

value it signals for your team’s culture

, which you get even when people don’t read it: we work on a team where we know different people work differently, and we empower people to think about and share those. It’s a powerful thing to get across.

What it should include

Consider including in your user manual topics like, but not limited to, these:

A topline summary of the way you operate with others

, along with any other self-reflections that you feel would be valuable for a new colleague to know about you.

Working hours

. Include time zones if your team is international. Define both your preferred hours and any hard lines when you can’t work.

Response time expectations for different modes of communication

. For each of the systems commonly used at your organization, call out which you prefer and how quickly you see and respond to each.

Meeting preferences

. If you hate meetings during certain times of day/week, or if you hate meetings overall, share that.

Feedback preferences

. Normalize

facilitating the open flow of valuable feedback

by telling people the way you’re most comfortable receiving feedback.

How you manage your to-dos

. How can people get visibility into your prioritization and feel invited to

start discussions

when they disagree?

A last updated date

, to reflect that everything above can and will change over time

You can write this in a collaborative document and link to it in your internal email signature, put it in your Slack profile somewhere if your administrator has enabled links, or share it with new teammates as a conversation starter.

Example

Here’s what my current personal user manual would look like.

I’m a conscientious optimizer of my own productivity as well as that of my team. Here’s the way I prefer to work, which I treat as defaults, but if your own ways of working are different, I’m adaptable and curious (I’d love to read your version of this manual!); bridging between different operators is one of the strengths I bring to teams.

Calendar, Hours & Meetings

I work from Eastern Time ~9-5. When my kid is out of school and awake, I am not actively working (

this is a hard line for me

) but can answer quick, urgent texts. I’m an early-morning guy and never pull all-nighters, which I know are disastrous for my net output.

My calendar is public and reflects these times. I also keep tentative

blocks on my calendar each day for my intended deep work and for batching replies

. These are always movable within each day for important and/or large-group meetings, but they need to happen, so I only skip them entirely for emergencies.

I don’t mind

meetings as long as they’re tightly designed around important outcomes

. I’ll walk out of a meeting if I realize my participation is not valuable. Please do the same with mine.

Communications

Here’s when I’ll see and respond to different messages:

Slack

. Slack gets the least attention from me because of its poor signal-to-noise ratio. I

aggressively defer my responses to most Slack inbounds to batched sweeps once or twice per day

but will respond as I see it to anything urgent, though I’m sometimes only looking at Slack once per hour.

Email

. I review all emails to: me as they come in and respond within a few hours; I don’t move on to Slack replies during a sweep unless I hit

inbox zero

. I prefer email to Slack for matters of substance and of long-term reference value.

Text message

. I’ll see it within minutes and respond as soon as I’m out of a meeting or done with a focused task.

Phone call

. Break glass. Breaks flow. Use only for the extremely

urgent and important

.

Feedback

I strongly prefer

timely and direct feedback

on all matters. Please bias strongly towards immediate bluntness; nobody’s offended me yet.

I recognize this is uncommon; I will ask you about your own preferences for receiving feedback before giving you any.

Task Management

My to-do list is public within the company. I update it at least once a week to reflect my evolving prioritization, and I take notes on significant developments via self-commenting on the respective tasks. If you see something you disagree with in my prioritization, please jump in with a comment or DM to let me know; these are always useful conversations.

You do not have to chase me to get something done once I’ve accepted it. I don’t drop the ball. Feel free to ping for updates, or you are welcome to follow along on individual tasks on my to-do list.

Last updated Sep 29, 2026

Here’s a

different example of a user manual by Rands

. This one’s admirably personal from someone who knows themselves and their own triggers well.

Put it into practice

Try writing your version of your user manual.

It needn’t and won’t be as long as my example; maybe for now all you’re even slightly sure of is your preferred working hours and whether you love or hate Slack. That’s a perfectly fine starting point!

Update and add to it once or twice a year.

You’ll find actionable learnings from the new trends and changes you see in your own processes.

Need a bit of extra help figuring out the optimal processes for your own ways of working? Check out my coaching and contact me for a free consultation.

Coaching

6

8

Share

Previous

Next