PROCESS

Here is How to Build

Design

Core

Handing off

No core process does everything itself. At points along its backbone, the core reaches a place where the next thing to be done is not its own work, and there it hands off: it passes the case to someone else, who does that part, and either returns it or carries it on. These points are the handoffs, and finding them is the next work after the backbone is drawn. The backbone showed the whole flow; the handoffs are the places in that flow where the core stops doing and passes the case out.

A handoff comes in two kinds, and the difference matters for how it is designed. In the first, the core hands off and waits: it passes the case to another, who does their part and hands it back, and the core picks it up and goes on. The case leaves the core's hands for a moment and returns. In the second, the core hands off and does not wait: it passes the case to another who takes it from there, and the core's part is done. The case leaves and does not come back, at least not to this core, at this point. The first is a loan; the second is a delivery. Both are handoffs, and a core's backbone is dotted with both.

Naming them as handoffs, rather than blurring them into the core's own steps, is what keeps the core honest about where its own work ends. A step the core performs itself and a point where the core passes the case to another are different things, and a design that treats them the same, that draws a handoff as though it were just another internal step, hides the seam where the core depends on something outside itself. Every handoff is such a seam, a place where the core's flow meets another's, and the core is only as reliable as those seams are clean. So the first act is simply to see them: to walk the backbone and mark every point where the case passes out of the core's own hands, whether to return or not.

The highest possible standard is to find every point along the backbone where the core hands the case out of its own work, marking each as a handoff rather than blurring it into an internal step, and knowing for each whether it is a handoff that returns or one that passes the case on for good.

Key Takeaway: No core does everything itself; at points along its backbone it reaches work that is not its own and hands off, passing the case to someone else who does that part and either returns it or carries it on. Handoffs come in two kinds: hand off and wait (the case leaves and returns, a loan) and hand off and pass on (the case leaves for good, a delivery). Naming them as handoffs, not blurring them into the core's own steps, keeps the core honest about where its work ends: every handoff is a seam where the core meets another's flow, and the core is only as reliable as those seams are clean.

A handoff is a point where the core passes the case out of its own work, to return or to pass on; find and name every one along the backbone.

MarvinPro · PROCESS · Here is How to Build · Design · Core · Discipline 5: The Handoffs · Section: Handing off

MarvinPro | September 2026

marvinpro.com

To a sub, an Owner, or outside

A handoff passes the case to someone, and that someone is one of three. The first is a sub-process, an independent process the core reaches when it needs work the core does not do itself. When money must move, the core hands off to the financial sub-processes, the charging, the invoicing, the collecting, which take the case, do their part, and hand it back; the core does not do their work, it hands off to them and carries on. When a condition is met, the core may hand off to another sub built for that case, as a breakdown hands a stranded customer off to a courtesy-mobility process. These sub-processes are their own work, with their own backbones, met fully in the next volume; here, what matters is the point at which the core hands off to them.

The second is an Owner, a person with the authority the case now needs. At some points along the backbone, the core reaches a decision it may not make on its own, and there it hands off to the Owner who may, who decides, and hands the case back for the core to carry on. This is a handoff to authority, built into the core's normal flow where a decision must be sanctioned by someone above the work. And the third is an external party, someone outside the organisation altogether: a vendor whose system does a part the core depends on, a partner who must act, a regulator or counsel who must be consulted. When the case needs what only an outside party can give, the core hands off outward, and waits or passes on as the case requires.

Whichever the destination, a handoff must define four things, or it is not a handoff but a gap. It must define the point: where, exactly, along the backbone the case is passed. The trigger: what condition causes the handoff, so it is not done by guess. What is passed: exactly what the receiver needs to do their part, no less, or they cannot act, and no more than they should hold. And what comes back: whether the case returns, and if so, in what state, so the core knows what it is picking up. A handoff with these four defined is clean; a handoff missing any of them is a place where the case can fall through, passed to no clear receiver, with no clear trigger, carrying too little to act on, or vanishing with no defined return.

