The handover that makes or breaks a fractional engagement.

Most fractional engagements that end badly were not undone by poor work. They were undone by a handover that was never designed — where the capability that was built lived in the fractional's head instead of in the organization. A good handover is not a document. It is a transition that was architected from week one.

Why handovers fail — and who is responsible when they do.

The standard narrative around a failed fractional engagement is that the operator did not deliver. The work was superficial, the recommendations were generic, the team was not equipped to implement. This happens. It is not, however, the most common reason engagements fail.

The more common failure is structural. The fractional delivered real work. They built a functioning demand generation system, or established a finance rhythm that the CEO could actually use, or rebuilt a product team that started shipping reliably. The work was real. But when the engagement ended, the capability degraded faster than anyone expected — because it was built around the fractional's presence, not the organization's capacity.

This is the dependency problem. The fractional becomes the single point of knowledge — for a process, a relationship, a decision-making framework, a vendor negotiation — and no one on the team has been systematically built up to hold that knowledge. When the engagement ends, the knowledge walks out with the fractional. The team reverts, slowly or quickly depending on how embedded the work was, to something close to where they started.

The question of responsibility here is not simple. Sometimes the company is at fault: they treated the fractional as a vendor rather than a capability-builder, they did not invest in the succession planning, they were happy to have the work done without caring how it was held after. But often the fractional bears significant responsibility. They built processes that only they could run. They held relationships that they did not transfer. They made decisions without creating the paper trail that would allow someone else to make the next decision in the same framework.

The discipline of a good handover starts with acknowledging that this is a design problem, not an exit problem. You do not design a good handover in the final month of an engagement. You design it in week one — and every decision you make about how to do your work is either making the handover easier or harder.

The design constraint that changes how you work.

When you internalize the handover as a design constraint from the start, it changes how you make daily decisions about where to put your attention. Here is the most common version of the choice it creates:

Option one: you handle something yourself because you can do it faster and better than anyone currently on the team. The meeting is scheduled, the vendor is managed, the report is built. It gets done. Option two: you spend 40% more time doing it alongside the person on the team who will eventually own it — explaining the reasoning as you go, having them take the lead on parts of it while you are still there to catch errors, building their competence and confidence in the process.

Option one produces better work in the short term. Option two produces a handover that actually works. The fractional who consistently chooses option one is accelerating throughput at the cost of organizational resilience. When they leave, the function degrades. The fractional who consistently chooses option two is slower in the short term and more expensive in their hours — but what they leave behind is durable.

The practical implication is that a fractional engagement should include, as an explicit deliverable, the development of at least one person on the team who can hold the critical functions when the engagement ends. Not as a secondary objective — as a primary one. The question to ask yourself monthly: if I left tomorrow, who on this team could run the three most important things I am currently running? If the answer is "no one," you are building dependency, not capability.

What a real handover actually involves.

The handover document is the artifact everyone focuses on and the part that matters least. A handover document is a static capture of knowledge at a point in time. It is useful for the things that can be written down clearly and unambiguously. It is nearly useless for the things that matter most: the informal operating norms, the relationship context, the judgment calls that are only meaningful if you understand why they were made that way.

A real handover involves three things that documents cannot replace. The first is a period of parallel operation — a defined window where the fractional and the successor are running the function together, with the successor taking progressively more of the weight and the fractional available to catch what breaks. The length of this window depends on the complexity of the function: for a well-documented operational process, two to four weeks may be sufficient. For a function that involves significant external relationships or strategic judgment, three months is closer to the right number.

The second is relationship transfer. Every significant external relationship the fractional holds — with key vendors, with strategic partners, with the investors they interact with regularly, with the customers they have been involved with — needs to be deliberately transferred, not just announced. The successor needs to be in the room for the final three or four touchpoints before the fractional leaves, in an increasingly active role, so that the external party has associated the successor's name with competent handling of the relationship before the fractional disappears.

The third is a forward-looking briefing rather than a backward-looking summary. The thing the successor needs most is not a history of what was done. It is a map of what is most likely to go wrong in the next six months, and what the early warning signals look like. "The agency will try to expand scope in Q3 — the contract language is on page 4 of the master agreement." "The ops manager is excellent but will need a forcing function to do strategic planning. Schedule a quarterly review now." This is the knowledge that lives in the fractional's head and is genuinely irreplaceable if not transferred.

The dependency that outlasts the engagement.

There is a version of the dependency problem that is more insidious than the functional one. It happens when the fractional, intentionally or not, becomes the person the CEO thinks through problems with. The sounding board. The one who gets the 10pm message when something is going wrong. The presence that the CEO has come to rely on for clarity.

This kind of dependency is common and understandable — it is partly a sign that the engagement has been genuinely valuable. But it is also a problem if it is not transferred. A CEO who relied on a fractional operator for strategic clarity and loses that relationship at the end of the engagement does not suddenly develop internal capacity for that function. They find someone else to fill it, often less well, or they go without.

The fractional's job, in this dimension, is not to be indispensable — it is to use the relationship to develop the CEO's own capacity. This is perhaps the hardest form of handover to execute because it requires the fractional to gradually transfer the function of their own role rather than just the operational knowledge they hold. Instead of answering the 10pm message with the answer, you start answering it with a question that leads the CEO to the answer. Instead of bringing a synthesized view to the leadership meeting, you help the CEO develop and present their own synthesis. You are not abdicating — you are withdrawing the scaffolding slowly enough that the structure it was supporting has time to stand on its own.

Done well, this is the highest-leverage thing a fractional operator can accomplish. The company does not just get the work product of the engagement. It gets a leadership team that is measurably more capable of operating without external support than it was before. That outcome is what separates a genuinely transformative fractional engagement from a competent operational contract.

• 01
  Design the handover from week one, not month six. Every decision about how you do your work — who you copy on emails, whether you handle something alone or alongside a team member, how you document your reasoning — either builds toward a clean handover or creates a dependency. Make these choices deliberately from the start.
• 02
  Name the successor early. Within the first month, identify the person or people on the team who will hold the critical functions when you leave. Make their development an explicit priority. If no one on the team is capable of eventually holding these functions, that conversation needs to happen with the CEO before the work gets further embedded.
• 03
  Run a parallel operation window. In the final phase of the engagement, the successor should be running the function with you present to catch what breaks — not the other way around. The length of this window should be proportional to the complexity of the function and the gap between the successor's current capability and what the role requires.
• 04
  Transfer relationships through active participation, not introduction. The external parties that matter need to meet and work with the successor in real contexts before you leave. A warm introduction is not enough. Three or four shared interactions where the successor demonstrates competence are the minimum for a relationship that will survive the transition.
• 05
  Write the forward brief, not the backward summary. The most valuable handover document is a map of what is most likely to go wrong in the next six months and what the early signals look like. History is in the systems. Judgment about what is coming next lives in your head and needs to be extracted before you leave.
• 06
  Transfer the CEO relationship deliberately. If the CEO has come to rely on you for strategic clarity, the handover includes gradually withdrawing that scaffolding — answering questions with questions, coaching the CEO's own synthesis rather than replacing it. The goal is a CEO who is more capable of operating alone than when you arrived.

Frequently asked questions.