What Is a Personal User Manual? (2022)
Personal User Manuals are concise guides detailing individuals' backgrounds, values, and communication styles to enhance empathy and connection in remote teams. They aid in understanding preferences, reducing misunderstandings, and fostering collaboration.
Read original articlePersonal User Manuals, also known as Personal Operating Manuals, are short descriptions of individuals' backgrounds, values, and communication styles aimed at fostering empathy and connection within distributed teams. These manuals help team members better understand each other's preferences and work styles in a flexible work environment. By explicitly communicating how they work and what works best for them, individuals can reduce misunderstandings and build trust among colleagues. Benefits include shortening the learning curve for new team members, improving communication, providing insight into motivations, avoiding misunderstandings, fostering empathy, and enhancing collaboration. Creating a Personal User Manual can also promote self-awareness, a crucial trait for effective leadership. Leaders are encouraged to initiate the process by completing their manuals first and then engaging in live discussions with their teams. The manuals should be concise, engaging, and cover topics like work style, values, preferred communication methods, common misunderstandings, and areas where patience may be lacking. Encouraging ongoing sharing and revisiting of these manuals can help teams evolve and deepen their connections over time.
Related
Seven Conversation Hacks
The article shares seven conversation hacks to enhance communication skills: using names, repeating key points, adjusting eye contact, pausing for reflection, asking for opinions, and listening for feedback.
The manager's unbearable lack of endorphins
The author explores satisfaction in swimming, coding, and managerial roles. Physical activities offer immediate feedback and endorphins, contrasting with managerial tasks lacking similar gratification. Transitioning to management poses challenges in finding fulfillment.
Software Engineering Practices (2022)
Gergely Orosz sparked a Twitter discussion on software engineering practices. Simon Willison elaborated on key practices in a blog post, emphasizing documentation, test data creation, database migrations, templates, code formatting, environment setup automation, and preview environments. Willison highlights the productivity and quality benefits of investing in these practices and recommends tools like Docker, Gitpod, and Codespaces for implementation.
The Blank Sheet Method: From Passive Reading to Active Learning
The Blank Sheet Method enhances learning by prompting active engagement through note-taking. It aids in comprehension, knowledge retention, and critical thinking by connecting ideas and correcting misconceptions, fostering effective learning.
No Matter What They Tell You, It's a People Problem (2008)
The article emphasizes the crucial role of people in software development, citing teamwork, communication, and problem-solving skills as key factors for project success. It highlights the importance of job satisfaction and team cohesion, underlining the significance of positive personal relationships within development teams.
The main context these make sense in is when written by a manager (or maaybe by a direct report for their manager). They can be useful to establish expectations for a team around things like "is it ok to message me on the weekend" and "here's what you should have prepared for our 1:1s".
I'm not sure I could muster the arrogance to write such a document about myself... and then expect people to read it. The suggested examples of what the document could contain are bizarre and yet also weirdly simple & obvious...
"I am a sponge. I’ll take more content earlier rather than a formal presentation"
"Please give me the bad news before I hear it from somewhere else"
"Be direct. Tell me what you need and when you need it."
And who has this complete picture of oneself that is not obscured by the lies that we tell about ourselves? The self-deception and the imposter syndromes that we foster?
I guess these manuals will be outdated sooner than the regular docs - and if your staff has time on their hands to write and maintain them, you might be running an adult daycare center!
They both are based on the wrong assumption that people have to ask your opinion before contacting you, while communication has always been based on shared standards.
Normality exists. It's not something to tend to, but it exists and must be recognized and respected, and everybody is expected to do their share in conforming to normality.
Its just such a weird intersection. First, you need people that are aware of their interpersonal pain points and for those problems to be deep rooted enough that an onboarding doc makes sense. Then, you need those same people to accept being emotionally vulnerable in a space others are going to use for blatant self promotion - in this case just being ignorant of your own flaws counts because you will write some dumb shit like 'I am data driven show me the facts' but in reality you will base decisions on your gut and a spreadsheet you threw together.
The way to deal with unwanted interruptions is to ignore them and then later claim you were so busy you didn't notice. No downside to that. (Headphones help with this if they've forced you back into an office.)
If you're employed in a company or organization, you have to conform your personality to their manual, modulo reasonable wiggle room. That's it.
Nobody has the time to read N different manuals, and then ponder over interpretations in order to decide on how to proceed.
The challenge with these methods is that when they're most needed, people often revert to more... "basic instincts" :-), sometimes underhanded, forms of communication. They can even twist these tools to serve their own agendas. I wonder if a 'how to talk to me' manual might be giving potential manipulators too much leverage...
--
Something along these lines is a good idea for a job listing though. Come up with a broad sketch of how the current team works and likes to work, have the team edit it until rough consensus, add it to the job listing. The best I've seen in that direction is https://github.com/symmetryinvestments/overview/blob/master/...
> Qualities and traits we value
Usually this is something vague around inclusivity and niceness. I can't remember the stated corporate qualities of anywhere I've worked, though the reality tends to stick in the mind. Symmetry have not taken that stance. The examples I find most interesting from that section are
> Practical people who are at the same time unreasonable when they ought to be
> Extreme and unusual intellectual capabilities
> Good taste and love of beauty
It's not enough to tell me whether I'd like to work there or not - in particular trading firms are usually obsessed with people sitting in office blocks - but it's higher signal than the usual waffle about everyone working together nicely to make things nice.
Richard Stallman has rider... (see: https://news.ycombinator.com/item?id=3159210 )
I normally have contracts I honor and I expect the other party honor as well, I have a reasonable human flexibility, tolerance etc, and all of that demand no manual. The company demand an onboarding manual and tried practice as much as possible because from remote the sole hard part is that. For all, in person or remote, the rest is about documentation in general, not crappy abandoned wikis, not "read the code" on a codebase that would demand years to be understood fully and change faster than such timeframe and so on.
I reject a future of meat-based robots on sale, I like a future of remote workers, humans, that know what to expect each others, because we are all humans, peers between peers.
This is being 'phrased' as though full time workers aren't experiencing any or their experience doesn't count. But looking at the charts and how close many of the results are, it appears more that the experience is split across the three types of workers, with remote only just edging out the others.
It seems like something that enables and promotes mental illness and would actually be counterproductive to uniting people towards a common goal, and rather would develop pettiness and fiefdoms.
However - content aside - I actually liked the page layout. I liked the clickable, table of contents thing on the side, that disappears if the page is narrow. This sort of presentation of text is really nice, imo.
The best examples I've seen of such manuals (and the best working relationships that have been informed by them) share a common thread: sharing about ourselves where useful,[^1] in order to help others know us better,[^2] and not to control or compel them to do any specific behavioral thing.
So, far from an "instructions [to follow]" (@phoenixy1) or "a one-size-fits-all approach to how different people should act with an individual" (@ralferoo), I think many people intend that the document simply share context in order that you can understand them better, and do whatever you like with the information.
There seems to also be a suggestion that producing such a document is in and of itself a burden to others (@jasoncartwright is very upset about the "arrogance" of even writing one, let alone "expect[ing]" someone to read it, @phoenixy considers them to be a "pretty unreasonable burden"). I can understand the reaction, but I think provided there is no expectation that anyone read it, or that it be a means of controlling or compelling someone to behave a certain way, it's pretty benign overall. (Like, I think everyone would at least once or twice in their careers have access to such a document about some colleague or another, if they thought it were relatively sincere? If so, I say go forth and self-document, just don't have any expectations.)
Here are the sections in mine:
1. Why I have this thing
2. The success criteria for my role, and some general ways I try to achieve them
3. Some general patterns of working (one-on-one cadence, skip mtgs, whatever)
4. Blind spots I have that others have experienced (all verbatim, sought from a mix of new/old colleagues, a few new ones added each year)
5. A few situations where those same people would encourage others to specifically seek me out in a jam (as before, all verbatim yada yada - not necessarily work-related)
6. Work things I love doing / work things that I find stressful (drawn from scenarios the reader will likely encounter)
Of these, 1, 2, 4, 5, and 6 contain precisely zero information relating to my preferences or instructions on "how to" do something. I'm simply providing what I hope to be useful context about me and my role at work. (Assuming you take me at my word that I am not sharing the things I love / things I find stressful for any reason other than you knowing me better.)
The general patterns of working at 3 contains some preferences relating to out of hours contact (along lines of "I don't check my emails or Slack outside of office hours, so you should call or text me if there is an emergency or if a few minutes of my time can save you several hours on something"). Maybe that's somehow outdated now? It's the sort of thing I like to know before I reach out to someone out of hours – a bit like I know some people who appreciate a heads up when visiting a "shoes off" household, so they can wear socks or clip their toenails.
tl;dr I think if you are clear that you have no expectation that anyone even read it, and share relevant, practical context on working together -- with a significant portion sincerely sought from a mixture of people, rather than your own navel-gazing -- these kinds of manuals can be a good shout.
I like reading them, and I like understanding my colleagues better. So I'll tell you that I would enjoy reading yours, and if you ever write one please share it, and that I hope you read mine. That's pretty much it!
[^1]: What constitutes " useful" is of course my determination to make, just as it's your determination to decide that what I shared wasn't useful, and tell me as much.
[^2]: I guess this is predicated on the axiom that understanding your colleagues better is useful. I suspect it is useful -- I think if I had to bet on whether or not any person is more effective in collaborative tasks with a stranger, or with someone they have worked professionally with in any field for several years, I would pick the latter -- although this is uninformed.
Related
Seven Conversation Hacks
The article shares seven conversation hacks to enhance communication skills: using names, repeating key points, adjusting eye contact, pausing for reflection, asking for opinions, and listening for feedback.
The manager's unbearable lack of endorphins
The author explores satisfaction in swimming, coding, and managerial roles. Physical activities offer immediate feedback and endorphins, contrasting with managerial tasks lacking similar gratification. Transitioning to management poses challenges in finding fulfillment.
Software Engineering Practices (2022)
Gergely Orosz sparked a Twitter discussion on software engineering practices. Simon Willison elaborated on key practices in a blog post, emphasizing documentation, test data creation, database migrations, templates, code formatting, environment setup automation, and preview environments. Willison highlights the productivity and quality benefits of investing in these practices and recommends tools like Docker, Gitpod, and Codespaces for implementation.
The Blank Sheet Method: From Passive Reading to Active Learning
The Blank Sheet Method enhances learning by prompting active engagement through note-taking. It aids in comprehension, knowledge retention, and critical thinking by connecting ideas and correcting misconceptions, fostering effective learning.
No Matter What They Tell You, It's a People Problem (2008)
The article emphasizes the crucial role of people in software development, citing teamwork, communication, and problem-solving skills as key factors for project success. It highlights the importance of job satisfaction and team cohesion, underlining the significance of positive personal relationships within development teams.