Manager's Readme
Introduction
My goal is to put into the open all the thoughts I have, or the questions you might think about. I want to give you insight into my thoughts, so there's no confusion about my expectations. I hope it will make your lives a bit easier 🙂.
My role
I believe my role within the business is to make sure that our team works well. To that end, there are two things that I spend a lot of time doing:
- Helping the team grow & thrive
- Listening during refinements & putting solutions in place off the back of it
- Regular 1:1s to understand how everyone is getting on and where they want their career to go
- Unblocking my team regularly by understanding the problems we face & finding the correct person or process to follow to make progress
- Delivering our work on time (and to a high quality)
- Asking probing questions during handover & refinement sessions to elicit technical detail about what we are looking to build
- Ensuring everyone on the team understands what we are trying to achieve
- Estimating our work
- Planning our work based upon previous sprints' velocities
1:1s
Typically we will have 1:1s for 45 minutes every 2 weeks, but ultimately we should schedule these in for an appropriate frequency & duration that works for us. It may be beneficial to have more frequent or less frequent 1:1s based upon how you like to work & how we work together.
If you ever have anything that you want to discuss with me, you don't have to wait until your 1:1 to discuss it with me. If you'd like, feel free to add time to my calendar. If I'm fully booked, reach out to me directly, & I'll make time for you.
1:1 Content
1:1s tend to work best when we both come to the meeting with an agenda in mind. I would love it if you take some notes since our last meeting & come with a list of things to discuss, but I appreciate that sometimes you may not have anything.
With my own manager, I frequently have a list of topics to discuss with them. I will explain what is going on with the team & try to make my manager understand how to help the team thrive by pointing them in the direction of things they can improve/fix for us. Please do treat our 1:1 in the same way.
Generally during our 1:1 meetings I will try to cover the following topics:
- Catch up on a personal level
- Understand how you've been getting on at work
- Including any successes/achievements
- Including any mistakes/things that could have gone better
- Align on your path forward (by giving feedback, discussing problems, or sharing my thoughts)
Feedback for me
Much like every other human, I often make mistakes or say the wrong things at the wrong time. If this happens, I would very much wish for you to tell me so that I can reflect on it & improve for the future. I like to think that I take feedback well & would appreciate you raising anything you think I could improve upon.
Day-to-day
Working hours
I don't expect or necessarily want you to work outside of work hours. I think it's important for everyone (myself included) to have downtime from work & not having that can lead to burnout or other undesirable outcomes.
Annual Leave
A significant part of my job is making sure that we can complete epics on time & to enable this I need to figure out how many people are working during any sprint. By requesting your annual leave as far in advance as possible, this can help me out.
When requesting annual leave, I would like us to try to stick to the following guidelines as much as possible:
- 1 - 3 days leave
- Try to give me 2 weeks or more notice when possible
- 4 - 6 days leave
- Try to give me 4 weeks or more notice when possible
- 7+ days leave
- Try to give me 6 weeks or more notice when possible
At certain times of the year (Summer/EOY), I may ask you to think ahead three months & request your summer or festive leave. This is to help make sure that we have appropriate cover over the period & so that I can plan in our roadmap. Generally I will be able to accommodate any changes you wish to make, but it helps me to plan if you can think ahead with regards to any leave you are requesting.
Appointments or other out-of-office periods
I expect you to manage your own time with regards to our workload & do not need you to ask permission to attend appointments or other times when you will be out of the office.
If you will be out of the office for 60+ minutes then it would be appreciated if you could notify the team in Slack & feel free to mark it in your calendar as such so someone doesn't attempt to book a meeting with you during that time.
If you need to be out for 120+ minutes or more, please do fire me a message to let me know, but generally this will also be fine.
This is because people may depend on you, and it's better for everyone to know when a response is expected rather than guessing your availability.
Availability
- Slack
- There is no expectation for you to answer (or read) messages after hours or on the weekend. I suggest not installing the app on any personal devices.
- If you are working at odd hours, either:
- schedule your messages to arrive the following morning, don’t send messages immediately.
- Explain in your message that you don't expect a reply until the recipient is within normal working hours.
Planning & Sprints
As we follow Scrum, we have a few ceremonies that are useful to make sure that:
- The team is aware of what we are trying to achieve
- I can plan our roadmap with our PO into the future to understand what we can achieve on a longer-term basis & how best to align with wider departmental or company goals
Stand up
We have daily stand-ups to ensure we're making good progress on our committed work. During stand ups, it is vital that you raise the following issues:
- If you're stuck/blocked for any reason. I or someone else on the team should be able to assist in unblocking you, which may involve pointing you to the correct person to help out or spending time with you to work through things
- You don't know what you should be doing today. I or someone else can point you in the right direction about which tasks to pick up next.
Estimation (Refinement)
During refinement, we will make sure that everyone understands what we expect to accomplish as part of the user story or task. We will then individually estimate how many story points we believe the issue warrants. As a team, we will generally take the average value for this. I don't believe that going in depth about the difference between a 2 or a 3 is at this stage as it's generally just a guess. However in aggregate, I find these story points useful for planning purposes.
When pointing a task we should be pointing based upon complexity. This means that regardless of your title or ability, you should estimate based upon the perceived complexity of the issue being estimated & not on how long it would take you in comparison to someone else to complete the issue.
I will account for the team's ability to deliver or any relative difference in seniority or ability as part of my planning 🙂.
Retrospective
I will always attempt to create the current sprint's retrospective board at the start of the sprint to give you the opportunity to add things as & when you think of them.
On the board & during retrospective we should discuss anything that has affected you during the sprint. Sometimes the retrospective can just be a complaining session about w/e & that's OK.
Oftentimes, we will be able to solve problems during the retrospective, so please do raise anything that you want to change, and it's a bonus if you have a solution in mind.
Remember that you as the engineers will spend a lot more time coding & going through the deployment process than I will as manager, so if something is bothering you, please do raise it as I may not be aware of it or feel the pain that you do in the same way.
Ownership of features
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. When you finish the design, for most epics you’ll need to share this with the rest of the team for feedback, this can be done via posting confluence docs in slack or (particularly for more complex epics) in a design review meeting with the team.
- 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. Previously, we've used task breakdown sessions to accomplish this.
- 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 refinement session. I can’t promise you’ll get time right away - but I’ll try my best.
Things I value as an Engineering Manager
Taking the initiative
I'm more than happy to be a sounding board or to help out with any questions or problems, but I expect you to try first & come to ask me or the team to help out when you run into issues.
Ideally you would work on a problem & write down what you have tried so far before raising this with the team or myself.
I'd much rather you put your best foot forward & are wrong or make mistakes than freeze or delay working on something.
Good Examples
When doing UI/UX/technical designs, it'll be common to receive a bunch of feedback or opinions when sharing with the team. Some of this feedback may be contradictory.
Note down all of the feedback you receive during these sessions & afterwards, update what you believe is correct based upon the input & your understanding of the problem space. After making the changes, share this again with the team/PO, explaining the decisions you have made & asking for further input.
When you are working on a task, if you get stuck or are struggling in some way, don't wait on someone (probably me) to come & ask for an update. Write a brief list of what you've tried so far and what went wrong. Then, either start a Slack thread or ask for help from me or the team to get unblocked.
Challenging yourself & making mistakes
It's human to make mistakes when we are pushed hard or outside of our comfort zone. I'm more than happy for us to try new things or ways of working as individuals or a team, as long as we learn from any mistakes that we make & adapt after making them.
Summary
This document doesn't cover everything I believe in or think about, and it doesn'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.