Helping other people get to know you

Some examples

This is a post to pull together and share some examples I’ve come across of people who have written a ‘user manual’ to help others get the best from them at work.

I’m interested in seeing other examples.
If you know any, please let me know, and I can update this post.


Why I’m doing this — my back story

A month ago I started a new job, in a new organisation.

I work in the technology department of Elsevier. There are about 7500 people in Elsevier, a global information and analytics provider, across 46 countries. I am based at home.

Elsevier has over 1200 people working in technology in areas such as natural language processing, machine learning, search, data visualization, big data and mobile. And it’s a rapidly growing area. There are currently about 450 people working in my bit of the tech department — working on the technology underpinning Elsevier’s products and services that support scientific research and help scientific discoveries by turning information into actionable knowledge.

Elsevier itself is part of a larger organisation, the RELX group, a global information and analytics company on the FTSE 100 and FT Global 500, which employs approximately 30,000 people.

For me, these are big numbers.

I’ve not worked in an organisation with more than a couple of thousand people before. I’ve led teams spread across the UK before, but I’ve not worked in a team spread across different countries, time zones and cultures.

Working with other people

One thing that’s important for me in teams is getting to know your colleagues as people. Each of us lives a life that is often only partly seen when we go to work. Yet things going on in our lives outside work can have a big impact on how we are when we’re working. Similarly, we’re all individuals, with our own quirks and preferences. Understanding these can help build working relationships. It’s also more human.

Sometimes people learn to work together through doing and getting on with stuff. But that can be harder when you’re not co-located and there are fewer opportunities for water cooler chats. Sometimes people do it through orchestrated team exercises, say at an away day. But again this is harder when your team is spread across different countries.

So I’ve been thinking about how to do this in my new job.

Learning from other people

About 6 months ago, I saw Cassie Robinson’s “user manual” of herself, and I instinctively liked the idea. In it, Cassie explains when and where she likes to work, how best to communicate with her, how she likes to receive feedback, and so on. The idea is not to explain what you do at work, but how you work.

Recently, I saw a couple of other people do something similar, and when I joined Elsevier, I thought maybe I’d try and write my own. Given the size of the organisation, and the fact that I’m home-based and working in a team across that is dispersed across the world, I thought it might help people get to know me.

Before putting ‘pen to paper’, I wanted to see what other people had included in theirs. This is something I often do, and I think it’s due to a combination of things:

  • I sometimes think it is because I don’t see myself as creative,
  • I hate re-inventing the wheel,
  • I often learn by seeing what others have done. Sometimes, it can be as simple as seeing something I like, that I think will work for what I’m trying to do, and copying/stealing with pride. Other times, I just take a bit of an idea and adapt it for my personal circumstances. Other times, it gives me something to react against. It’s part of how I do discovery.

So I did something that has worked for me before. I asked for help on twitter:

This tweet led me to discover that Matthew Knight and a small community have gone so far as to create a tool to help anyone wanting to create a ‘people manual’ for themselves. As he explains it:

“So often, when new people join a team, it takes months to understand how they thrive professionally, the way in which they prefer to communicate, engage and collaborate (or not). The Manual of Me attempts to accelerate that process.”

Their website includes a number of exercises for people to reflect on and help articulate how they operate at work. Matt has also written a short history of this way of trying “to shorten the learning curve when you build new teams and bring new people on board”.

From the ‘Manual of Me’ website

So, if you want to create your own ‘manual of me’, there is a tool, a template, exercises and things to read. And if, like me, you like to see what others have included in their own ‘user manual’ to spark your own ideas/creative juices, you might find the following list helpful.

Examples from other people

Here is the list I’ve got so far:

At some point soon, I’ll add my own.

Update: Mine is here (plus short story)

Update 2: Here are two more:

Update 3: Dan Barrett has published A user manual for Dan (which uses the headings from Cassie’s template)

Update 4: Here’s a template from FutureGov (HT kim mclaren)

Update 5: Zoe G has published a user manual

Update 6: So my list of examples has now doubled in number, and I’ve discovered a bit more about the history of user manuals. Also, if you’re thinking you’d like to give this a go yourself, I have also got more templates and questions to get you started:

Inspired by Rands (see update 2 above), Matt Newkirk published a ‘manager read me’.

Oren Ellenbogen published his ‘manger read me’ in January 2018.

I found Oren’s example from a post by John Cline in which John spells out some of the benefits he’s had from writing his user manual.

Oren credited Luc Levesque with writing the first user manual, which he called a ‘Blueprint to Luc and his quirks’.

From there I discovered ‘7 questions to Ask (and Answer) For Your User’s Manual’ and two interviews from 2013 with Luc Levesque and Ivar Kroghrud in which they talk about their user manuals and the benefits they’ve found in writing them.

Luc open sourced his template, which Sara Borgstede used to create her own blueprint.

Luc’s blueprint also inspired this 2013 example by John Duff.

In 2016 David Politis went to a conference session with Ivar Kroghrud on creating user manuals. David wrote up the questions Ivan gave the audience to help get started on writing a user manual and also shared his own user manual in this blogpost. Indeed David was so inspired by the session that he had his whole company (130 people) create user manuals!

Abby Falik was also inspired by Ivar to write her user manual with six sections and to share five steps that will help you create a manual.

Aaron Hirst published his user manual in 2013 inspired by this article.

Update 7: Katie Womersley published her ‘manager readme’ on github, together with an explanation of the benefits/reasons why she wrote one.

Katie was inspired by Lara Hogan and her post on her management expectations.

Derek Lakin published his manager read me, inspired by Matt Newkirk (see update 6 above).

Liran Tal, who was also inspired by Matt Newkirk, also published his manager read me.

Update 8: Over the past two months, I’ve been regularly updating this post, adding new examples as I’ve come across them. The list of examples has more than doubled in length, growing from 8 to well over 20.

And now I’m going to put it to bed and stop updating it.

For one thing, I can’t keep up! There seems to be growing interest in personal user manuals, and publishing them appears to be increasingly popular as well.

For example, Brennan McEachran has just published ‘12 Manager READMEs from Silicon Valley’s top tech companies’. Most of those examples are in my list above, but there are some interesting examples I’d not seen before.

Also, Oren Ellenbogen has launched his fantastic Manager README website. The website sets out different use cases where a manager can find having a personal user manual helpful, and it includes an online tool to help people to write their own. There is also a growing community there of people who share their own example (26 people at the time I write this — and I’ve just added mine).

And that made me realise that an interactive website where people can upload examples is a much better and more sustainable model than a blogpost.

So that’s where I’ll leave this post.

With two final thoughts, triggered by Camille Fournier:

  1. A user manual is only worthwhile if it genuinely reflects you as a person, if you are confident you will follow through on commitments in it, and if you keep it up to date.
  2. User manuals are not just for managers.

I don’t like the title ‘Manager README’ — it sounds like an instruction, and the block caps send the wrong signal for the message I want to convey about my management style.

I came to these tools as a way to help other people get to know me at work at a time when I wasn’t directly managing anyone. For me it was a quick way to share information with team mates and help colleagues get to know a bit about me as a person. I have found writing my user manual helpful for that purpose, and it’s triggered lots of great conversations I might not have had otherwise.