The Resignation Landed. What You Do in the Next 48 Hours Is Everything.

They walked into your office - or sent you a Slack message - and said: "I've accepted another offer." Your stomach dropped. This is the engineer who knows how the payment system works. The one that the rest of the team goes to when something is on fire. This is going to hurt. But what you do in the next 48 hours determines whether it's a temporary setback or a cascading disaster.

The first 24 hours: don't panic, don't counteroffer

Your first instinct will be to make a counteroffer. Stop. Take a breath. Before you throw money at the problem, understand what's actually happening. Ask the engineer why they're leaving - not confrontationally, but genuinely: "I want to understand your decision. What's driving the move?" Then listen.

Engineers who stay for a counteroffer leave within 6–12 months about 70–80% of the time. The underlying issues - feeling undervalued, stagnant growth, boring work - don't disappear because you added 5L to their salary. And now you've also signalled to the rest of the team that threatening to quit is the fastest way to get a raise.

If the reason is about work, team, or growth, a counteroffer won't help. Acknowledging this - "I hear you, and I understand" - is better than making promises you can't keep. In most cases, accept the resignation gracefully and focus your energy on making the transition smooth.

The next 48 hours: secure the knowledge

The biggest risk when a key engineer leaves isn't losing their productivity. It's losing what they know. Every senior engineer carries undocumented knowledge - why the system is designed a certain way, which edge cases cause failures, and where the configuration quirks are. Start the knowledge transfer immediately. Don't wait until their last week.

Identify the critical knowledge

Ask: "If you were hit by a bus tomorrow, what are the top 10 things someone would need to know to keep your systems running?" This surfaces the undocumented knowledge that lives only in this person's head.

Assign a specific person to receive the transfer

Not "the team" - a person. One engineer will shadow the departing engineer, ask questions, and become the new point person.

Record architecture walkthroughs

Hit record on a Zoom call and have the engineer walk through the systems they own. A 90-minute video of someone explaining how the payment reconciliation system works is worth 10x a written document — you capture the reasoning and context, not just the facts.

The first two weeks: communicate and stabilise

Tell the team promptly

Don't wait for the departing engineer to tell everyone individually over 3 days of awkward conversations. Announce it in the next team meeting: "[Name] has decided to move on. Their last day is [date]. Here's our plan for the transition." If you try to hide it or spin it, people notice. And they start wondering what else leadership isn't telling them.

Watch for contagion

When a respected engineer leaves, others start questioning their own situation. "If [name] thinks this company isn't worth staying at, maybe I should be looking too." Have 1-on-1s with the remaining team in the first week - not to be paranoid, but to check in: "How are you feeling about the transition? Is there anything about your own situation we should discuss?"

Don't badmouth the departing engineer

Even if you're frustrated. Even if you feel betrayed. The rest of the team is watching how you handle this and imagining what you'd say about them in the same situation. "We wish them well, and we're grateful for what they built here" is the only acceptable message.

The first month: backfill strategically

Don't try to hire a clone

The departing engineer's unique combination of skills was built over years at your company. You're not replacing them — you're hiring someone who can eventually fill their shoes differently. Hire for the capability, not the biography.

Start the search immediately

Every day you wait is a day your team is absorbing the extra load. Start the recruitment process the day after the resignation. If the notice period is 60 days and the hiring process takes 30–45 days, you can have a replacement identified before the engineer even leaves.

Consider internal candidates

Sometimes the best replacement is already on the team - a mid-level engineer who's been absorbing knowledge during the transition, understands the systems, and is ready for a step up. An internal promotion is faster, cheaper, and sends a powerful signal to the rest of the team: there's a growth path here.

The longer game: why did this happen?

After the immediate crisis is handled, take time to understand the structural issue. Ask yourself:

• Were they paid fairly? Not "what we could afford" — what the market says their skills are worth

• Were they given growth? Senior engineers need new challenges; if the work became repetitive, they were already half out the door

• Were they heard? Did they raise concerns that weren't addressed, suggest improvements that were ignored?

• Were they managed well? A strong engineer under a weak manager is a retention time bomb

The silver lining

Losing a key engineer feels like a crisis. But I've seen companies come out stronger when they use it as an opportunity: to distribute knowledge that was too concentrated in one person, to reassess architecture with a fresh perspective, to promote from within, and to fix the issues that caused the departure in the first place.

The best engineering leaders treat every departure as a data point — not a personal failure, not someone else's fault, but a signal that something needs attention. The companies that learn from departures retain better over time. The ones that just panic and backfill end up losing the next key engineer for the same reasons.