Your CTO has a departure date. Your next release and vendor renewal have dates too, and neither waits for a new hire.
This page covers departure. If the lead is overloaded rather than leaving, start with the mandate comparison.
Short answer. Look for release exceptions, architecture trade-offs, vendor and hosting renewals, security-exception approvals and product–engineering disputes due around the last day. These are illustrative categories, not a measured ranking or complete list. Record each decision, account and knowledge dependency and who has accepted authority before choosing a replacement role. Three steps:
- List the decisions due before the next business milestone, each with a date.
- Sort each gap by type: missing decision authority, unclear account control, or knowledge held by one person.
- Agree a temporary mandate: a named owner who accepts it, limits the sponsor authorizes, and an escalation route.
An ownership-gap record is an entry per decision or control dependency, with a status of unknown, proposed, accepted, verified or blocked. It is a who-decides, who-controls, who-can-explain list; a proposed owner counts only after they accept and the sponsor authorizes.
Want to talk through your map? Talk with the Grand Rounds curator about relevant CTO experience.
Start with the next decision, not the empty job title
Use the release calendar, roadmap, vendor commitments and departure date. List the decisions due soon, their latest useful dates and the dependency if they wait. The sponsor authorizes the temporary remit; specialist reviewers retain their own approvals.
Separate three kinds of gap
Track decision authority, account/contract control and knowledge separately. Confirm administrative continuity with authorized administrators, then have a receiving person walk through an imminent decision using the handover material. Keep secrets in the existing vault.
If the trigger is a missed milestone rather than departure, verify what you own with the team is busy but your product does not ship.
Copy this ownership-gap record
Copy one record per decision or control dependency. Give each field a status, evidence locator, owner, next check and escalation. Confirm acceptance, authority and capacity independently.
Start with four fields: decision and due date, proposed temporary owner, authority and exclusions, acceptance. Expand the record only where the dependency needs it.
| Field | What to record |
|---|---|
| Decision and due date | The question that must be answered; when the answer is needed |
| Business dependency | The release, customer commitment, spend or other event it affects |
| Current coverage | Who handles it now; whether their involvement ends at departure |
| Evidence and knowledge | Relevant document or system location; what the recipient still needs explained |
| Account or contract control | Required role; who can confirm it; verification status, using evidence locations and authorized roles |
| Proposed temporary owner | Person or role being asked to decide—not just attend meetings |
| Authority and exclusions | What they may approve; budget/product/specialist decisions reserved elsewhere |
| Acceptance | Owner's agreement and sponsor authorization, with date; otherwise “proposed” |
| Execution | Internal team or selected supplier responsible for carrying out the decision |
| Escalation and backup | Who resolves an out-of-scope decision, or covers an unavailable owner, before the deadline |
| Handover | Recipient, material to transfer, review date and how receipt will be confirmed |
An invented example: the lead can ship, but cannot renew the vendor
Invented example: a B2B product’s CTO leaves in three weeks. The engineering lead can run delivery; a customer release falls before departure and a hosting renewal after it. Use the table to split release authority, spending/signature authority and account continuity. If daily delivery consumes the lead’s capacity, the sponsor must move duties or arrange cover.
| Item | What the map reveals | Proposed repair, subject to acceptance |
|---|---|---|
| Release scope, due before the customer commitment | The lead can assess technical readiness; product and CEO still own the commercial scope change | Lead decides technical readiness within agreed criteria; product and CEO resolve any scope or date exception |
| Hosting renewal, due after departure | Lead can assess technical fit but has no spending authority | Lead prepares the recommendation; the authorized budget holder decides spend and the authorized signatory handles the contract |
| Repository organization continuity | The team has working access; the remaining administrative coverage awaits confirmation | Authorized administrator confirms the appropriate owner arrangement and records the evidence location |
Completed record—same invented hosting example:
- Decision and due date: renew hosting, 12 days after the CTO's last day.
- Current coverage: CTO; ends at departure.
- Account or contract control: CTO signed the contract; next authorized signatory unconfirmed.
- Proposed temporary owner: engineering lead, technical recommendation only.
- Authority and exclusions: lead has no spending authority; budget holder decides spend.
- Acceptance: proposed, not accepted.
- Escalation: CEO.
For this example's planning horizon, date the release decision two days before departure and the repository-administration check five days before departure. Both assignments remain proposed pending the relevant owners' agreement.
A profile to read for a temporary mandate
A career example, as stated in the CTO's profile—not a recommendation for your situation:
- As stated in Andrew Frith's profile, his experience includes Group CIO work at Cloudfm. Ask which decisions and handover responsibilities he personally covered; confirm the mandate you need rather than inferring it from a title or a past role.
Experts' availability and the form of any engagement are confirmed through the curator.
If the map shows a leadership gap
As an editorial planning heuristic, move to format selection when each decision due before the milestone has a date, gap type and status, and at least one remains unknown, proposed or blocked after asking current owners. If dates or gap types are missing, complete the record first. If all decisions have accepted owners with capacity, retain the arrangement and set a review date rather than adding a role by default.
The invented example can move to comparison once its dates are recorded: spending/signature and administration gaps remain proposed. This is preparation for a decision, not a validated test of leadership need.
The sponsor agrees delegated and reserved decisions, coverage, backup, escalation, the end condition and receiving owner. Bring the filled record to a curator conversation to discuss relevant experience; any actual scope, timing or participation requires confirmation.
- Current team can cover it with a narrow escalation route: keep the record and review it on the date you set.
- You are unsure which format fits: compare full-time, interim and fractional mandates.
- Operational decisions need temporary senior ownership: see interim CTO. Ongoing part-time senior input: see fractional CTO.
- You want a second opinion on the map: talk with the curator and browse the CTOs in the network.
Boundaries
This article is general guidance. The ownership-gap record is a planning template that records authority, account control and knowledge; security, legal, financial and sector-regulator approvals stay with the reviewers who hold them. The example company is invented, and its repairs are proposals. CTO experience shown comes from public CTO profiles and reflects each CTO's own career. Scope, timing and CTO availability are agreed through the curator.
Grand Rounds is an initiative of Dinarys, and a conversation may lead to cooperation with Dinarys.