A critical technical person or vendor disappears. The company still has customers, releases and bills due. Nobody knows exactly what disappeared with them.
Stay calm. No one is irreplaceable.
They may have been extremely important. That does not change the job: identify everything that depended on them and give it a new owner.
The immediate question is how to keep the company operating while you reconstruct what just disappeared. Choosing the replacement comes after you understand what actually needs replacing.
You need to appoint someone to execute.
Give that person responsibility and authority immediately.
The first 24–48 hours: establish control without breaking things
The CEO needs to make the appointment clear to the team: who makes technical decisions, who can approve releases, incident actions and spend, and what must come back to the CEO.
Name who will speak to engineering, customers, vendors and the board. Customers with active commitments need a reachable contact before a missed call becomes their first indication that something has changed.
Recover and verify control of the assets needed to keep operating:
- Source repositories, CI/CD and the deployment process.
- Cloud accounts, production systems, databases, backups and monitoring.
- Domains and DNS, secrets, admin credentials, app stores and SaaS administration.
- Vendor contracts, billing relationships, infrastructure ownership and documentation, including the relevant IP ownership records.
Verify that an authorised person can actually use the access. An account name in a document does not establish control. Check dependencies before changing credentials so you do not accidentally stop production. If the departure is hostile, trust is in question, access is compromised or there is a security incident, revoke questionable access and rotate affected credentials immediately.
For a disappearing vendor, establish who owns the code, repositories, hosting, cloud, domain and DNS accounts, and who controls deployment. Can company data be exported and restored? Check what the contract says about handover and termination. Identify any subcontractors or accounts held personally by people at the vendor. Find out which services stop if the vendor never answers another email. Source access alone will not keep the system running.
Maintain service. Do not rewrite, re-platform or promote somebody permanently because everyone is nervous.
Days 2–7: reconstruct their actual job
Before trying to redesign anything, find out what the missing person actually did.
Org charts and job descriptions are not enough. Reconstruct their working life. Talk individually to the people who worked with the CTO, technical founder or vendor every day, including people outside engineering.
Ask what they asked you for, what you asked them for, which decisions depended on them and what problems they repeatedly solved. Find out who relied on them and who they relied on. Ask what was waiting for their approval when they disappeared.
What was their mind busy with?
That question reaches the things they were watching, the questions people routinely brought to them and the things they were quietly fixing before anybody else noticed.
Follow the customer relationships. Which customers did they personally deal with? What had been promised? Where were expectations being managed informally? A roadmap can show a feature without showing the conversation that made its date important.
Do the same with vendors. Find the people who contacted them directly and the renewals, negotiations, problems and dependencies still active. Then follow the decisions: approvals waiting in tickets, releases awaiting review, migrations already in flight, support escalations and incidents that someone still needs to close.
Where legally and operationally appropriate, use company-owned evidence rather than relying only on recollection. Have authorised people review the relevant calendar and recurring meetings, corporate email, Slack or Teams, tickets and GitHub or GitLab activity. Compare those traces with customer meetings, vendor correspondence, contracts, the roadmap, release calendar, incident history and invoices. Keep access to that material limited to the continuity work.
You are recovering the work, decisions, relationships, promises and worries that disappeared with them.
If this person had a weekly call with the largest customer every Tuesday, somebody needs to know that before Tuesday. Recover what the call was for, what was discussed last time and what the customer expects next. Putting a new name on the invitation is only part of the handover.
If they reviewed releases every Thursday, somebody has to own that decision. Find out what they checked and what would have made them stop the release. If three vendors only ever spoke to them, those relationships need an owner. If everybody went to them before changing production, that informal control existed whether or not it was written in an org chart.
Record each discovered responsibility with the next action or date, the evidence behind it and the person covering it. Mark what remains uncertain. An unanswered question about a customer promise should stay visible until somebody checks it with the people involved.
Return to what they were worried about. What did they repeatedly check because they knew it could go wrong? Whoever takes over needs that answer more urgently than they need a beautifully documented architecture diagram.
Even if you bring in a senior external operator on day one, this is where they will start. They cannot responsibly arrive on Monday and invent a new operating model on Tuesday.
Keep the existing rhythm alive
For the first days, continuity beats cleverness.
Keep the existing machine moving in roughly the same rhythm while you establish what is safe to change. Preserve customer commitments, useful recurring meetings, reporting, vendor communication, support paths and a sensible release cadence. Make sure decisions continue to get made.
If the old release process relied on a check nobody can now perform, that release needs scrutiny. If a commitment is no longer achievable, tell the customer and agree what happens next.
Don’t cancel the meetings, rewrite the process and redraw the architecture all at once. You already have enough change to deal with.
The business should feel boring again.
That is success.
Week 2: turn assumptions into evidence
By week two, inspect the system properly. If production or recovery is already in doubt, obviously do this sooner. Bring in independent technical judgement where you need it.
Establish what systems exist, where they run, who owns them and whether they are recoverable. Have somebody other than the departed person or vendor demonstrate a deployment in a safe environment. Test a backup restore without putting production at risk.
Treat verbal assurances as hypotheses until checked. A handover can be tested by asking another person to carry out the work it describes.
Examine major technical debt, security risks and undocumented dependencies. Compare the roadmap and customer commitments with the team’s actual capability. Identify any other person or supplier on whom recovery or delivery now depends.
This is technical due diligence on your own company.
Weeks 2–3: give the recovered work an owner
Make the owners of the work you discovered explicit and visible. Engineering, IT and the vendor are not owners. Name a person.
Check that the engineer now covering releases has time for it, and that the person speaking to a customer can get a decision on the promise being discussed. Otherwise you can recreate the same dependency around the person who happened to answer every question during the first week.
Weeks 3–4: decide what the next model should be
You now have evidence to choose who should lead or support the technology next, and what the job requires.
Do not recruit a copy of the person who left simply because they left. The same applies to vendors. Changing the logo while recreating the same dependency fixes nothing. After two or three weeks of reconstruction and assessment, the company may discover that the role it actually needs is different from the role it previously had.
By day 30, everything will not be fixed. The business should be back under control, with the important unknowns visible and responsibilities covered. Put the remaining work into a 30/60/90-day plan. Make the next leadership or vendor decision from evidence rather than panic.
A CTO disappearing and a software vendor disappearing can expose the same failure: too much operating context depended on one person or one relationship, with no workable way to reconstruct it.
Good vendors and strong executives are valuable precisely because they carry context. They probably mattered enormously. A resilient company still needs to remain operable when someone important is unavailable.
The Tuesday customer call needs a person who understands the promise. The Thursday release needs someone who knows what must be checked and can decide whether it goes ahead. The worry that lived in one person’s head needs to become a risk somebody else can recognise and act on.
Once that work is visible and covered, you can decide what to keep, what to change and who should own it next.
When this matters
How do I keep the company operating when our technical leader or software vendor suddenly becomes unavailable?
Execution, not consulting.
If you are looking for another strategy deck, Safyron is probably not the right fit. If you need someone who will still be there when the difficult work starts, read how Safyron operates.