A designer’s resignation becomes a product crisis when the team cannot explain who will make the decisions that the designer quietly held together. Before replacing the person, a founder should identify which choices, context and unresolved disagreements are about to leave with them.
At 8:17 on Friday morning, Sena saw the resignation email above the calendar reminder for stand-up. She had planned to spend the meeting reviewing onboarding screens with Malik, the only designer on her four-person SaaS team. Instead, she had to decide whether she was losing someone who produced interface files or the person who kept the product coherent.
Sena is a composite founder, but the decision is familiar. Her company served customers in Accra and London, had limited runway, and still depended on the founders to close sales. Malik’s final day would arrive before the next onboarding release. If Sena misread his role, the team could ship a technically complete flow that asked customers the wrong questions in the wrong order.
The work hidden behind the screens
The obvious response was to open Malik’s design files and count what remained unfinished. Two onboarding screens needed revisions. The empty state needed copy. Engineering had questions about what happened when a customer abandoned setup halfway through.
That list made the departure look manageable.
Then Sena asked Malik to walk through the decisions behind the files. Why did onboarding begin with the company’s current process rather than its desired outcome? Why had he removed the document upload from the first screen? Which customer objections had changed his thinking?
His answers exposed the work the files could not show. Malik remembered a sales call where a prospect confused “workspace” with “team.” He knew the engineer preferred collecting every required field upfront, while Sena wanted customers to reach the first useful result earlier. He had been resolving that tension in small comments, calls and prototypes.
Nobody had assigned him ownership of those decisions. The team had simply grown used to him making them cohere.
The replacement decision was premature
By 10:30, Sena had two options on her screen. She could begin searching for another designer that afternoon, or ask the engineer to implement the remaining screens while she covered product decisions herself.
Both options assumed the role was already understood.
A new designer could reproduce Malik’s visible output and still miss the judgment that shaped it. Sena could take over, but every hour spent reconstructing old decisions would come from sales, customer interviews or the roadmap. The engineer could ship the screens, yet unresolved product questions would then be answered inside code, often by whoever needed to unblock the next pull request.
The release was close enough to create dangerous confidence. Most of the interface existed. That made continuation feel cheaper than stopping.
This is the same pressure that appears when a working demo hides what Monday still needs to prove. I wrote about that gap in The Six Weeks Left After the Demo Works, and What Monday Must Prove. Visible progress can conceal missing ownership until the team has little room to recover.
Sena paused the search. By midday, she still could not promise the onboarding release would ship as planned. Delaying it could cost a pending customer conversation. Continuing without Malik’s reasoning could produce a release that created more support work and weakened the same conversation.
The bad ending remained possible: Malik would leave, the knowledge transfer would become a rushed folder handoff, and Monday’s product decisions would belong to whoever happened to encounter them first.
Reconstructing the decision system
With one week left, Sena changed the handover request. She did not ask Malik to tidy every file. She asked him to document the live decisions.
They worked through the onboarding flow screen by screen. For each disputed choice, they recorded the customer evidence, the constraint, the alternative they rejected and the condition that would justify revisiting it. They listed decisions Malik had been making alone, decisions Sena needed to own, and questions engineering could answer without waiting for a founder.
One disagreement surfaced immediately. Sena thought the missing document upload was unfinished work. Malik had removed it deliberately after observing that prospects hesitated when asked for documents before seeing any value. That choice could have disappeared with him and returned as a “quick fix” the following week.
The handover also revealed where Malik had too much authority by accident. He had been settling pricing-page language and onboarding scope because no one else made the call quickly enough. His resignation created the urgency to assign those decisions explicitly.
There is a related failure mode in automation and engineering work: execution begins while authority remains vague. Ama’s authority gap shows what happens when a team treats permission and ownership as details to resolve later.
What Monday needed to look different
Sena eventually opened the design search, but the role had changed. She was hiring for the judgment the company required, with clearer boundaries around which product decisions belonged to the founder, the designer and engineering.
She also moved the onboarding release. The delay was uncomfortable, especially with a customer conversation approaching, but it gave the team time to test the flow without pretending the screens carried their own reasoning.
On Malik’s final afternoon, the useful handover was a short decision log, a map of unresolved questions and a recording of the onboarding review. The polished files mattered. The record of why they looked that way mattered more.
On Monday morning, engineering raised a question about the abandoned setup flow. This time, it did not sit in a design comment waiting for the absent person who usually made everything fit. Sena knew who owned the call, what evidence had shaped the previous choice and what would have to be true to change it.
The resignation still left a gap. At least the gap had edges.
Comments
No comments yet.