How to make your team read your mind

Why writing a Manager's ReadMe is not weird

The worst thing you can do to your team is to not clearly communicate your expectations. Working with unspoken expectations is like solving a puzzle with no picture - everything is much harder than it needs to be.

It’s hard even with an extra hand! 😂

When people don’t meet your mysterious standards, everyone will be frustrated.

A few weeks ago (after 2 years in the current role - better late than never!), I decided to write down my ‘Manager’s ReadMe’.

Context

I’m currently leading a FullStack team of 4 developers, all of whom are at least a year on the team. I wanted to put everything together in a single document, and then we talked about it in a team meeting.

The point was to clearly discuss what I expect from each of them. What’s important to me, and what am I measuring myself on.

Honestly, I’m a bit scared to share this, as it gives a lot of room for criticism and ridicule. I decided to share the raw document, in hopes it’ll give you some inspiration. It’s not intended to be read as it is, but talked about. Please, don’t quote it out of context.

The most important part of this article is NOT the content of my Manager’s ReadMe, but the concept of creating such a document for yourself!

Enough caveats. A deep breath, and here we go:

---

---

The motivation for this document

My goal is to put into the open all the thoughts I have, or the questions you might think about. I want you to have a view into my mind, so there is no confusion as to what I expect. I hope it will make your lives a bit easier 🙂

My role

I believe that a big part of my role is to make sure our team works seamlessly without me. I’m measuring myself by those 2 things:

• Helping you improve. Thinking together about a career path you want to pursue, and finding suitable tasks to challenge you. Sometimes, it may require moving to another team, if I feel I have nothing to give to you. 
  Anton here: The conversation happened right after our most senior engineer moved to another team, because she wanted to specialize in frontend.

• Delivering our work on time (and in high quality). I try my best to understand the scope, consider the alternatives, estimate correctly - and help you execute. 

1:1s

I have 2 goals for our 1:1s:

• Catch up on a personal level

• Align on your path forward (by giving feedback, discussing problems, or sharing my thoughts)

I prefer to be intentional in the 1:1s with my manager - come up with my topics, share feedback, and push for things I want my manager to move. 

It’s a great opportunity for you to steer me in the right direction, use it. 

Our day-to-day

Anton here: We work 3 days from the office and 2 from home. Our daily is at 10 AM. I struggle a lot with it - on one hand, I think 10 AM is a very reasonable time to arrive at the office (we work until 5-6 PM), and I strongly prefer to do the daily in person. On the other hand, some people have trouble coming on time, and doing it on Zoom is not such a big downside.

Working from the office

• Daily - as you know, I strongly prefer for everyone to be in the office. 

• Planning day - this is my red line, we start at 10 AM, in the office. Take whatever buffers you need. 

• Working hours - I’m sensitive about this topic, as I was burned by a culture of measuring it. Always try to assume the best about other people. Each one has their own routine, no need to compare. Also, no need to announce you will continue from home if you leave early - I trust you to manage your own time. 

Working from home

You manage your own schedule, you have my full trust.

Please, when you are not working for more than an hour during working hours, put ‘out of office’ in your calendar. No need to ask permission or share the reason. Same for 'focus time' - if you want to code without distractions, just put it in the calendar before you start. I’ll know not to bother you.

The reason is that sometimes people depend on you, and it’s nicer for everyone to know when a response is expected.

Team Rep

Anton here: we work in an AgTech startup, April-August are crazy months for us, and the rest of the year is calmer in terms of production incidents.

As we are in the off-season, it’s less critical. But it’s still important, and a routine I would like to keep. 

• At the start of your day, go over the alerts of our Pagerduty channel, and see what was not acknowledged (by an eyes emoji) from the day before. 

• There might be things from the previous day - maybe the previous rep missed it, or was on vacation (and I missed it, or forgot). 

• You are not responsible for fixing the issues. You are responsible for making sure they are addressed. If in doubt, ask.

• Judge when it’s worth spending your time - don’t dig deep into test tickets. But make sure each alert is investigated. 

Bonus

If you understand why an issue is happening, open a ticket to fix it. Or if it’s very small - even fix it. Things like: threshold policies, null references, edge cases. 

