Tips for Remote Offboarding as a Product Designer
Five best practices when leaving your product design role.
Hey there! I’m Nicole, and I’m a product designer. I write this newsletter to share my experiences and lessons learned through my work.
In the process of preparing to leave my previous role, I did some research to figure out how to go about it in an effective and efficient way. My goal was to offboard as smoothly as possible, leaving my team and colleagues with what they need to continue successfully after my departure.
In my research, I came across two super helpful resources:
I followed these resources closely when preparing for and executing my transition. In this post, I’ll be detailing my own experience of what worked well, and what I’d recommend if you’re looking to leave your role. Let’s get into it 👇
Step 0: Before you submit your notice, think through the next few steps
First off, before making any kind of announcement: if possible, take some time to identify what steps to take to prepare for the transition process. Say that you’re in the final stages of interviewing for a new role, and you feel confident that you’ll receive an offer: now’s a great time to start preparing!
As a starting point, each of the steps outlined below will be helpful to start thinking through. You can also make note of anything else that comes to mind when thinking about your role and planning your departure. With this, the more time you can give yourself in advance of your formal transition window, the better; you’ll feel less rushed and overwhelmed and more prepared to deal with other things that might come up.
Step 1: Create a shared document with all your responsibilities and by whom they’ll be taken on
As product designers, we work with so many different roles and individuals – other designers, product managers, engineers, engineering managers or technical leads, and often other internal operations teams.
To avoid confusion and mass hysteria about who’s taking on which responsibility and when such-and-such is due, I found it helpful to create a shared Google Doc which acts as a single source of truth for everyone involved in your transition.
My document contained the following:
My current projects and responsibilities, in order of priority. Because I worked on multiple project teams, I also organized these by team, so it’s easy for different team members to zoom in directly to their section.
For each project/responsibility, I also listed out the project team members. This is helpful for everyone viewing the document and the designers who ultimately took on the projects to understand exactly who is involved, from product and engineering to stakeholders.
Which team member(s) is assuming responsibility for each project/task. For example, most of my responsibilities went to another designer on the team, but there were a few that were scattered amongst others. Tagging people in the Google Doc helped to highlight who’s responsible for what, and it also helped me keep track of whom I needed to meet with in order to hand off those specific projects.
Any other responsibilities that aren’t tied to specific projects. For me, that included tasks like leading team meetings or coaching junior designers on the team. In the same fashion as above, I listed out whom these responsibilities would fall on. If it was unknown, or if we weren’t able to decide who would take it on, I noted that as well – just so that my manager and others viewing the document could know which items were open-ended.
Prior to making the formal announcement that I was departing, I didn’t know concretely which team members would be taking on which responsibilities. I had hunches about what made sense, but I wanted to avoid making any assumptions and piling on more work to others during an already stressful time. So my approach was to first write the document with the projects/responsibilities only. Then, after I started the formal offboarding process, I met with team members (as a group and individually) to go through the document, bullet by bullet, and see if they could take on certain projects/responsibilities.
That was also a good opportunity to clarify project context, expectations, and deliverables to ensure that team members knew what they were signing up for. After reaching a consensus, I added their name to the document – and made it clear that going forward, they would be representatives of that project/responsibility.
This process worked pretty well, overall. It also highlighted where team members might need more help or guidance with taking on a responsibility, so that I could arrange additional meetings, resources, or documentation accordingly.
I shared this document with my manager, design team, product team, and the engineering leads I worked with. It became something that was referenced throughout my full transitioning-out process by everyone, especially the team members involved and my manager.
Step 2: Make a list of people (or teams/groups) you need to inform
Product design is a highly collaborative role, so chances are there will be various people outside your specific team whom you’ll also want to notify that you’re leaving.
For me, that included each of my team members (product managers and designers) plus close collaborators (marketing, engineering managers, leads of other internal teams, etc.) I was working in a smaller company, interfacing with multiple teams and wearing different hats – so if you’re in a similar situation, you might also have a longer list of people to inform.
As a baseline, here are a few individuals to start your list:
Your manager
Other designers and product managers you work closely with
The engineering team you work with, plus the engineering manager and/or technical lead
Any cross-team collaborators, like product marketing, customer success, etc.
Once you have an idea of whom you should inform, you can think through the how. This is made a bit more complex by the nature of remote work; if your company doesn’t have a formalized offboarding communications process, you might have to be resourceful.
We’ll go into what to say in the next section, but a standard best practice is to inform your manager first. Schedule a quick chat to inform them of the news, and then send a follow-up email (with your same points) afterwards, as a formal resignation letter.
From there, it’s up to your discretion (or company policies) about who to inform next. I opted to inform my design team, then the product team, and then the engineering teams I worked closely with. To do so, I utilized existing meetings that we had – meetings that happened the same day that I delivered the news to my manager or the start of the following day.
For others who I worked with but didn’t have as frequent meetings with (like those from product marketing or customer success), I sent an email to the department leads with the same news and let them know to also inform their teams.
It’s helpful to think through the order of how you’ll want to inform people – news might travel fast, but at least you can demonstrate thoughtfulness in taking the time to inform people yourself. Now that you have an idea of who to inform, let’s figure out what you should actually say.
Step 3: Iron out what you want to say (and practice in advance)
I was pretty terrified at the thought of delivering the “I’m leaving” news. Every time I tried to visualize it happening, my heart would race and I would feel a wave of anxiety. This was exacerbated by the fact that I had to deliver it multiple times, in various meetings and to various groups.
What I found to be helpful was writing out exactly what I wanted to say. I even went as far as writing it out for each group, individual, or session that I was planning to deliver the news at. When it came time to actually do it, I had my script ready and was able to read (or improvise) accordingly. And I found that after the first few times, it got easier and I could spend more energy being focused on the present – how people were reacting or what they were saying in response. So the preparation paid off!
When preparing to deliver your own “I’m leaving” news, I’d recommend the following format:
Start with appreciation. Regardless of your reasons for leaving, you want to end on good terms – so as a starting point, you can express gratitude for the opportunity you’ve had, the work you’ve been able to do, and/or how much you’ve learned from your time. My go-to was “I’m very appreciative of this opportunity to be a part of the team and to contribute such meaningful work. I’ve learned a lot from my time here.”
Segue into the details, including the date of your last day. You can soften the transition with something like “there’s no easy way to say this, so I’ll be direct,” but it’s best to get straight into it in a succinct way. My statement was along the lines of “That being said, I’ve decided that it’s best for me to move on from [company]. I’ll be putting in my two weeks' notice, and my last day will be [date].”
Conclude by emphasizing your support through the transition. At this point, it’s helpful to mention what you’re doing to support others during this time – that you’ve put together a transition document that you can share with them, or that you’ll be working with others on the team to hand off your existing responsibilities, or that others can direct questions to your manager. You can also tailor this to the group/individual you’re speaking with, in case you can foresee any specific concerns they’d have (for example, if you’re currently working with them on a significant project).
Depending on your role, projects, and the folks you work with, there might be different reactions, questions, or concerns. I found the resource from Elpha listed above helpful in understanding different situations you could find yourself in, from a counteroffer to concern and other questions.
At a high level, these are some points I found helpful in my own experience when delivering the news (and handling the conversations that followed):
Allow for silence. Some folks might have immediate reactions, whereas others will respond over time. Having a script (like the one described above) helps to keep you on track with what you need to say.
Stick to the points and maintain a positive tone. It can be helpful to have a few specific statements written down and practiced, such as that this decision is based solely on your own professional and personal growth, and that you’ll do what you can to support the transition until your last day. From the Elpha article: “It’s up to you what reasons you want to share when leaving. But generally, we recommend framing your decision so it’s not about the shortcomings of your current employer, and instead is focused on your own career growth.”
Only provide as much information as you’re comfortable with. People will likely be curious about what’s next for you; as the article states, “If you’re not sure, or not ready to share, you don’t have to! You can simply reply, ‘I will share how we can stay in touch once I am settled.’"
For team leads: Plan how to handle it with your team
If you lead a team or even if you’re a mentor to others on the team, news of you leaving can hit them hard. On my team, there were several junior team members that I mentored, so I wanted to be thoughtful in taking the steps to set them up for success even when I wasn’t there, and to help them feel prepared for what’s next.
Some of the steps I took to mitigate the fear and uncertainty:
Making myself especially available in my last two weeks. I emphasized with my team members that I was available to meet or chat about anything, big or small. I set up a few additional 1-1’s with junior team members to address questions or concerns. I also scheduled quick sessions with those who were receiving my projects to talk through context, details, deliverables, and any tips for success (especially if those wouldn’t be obvious at the start of the project).
Emphasizing the “longevity” aspect of our mentor/mentee relationship — as in, that our relationship doesn’t need to end just because I’ll be moving on to a new role. I reinforced my interest in keeping in touch with each of them and continuing to help in their professional journeys, however possible. (This can be especially helpful if you’re mentoring junior designers, as they can be worried about what your mentor/mentee relationship will look like afterwards, and they might not have had the experience of a long-term mentorship that transcends roles/companies.)
In my experience, offboarding was aimed toward clarifying boundaries with my mentees – not in a “I’m not available anymore” kind of way, but rather, “Here’s how you can continue to reach me, and for what kind of advice/questions/help.” I also found it helpful to discuss preferred ways of staying in touch, like social media or email. My goal was to leave my role with my mentees understanding how our relationship can evolve going forward – with this new chapter ahead of us.
Leaving your job is an exciting and nerve-racking process, but hopefully these tips help you feel more prepared to take the leap. Good luck! 💪
I hope you found this newsletter helpful! If you’re interested in reading more, subscribe for free and share it with a friend. You can also find me on Twitter (@wontonface).