Unit 2 — Building from Nothing: The Single-Owner Micro-Process
Unit ID: FO-FND-02
Estimated Time: 60–120 minutes
Delivery Mode: Self-Guided or Catalyst-Led
Applies To: Founders, operators, managers, individual contributors
Prerequisites: Completion of Unit 1 Diagnostic
Unit Purpose and Role in FlowOps
Unit 2 is where FlowOps becomes tangible.
This unit teaches how to design one small, functional process from scratch — intentionally constrained to a single owner, no handoffs, no automation, and no dependencies.
The purpose is not to build a “complete workflow.”
The purpose is to learn how process works at its most basic level.
Every failure that occurs in complex systems also occurs here — just in a visible, understandable way. Mastering this unit prevents teams from scaling broken thinking into larger systems.
Why FlowOps Starts This Small
Organizations frequently attempt to “fix operations” by:
- Mapping entire departments
- Designing end-to-end flows immediately
- Introducing tools before clarity exists
This creates cognitive overload and hides root causes.
A single-owner micro-process removes:
- Coordination complexity
- Political friction
- Dependency confusion
What remains is the pure mechanics of work:
- What triggers it
- What steps occur
- What “done” actually means
If a team cannot design this correctly, adding handoffs or automation will only magnify the failure.
1. What This Unit Solves
The Problem It Addresses
Many organizations believe they “have processes” when in reality they have:
- Habits
- Expectations
- Informal routines
- Heroic effort
This unit exposes the difference.
It solves the problem of implicit work by making it explicit, inspectable, and repeatable — without the noise of multi-person coordination.
Common Symptoms This Unit Targets
- One person does the work “their way”
- Quality varies depending on who performs the task
- Knowledge lives in someone’s head
- Mistakes are caught late or not at all
- No clear definition of success exists
These symptoms often go unnoticed because the work appears to function.
2. The Standard: What a Micro-Process Is (and Is Not)
What This Section Defines
This section defines the minimum viable process — the smallest unit of structured work FlowOps recognizes as a process.
A Micro-Process Is:
- Owned by one person
- Triggered by a clear event
- Executed through explicit steps
- Completed with a defined outcome
- Verifiable without interpretation
A Micro-Process Is NOT:
- A role description
- A checklist without context
- A workflow involving handoffs
- A tool configuration
- An automation candidate (yet)
This distinction is critical. Most early “process” failures come from confusing these concepts.
3. Micro-Process Anatomy
This section explains the core structure every micro-process must contain.
3.1 Trigger
What It Is
The trigger is the event that causes the work to start.
Why It Matters
Without a clear trigger:
- Work starts inconsistently
- Tasks are forgotten or duplicated
- Accountability is unclear
Examples
- Request received
- File uploaded
- Status changed
- Scheduled time reached
A process without a trigger is not a process — it is a reaction.
3.2 Steps
What They Are
Steps are the ordered actions required to complete the work.
Why They Matter
Explicit steps:
- Reduce variation
- Lower cognitive load
- Make quality inspectable
Steps should describe what must happen, not how a specific person prefers to do it.
3.3 Definition of Done
What It Is
A clear, objective statement describing when the process is complete.
Why It Matters
Without a definition of done:
- Work drags on
- Quality disputes arise
- Downstream work suffers
“Done” must be verifiable without asking the owner.
4. Designing the Micro-Process
4.1 Selecting the Right Process
This unit works best when the selected process is:
- Repetitive
- Bounded
- Friction-heavy
- Owned by one person
Avoid:
- Strategic work
- Creative work
- Exception-heavy tasks
- Cross-functional work
The goal is learning, not optimization.
4.2 Documenting the Process
The micro-process should be documented in one page or less.
At minimum, it must include:
- Name
- Owner
- Trigger
- Steps
- Definition of done
Over-documentation at this stage is a failure mode.
4.3 Validating the Process
Validation answers one question:
“If someone else read this, would they do the same thing?”
Validation methods:
- Self-review after a day
- Peer walk-through
- Catalyst review (optional)
If interpretation is required, clarity is missing.
5. Quality and Failure Inside a Single Process
Why Quality Must Exist Before Scale
Quality issues that exist in a micro-process will multiply when handoffs are introduced.
This unit intentionally surfaces:
- Ambiguous steps
- Missing criteria
- Hidden assumptions
Common Micro-Process Failure Modes
- Steps describe outcomes, not actions
- Definition of done is subjective
- Exceptions are ignored
- Owner relies on memory instead of structure
These are signals, not setbacks.
6. Outputs of Unit 2
By the end of this unit, the organization must have:
- One documented micro-process
- A clearly assigned owner
- A defined trigger
- Explicit steps
- An objective definition of done
If any of these are missing, the unit is incomplete.
7. How This Unit Connects Forward
This unit intentionally avoids:
- Handoffs
- Metrics
- Automation
- Cross-team coordination
Those concepts are introduced only after micro-process discipline exists.
Unit 2 enables:
- Unit 3 (handoffs)
- Unit 4 (chained workflows)
- Unit 6 (data design)
Skipping this discipline causes downstream fragility.
8. Governance
Ownership
The process owner is responsible for:
- Executing the process
- Maintaining clarity
- Proposing improvements
Ownership does not imply authority beyond the process boundary.
Review Cadence
Micro-processes should be reviewed:
- After initial use
- After 30 days
- Before adding complexity
9. Common Failure Modes
- Choosing a process with hidden handoffs
- Over-engineering documentation
- Treating the process as permanent
- Attempting automation prematurely
Discomfort indicates learning.
10. Catalyst-Led Option
Catalyst may:
- Help select the right process
- Facilitate design sessions
- Pressure-test clarity
- Prevent over-engineering
Catalyst does not replace ownership.
11. Completion Criteria
Unit 2 is complete only when:
- One micro-process exists
- It has one owner
- Trigger is explicit
- Steps are unambiguous
- Definition of done is objective
Do not proceed until this is true.
COPY-PASTE MICRO-PROCESS TEMPLATE
(Word / Docs friendly)
Process Name: __________________________
Owner: __________________________
Trigger:
Steps:
Definition of Done:
Known Exceptions (if any):
Last Reviewed: _____