Availability 

• Slack:

  • I expect you to be available during working hours, in a reasonable amount of time (unless you are out-of-office). 

  • There is no expectation for you to answer (or read) messages after hours or on the weekend. I suggest not installing the app. 

  • If you are working at odd hours, schedule your messages to arrive the following morning, don’t send messages immediately. 

• Whatsapp 

  • I will use our group for the very rare cases where I need someone to help outside working hours. If I send a message - please make an effort to help.

• Phone calls

  • During the season, make sure you have all the support people saved on your phone. They have a priority list of phone numbers for each system, always calling me first. If I don’t answer they’ll call you. 

Our work

Planning and sprints

Anton here: I know this part will be controversial. I would be happy to hear your comments :)

Estimating tickets is betting, we will never be 100% accurate. The goal of the planning day, is to improve our odds. Please use it for that purpose, and not to complete the previous sprint’s work. 

• Read the information in the ticket, in full. Don’t assume what’s in the ticket based on the title. 

• If something is missing - raise it to me or the PM. 

• Consider UTs, PR times, testing in QA.

When you commit to an estimation, I expect you to do your best to finish the sprint on time. If there is a small error in estimation, I expect you to work harder to deliver. 

But remember, that the sprints framework is not the goal, it’s just a method. No need to overwork yourself if there is no real deadline behind it. There might be tons of reasons to not complete a sprint - you handled a big production incident, the requirements were changed, you are blocked by someone else. You should know the priorities and what is time-sensitive, and if not - ask. 

Retrospective

On the last day of the sprint, think for a couple of minutes about what annoyed you during the sprint, or didn’t go well. Even better - try to think of practical ways to solve it. 

When I look back, most of the things that were actually changed were because you suggested solutions. 

I’m not escaping responsibility here - it’s my job to make sure the issues are addressed and improved. But it makes it a lot easier when there are concrete suggestions :) 

Ownership of features

Anton here: In our organization, the team leaders are also kind of tech-leads, responsible for both managing the people and doing the design for bigger projects.

Per my goal for the team to not be dependent on me - I want every feature to have a leader from inside the team. I’ll support you along the way, but I think that we are in a stage where you don’t really need me to lead the features. 

What do I expect when you lead a feature?

• A thorough design, frontend+backend. When you finish the design, for most epics you’ll lead a design presentation meeting (that’ll include the team, The VP R&D, QA Team Lead, the architects, and other team leaders if appropriate). 

• Ask questions. Don’t take anything for granted. Challenge the assumptions, and aim to understand WHY we are doing that epic. I’ll back you up. 

• Break down the epic into tasks, with instructions for each. Assume you won’t be the one implementing the task.

• Suggest the best way to divide the work, and take full ownership of that. Sit with the other developers working on your epic, and make sure they understand it.

• A feature doesn’t end when we publish it. Think about the relevant Mixpanel events (consult with the PM), and follow up on that. How was the feature received? What feedback did we get on it? 

• Gather feedback on your work. Ask me, the architects, other team members. Be specific, and aim to know where you could improve. 

Your initiatives

If something bothers you - it’s on you to fix it. Open a ticket, write the description, and put it in the next sprint’s board. I can’t promise you’ll get time right away - but I’ll try my best. 

Summary

The document didn’t cover everything I believe in or think about, and it didn’t aim to. It should have given you a general understanding of how my mind works, and what is expected from you, as a developer on my team. 

---

---

Presenting it to the team wasn’t a smooth experience. As they already knew my agenda on all of those items, they felt it was a sort of criticism. Still, I’m glad I did it, and only regret I didn’t do it sooner.

Such a document is not intended to be printed and hung on the wall. It’s a useful tool for you to think about your expectations and then discuss them with the team.

You may feel some parts are too strict, or too loose. That’s ok. Each company has a different culture. Take what resonates.

2 useful resources for you:

1. A template for this document - A Google doc with the questions that guided me, you can copy it (file → make a copy) and write your own ReadMe.

2. Manager’s ReadMe website - the site by Oren Ellenbogen inspired me to write mine, you can use the template there instead.