The CTO just resigned. Or was fired. Or simply stopped showing up. The reason matters less than the situation you’re in now: a project in flight with no one at the technical helm.

This happens more than anyone admits. And the response in the first two weeks determines whether the project survives or spirals.

The first 48 hours

Don’t panic-hire. The worst thing you can do is rush to fill the role with whoever is available. A bad CTO replacement is worse than no CTO at all — they’ll make confident decisions based on incomplete context.

Secure access. Make sure you have admin access to all critical systems: cloud infrastructure, source code repositories, CI/CD pipelines, domain registrars, third-party API keys. If the departing CTO was the only admin, fix that today. Not tomorrow. Today.

Talk to the team. Not a group meeting — individual conversations. Ask each person: “What are you working on? What decisions are you blocked on? What did you rely on the CTO for?” The pattern in their answers will show you where the gaps are.

The first two weeks

Map the knowledge debt. The CTO held context in their head. Some of that context is in the code, some in Slack messages, some nowhere. Create a simple document: “Things only [name] knew.” The team will fill it surprisingly fast.

Identify the interim leader. Someone on the team is already the person others go to with questions. Make it official. Give them the authority to make day-to-day technical decisions. They don’t need to be the new CTO — they need to keep the project moving.

Reduce scope. Now is not the time for ambitious new features. Focus on: keeping production stable, finishing work already in progress, and documenting what exists. Anything else can wait.

The real risk isn’t technical

The danger isn’t that the code breaks. It’s that the team loses direction. Without someone making clear technical decisions, small disagreements become big ones. Developers route around uncertainty by building what they personally think is right. In three months, you have three different architectures growing in three different directions.

The fix is clear decision-making authority, not necessarily a permanent hire. An experienced consultant or fractional CTO can hold that role while you figure out what the organization actually needs.

When to worry

If the CTO left because they disagreed with the direction of the project, that’s a signal worth listening to. If they left because the project is in worse shape than leadership realizes, you need to find that out now. An external technical audit — by someone with no political investment in the outcome — will tell you what you’re actually working with.