Principle 3: Classification = Complexity + Scale

This principle defines how FLOW classifications are determined. Units of Effort are classified based on how difficult they are to execute and how large their impact or reach is—not by their subject matter or perceived importance. This prevents misclassification driven by labels instead of execution reality.

Summary

Don’t judge a Unit of Effort by what it is – judge it by how hard it is to execute. A routine task like submitting a form can be FLOW D if it involves hundreds of people, coordination across systems, and policy constraints. Likewise, a simulation of a rocket launch can be FLOW A if the simulation is meant to test a set of well-defined values and there are no real-world consequences.

The purpose of the work often determines whether judgment is incidental or essential. When the outcome requires interpretation, tradeoffs, or decision-making beyond predefined rules, complexity increases—even if the task steps themselves appear simple.

Examples

Effort Description: Processing a low-dollar purchase request

Context: Single buyer processing a commercially available item purchase request.

FLOW Classification: FLOW A – Low Complexity/Low Scale

Effort Description: Processing a low-dollar purchase request

Context: Requires coordination with 3 external vendors and technical review by senior engineer.

FLOW Classification: FLOW C – High Complexity/Moderate Scale

Effort Description: Conducting a supplier site visit

Context: Solo visit with checklist and no formal reporting

FLOW Classification: FLOW A – Low Complexity/Low Scale

Effort Description: Conducting a supplier site visit

Context: First time review with legal, safety, and export report requirements

FLOW Classification: FLOW D – Large Scale

Effort Description: Developing a training session

Context: One on one tutorial using existing slides

FLOW Classification: FLOW A – Low Complexity/Low Scale

Effort Description: Developing a training session

Context: Launching a global LMS module requiring extensive compliance alignment and policy coordination

FLOW Classification: FLOW D – Large Scale

Special Note

The same Unit of Effort can be FLOW A in one context and FLOW C in another, but never both at once. One Unit – One Flow.

Quick Case Studies

Name: Form 302-B

Effort Description: A military unit must submit Form 302-B to order parts. The form takes 5 minutes to fill out – but it triggers routing across five commands, legal review, and system constraints tied to funding codes.

FLOW Classification: Though it’s “just a form”, this Unit of Effort is FLOW C or D depending on relevant scale.

Name: Contract Award Review

Effort Description: A legal advisor reviews a contract template already vetted and approved. No changes, no negotiations.

FLOW Classification: Despite being “a contract”, this is FLOW A given that the process is routine, with no process variation.

Common Mistakes

Equating subject matter with FLOW Classification (“if it’s procurement, it’s always FLOW x”)
Using role-based assumptions (“if a senior manager is involved, it must be FLOW C” – not necessarily)
Ignoring execution context (Same task can be FLOW A in one organization, FLOW C in another)

Red Flag Indicators

Same task with wildly different completion times across teams. This signals execution context is driving FLOW classification.
Leaders assigning work based on topic labels only. “All audit tasks are FLOW C” is probably a flawed generalization.
Overreliance on automation labels (e.g., “digital = FLOW A). Hidden rules, integrations, or manual checkpoints may still make some instances of “digital efforts” FLOW C.
Complaints about “simple” tasks taking forever. This indicates the presence of invisible complexity or coordination burdens.
High burnout or turnover in teams handling “routine” tasks. This may be a FLOW misclassification problem rather than a performance issue.

Key Diagnostic Questions

How many approvals, systems, or steps are involved?
Could another team complete this faster or more easily?
Is complexity being hidden behind automation?
How does this task behave under volume or urgency?

Local Application Prompts

Reclassify a few “easy or routine” tasks from your team. What’s the real FLOW classification if you factor in approvals and dependencies?
Interview a colleague about a task you think is FLOW A. Ask how many people or systems they interact with.

Alignment Risks

Misallocating tasks (Units of Effort) to junior staff who are unequipped for the actual complexity.
Leadership believing “nothing is wrong” because all tasks look small in name.
Creating FLOW bottlenecks due to FLOW D workflows hidden in FLOW A disguises.

Systems Design Anchors

Include FLOW classification as part of SOP documentation and task handoff design.
Build virtual heatmaps showing execution complexity, not just output names.
Reassess legacy labels that may no longer reflect actual execution realities.

Role Implications

Data Modelers: Should factor FLOW level into operational dashboards.

Leaders: Must avoid equating complexity with importance - FLOW A and C efforts can be equally critical.

Process Designers: Must identify choke points where FLOW misclassification leads to systemic friction.