Skip to main content

Manual on Me: Matt Long

· 6 min read
Matt Long

As I was waking up this morning, I started surfing Reddit. One post, in particular, jumped out at me. In this post, the writer (OP in Reddit parlance) had been asked to take a personality test at work by a new supervisor. The OP was asking if this was something they should agree to do.

The responses varied. Some were mildly positive, but most were very cynical since this sort of testing can be misused by bad management. However, this got me thinking and, eventually, writing this post.

Let's look at the supervisor mentioned on Reddit and view their actions in a charitable light. It is entirely probable that they only wanted to better understand and work with their new direct reports. This is undoubtedly great! However, a personality test is not a particularly useful tool for this -- people are too varied, and lives are too complicated. This interview with Brian Little, the author of "Me, Myself and Us: The Science of Personality and the Art of Well-Being," discusses some of the problems with these sorts of assessments.

And as an employee, who wants a supervisor that uses an impersonal online test to figure out the best way to work with someone?

Our Process

At Working Group Two, we do things a little bit differently. We follow a straightforward process of treating employees like grownups. I thought it might be worth talking about how we handle the "let's try to understand our employees" problem and share a public version of what I have shared inside the company.

The short answer to this is this: just ask. Amazing!

When new employees start working with us, we ask them to fill out a "Manual on Me." Since we are a distributed company and everyone is de-facto remote, this manual serves two purposes: it is a bit of an icebreaker and a powerful communication tool. Everyone in the company has a "Manual on Me," from the CEO and CTO to the most recent new hire.

As Professor Little notes: "Once you understand what a person's core projects are or even ask a person, 'How is it going, David?,' it puts us in a position where we can actually treat humans as humans. That to me is going to pay enormous benefits in the long term."

Here's what I was asked to put into my manual:

  • What I know about that people can ask me
  • How I think about things
  • Common mistakes I make in my interactions with others
  • My expectations from others
  • What frustrates me
  • How to reach out and get in touch with me
  • How to give me feedback

Although nobody in the company remembers how this practice actually started, this is not a completely new idea. I see that there are a few references to this concept around the internet, including at least one online version. Their about page cites a few previous inspirations and sources for this "personal user manual."

So how does this solve the problem on Reddit? Assuming the OP's new supervisor really wanted to know their employees, they could just ask and probably find out just as much (or more) than having everyone take the MBTI.

My "Manual on Me"

So what does my "Manual on Me" look like? Here is what I wrote in the summer of 2018:

Manual on Me

What I know something about:

  • I know a little bit about a lot of things.
  • Recently, I've been doing a lot of cloud infrastructure work, so that is freshest in my mind.
  • I've also had experience with development of embedded Java VMs, garbage collection, graphics drivers, distributed workflow systems, robotics, AI, machine learning, and autonomous ships.

How I think about things:

  • I like to challenge how things are done and find simpler solutions. This often involves understanding why things are currently done the way they are.
  • I very much like to think about an end goal and develop solutions towards the goal.
  • While I like to think a little about the steps in the middle, I don't like planning them in great detail.

Common mistakes I make in my interaction with you:

  • Sometimes, I will offer possibilities and suggestions as a way of discussion -- sort of like the "rubber duck" development process. This is not meant as a negative criticism but intended to continue the conversation and explore possibilities. But I do understand how it can be interpreted in other ways. Let me know if this is annoying!

My expectations to you:

  • I expect people to try, experiment, and learn.
  • I also hope that everyone feels comfortable speaking up and expressing their point of view and ideas.
  • If something is not clear, ask for clarification.

What frustrates me:

  • Bureaucracy, particularly rules that exist without an explanation of why the rule exists.
  • Broken software systems. When tied with bureaucracy, these are often known as "Enterprise software."

How to reach out to me:

  • I prefer asynchronous messaging
    • Work Slack is absolutely the easiest way to reach me
    • SMS is second-best
  • Voice is also fine as long as it is a reasonable time or arranged through one of the async methods.

How to give me feedback:

  • I like feedback, and direct, actionable feedback is fantastic!
  • If it is serious, I like to have time to digest the feedback before I need to give a response, if possible.

Most of this is still true, but maybe it is time for an update!

A management perspective

As a manager who likes to make sure my team is happy and enjoying their work (to the extent that I can do so), I really like these.

When talking to new colleagues, I have a great way to start conversations ("So, where have you been climbing recently?", "How're the corona regulations in Canada these days?", "What type of photography do you like to do?").

They also help with giving and receiving feedback. Should I drop a note into Slack, then set up a video meeting? How blunt should I be? Should I expect to talk about the feedback immediately or schedule a follow-up meeting after they (or I) have had a chance to think?

But most importantly, we feel that the "Manual on Me" is a respectful, adult way to communicate preferences without trying to pigeonhole everyone into one of sixteen types.