A resignation before release weekend rarely begins with the resignation. It usually begins weeks earlier, when one engineer becomes the only person who can explain the release and everyone mistakes dependence for speed.
Consider Ama, an invented composite of product leads I have worked alongside. At 4:17 on Friday afternoon in Accra, she was holding a paper cup of coffee she had forgotten to drink when Kofi asked for ten minutes.
Monday’s release would move transaction alerts from a manual process into the product. Support had already prepared its customer message. The operations team planned around the change. Kofi owned the service connecting the new flow to the existing ledger, and he was leaving.
His final day would be the following Friday.
The release had one owner and several observers
Ama’s first thought was to save Monday.
She opened the release checklist and found plenty of names. Product had signed off on the acceptance criteria. QA had tested the main paths. Operations knew when to watch the dashboard. Another engineer had reviewed two pull requests.
Yet every difficult question still ended with Kofi.
What happened if an alert was retried after a timeout? Which configuration differed between staging and production? Why had one part of the deployment stayed manual? The answers lived across his memory, private notes and several chat threads.
The team had treated his presence as part of the system.
The warning signs had been visible. Kofi attended nearly every release call because nobody else felt safe making the final deployment decision. Reviews waited for him. When he took a day off, one change moved to the next sprint because the team could not confirm how it affected reconciliation.
Each event looked manageable on its own. Together, they described a product that could not move without one person.
Monday’s release was now genuinely at risk. Shipping could produce duplicate alerts that confused customers and increased support work. Delaying would break commitments already made inside the company. Ama had no clean option, and Kofi’s remaining week was too short for a broad “knowledge transfer.”
Friday’s decision was smaller than the release
Ama asked the team to stop preparing for a normal deployment.
That mattered because release pressure encourages the wrong kind of activity. People add meetings, write larger documents and ask the departing engineer to explain everything. The calendar fills while the critical uncertainty remains untouched.
Ama chose one narrower question: what could happen on Monday that only Kofi would know how to diagnose?
The answer changed the weekend.
Kofi walked another engineer through the failure paths rather than the happy path. They traced what the service would do after a timeout, where a retry could create the wrong customer state, and which production checks depended on judgment rather than an automated rule. The second engineer performed the steps while Kofi watched.
Ama also removed part of the release scope. One workflow would remain manual for another cycle. It was less impressive than the original plan, but the team could observe and reverse it without waiting for Kofi.
This is the same authority problem I explored in how Abena gained the power to protect a release. A product lead needs permission to reduce scope when the evidence changes. Without that permission, the release date quietly outranks the product’s actual condition.
The departure exposed a management decision
It would have been easy for Ama to describe Kofi as a flight risk the team failed to detect. That explanation would also have been convenient.
His resignation mattered, but the larger failure was the way the team had assigned work. They had repeatedly given the hardest path to the person most likely to finish it quickly. Each sensible local decision increased the company’s dependence on him.
I have made versions of that trade myself while building products on limited runway. The strongest engineer takes the urgent integration because the contract, pilot or release cannot wait. The work gets done. Then the next urgent task goes to the same person because teaching someone else feels expensive.
You save this week by borrowing from a future week you cannot schedule.
That debt becomes visible when someone resigns, gets sick or simply becomes unavailable during a production incident. By then, asking for documentation is late. A document can describe steps, but it cannot prove another person can make the decision under pressure.
The practical test is direct: can someone else deploy, diagnose and reverse the change while the original owner stays silent?
Monday became a controlled decision
On Monday morning, Ama did not ask whether the team still felt confident. Confidence was too easy to perform after a tense weekend.
She asked the second engineer to lead the release review. He explained the reduced scope, named the failure condition that would stop deployment and walked through the rollback. Kofi listened without correcting him.
That was the turn. The release no longer depended on Kofi translating the system in real time.
Ama approved the smaller version. The team kept the removed workflow manual and watched the first production events together. Kofi spent his remaining days closing the gaps the rehearsal had exposed, much like preserving product judgment before a departure in Sena and Malik’s designer handover.
The following Friday, Ama removed Kofi’s name from the release checklist. She did not replace it with another single owner. Two engineers were listed, and either one could explain when to stop.
Comments
No comments yet.