My CTO has left: take back the keys before hiring a successor

A familiar scene after a departure: somebody is looking for the registrar password. It was in the CTO’s head, or on their phone, or under their personal email address because one evening that was quicker. They hid nothing; they were simply, for years, the place where everything converged. That is what a departure reveals: not a gap in the org chart, the list of everything one person knew.

The CTO who leaves is not the problem. The problem is what they alone knew, and the first thirty days are for recovering it so you can define the lasting need. Reusing the old job description without that inventory means hiring before you know what work still needs covering. What cannot wait, on the other hand, is naming on day one who decides on the urgent matters.

This plan applies to a planned departure as much as to a sudden one, with a difference that changes everything: while the person is still there, during a notice period, half the work can be done with them.

The first week has one purpose: making sure that at least two people in the company can act on every critical system. Not one. Two. You have just lived through what the number one costs. The list starts with whatever gives control over everything else:

• the domain name registrar and DNS management
• the cloud provider’s main account and its billing
• source code hosting and the organisation’s owner rights
• the password manager and deployment secrets
• email and the account directory
• payment accounts, app stores and monitoring tools

An account opened with the CTO’s personal address, or two-factor authentication tied to their phone, blocks a handover for days. If the departure is planned, these transfers happen with them, before their last day. It is the first thing to ask of them, before the documentation.

Removing access is not proof that it has gone. The access that outlives the tools shows how to verify a removal, and the page on reliability and security places this work within operational risk management.

The next two weeks are for taking stock of what the company uses and pays for. Three sources, none complete on its own: billing, bank statements and the integrations present in the code. You cross-check them, and you always find a supplier nobody had in mind. The same inventory will be asked of you in a technical due diligence before a sale; it may as well already exist.

For each supplier, who pays, how, on what date, under which account. For each domain, the expiry date, auto-renewal and the registrant. For each contract, the term, the notice period and the signatory. For each integration, the data it receives and the access it holds.

A subscription paid with the CTO’s card may stop after their departure if the payment method has not been transferred. A domain nobody renews any more expires, takes down the site or the email, then gets registered by someone else who, as the article on email impersonation explains, can use it to send fake emails in the company’s name.

Part of what the CTO knew is written nowhere. How to deploy. How to restore a backup. Why that architecture choice. Which customer has a particular integration. While they are still there, their last weeks are for this first, and the only handover worth anything consists of having someone else perform each routine, in front of them. A procedure written by the person leaving and never replayed by the person staying is one more document.

After the departure, the same knowledge almost always ends up in the same place: with one or two people, often a lead developer, who become indispensable overnight. They asked for none of it. Indispensable means overloaded, then courted, and their departure becomes the next risk. Spot them straight away, to lighten their load and spread what they know before it matters; how to do that without alienating them is in Growing an engineering team.

The team health radar is a way to open that conversation without making it an appraisal: it compares leadership’s reading with the team’s, including knowledge sharing, without grading people.

A departure pushes you to decide quickly, because deciding brings relief. Resist. Four decisions are better off waiting for what the first month will teach you:

• a rewrite, a change of technology or hosting provider
• a reorganisation of the team
• new schedule commitments to customers
• a hire launched on the sole basis of the previous CTO’s job description

Each commits the company for months. Taken in the first week, it rests on what you do not yet know about the system, the contracts and the team.

One decision cannot wait, and it is the one that gets forgotten: who decides what during the interim. One person for incidents, another for priorities, a date for what comes next. A team copes with a month of vagueness about strategy. It does not cope with three days of silence about who decides.

Interim arrangements must cover urgent decisions from day one. To define the lasting replacement, the inventory then helps identify the decisions the CTO made and those waiting for an owner. The article Hiring a CTO details that investigation. The role to fill is almost never the one that has just been vacated: the previous CTO had shaped it around their own strengths.

To cover the interim, two formats are constantly confused. An interim CTO replaces the CTO full time, every day, until a successor arrives. A fractional CTO works a few days a month or a week, on an agreed scope. I work in the second format and have never taken on an interim assignment.

Fractional leadership is enough when a lead developer can run the team day to day, production is stable and decisions are made at the pace of the week rather than the hour. It then serves to take over the trade-offs, prepare the hire and support the successor’s arrival. It is not enough when nobody can run the team, incidents demand constant presence or a critical project needs decisions every day. Then you need someone full time: an internal promotion, a hire or an interim assignment. Telling you otherwise would be selling you something.

At the end of the month you have four things you did not have on the day of the departure: the list of critical access with two administrators for each, the inventory of suppliers and domains with their deadlines, the map of who knows what, and the list of pending decisions. With those, you can choose the replacement.

This plan does not guarantee you a month without incident. Nor does it tell you to hire: it sometimes turns out that someone internal already carries half the role, or that the remaining decisions describe a different position from the one that has just emptied. I want to be able to describe the work that needs taking over before looking for the person to take it over. When the interim can be held part time, the fractional CTO offer describes how that kind of mandate is framed.