A senior engineer’s resignation before payroll clears creates three choices: counteroffer, replace, or redesign the product plan around a smaller team. The right response depends on which loss the company can survive: cash, delivery capacity, or product knowledge.
Consider Kojo, a composite of bootstrapped founders I have worked alongside across Accra, Berlin and the US. At 9:12 on Monday, he was holding a mug of tea and rereading a four-line resignation from Daniel, the senior engineer who understood every shortcut in the product. Payroll had yet to clear. A customer demonstration was booked for Thursday.
Kojo had three possible replies open in separate drafts. He could offer Daniel more money, start recruiting immediately, or accept the resignation and cut the next release until the remaining team could carry it.
None was harmless.
Three replies, three different risks
The counteroffer felt fastest. It also consumed cash already assigned to contractors and hosting. Even if Daniel stayed, Kojo would still have a product whose critical decisions lived inside one person’s head.
Recruiting sounded more responsible. Yet a replacement could take longer than the runway allowed, and the Thursday demonstration would still arrive before a new engineer understood the codebase.
Reducing scope protected cash. It also meant telling the prospect that two promised capabilities would not appear in the demonstration. If the prospect walked, the company would lose the contract Kojo expected to fund the next quarter.
At 9:28, he had still sent nothing.
This is where founders often mistake urgency for clarity. A resignation produces immediate motion: salary comparisons, recruiter messages, access reviews, anxious calls with advisers. Those activities can postpone the harder decision. What must the company still be able to deliver if this person leaves on schedule?
That question changes the unit of analysis. Kojo did not need to save Monday’s plan. He needed a plan that remained credible on Friday.
Preserve decisions before preserving velocity
I have seen teams respond to departures by asking for documentation. The departing person then spends several days producing pages nobody can evaluate until the first production failure.
Kojo took a narrower route. He asked Daniel for a ninety-minute session on the decisions that could stop another engineer: where the AI output was constrained, which customer data paths were fragile, what had been deliberately postponed, and which apparently simple changes carried hidden consequences.
The distinction matters. Code shows what the team built. It rarely explains why one approach survived and three others were abandoned.
This resembles the problem in Designer Resignation: How Sena Preserved Product Decisions Before Malik Left. A handover earns its value when the remaining team can make the next decision without reconstructing months of context.
By midday, Kojo had found the real danger. Daniel alone understood a fallback that prevented uncertain AI output from triggering a customer-facing action. The feature looked complete in the interface, but its safety depended on a manual check buried in the operating routine.
If Daniel left without transferring that reasoning, the team could ship Thursday’s demonstration and still fail after it. The prospect might see a polished workflow built on an assumption nobody remaining could defend.
Cut the promise before adding the salary
Kojo withdrew the counteroffer.
That choice did not mean Daniel lacked value. It meant paying more would preserve the same concentration of knowledge while shortening the company’s runway. The salary increase bought time without changing the structure that made the resignation dangerous.
He also paused recruitment. A job description written during panic tends to describe the person leaving, complete with every skill they accumulated through circumstance. Kojo first needed to decide what work would remain after the release changed.
With three days left, he removed the automated final action from the demonstration. The product would prepare the recommendation, expose the supporting inputs, and require a person to approve the result. That reduced the engineering surface and made the uncertain part visible. It followed the same principle I use when evaluating an AI agent’s first irreversible action: keep human control where an error cannot be cheaply undone.
The prospect could reject the smaller demonstration. That possibility remained live when Kojo sent the revised agenda on Tuesday afternoon.
They accepted the meeting. The contract was still unresolved.
The first morning after the resignation
On Friday, Daniel’s name was gone from the deployment checklist. Beside each remaining step was the person who could explain the decision, perform the work, and recover if it failed.
Kojo had also rewritten the role he planned to hire. He removed several technologies that belonged to Daniel’s history rather than the company’s next six months. The new brief focused on the work the smaller roadmap actually required.
The useful response to a resignation is rarely the fastest way to refill the empty chair. Start by identifying the promises, decisions and failure controls that disappeared with the person. Then decide which of those the company can transfer, reduce or stop.
Before replying to the resignation, open the next release plan. Mark every item that only the departing person can explain. That list should shape the handover, the customer conversation and the eventual hire.
At 9:12 on Monday, Kojo thought he had lost an engineer. By Friday morning, he understood that he had lost a version of the company’s plan. The smaller plan remained deliverable, and nobody had to pretend the risk had left with Daniel.
Comments
No comments yet.