The highest possible standard is to route each handoff to the right destination, a sub-process, an Owner, or an external party, and to define for each the point, the trigger, what is passed, and what comes back, so that every handoff is a clean seam and not a gap the case can fall through.

Key Takeaway: A handoff passes the case to one of three: a sub-process (an independent process the core reaches for work it does not do, financial subs at money-movement, or a conditional sub like courtesy-mobility, met in the next volume); an Owner (authority the case needs, a decision handed off and returned); or an external party (a vendor, partner, or regulator outside the organisation). Whichever the destination, a handoff must define four things or it is a gap: the point (where), the trigger (when), what is passed (what the receiver needs), and what comes back (whether and how it returns). Four defined, it is clean; any missing, the case can fall through.

Route each handoff to a sub, an Owner, or outside, and define its point, trigger, what is passed, and what comes back.

MarvinPro · PROCESS · Here is How to Build · Design · Core · Discipline 5: The Handoffs · Section: To a sub, an Owner, or outside

MarvinPro | September 2026

marvinpro.com

The clean edge

The handoffs are where a core most often fails, and this is worth saying plainly, because it is where the least attention is usually paid. The steps the core performs itself get designed with care; the points where it passes the case to another are treated as afterthoughts, a line drawn to a box marked finance or vendor, with no thought to what is passed or what returns. But it is exactly there, at the seams, that cases are lost, delayed, and dropped, handed to a receiver who did not know they were receiving, or passed with too little to act on, or sent off with no defined way back. A core with beautiful steps and careless handoffs is not a reliable core; it is a set of good parts that spill the case between them.

So the handoffs define the edge of the core, and a clean edge is as much the designer's work as a clean flow. The core is complete up to its handoff points: it does its own work fully, and at each seam it passes the case cleanly to whoever does the next part, knowing what it hands over and what it will get back. What lies across each seam, the sub-process, the Owner's decision, the external party's work, is not the core's to design here; the sub-processes in particular are the whole of the next volume. But the seam itself, the handoff, is the core's, and drawing it cleanly is what makes the core a whole that connects, rather than an island that ends.

This is the last of the core's own design. With the backbone deepened and the handoffs defined, the core is shaped: it knows what it does, and it knows, at every point where it does not, exactly how it passes the case to what does. It is ready to be agreed and signed off, and ready to connect to the sub-processes, the Owners, and the outside parties its handoffs name. The core does not stand alone, and was never meant to. It stands as a spine with clean seams, doing its own work and handing off the rest, which is what lets it be one part of a larger design that holds together.

The highest possible standard is to design the handoffs with the same care as the core's own steps, making each a clean seam where the case passes without being lost, so the core is complete up to its edges and connects cleanly to everything its handoffs reach.

