Anton here - this document is intended as a framework with examples. Please don't use it as it is, there are parts that are very specific to my team and culture.

How to read it:

The regular text will be the questions to answer in each section.
The italics text will be example answers to the questions

If you find it useful, please subscribe to my newsletter 🙂

The inspiration for this document came from Oren Ollenbogen's Manager's ReadMe website.

Intro

Motivation for this document

In case you want your people to read it (I suggest presenting it in a team meeting), why are you writing 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

What are you measured by? What do you consider your own success?

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.
Delivering our work on time (and in high quality). In the last 2 years, we delivered every project on time. I try my best to understand the scope, consider the alternatives, estimate correctly - and help you execute.

1:1s

How do you like to conduct your 1:1s, and why? Do you expect them to prepare something?

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)

Personally, I'm intentional in the 1:1s with my manager (and I was the same as a developer). I come with my topics, share my 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

Working from the office

How often should people come to the office? Are working hours important to you? How should the daily be conducted?

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 tell me you will continue from home if you leave early - I trust you to manage your own time.

Working from home

Especially in remote work - clear expectations are crucial! What are the working hours? Can people do leisure activities in the middle of the day?

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

Please, when you are not working for more than a hour during working hours, put 'out of office' in your calendar. No need to ask permission or give the reason. Remember that sometimes people depend on you, and it's nicer for everyone to know when a response is expected.

Team Rep

In each weekday we have a different team-rep who is responsible for production support. If you have any oncall duty, or equivalents, it's a good practice to specify exactly how it works.

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 out 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 for fixing it. Or if it's very small - even fix it. Things like: threshold policies, null references, edge cases.

Availability

How should the people be reachable? In what hours?

Slack:
- I expect you to be available during the 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 in the weekend. I suggest not installing the mobile app.
- If you are working at odd hours, schedule your messages to arrive in the following morning, don't send message 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 do 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

How does the planning process works for your team? What do you expect from your people in that regard?

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 on time.

But remember, that the sprint 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 Sunday (a working day for us, the last in the sprint - A.Z.), think for couple of minutes on 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 thing that were implemented 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

What do you expect when a team member is responsible for a feature?

Per my goal for the team to not be depended 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, 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, make sure they understand it.
A feature doesn't end when we publish it. Think about the relevant Mixpanel events (consult with the product team), 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

How do you treat initiatives in your team? Do you have a dedicate time for them?

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

My suggestion is to present this document in a team meeting, and go over it together. Writing it is mainly for yourself, please don't hang it on the wall or something like that 😂

Thanks for reading up to here :)

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.