Personal User Manual

Your client has been with their team for two years. In that time, the team has built up a working model of who they are - mostly accurate, partly wrong, and in a few places significantly off. A key misread: the team interprets your client's silence during meetings as disagreement. It is actually how they process. Two team members have been holding back ideas in meetings because they have concluded that the ideas were rejected without anything being said. Your client does not know this is happening. The manual is the fastest way to correct multiple misreads at once, before the session tries to address each one individually.

Frame this as making the implicit explicit, not as a vulnerability exercise. 'You have operating preferences that your team has had to infer through observation. Some of those inferences are accurate; some of them are probably not. The manual surfaces the ones that matter most and puts them somewhere accessible.' The resistance pattern: technically-oriented leaders sometimes see a document like this as soft or unnecessary. Name that the team is already making inferences about how to work with them - the question is whether those inferences are accurate.

Watch Section 2 ('Something people often misunderstand about me'). If that field is left blank or produces a very generic answer, your client has not yet identified the most costly misread. Ask directly: 'What is the most important thing someone could get wrong about how you operate?' Also watch 'My communication style under stress' - clients often write an aspirational version ('I get quiet and focused') rather than an honest one ('I get short and shut people out'). The useful version is the behavioral description that would actually help a teammate recognize the pattern and adjust.

After the manual is drafted, ask your client to read the 'How to give me feedback' field aloud and then ask: 'Is this how feedback has actually landed in the last year?' That question checks whether the stated preference matches the behavioral reality. Then ask: 'Which section, if your team read it, would change how they work with you most?' The answer to that question tells you which part of the manual deserves explicit conversation rather than just distribution.

Your client is starting a new role in three weeks. They have a strong track record but have also left their last two roles with some relationship friction that, in retrospect, was partly caused by their operating preferences never being made explicit. They know this about themselves. They want to handle the onboarding differently this time: get their preferences in the open early, create conditions for the team to raise concerns rather than silently working around them. The manual is the right tool at the right moment - before the team has formed its working model.

Frame this as preemptive calibration rather than rule-setting. 'This is not about telling the team how to work for you - it is about giving them information that makes it easier to work with you and easier to surface problems early.' The resistance pattern: new leaders sometimes worry that sharing preferences before trust is established reads as demanding. Name that a manual shared with genuine curiosity and an invitation to reciprocate is a relationship-opening move, not a positioning one.

Watch the 'How to give me feedback' and 'How to NOT give me feedback' sections - these two fields in combination reveal a lot. If 'How to NOT give me feedback' is blank, your client has not thought carefully about their feedback blind spots. Also watch whether the Pet Peeves field is honest. A new leader writing 'I don't really have pet peeves' has not done the work - everyone has specific things that consistently irritate them, and naming them prevents the team from discovering them through accidental violation.

Read the full manual with your client and ask: 'Is there anything in here that you are worried about the team seeing?' Whatever they name is usually a real risk worth discussing. Then ask: 'How do you want to share this - distribute it ahead of your first team meeting, bring it to a one-on-one, use it as a conversation opener?' The how-to-share decision matters as much as the content.

Your client's team is functional and gets results. They are also expert at managing around their leader. They have learned which topics to bring up in private versus group settings, which decisions to make quietly and present as done, and which information to filter before it reaches your client. None of this is malicious. It is efficient adaptation by a capable team. The problem is that your client is increasingly operating on curated information and is losing visibility into how decisions are actually being made. The manual, done well, can create conditions for a reset.

Frame this as creating new entry points, not fixing the team. 'What you are describing is a team that has learned to work with you very efficiently - but some of that efficiency has come from limiting what reaches you. The manual gives you a way to name what you actually want, so the adaptation they've built can recalibrate.' The resistance pattern: leaders who are getting results often resist examining the team dynamics that produce those results because the system is working in an immediate sense. Name that adaptation that filters information is working against them even when the results look fine.

Watch Section 3 ('How I make decisions') especially. Leaders whose teams have learned to manage around them often have informal decision preferences that the team has figured out but that have never been named. If the 'How I make decisions' field produces a clean, process-oriented answer that does not match how decisions actually happen, ask: 'If one of your direct reports were answering this question about you, what would they write?' That question often surfaces the actual process versus the stated one. Also watch 'What I need from meetings' - if this field does not name something specific that the team is currently not delivering, the work has stayed at the surface.

After the manual is drafted, ask your client: 'Which section would most surprise your team?' Whatever they name is the field where the gap between what they communicate and what the team has inferred is widest. Then ask: 'Is there anything in this manual that you have wanted the team to know but have not found a way to say directly?' The answer to that question is usually the most important item in the document.