Key Takeaway: Handoffs are where a core most often fails, because they get the least attention: the core's own steps are designed with care while the seams are treated as afterthoughts, and it is there that cases are lost, delayed, or dropped. So a clean edge is as much the designer's work as a clean flow. The core is complete up to its handoff points, doing its own work fully and passing the case cleanly at each seam. What lies across the seam (the sub, the Owner's decision, the external work) is not designed here, but the seam itself is the core's. With backbone deepened and handoffs defined, the core is shaped, ready to be agreed and to connect.

Design the handoffs as carefully as the steps: a clean seam where the case never falls through is what lets the core connect into a larger whole.

MarvinPro · PROCESS · Here is How to Build · Design · Core · Discipline 5: The Handoffs · Section: The clean edge

MarvinPro | September 2026

marvinpro.com

A real example

Return to the software core, its backbone deepened: subscribe, activate, deliver, verify. Walk it, and the handoffs appear. At activate, when the payment must be settled, the core does not itself take the money; it hands off to the financial sub-process that charges the customer, which takes the case, settles the payment, and hands it back, so the core can open the account and go on. That is a handoff to a sub, of the returning kind: the case leaves for the charging, and comes back settled. It defines its four things: the point (at activate, before the account opens), the trigger (a new subscription to be charged), what is passed (the customer, the plan, the amount), and what comes back (the payment settled, or a failure the core must handle).

Other handoffs go elsewhere. When the delivery depends on a payment provider's own system, an outside party, the core hands off externally: it passes the charge to the provider and waits for the provider's answer, a handoff outward that returns. When a customer's case touches something only the Offer Owner may decide, a concession, a variation to what was promised, the core hands off to that Owner, who decides and hands the case back. And where a subscription lapses and the case becomes a matter of collection, the core hands off to the collecting sub-process, which may take the case on from there. Sub, Owner, outside, each a defined point on the backbone where the core passes the case to what does the next part.

And each seam was drawn as carefully as the steps between them. The handoff to charging was not a mere arrow to a box marked finance; it named what finance received and what it returned, so a failed payment came back as a defined case the core knew how to meet, not as a silence. The handoff to the provider named what was sent and what was awaited, so a slow provider did not leave the core hanging with no defined wait. That care is what made the core reliable at its edges as well as its middle. With its backbone deepened and its handoffs defined, the software core was shaped: a spine that did subscribe, activate, deliver, verify itself, and at every point where it did not, handed the case off cleanly to the sub, the Owner, or the outside party that did. It was ready to be agreed, and ready to connect.

The core's handoffs were drawn as carefully as its steps: each a clean seam to a sub, an Owner, or an outside party, with what was passed and what returned defined, so the case never fell through.

MarvinPro · PROCESS · Here is How to Build · Design · Core · Discipline 5: The Handoffs · A real example

MarvinPro | September 2026

marvinpro.com

The Handoffs

No core does everything itself. At points along its backbone it reaches work that is not its own, and there it hands off: it passes the case to someone else who does that part and either hands it back or carries it on. These are the handoffs, found by walking the backbone and marking every point where the case leaves the core's own hands. They come in two kinds: hand off and wait, where the case leaves and returns, and hand off and pass on, where it leaves for good. Naming them as handoffs, not blurring them into the core's own steps, keeps the core honest about where its work ends, because every handoff is a seam where the core's flow meets another's.

A handoff passes the case to one of three. To a sub-process, an independent process the core reaches for work it does not do, the financial subs when money must move, a conditional sub like courtesy-mobility when a case calls for it, met in the next volume. To an Owner, when the case needs a decision the core may not make alone, handed off to the authority who may and handed back. Or to an external party, a vendor, partner, or regulator outside the organisation, when the case needs what only they can give. Whichever the destination, a handoff must define four things, or it is a gap: the point where the case is passed, the trigger that causes it, what is passed so the receiver can act, and what comes back so the core knows what it picks up.

The handoffs are where a core most often fails, because they get the least care: the steps are designed well and the seams treated as afterthoughts, and it is at the seams that cases are lost, delayed, and dropped. So a clean edge is as much the designer's work as a clean flow. The core is complete up to its handoff points, doing its own work fully and passing the case cleanly at each seam, knowing what it hands over and what returns. What lies across the seam is not designed here, the sub-processes in particular are the next volume, but the seam itself is the core's, and drawing it cleanly is what makes the core connect rather than end.

So the discipline is this: with the backbone deepened, walk it and find every handoff; know each as the returning or the passing-on kind; route each to its right destination, a sub, an Owner, or an outside party; and define for each the point, the trigger, what is passed, and what comes back, so no case falls through the seam. Do this, and the core is shaped and complete to its edges: a spine that does its own work and hands off the rest cleanly, ready to be agreed and signed off, and ready to take its place as one connected part of a larger design.

Find every handoff along the backbone, route each to a sub, an Owner, or outside, and define what is passed and what returns, so the core connects cleanly at every edge.

MarvinPro · PROCESS · Here is How to Build · Design · Core · Discipline 5: The Handoffs · Chapter Outcome

MarvinPro | September 2026

marvinpro.com

Think Simple.