Something about that post didn’t sit right with me. It made it to hacker-news and the comment section gave me a few clues on why I had such an allergic reaction to the post. I have had to a few times in my career, write a user guide like Julie described. I’ve always found it uncomfortable, but never dug deeper. I wrote the document and carried on, treating it as a piece of paperwork that I have to get out of the way.
The purported aim of creating this document in a Silicon Valley tech company goes somewhat like this (it’s a bit tongue in cheek)
- Most, if not all, organizational friction is due to communication issues
As a manager/leader your job is to increase output and reduce this friction
Discovery of communication styles is lossy (why can’t there be an API for this? :))
Communication needs to be disrupted, and what is communication anyway, it is the same as code
Let us document it, wouldn’t it be great if there was a document that laid out everything about you!
A user guide for you is born
This guide always fails. A few key reasons
Its always aspirational
Your natural human nature is going to push you towards documenting the aspirational side of you. You are going to describe your ideal management style – which is not a true reflection of what you are like in real life. There is an overwhelming need to signal that you are a great manager! Signaling is everything!
It’s also a great excuse
The user guide also serves as a great opportunity to excuse all your bad habits/behaviors that you don’t want to fix. Its easier to write it down in the user guide as a behavior that’s just you. Examples like: I’m always late for meetings (Julie uses it in her document)., I’m not good at following up. The user guide makes your flaws somebody else’s problem to deal with. Hey, I told you I was flawed, why are you asking me to change?
Nobody reads it
Just like documentation for everything – nobody reads it! Its written, filed, wiki’ed, and forgotten. This is not a tool issue, it is a people issue. When there is a communication issue/conflict between two people, looking up a document is never going to be the first thing they do!
Fundamentally I believe that the user guide to you is the absolute wrong way to solve this problem. The belief that, if you are explicit and document the problem, it will automatically be solved – is just wrong. This is an anti-pattern that is very prevalent in companies especially software companies.
- People don’t get along → let us make sure roles and responsibilities are documented → problem solved
People don’t know what to work on → let us make sure there is a goal-setting tool→ problem solved
People don’t follow a process → Lets document the process→ problem solved
People not working well with a manager → Lets document and make a user guide → problem solved
Documenting the problem, alone does not solve the problem!
The real solution comes from talking 1×1 and building real connections and trust. You have to work together in the trenches. A manager has to spend time doing the nitty-gritty. You have to via 1×1’s and team rituals figure out each person’s strengths and weaknesses. You have to be the glue that binds everyone together to create a trusted environment that leads to a high performing team. You cannot outsource it to a document!
The right mental model to think about this is that as a leader you are the editor of the team. You are not the talent, your team is. They are the ones doing the work. Your job is fine-tuning. You should be in the background, you are serving the team not the other way around. By writing a user guide, you are signaling that you are the important person here. Everyone has to adjust to you and you are now in the foreground. It is about you and not really about the team.
The User Guide isn’t really about better communication, it’s just signaling…