Leading Through Change: How I Deal with Team Departures
My personal framework and approach to handling and navigating around a team member's departure
Welcome to the Captain’s Codebook newsletter. I'm Ilija Eftimov, an engineering manager at Stripe. Each week (or so) I write a newsletter article on tech industry careers, practical leadership advice, and management how-tos.
Management sucks, not because you get stuck in meetings. A lot of the meetings are good use of one's time. No, management sucks because when I get hit by a resignation, I have to absorb the blow. That's it. That's all one can do. I could've done something before to avoid the resignation. Or solve it. Prevent it. But once I hear a variant of that dreaded phrase "I resign", I see a massive black cloud forming over my head. And I can only embrace the shower I will get, compliments of Mother Nature.
I've embraced a few such showers so far, so I decided to document how I think about resignations and my opinions on best handling them. Again, these are my learnings and experiences, which might differ from yours. I'd love to discuss this in the comments!
Sidenote: In continuation, I will be using the word “departee” to denote the individual leaving the team/company. The alternatives were either too negative (“quitter”) or awkward ('“leaver”) or just too verbose (“Person leaving the company”). So I opted for departee.
Goals of the EM
Before I explain the steps I take to deal with a departure on my team, it's worth discussing goals. Every engineering manager should have goals in place when dealing with such situations. My goals as a manager are:
Ensure I understand the motivation behind the departure (i.e. the "Why?")
Ensure non-disruptive departure and smooth transition (i.e. the "How?")
Ensure clear handover of ongoing work (i.e. the "What?")
Part ways on good terms, i.e. do not burn bridges. It's vital when it's regrettable attrition.
Stifle the effects of the departure on the team's culture, vibe, work enjoyment, and feeling of psychological safety of the team members
Having these goals in place sets my priorities straight. It ensures I do the right things to retain a healthy environment in the team while giving the individual leaving a proper send-off.
The Move-on Maxim
Once the colleague blurts out, "I resign," you might think it's time to damage control or change their mind. I don't see it this way. Don't attempt anything. It's done. I like to ask them to elaborate on how and why they decided. While they do that, grabbing something to jot down the keywords is good. "Lack of opportunity". "Not fulfilled". "Not motivated". "Underpaid". "Found a better offer." And so on.
But whatever I do, I do not react. I actively listen. It's not the point to be a soulless robot and avoid showing emotion. There will be time for that. But first, I want to understand what this person is truly saying. Another big no-no is to turn the conversation towards myself. Empathy is critical here: the departee is making a major career (and possibly life) choice, so the spotlight is theirs.
Getting the knee-jerk reaction to somehow stop or unwind the just-announced resignation is to be expected. It's a normal human reaction. I've gotten it, but it's important to suppress it. Use "I see." Or "I understand". Or "I wasn't expecting this; I am processing." Or "That caught me off-guard; I am collecting my thoughts.” Whatever it is, I do not make counteroffers on the spot - they do not work anyway. Even if I did all the backflips and made them change their mind about leaving, the statistics say that over 50% of employees who accept a counteroffer leave the company within a year. Some reports suggest that this number can be as high as 90%. So, moving on is better than attempting to unwind the decision. I call this the Move-on Maxim.
Reasonable people spend a lot of time deciding whether to change jobs. By the time I learn about their choice - it's too late. Respecting their wish to move on is the best I can do. It'll go a long way. So, when someone is leaving - they're gone, and that's it. I make peace with the situation and try to learn from it.
There are exceptions, as with many things in life: if they appear to resign while being very stressed, like due to a big argument with me or someone else in the company. Then, I wouldn't necessarily try to unwind their decision, but I would slow them down. So, I see the departure as an overreaction to an acute problem. In that case, it's my responsibility as an EM to ask them to take some time off, de-escalate, sleep on the decision, and restart the conversation the next day or week.
Protip: if this happens - inform HR. In such cases, I do not ask for any action by HR. Still, I want to create an awareness with them that there was a resignation as an apparent overreaction.
What's next for them?
If the departee hasn’t shared their next steps with me, I respectfully ask what is next for them. Did they find a better job? Then congratulations are in order! They are excited for their next step, and so should I. I put myself in their shoes. If I decided to change jobs, I would want people I respect to be excited for me.
I express that the team will miss them, but I am also genuinely happy for them and want to see them be happy and succeed. I wish them a ton of luck in their next endeavour. Even if it's non-regrettable attrition, I am supportive and excited for the person. Maybe they didn't gel well with me and/or my team, but they can still flourish in their next team or company.
Why should I know their next steps?
I find it essential to consider the combination of factors when someone resigns. Such as how they give their resignation, explain their reasoning, and their next steps. When considered together, these factors provide insight into what went wrong. For instance, if someone resigns without finding a new job first, it could suggest that they were so unhappy with their current work situation that they didn't bother to find another job before quitting.
I consider a few things when creating a narrative around someone's departure. These include their work history, performance over time, tenure length, motivation, and any prior signals of dissatisfaction. Additionally, it's crucial to think about growth opportunities, whether they felt challenged and engaged in their role, and if they had a clear career path.
I also consider collaboration and work-related factors should also be considered, such as friction with other team members, the adequacy of their projects, and their level of engagement and motivation. Stress and burnout are also important considerations, including workload, concerns, and periods of high pressure or tight deadlines.
Finally, I reflect on any recent pushback I've given the individual. For instance, if the employee received difficult feedback or had their requests for a promotion or raise denied, this can be a factor in their decision to resign.
Setting Expectations & Handover Plan
Once I understand how the departee decided to leave the company, I move on to set up some expectations around the process. HR usually directs the departure process. I am more interested in setting expectations regarding what I would like the departee to do before they're free to go.
They're free to go at any moment from a legal perspective. But assuming they want to do the right thing, I give them a rough outline of my thinking. I like to lead with a transition plan, co-authored by us, to cover the following items:
What are their responsibilities, and who will take them over, or whether they're simply going to be phased out.
Knowledge they need to transfer, either by writing it down or by training other team members (1:1 or via presentations)
Projects they intend to finish before they depart. Ongoing projects should be the lowest priority. It's more important that we set the team up for success without the departee, than that you write a few more lines of code.
From here on, we will write an inventory of items that fall into the three buckets above, and we will prioritize. Once we complete the list, the departee and I commit to it. Then, we are off to the races.
Before the announcement
Before I tell the team we're losing a valued team member, I want to lock down a few things. First, I want to know the individual's motivation for leaving the team or the company. Knowing that is essential because it will be a recurring theme in the next 1:1s with the remaining team members.
Ongoing responsibilities
First, I resolve the departee from their ongoing responsibilities. What responsibilities they have should already be outlined in the handover plan. Think of project leadership, ongoing code development, or some design documents or reviews that are in flight. All these need a decision: transfer, complete, or drop.
If they're a project lead, the handover plan must detail a handover to a new project lead. It's up to me to figure out who that will be. There's flexibility here, e.g., if the project is near its end, it might be easier to ask the departee to stay until they ship the project. In contrast, handing over to a new lead near the completion of the project might jeopardize the timeline. Use the flexibility.
My experience shows that ongoing code development should be simple. The departee can either get the patch(es) merged before leaving the team, or not. Folks like to ship their stuff before they leave, so this should be a non-issue in practice.
Securing Backfills
The ease of replacing someone can drastically vary depending on how the company operates, its size, and its processes. That is, leaving aside recruiting the actual person. Some companies are process-heavy, so getting the backfill request in HR's system ASAP is good practice. I've seen managers struggle to get their backfill requests approved for months. For example, I've seen this happen because finance reprioritizes budgets between organizations, eventually forcing the manager to backfill their departee months later.
So, I get to know the process immediately once I get the resignation and follow through. By the time the handover plan is in shape and I communicate the departure with the rest of the team, my recruiters will already have people interviewing for the role.
Inform my manager
The relationship an engineering manager should have with their manager is a whole topic in itself. Keeping them in the loop on what's up with my team is of the essence. When I get the resignation, I immediately communicate that with my manager.
I like to explain the context around departure, e.g., they've found a better-paying job – an essential first signal for the manager to think whether there's a bigger problem at play here that is not immediately obvious to me. Next, I explain the severity of the departure on the team. I ask myself, "How disruptive is this departure for the team?". Every team member has a specific expertise that will leave with them. The departee might be a project leader. Or perhaps a mentor to another engineer. Some individuals can be culture builders or bar-raisers. I must communicate these critical aspects of the departee, so the manager is in the know.
Lastly, I inform my manager about the backfill request I've submitted. If it still needs approval by then, I would ask them to help me accelerate the approval.
Inform HR
As I mentioned before, the departure process varies between companies. Nevertheless, I inform my peer(s) from the HR team about the departure as soon as possible. In my experience, HR will try to do two things:
sniff out the departure on the fly to check if there's something odd happening
provide directions on the next steps of the process, with some documentation or checklists to follow
It's HR's job to ask about the motivation behind the departure, the next steps of the departee, etc., as they will try to assess whether there's a bigger problem in the team at play. I should already know the context at this point, so preparation is optional. Assuming there's nothing odd at hand here, it should be a casual conversation.
Announcing the departure
At this point, I have done a lot of work with the departee, my manager, and HR. It's time to spill the beans. Managers announcing departures is very old-school to me. I prefer if the departee shares the news. It's their news, not mine.
I like to be mindful of the timing. I think about big annual holidays, where people take time off. If I can avoid it, I like to delay the announcement until everyone's back from break. A good example is the end-of-year holidays and New Year's. I like to send people off to the holidays on a high note. We'll be back in business soon enough.
The announcement is, in fact, three separate announcements. The first is my communication with my closest allies. The second is for people that need to know sooner than the rest. The third announcement is for the rest.
The first announcement
I like to keep my peers and allies informed as soon as possible. I trust my network of other EMs, engineering, and product leaders to share departure news. I emphasize that I share the news soon after I receive it. Early sharing of the departure helps others have a better short-to-mid-term look at my team. For example, if my peer EMs know that an individual will leave my team in four weeks, it will be easier to discuss horizontal commitments. Or projects we've been planning to kick off together. Or cross-team dependencies.
Also, it implicitly sets expectations for others. They can expect the team's productivity to drop when they know it's losing a valuable member. So, keeping my peers and partners in the loop is the best way. I make sure they understand to keep the news under wraps.
The second announcement
The first announcement should be a collaborative effort. I co-create the list of people with the departee. Putting people on that list should be intentional. We then decide on how they'll share their departure news - the departee can invite them on 1:1 and spill the beans. Or they can share the news in a group setting. It's all up to the individual how they want to do it.
Assuming that this entails the people on my team, I like to be intentional in handling the departure's immediate after-effects. I like to schedule 1:1s with everyone a day later so people have time to process the news. The EM's reaction is essential, as it sends a message to the team, so I want to start immediately. Chatting on 1:1s the following day is enough time to process. The last message I want to send to the remaining folks on my team is to appear disinterested in the person leaving the team. EMs should appear confident, calm, and collected. Not disinterested.
In these conversations, I focus on the thoughts and feelings of other team members. How are they feeling? What are they thinking about? How do they see their teammate's departure? In their opinion, what are the reasons? The consequences? What could've we done better? What could we do better? The list goes on. The key is to probe enough times so they open up and we have a candid conversation. The last thing I want is for people to keep their thoughts and feelings buried - a source for other problems down the line.
The third announcement
Once the team knows, the word will spread out fast. Knowing this, I ask the leaving individual to message the broader organization about their decision. It's also good to share the message with other cross-functional team partners. I ask them to keep it short and sweet. Email or Slack, it's their choice. That's it.
The future of the team and beyond
As no two people are the same, no two people leaving the team are digested the same by the team. The effects can vary. As the EM, I want to be grounded and acknowledge the departure. Suppose I do not pay the proper respects to the departee's achievements on the team. In that case, it might come across as disinterested. Or as disingenuous, like I am downplaying the effects on the team.
The people I work with are smart, so I keep it bullshit-free. I acknowledge the departure, but I do not dwell on it. It's a job that someone leaves. Sure, it's sad, but it's not tragic. Next, I switch the focus on the future, the ambitious goals that we have ahead, and the exciting future. If needed, I list the mission, the goals, and the projects that we have ahead. I reminisce on the team's prior achievements and verbalize my excitement.
Staying on good terms
Our industry is a microcosm. Burning bridges is never a smart idea, as one never knows when an ex-colleague or a business connection might prove valuable. The same applies with folks leaving the team - as disappointing it is, I believe it's paramount to make it a pleasant experience for everyone involved. I would hate if the first reaction of the people I've worked with is "what a dick". All bridges should remain intact. Or perhaps even reinforced.
So, in continuation, I will share a few ideas on how to give people the opportunity to leave on good terms.
Suggest exit scenarios fitting to the motivation of the departee. If they hate working with a particular individual, I will figure out how to hand over work without them having to interface with that individual. Same with projects or codebases. In their last days in the company, I limit the exposure to said project/codebase. I am willing to work to get a pleasant after-taste for all involved.
Make the exit as swift as possible. We covered this before: when someone leaves, there's no point in holding the person back. The opportunity to fix the problem has gone past. I own it. I opt for a swift exit and bear the pain for a bit. For example, offering an extended leave of absence wastes everyone's time. Practice shows that people who usually take longer leave will never return anyway. And even if they come back - there's a good chance they will only stay for a while. The best case scenario will be to leave for another team, so at least the company retains the talent.
I make sure they use all their vacation days. Pulling shady shit with their PTO time will undoubtedly burn the bridge. I encourage the departee to use all their vacation days before leaving. And not only that - I make sure they do it. For them to use their PTO, we need to account for it while making the handover plan and setting their exit date. The only alternative is to reimburse the departee for their remaining vacation days. Reimbursement should be something other than a go-to - only when departee demands it and the company allows for it.
Offer a recommendation letter. I extend such offers only genuinely; if I do not believe the person leaving deserves it, I don't offer it. Full stop. I avoid half-assed recommendations at all costs. In some companies, HR regulates and reviews recommendation letters. For example, I've heard that Amazon has a recommendation letter tool managers can use to piece together a recommendation letter. HR then reviews and approves the generated letter before the manager can send it to the individual.
Aside: My litmus test to decide whether I should write someone a recommendation letter
Assuming the person that leaves has sorted their shit in 3 months, would you hire them back in a heartbeat? If the answer is yes, I will give the recommendation. If not - I emphatically reject it.
Offer to be a reference. Many companies ask for one or two references to perform a reference check during hiring. These are usually people that the candidate has worked with, commonly a peer and a manager. As the manager, it's cool to offer to be a reference to the departee. I apply the same judgment as on the recommendation letter - only genuine offers. If I have doubts, I stay clear of the idea.
And that’s it for this week! If you liked this, consider doing any of these:
1) ❤️ Share it — Captain’s Codebook lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!
2) ✉️ Subscribe — if you aren’t already, consider becoming a subscriber. Seeing folks read the newsletter energizes me and gives me ideas to write.
3) 🧠 Let’s chat — I am always on the lookout for questions to answer, to help out with challenges, or topic ideas to cover. Hit me up on LinkedIn, Twitter or send me an email to blog@ieftimov.com.
Until next time,
Ilija