When a machine-learning engineer leaves with seven weeks of runway, the safer decision is usually to remove the product’s dependence on that one person before hiring a replacement. A new hire may restore capacity, but a simpler product boundary can protect the roadmap, expose what customers actually need, and keep the company alive long enough to learn.
At 4:47 on a Friday afternoon, Samira read the resignation email twice at the corner table of a café in Accra. Her laptop was open beside a cold bottle of water, and the engineer’s last pull request sat in another tab: a change to the model-serving pipeline that nobody else on the team could confidently review.
The engineer had given notice. The product’s central promise depended on a prediction model he had trained, tuned, and kept running. Samira had seven weeks before payroll and cloud costs forced a harder conversation with her two other teammates.
Replacing him felt like the obvious move. The job description was already half written.
Then she looked at the pipeline again and saw the real problem. They had built a product where one person owned the model, the deployment process, the monitoring logic, and the explanation for why a customer received a particular recommendation. Hiring quickly might fill the chair. It would leave the same single point of failure in place.
The part of the product that had become a hostage
Samira’s company helped small distributors decide which customers to call first each morning. The original product brief had sounded modest: rank accounts by likelihood to reorder.
Over time, the model had absorbed more of the workflow. It ranked accounts, suggested a reason, prepared the call list, and fed results back into retraining. The demo looked impressive. A sales lead could watch a list rearrange itself and immediately imagine a more productive team.
The customer conversations had been less impressed by the machinery.
One operations manager kept returning to a simpler question: “Can my supervisor change the list when she knows something the system does not?”
That question had been answered with a workaround. The team planned to improve it after the next release.
Now the engineer was leaving, and the workaround had become the decision. If Samira hired another specialist first, she would spend scarce time assessing candidates, explaining an undocumented system, and hoping the new person could take over before the departing engineer’s final day. The runway clock would keep moving.
If she cut the product back, the team could ship a call-prioritisation workflow that used transparent rules and allowed supervisors to override recommendations. It would lose some of the model’s sophistication. It would also give the remaining team a product they could understand, support, and change.
The bad ending was no longer abstract. A replacement could take longer than expected, the model could fail during handover, and a customer could discover that the promised intelligence depended on someone who had already left.
The decision was to preserve the job, not the model
On Monday, Samira cancelled the planned model expansion. She asked the departing engineer to document only three things before his final day: the data inputs that were genuinely reliable, the conditions that made a recommendation unsafe, and the smallest version of the ranking logic the rest of the team could operate.
The team then split the product in two.
The customer-facing workflow became a visible queue with reasons a supervisor could read: recent order history, overdue follow-up, a change in buying pattern. Staff could reorder the queue and record why. Those decisions became useful product input instead of exceptions buried in chat messages.
The model became an internal component with a narrower role. It could suggest a ranking where the evidence was strong. It could not decide alone, and it could not hide the basis for a recommendation behind a score nobody on the team could explain.
This was not a retreat from AI. It was a correction to the order of operations.
A team with limited runway needs to know which part of an AI product creates value today and which part creates fragility. If customers need a trusted next action, build the workflow that makes that action possible. Add complexity only when the team can own it after the person who introduced it has gone.
That same ownership question appears in The One Name Behind a Critical Workflow, and What It Could Cost the Team. A system can look healthy right up until the one person who understands it is unavailable.
What changed when the engineer left
Three weeks later, Samira sat with the same operations manager during a product review. This time, the manager moved two accounts to the top of the queue and added a note about a delivery issue that had not reached the product data yet.
The system kept the change. The team could see it. The manager did not need permission from an engineer to use her own judgment.
That was the landing Samira needed. The product had become less dependent on a person who was leaving and more connected to the people doing the work.
There was still a hiring decision ahead. A strong machine-learning engineer could help the company improve predictions, evaluate edge cases, and build a more durable model layer. But the hire would enter a product with boundaries, documentation, and a team that knew where human judgment belonged.
For founders, the useful question after a key technical resignation is not “How fast can we replace this person?” Ask which customer outcome would disappear if nobody replaced them. If the answer is “the model runs,” keep looking. If the answer is “customers cannot complete the workflow,” rebuild the workflow so more than one person can carry it.
Build a handover test into the roadmap
Before the next feature ships, run a simple test: could another person on the team explain what it does, change its main rules, and respond when it gives a bad result?
If the answer is no, the feature has created technical dependency disguised as progress.
Document the decisions that shape customer outcomes. Put approval paths around high-consequence actions. Keep the product’s core job usable when data is incomplete, a model is unavailable, or the specialist who built it has moved on. What Happens When Everyone Approves the Code but Nobody Owns the Workflow? explores the operational version of the same problem.
Samira still had seven weeks of runway. She did not spend them trying to recreate one engineer’s private map of the product. She used them to make the map readable to the team that remained.
Comments
No comments yet.