How I Planned My Maternity Leave as an Engineering Manager
Image Credit: Photo by Matt Walsh on Unsplash
As a manager of nine engineers with different responsibilities, I wanted to prepare for my maternity leave carefully. My goal was to leave everything well organized so the impact on others would be minimal. I’m based in Europe, so I’m fortunate to have generous time off to care for my newborn. I wanted to ensure my team wouldn’t be left without guidance during those months.
How to start the process
I first shared the news with my manager, skip level, and HR. A couple of weeks later, I told my reports and close team. You’ll know when the right timing is for you. It was important to me that they knew in advance. Being pregnant adds a lot to your calendar and might require adjustments to your agenda—at least it did for me. Having everyone in the loop made it easier to skip or rearrange meetings for doctor appointments, physiotherapy sessions, or exams.
Right after sharing the news, I started preparing my coverage plan. My main question was—where to start? I searched for examples and articles, but was surprised to find limited content, especially for engineering. Engineering is a male-dominated field, but engineering leadership takes it to another level. So it’s not surprising that most documented parental leaves are from a father’s perspective and rarely exceed two or three weeks. After my investigation, I found two helpful resources: https://www.linkedin.com/pulse/parental-leave-planning-framework-from-engineering-leader-kelly-ling-j0qdc/ and https://www.lennysnewsletter.com/p/how-to-create-an-exceptional-coverage (from a PM, but with a great template I adapted for engineering content).
About four months before my leave, I started with an empty document and a table listing my current responsibilities and their new points of contact. Starting early helped me ensure I assigned the right people and didn’t forget any responsibilities. I kept updating this document until I had a solid coverage plan for everything.
What and how to delegate
With a clear view of my responsibilities, delegation became the natural next focus. I carefully considered who would be the best interim manager for each of my reports based on their proximity, current projects, and domain knowledge. I ensured everyone felt comfortable with the arrangement and confirmed with all interim managers that they were available for the role, they would schedule 1:1s and provide guidance. Make sure to open a ticket or reach out to HR so they can update the necessary tools for expenses, PTO approvals, and other administrative tasks.
To ensure my team members’ progression isn’t impacted by my absence, I wrote all reviews with suggested ratings and shared promotion requests with interim managers. Since I’ll still be off when the next cycle begins, I also added future promotion suggestions so interim managers can prepare during the new cycle and include them in the yearly review. If applicable, write your self-review as well. As part of the responsibilities delegation, I included the projects and areas each engineer was planned to work on in the coming months, so even if the roadmap changes and defined projects are no longer applicable, they know which area they’re covering. Because we don’t have rigid teams and change what we contribute to very often, this was particularly important.
I was also heavily involved in the code review process, so I worked to optimize it so people wouldn’t depend on me. This meant having senior engineers review most of the code and other engineering managers provide final checks on feature risk. Making sure the process was clear would, hopefully, make it easier for engineers to keep their shipping speed.
Housekeeping can also be an incentive to process improvement. One important responsibility I had was to triage all of our recent product JIRA tickets. This was probably the hardest thing to delegate. I know how much time and energy this process can take, how important it is (especially for escalation tickets coming from support) and how easy it is to miss JIRA emails and updates :) We end up assigning a new person to this process, while also creating a Slack channel where the new tickets are posted. This was a big improvement as it’s much easier to track new tickets and loop people in on Slack than through JIRA comments.
On the other hand, not every responsibility needs to stay within engineering leadership. I realized Product Managers would actually make a great point of contact for some areas I was also responsible for. They know the area or feature and can certainly point to the right engineer when assistance is needed. One important change was adding the tech leads responsible for those product areas to recurring meetings with PMs, as they had not been included before.
Final Handover
Once the coverage plan was complete, the most important step was walking the team through it. I shared my coverage plan with the team in advance. While there were people with almost no questions, there were people with a lot of meaningful questions that I really appreciated and required more than 1 or 2 meetings to address everything properly. Everyone will handle it differently. Make sure to reserve enough time for this kind of discussion and 1:1s because they will be important for the person’s confidence in the times ahead. The last week was mostly to wrap up everything, adding a Slack status with my coverage plan URL (unfortunately, Slack doesn’t allow links on the status), an OOO auto-response email and share the performance reviews and private notes with the interim managers (I wanted them to be as up to date as possible, so I didn’t finish them much in advance).
Even with all of this preparation, I knew no plan would cover everything, but I trust I have prepared and provided the essential guidance for my team to handle everything smoothly. Most importantly, I trust them to make good decisions on the fly and support each other when things don’t go as planned.