Skip to main content

Unit 3 — Introducing Handoffs: Adding a Second Person Without Breaking the Process

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: __________________________

Back to top