The handover ramp nobody scheduled

The handover ramp asks a new hire to hold eleven artefacts in their head by week three. Six is the realistic number. That gap is where a fractional exit turns into a quarter of slow, careful, fearful work by whoever inherits the system.

What is the handover ramp, and what should it deliver?

A fractional team builds workflows, properties, sequences and reports over a few months, then the engagement ends and a new hire, often a RevOps generalist, takes over. The handover ramp is the time it takes that person to change something in the system without being afraid of it.

Firms in this space describe their work as bounded. DragonflyGTM presents project-based GTM engineering delivered without adding headcount, and RevPartners lists implementations and migrations among its services. A bounded engagement is a fair model. It also means the system has a finish date and the inheritor has a start date, and the plan seldom connects the two.

The capability at the end of the ramp is observable: the new hire can change a routing rule, ship it, and explain what else it touches. That is time to first change, and it is the honest measure of the handover.

How many things is the new hire holding at once?

Count the artefacts. A typical handover pack has five workflows that fire on record changes, three scoring or enrichment jobs, a set of custom properties, a sequence library, a dashboard, and a document written by someone who has left. Eleven items, and most of them depend on each other.

Certification does not help here. Nobody certifies a person on a system that exists in one company. The programme is a folder and a call, and the new hire learns the rest by breaking things.

There is a second cost. The new hire is holding the system and the fear of the system at the same time. Every change is checked against what might silently break, because the person who knew is not reachable. That is cognitive load of a specific kind, and it appears in no plan. Eleven is more than a person holds in the first three weeks. The realistic number is six. The five that are dropped are not chosen. They are the ones that fire rarely, and rare workflows are the ones that fail the first time they run without their builder.

What does a sensible handover ramp look like in weeks?

Weeks one and two: the new hire can draw the data flow on a whiteboard from memory, from record creation to first sequence step. Two artefacts only: the flow diagram and the workflow list. No changes are made to anything.

Weeks three and four: the new hire makes one small change with the manager watching. Two more artefacts: the property dictionary and the routing rule. The change is reversible and logged.

Weeks five and six: the new hire owns one workflow completely, including its failure alert. Two more artefacts: the enrichment job and its credentials. The manager reviews the alert, not the workflow.

That is six artefacts in six weeks, each tied to something a manager can watch happen. Most of the handover ramp is the manager's, and the programme adds nothing to it by adding a module. The manager's part is concrete: two calls a week in the first fortnight, one a week after, and a rule that the new hire is never asked to change a workflow they cannot yet draw.

What should the handover stop asking for?

It should stop asking for the other five. Retire the dashboard nobody opens, the two sequences that have not sent since spring, and the property that duplicates another. Prefer removing content to adding a module. Every artefact deleted before week one is one the new hire never has to hold. Certification of the handover, if anyone proposes it, would measure whether the new hire can pass a test written by the person who left, which is a test about the past.

It should also stop measuring completion by a date. A handover ramp is finished when the new hire has shipped a change without help, not when the folder has been read.

Where does an embedded team change this?

The handover ramp exists because the builder and the inheritor are different people. In a model where the delivery team stays on the account, Checkpoint GTM being one such arrangement, the system is never handed to someone cold: the people who built a workflow are still the people asked what it does. The ramp shrinks from a cliff to a slope, because knowledge is carried in people who remain.

That has a cost. It is a continuing commitment, and it only makes sense if the system will keep changing. A one-off build that will sit unchanged for a year is better handled by a fractional team and a good document.

How would the change be observed?

Not in a survey. Watch time to first change: the number of days from the new hire's start to a shipped, reversible edit. If it is under thirty, the programme is adequate. If it is over sixty, the handover ramp was mis-sized, and the fix is subtraction. Set the threshold before the start date, write it on the plan, and let the manager own the number. Enablement fails quietly here: nothing breaks, and the ramp just takes a quarter longer than it says.