Unit 3 — Introducing Handoffs: Adding a Second Person Without Breaking the Process
Unit ID: FO-FND-03
Estimated Time: 90–150 minutes
Delivery Mode: Self-Guided or Catalyst-Led
Applies To: Founders, operators, managers, individual contributors
Prerequisites: Completion of Unit 2 (Single-Owner Micro-Process)
Unit Purpose and Role in FlowOps
Unit 3 is where most processes fail for the first time.
Up to this point, work has been intentionally constrained to a single owner. That constraint removed ambiguity, politics, and coordination overhead. The moment a second person is introduced, new failure modes appear—even if the original work itself has not changed.
The purpose of this unit is to teach how to add a second person without destroying clarity, accountability, or flow.
This unit introduces the concept of a handoff—not as a casual transition, but as a designed interface between two pieces of work.
Why Handoffs Are the Primary Source of Operational Breakdown
Organizations often assume problems arise because:
- People are careless
- Communication is poor
- Tools are missing
In reality, most breakdowns occur because handoffs are undefined.
When work moves from one person to another without a clear contract:
- Responsibility becomes blurred
- Quality expectations change
- Work stalls or bounces back
- Rework increases
This unit exists to make handoffs explicit, inspectable, and enforceable.
1. What This Unit Solves
The Problem It Addresses
In most organizations, handoffs are implied rather than designed.
People assume:
- “They know what I meant”
- “They’ll figure it out”
- “That’s how we’ve always done it”
This unit solves the problem of implicit transitions by teaching teams how to define exactly what must be true for work to move forward.
Common Symptoms of Broken Handoffs
- Work is sent back repeatedly
- Downstream teams complain about quality
- Upstream teams feel blocked or nitpicked
- Status meetings exist to compensate for poor flow
- People hoard work instead of passing it on
These symptoms are not interpersonal issues — they are structural failures.
2. The Standard: What a Proper Handoff Is
What This Section Defines
This section defines what FlowOps considers a valid handoff.
A handoff is not:
- Sending a message
- Changing a status
- Uploading a file
A handoff is a contract.
A Proper Handoff Includes
- A clearly defined sender
- A clearly defined receiver
- Explicit inputs
- Explicit acceptance criteria
- Clear ownership transfer point
Until these exist, work has not truly been handed off.
What a Handoff Is Not
- A favor
- A suggestion
- An assumption of readiness
- A hope that “they’ll fix it downstream”
Handoffs are not communication events — they are control points.
3. Handoff Anatomy
This section breaks down the components of a handoff and explains why each one exists.
3.1 Sender
What It Is
The sender is the role or person responsible for preparing work for transfer.
Why It Matters
Without a defined sender:
- Accountability is unclear
- Quality becomes subjective
The sender owns:
- Preparing required inputs
- Verifying readiness
- Initiating the handoff
3.2 Receiver
What It Is
The receiver is the role or person who accepts responsibility for the work after the handoff.
Why It Matters
Without a defined receiver:
- Work sits idle
- Ownership is disputed
- Follow-ups multiply
Acceptance must be intentional, not assumed.
3.3 Inputs
What They Are
Inputs are the specific information, materials, or conditions required for the receiver to proceed.
Why They Matter
Undefined inputs cause:
- Rework
- Delays
- Quality degradation
Inputs must be:
- Explicit
- Verifiable
- Minimal but sufficient
3.4 Acceptance Criteria
What It Is
Acceptance criteria define what must be true for the receiver to accept the work.
Why It Matters
Without acceptance criteria:
- Receivers inherit upstream problems
- Senders offload incomplete work
Acceptance criteria protect both sides.
3.5 Ownership Transfer Point
What It Is
The exact moment responsibility transfers from sender to receiver.
Why It Matters
Without a clear transfer point:
- Accountability overlaps
- Work is abandoned or duplicated
Ownership must transfer cleanly.
4. Designing the First Handoff
4.1 Selecting the Right Process
Start with the micro-process created in Unit 2 and identify one natural transition point where another person becomes involved.
Good candidates:
- Review steps
- Approvals
- Preparation → execution transitions
Avoid:
- Multi-team chains
- External dependencies
4.2 Defining the Handoff Contract
Document the handoff explicitly:
- Sender
- Receiver
- Inputs
- Acceptance criteria
- Transfer signal
This documentation should fit on one page.
If it cannot, the handoff is too complex.
4.3 Designing Rejection and Return Rules
A valid handoff must include rejection logic.
Define:
- When work can be rejected
- How it is returned
- Who owns fixes
Rejection is not failure — it is quality control.
5. Flow Control and Timing
Why Timing Matters
Even perfect handoffs fail if timing is unclear.
This section ensures teams define:
- When handoffs occur
- How often they are checked
- What happens when queues form
Basic Timing Rules
- Handoffs occur at defined moments, not continuously
- Work waits in a visible state
- Ownership is never ambiguous during waiting
This prevents silent backlog accumulation.
6. Outputs of Unit 3
By the end of this unit, the organization must have:
- One documented handoff
- Defined sender and receiver
- Explicit inputs and acceptance criteria
- Clear ownership transfer point
- Defined rejection rules
Without these, downstream units will magnify instability.
7. How This Unit Connects Forward
This unit introduces:
- Multi-person accountability
- Controlled transitions
- Quality gates
It enables:
- Unit 4 (chaining processes)
- Unit 5 (exceptions)
- Unit 6 (data design)
If handoffs are weak here, every later workflow will fracture.
8. Governance
Ownership
The sender and receiver jointly own handoff quality.
The process owner owns the design.
Review Cadence
Review handoffs:
- After initial use
- After first rejection cycle
- Before adding additional handoffs
9. Common Failure Modes
- Treating handoffs as communication
- Allowing informal exceptions
- Overloading acceptance criteria
- Avoiding rejection to “be nice”
Handoffs fail when clarity is sacrificed for speed.
10. Catalyst-Led Option
Catalyst may:
- Facilitate handoff design sessions
- Pressure-test acceptance criteria
- Normalize expectations between roles
Catalyst ensures handoffs are enforceable, not theoretical.
11. Completion Criteria
Unit 3 is complete only when:
- A handoff is documented
- Sender and receiver are explicit
- Inputs are defined
- Acceptance criteria exist
- Ownership transfer is clear
Do not proceed until these conditions are met.
COPY-PASTE HANDOFF TEMPLATE
(Word / Docs friendly)
Process Name: __________________________
Handoff Name: __________________________
Sender (Role): __________________________
Receiver (Role): __________________________
Required Inputs:
Acceptance Criteria:
Ownership Transfers When:
Rejection Rules:
Last Reviewed: __________________________