Why I Don’t Have a Manager README

Despite being one of the most recommended manager tools

Last year I took charge of a new team. It was the perfect moment for me to write my first ever Manager README.

If you haven’t come across one, it is a document that tells your team how to work with you - your values, philosophy, quirks, expectations, communication style.

Engineering managers love them for three main reasons:
1. gets faster alignment and onboarding
2. establishes culture of transparency and vulnerability
3. sets clear expectations and ground rules

Sounds like a no-brainer. So why don’t I have one?

Because after trying and watching others do it, I found out that Manager READMEs create more problems than they try to solve. And there are better alternatives, which I share later in the post.

What problem READMEs try to fix

When someone (or an entire team) is new to working with you as a manager, they have some top of mind questions:

• “What kind of manager are you?”

• “When should I message you?”

• “How do you like to get updates?”

• “Is it okay to push back?”

• “What does ‘good’ look like to you?”

Answering these questions help the team to start aligning with you quicker. Without which, it can lead to assumptions and false starts.

So someone came up with the genius idea of a README, just like the one for a code repo, covering “how this works” but for a human.

Sounds reasonable but here are three main problems with that.

Problem #1: It creates a fake version of you

When you write about yourself, you don’t actually describe who you are. You describe who you wish you were.

So your READMEs often come out feeling either idealistic or generic, like they could’ve been written by anyone in the world. Example,

• “I value transparency”

• “I’m here to support you”

• “I prefer async communication but open to anything”

There’s nothing concrete here to disagree with or align to. It doesn’t help your team navigate real situations. Like how transparent are you really? Is it 100%, 96.7%, or 75%? Will you tell me if I’m on a layoff list?

You end up creating this sanitized, curated, idealized manager persona that your team will hold you against. You will miss your blind spots and your team will notice it.

“Umm, your actions don’t really match what’s in the document”

It shows lack of self-awareness. That gap erodes trust way faster than having no document at all.

Problem #2: It ignores power dynamics

The manager–report relationships aren’t neutral by nature. We as managers have power to impact their career, salary and what work they get to do.

So, when a manager writes:

“I value feedback. Feel free to challenge me”

It sounds good in theory but a new engineer will not take it at face value. They will think:

“Is it actually safe for me to push back on my manager?”

And no document can answer that. Because that trust is gonna get established with time, based on how you behave and what you reward.

Problem #3: It creates a one-way street

The biggest insight that changed my mind about READMEs is this.

When someone is new to working with me, they ought to know how I work. But shouldn’t I as a manager learn how they work? And how the team works?

Expecting team members to conform to my personality quirks and preferences establishes me as a rigid robot who doesn’t take into account the team’s context.

READMEs push the burden in the wrong direction. You’re saying,

“Here’s how to work with me.”

Instead of:

“I’ll adapt to how you work.”

That’s backward. A manager’s job is to be flexible based on the needs of the team, not the other way around.

---

What I do instead

So basically I need to solve the same problems that Manager README tries to solve but without all the baggage around it. I do three things for that:

1. An intro meeting

On day one, I setup time to meet the team virtually and shared a bit about myself - name, background, hobbies, family, etc. Then went around the room learning the same things about them.

I do this whenever a new team member joins the team. It may seen basic (boring?) but nothing beats real conversation when starting to build a relationship.

2. 1-on-1s

I immediately setup my first 1-on-1 with every one on the team and then found the best day to schedule a biweekly. First meeting is all about getting to know them better. I take the tidbits I learned in the general intro meeting and go deeper.

“Really, what kind of guitar you play?”
“You mentioned you do woodworking, tell me more about that.”

I may go a little deeper on the work stuff in the first or second meeting:

• “What’s working?”

• “What’s not working?”

• “If there’s one problem you could have me focus on, what would that be?”

And then with regular cadence, I can set clear expectations individually in this meeting.

3. Ask Me Anything sessions

In my first week in the new team, I setup a weekly AMA.

This way the team can get their burning questions answered live and hear directly from me. It’s better than a pile of text in the doc that doesn’t facilitate discussion.

There’s no pressure to read a document and memorize some arbitrary “core values”.

As a manager, it’s liberating to not have to abide by a doc I may have written in an ideal state of mind. I know I’ll evolve and grow, so will my team members’ understanding of me.

4. A Team Working Agreement

I highly recommend this instead of README, because this is about “what we need to do as a team to succeed” not focusing on you alone.

I wrote a full post on this subject back in December.

Creating Team Working Agreements

When your team succeeds, it’s not because they understood your quirks. It’s because they understood what their role is and what to focus on in the next 3, 6, 12 months.

---

Closing Thoughts

Manager READMEs are appealing because they sound like a good idea in theory. You write something, share with your team and the things just happen.

But you can’t document your way into trust. You can’t shortcut human relationships with a self-serving one-sided doc.

Writing a README is a tempting distraction from doing the real work.

Go spend time with the team. Dig deeper into what your team actually needs. And let them learn about you by your behaviors and actions, not through another process.

---