What Slab gets right about personal user manuals at work

Your new manager sends you a message: “Hi.” Then the typing indicator remains visible for three minutes. You do not know whether a problem is coming, whether you should respond immediately, or why the question was not included in the first message. To the sender, this is an innocent habit. To you, one empty word suddenly becomes missing work information.

Small moments like this sit at the centre of the guide to personal user manuals that Slab published on 30 August 2023. Slab describes how managers and colleagues can document their working hours, communication preferences, ways of collaborating, feedback habits, and personal routines. The goal is less trial and error and less friction, especially when people work remotely and informal encounters provide less context.

The strongest idea in the article is not that you can capture your whole self on paper. It is that knowledge about collaboration is still knowledge. Teams document processes, decisions, and product information, yet often leave the instructions for daily interaction inside people's heads. A personal user manual moves some of that information to a place where others can read, discuss, and improve it.

Slab treats working style as shared knowledge

A team wiki probably explains how to request leave, who handles an incident, and where the roadmap lives. You may still need weeks to discover that a colleague needs written feedback to respond well. You may only learn after a project stalls that “work it out yourself” means to the manager: choose your own route, but check in before a deadline is at risk.

That information is no less important because it is personal. It affects how quickly someone asks a question, shares bad news, or challenges a decision. Slab therefore makes a useful connection between personal reflection and knowledge sharing. The manual is not a profile to reread alone, but a document that helps another person act.

Every preference must be translated into an observable moment. “I like direct communication” is still too vague. A colleague does not know whether it means that you get to the point quickly, give criticism without preparation, or prefer one clear decision. Write instead: “For an urgent question, put the deadline in the first sentence. When giving me feedback, start with the desired result and then share the examples.”

The difference is testability. A general characteristic may sound familiar. A concrete agreement can actually change something at 10 a.m. on Tuesday.

A blank page attracts the ideal version of yourself

Slab advises writers to first investigate their own patterns, possibly with a personality assessment and feedback from people who know them well. That is sensible. A blank page asking “how do I work best?” quickly produces polished generalities: I am open, I care about quality, and I value honesty.

The question is not whether those sentences are true. The question is what information they give a colleague. Almost everyone values quality. Not everyone means the same thing by sufficient preparation, a good decision, or timely feedback.

It is therefore better to create a personal user manual from situations rather than compliments about yourself. When do you gain energy in a meeting? When do you need silence first? What do you do when a plan changes? How do you sound under time pressure? Which behaviour of yours is repeatedly interpreted differently from what you intended?

An assessment can give words to those patterns, but its result is only source material. Translate each preference with four questions:

1. What do other people concretely see me do?
2. What intention or need sits behind it?
3. How could that behaviour be misread?
4. Which mutual agreement would help in that situation?

“I am quiet” can then become: “In a fast meeting, I listen first and formulate more clearly later. Send the main question in advance. I will give my first response during the conversation and add something later that day if needed.”

The data shows why no single working style is normal

Slab argues that manuals do more than reveal differences: they make them easier to discuss. Our latest privacy-safe analysis helps show the scale of that variation. It contains 2,704 complete profiles. Public demo profiles were excluded, all figures are aggregates, and percentages were rounded to whole numbers.

Preferences around contact and planning are particularly practical in a user manual. They influence how much interaction someone seeks, how visibly they show enthusiasm, and how much structure a plan needs to provide.

Quiet24%Merry40%Dominant36%

Flexible19%Methodical35%Focused46%

For contact, 24% of profiles are quiet, 40% merry, and 36% dominant. For planning, 19% are flexible, 35% methodical, and 46% focused. Neither area has one approach that is self-evident for almost everyone.

You notice the difference in ordinary work moments. A dominant colleague may share an early idea out loud. A quiet colleague may want to think independently before discussing the same idea. A focused colleague gains confidence from an early choice. A flexible colleague prefers to leave room for new information.

No preference dictates the correct process. The distribution simply shows why “this is how professionals work” is a weak basis for collaboration. Teams are likely to contain multiple routes to involvement and quality. A user manual reveals those routes earlier.

These profiles are not a representative sample of all workers. We also do not know the context in which each participant created their manual. The figures describe our user population and do not prove that teams with manuals perform better.

Personal becomes useful only when it remains reciprocal

Slab encourages writers to be open and personal. Specific habits make a text more human and memorable. There is also a boundary. A colleague does not need to share private information to collaborate professionally, and vulnerability from a manager does not create a right to vulnerability from employees.

The power difference matters especially in a manager manual. “I want you to challenge me directly” sounds inviting, but the manager evaluates performance and allocates opportunities. An employee therefore watches what happens after they disagree.

Make every expectation reciprocal:

• Not: “Only bring me solutions.”
• Instead: “Describe the problem, the risk, and what you need now. If there is no solution yet, I will help determine the next step.”
• Not: “Keep me proactively informed.”
• Instead: “Report a risk as soon as the deadline or quality may shift. I will respond the same working day with a decision, question, or new check-in.”
• Not: “I am just very direct.”
• Instead: “I get to the point quickly. If my message lands unnecessarily hard, you may say so. I will clarify my intention without dismissing the impact.”

Managers can use the more detailed guide to writing a manager README. It also covers availability, decisions, delegation, mistakes, and safe dissent.

A living document needs a correction mechanism

Slab rightly calls the manual a living document. People are complex, roles change, and a preference that helps in one situation may hinder another. Adding a date at the bottom does not make a document alive. It needs a route for correction.

Schedule three short checks:

1. After sharing: which sentence helps immediately, which mainly describes my good intention, and what is missing?
2. After thirty days: which real work moment confirmed or contradicted the text?
3. After a change: what needs to change because of a new role, colleague, manager, or recurring conflict?

Let readers comment directly in the document. The writer remains the owner, but not the only source. Someone may experience themselves as quiet and careful while colleagues mainly see silence under pressure and do not know when an answer will come. Both observations matter. The manual improves when it turns that gap into behaviour: “If I do not have an answer yet, I will tell you before 4 p.m. when you will receive it.”

Flexibility does not mean that every preference is always followed. A team may decide that an incident must be reported verbally at once, even if someone prefers writing. The manual then makes visible where adaptation is needed and which support makes it possible.

Slab offers a strong start, not proven impact

The Slab guide speaks confidently about less friction, faster onboarding, trust, and better collaboration. It provides examples and a convincing practice, but no impact research that attributes those outcomes to personal user manuals.

Our platform data does not supply that proof either. It shows that work preferences vary, not that documenting them causes retention, speed, or performance. To test that, you would need to follow teams before and after adoption, define the target behaviour in advance, and account for leadership, role clarity, workload, and other influences.

Start with modest, direct signals. Can colleagues correctly name each other's feedback preference? Is the channel for urgent issues clear? Is a risk reported earlier? Has a recurring misunderstanding happened less often after thirty days? Such questions match what one document can realistically influence.

Document the message that only says “hi” first

You do not need to start with a complete life story or a perfect template. Choose the small work moment where someone still has to guess. It might be the message that only says “hi,” an unexpected feedback call, or a deadline that nobody knows is truly fixed.

Write four lines: this is what you see me do, this is what I mean, this is how it may come across, and this is what we can both agree to do. Ask one colleague to respond and immediately schedule the moment when you will check whether the agreement helped.

That makes Slab's best insight practical. Personal work knowledge should not live only in someone's head. Once you can read, challenge, and improve it together, a user manual stops being a rulebook about you and becomes shared infrastructure for the work.