Unit 4 — Chaining Processes: Creating a Simple Workflow
Unit ID: FO-FND-04
Estimated Time: 120–180 minutes
Delivery Mode: Self-Guided or Catalyst-Led
Applies To: Founders, operators, managers, process owners
Prerequisites: Completion of Unit 3 (Defined Handoffs)
Unit Purpose and Role in FlowOps
Unit 4 is where isolated processes become a system.
Up to this point, FlowOps work has been deliberately constrained:
- Unit 2 focused on a single-owner process
- Unit 3 introduced one controlled handoff
Unit 4 introduces sequence.
This unit teaches how to connect multiple processes together into a simple, repeatable workflow—without losing clarity, ownership, or control.
The goal is not to design an end-to-end enterprise flow.
The goal is to learn how work moves through stages and how breakdowns emerge when stages are poorly defined.
Why Chaining Changes Everything
The moment processes are chained:
- Local decisions affect downstream work
- Bottlenecks become visible
- Timing and queues begin to matter
- Exceptions propagate instead of staying contained
Many organizations experience chaos not because individual processes are broken, but because the connections between them are undefined or unmanaged.
This unit exists to make those connections intentional.
1. What This Unit Solves
The Problem It Addresses
Organizations often have multiple “working” processes that fail when combined.
Symptoms include:
- Work piles up between steps
- Ownership feels fragmented
- Status is unclear
- Teams argue about “where things are stuck”
This unit solves the problem of unstructured sequencing by introducing clear stages, boundaries, and flow logic.
Why This Matters Before Scaling
If chaining is poorly designed at a small scale, complexity multiplies exponentially as:
- More handoffs are added
- More volume flows through the system
- More exceptions occur
Unit 4 prevents fragile flow from becoming institutionalized.
2. The Standard: What a Workflow Is (and Is Not)
What This Section Defines
This section defines what FlowOps considers a workflow.
A workflow is not:
- A list of tasks
- A department map
- A software pipeline
A workflow is a sequence of processes connected by explicit handoffs and stage boundaries.
A Valid Workflow Has
- A clear start condition
- A defined end condition
- Discrete stages
- Explicit ownership at each stage
- Visible work-in-progress
Without these, work does not “flow”—it drifts.
What This Unit Intentionally Avoids
At this stage, workflows should not include:
- Parallel paths
- Conditional branching
- Automation logic
- Cross-department orchestration
Those belong later. Simplicity is the point.
3. Workflow Anatomy
This section explains the structural elements of a simple workflow and why each exists.
3.1 Start Condition
What It Is
The start condition defines when work officially enters the workflow.
Why It Matters
Without a clear start:
- Work enters inconsistently
- Metrics are unreliable
- Ownership is disputed
The start condition is the first moment the system accepts responsibility for the work.
3.2 Stages
What They Are
Stages are named segments of work where ownership and intent are stable.
Why They Matter
Stages:
- Reduce ambiguity
- Create natural control points
- Enable visibility
Each stage should represent a meaningful change in the state of the work, not just activity.
3.3 Handoffs Between Stages
Each transition between stages must have a defined handoff as designed in Unit 3.
If a transition does not meet handoff standards, it is not a valid stage boundary.
3.4 End Condition
What It Is
The end condition defines when the workflow is complete.
Why It Matters
Without a clear end:
- Work lingers
- Accountability fades
- Metrics become meaningless
The end condition must be verifiable.
4. Designing the First Workflow
4.1 Selecting the Right Scope
A first workflow should:
- Chain 2–4 processes
- Involve limited roles
- Represent real work
- Have visible friction
Avoid:
- “Everything from start to finish”
- Rare or edge-case flows
The goal is learning, not completeness.
4.2 Mapping the Workflow
Mapping should focus on:
- Sequence, not detail
- Ownership, not tools
- State changes, not tasks
A simple left-to-right representation is sufficient.
If mapping becomes complex, scope is too large.
4.3 Naming Stages Correctly
Stage names should describe state, not action.
Good examples:
- “Ready for Review”
- “Approved”
- “Pending Execution”
Poor examples:
- “Working”
- “Doing Stuff”
- “Processing”
Clear stage names create shared language.
5. Flow Control and Visibility
Why Flow Control Matters
When work is chained:
- Delays compound
- Queues form naturally
- Bottlenecks emerge
This section introduces basic flow control concepts without metrics yet.
Visibility Principles
- Every piece of work must be in exactly one stage
- Work between stages must be visible
- Ownership must be clear even when work is waiting
If you have to ask someone where work is, visibility is missing.
6. Outputs of Unit 4
By the end of this unit, the organization must have:
- One documented workflow
- Defined start and end conditions
- Named stages with ownership
- Explicit handoffs between stages
- A visible representation of work-in-progress
Without these, the workflow is conceptual, not operational.
7. How This Unit Connects Forward
This unit enables:
- Unit 5 (exceptions and edge cases)
- Unit 6 (data design)
- Unit 9 (capacity and bottlenecks)
Workflow clarity is required before any of those concepts can be applied meaningfully.
8. Governance
Ownership
A single workflow owner is responsible for:
- Stage definitions
- Handoff integrity
- Change proposals
Stage owners manage execution, not design.
Review Cadence
Review workflows:
- After initial implementation
- After visible congestion
- Before adding branches or automation
9. Common Failure Modes
- Treating workflows as task lists
- Creating too many stages
- Naming stages after people or tools
- Adding logic before stability exists
If the workflow feels hard to explain, it is too complex.
10. Catalyst-Led Option
Catalyst may:
- Facilitate workflow mapping
- Pressure-test stage boundaries
- Prevent over-scoping
Catalyst’s role is to enforce simplicity and clarity.
11. Completion Criteria
Unit 4 is complete only when:
- A workflow is documented
- Start and end conditions are explicit
- Stages are clearly named
- Handoffs meet Unit 3 standards
- Work-in-progress is visible
Do not proceed until these conditions are met.
COPY-PASTE WORKFLOW TEMPLATE
(Word / Docs friendly)
Workflow Name: __________________________
Workflow Owner: __________________________
Start Condition:
Stages:
- Stage Name: __________________________
Owner: __________________________ - Stage Name: __________________________
Owner: __________________________ - Stage Name: __________________________
Owner: __________________________
End Condition:
Notes / Known Issues:
Last Reviewed: __________________________