OffBoarding as an Engineering Leader

There have been a lot of blog posts written about finding a new job or starting a new job with a 90 day plan, but not as many about leaving your current job. Any engineering leader leaving a company has an impact on the people around them, especially if you have people reporting to you. Recently, as I went through a job transition, and was leaving my gig at InVision, I wanted to make sure I was making it as easy as possible for the interim/future managers to onboard and lead the team once I was gone. But most importantly I wanted to ensure no ball was dropped, especially for anything people-related. We have all been at the receiving end of having a new manager and a lot of times that means our promotion or a growth opportunity gets delayed. I wanted to make sure people are cared for, and none of this dropped on account of me leaving. So I wrote up a transition plan. This post is about sharing the various components of my transition plan, and I hope to hear from others who have written similar plans to learn from their experience.

The transition plan documents what you are responsible for (be it teams, people, projects/initiatives), its current state, any plans for its future state, the interim/long term owner, and the rollout strategy of this transition, including the communication plan.

People

When leaders transition, people who report to them are often impacted — career development and personal growth sometimes get reset, promotions get delayed, salary raises might get missed.

For the people who report to me, I focused on documenting the following as much as possible:

• Performance Reviews: Even if it is not performance review season, it is helpful to document any progress, accomplishments and growth goals you and your employee might have discussed. In the spirit of transparency, I share this document with each individual like I would for a performance review and, to make sure we both are aligned in my representation of the individual. This is an opportunity for the individual to not only review it but they also have a say in how they are represented as a part of the transition. I seek feedback from them on whether I missed anything or mis-represented anything. This also makes it easier for the next manager to have historical context, and helps carry forward any growth goals or opportunities you might have discussed. Yes, this did mean I was basically writing for two consecutive weeks. In the past, I have done these sessions as a 3 person meeting with the individual, their future manager and me.
• Salary/Equity: Sometimes folks are hesitant to bring up salary discussions with a new manager. If anyone needs adjustment or related topics have been discussed, they should be documented.
• Promotion Documentation: If you are transitioning close to promotion cycle time, it is helpful to get a head start on the promotion documentation for your employees and gather any evidence/data points and feedback you need. You have seen this person grow and believe they deserve this promotion, and there is no better advocate to document this than you. In the past, when an engineering leader was leaving a company, he reached out to me to be the champion for an engineer’s promotion on his team — to ensure I answered any questions which came up or if the document needed additional details, and to carry back any relevant feedback to the engineer. I thought this was a great mechanism to ensure there is an individual who had the explicit responsibility of carrying forward this promotion discussion. So I did the same. In some cases the interim/next manager is the new champion, but in some cases it might be someone else who is more familiar with this individual’s work.

For any stakeholders you work closely with (product managers, partner teams), focus on identifying the next owner for the combined deliverables, and ensure there is sufficient context transfer.

For any ongoing hiring, you should make sure there is both formal handoff with documented panel, questions and expectations and as well informal handoff providing any additional context like expected team fit, etc.

There is a fourth category of people whom I mentored and sponsored within the company who did not directly report to me that I wanted to make sure they had the support they needed when I left the company. It is possible to continue mentorship when you leave a company and these folks know I am always available to them. But when it comes to sponsorship, it is helpful to have an advocate within the company who can look out for opportunities for these individuals. For these folks, I reached out to other engineering leaders to ensure that these individuals were on their radar to reach out and check in once I left the company.

Team

The goal of the team transition document is ensuring all the team context is carried forward. For each of the teams I managed, I created a separate document listing details about the team and linking to any relevant documents which might already exist. I linked the current OKRs, any documentation to the team processes followed, team roadmap, and links to all the people documentation from the previous people section.

In some cases where I had a vision or plan for where I want to see the team go next in terms of process or culture, I made sure it was documented. I also wrote down who might possibly be good future champions for my vision. The future manager for the team might have a completely different vision, but nevertheless it is helpful for them to see where your headspace was at while managing that team.

Engineering Initiatives

Apart from my team deliverables, I had also been invested in improving some engineering practices across the company. For the ones which were an identified priority across multiple teams, and had a well documented timeline and plan, the transition was easier as it consisted of identifying a new owner and knowledge transfer.

The initiatives which I was personally championing, which were not associated with a team or a roadmap, I know are the most likely to fall off the radar when I leave the company. The key here is either to make sure it belongs to a roadmap or a priority list, or else has another champion identified and documented who will carry it forward.

Rollout strategy and Communication Plan

For each of the categories listed above we needed to identify an owner — either interim or long term. The written documentation served as handoff to these new owners. In some cases I also set up a meeting to go over these documents with the new owners. I would try to not keep this till the last day so that the new owner had sufficient time to go over the documentation and ask any questions they might have.

The final part of my transition plan was the communication timeline and messaging. Once owners have been identified (or there is a plan in place to identify them), I worked closely with my manager and peers to document what and when I am communicating to various teams and leaders so that everyone was on the same page, and knew when to reach out to folks to check in.

Transition Plan Format

For your transition plan I would recommend breaking it up into individual documents based on the level of access (one for each person, one for team, etc) so that you can set individual permissions at the document level. For example, the performance review document had permission access to both the individual and the interim manager. Then create a master document of the Transition Format, which was basically a google doc in my case, with a table with columns — What I am responsible for, Who will be the new owner, What is my transition plan, Transition Status. Here I made sure that my manager and relevant folks had access to it.

Conclusion

I am sure my transition plan has gaps or areas I missed that I will learn about eventually. But I hope this is helpful to folks who are planning to leave or change jobs. If you have written a transition or exit plan, I would love to hear from you about your experience as well!