Principle 6: Comprised of Subordinate Units
This principle focuses on the internal structure of a Unit of Effort. It establishes that a single Unit may be composed of multiple subordinate Units, each contributing to the overall complexity and scale of the parent. Understanding this internal composition is essential for proper scoping, delegation, and system design, ensuring that hidden sub-work does not undermine execution.
Summary
A Unit of Effort can be nested, containing smaller Units of Effort within it. These “junior” Units contribute to the overall complexity and scale of the “senior” Unit. FLOW classification can be applied to both the senior Unit as a whole and its constituent parts.
Examples
Senior Unit of Effort: Deploy a new internal procurement system tool (FLOW C)
Subordinate Units:
-
Write user instructions (FLOW B)
-
Train users on new workflows (FLOW B)
-
Review approval logic with senior stakeholders (FLOW C)
-
Validate user emails (FLOW A)
Senior Unit of Effort: Launch robotic surgery service (FLOW D)
Subordinate Units:
-
Credentialing staff (FLOW A)
-
Training surgeons on admin tools (FLOW B)
-
Building surgical protocols (FLOW C)
-
Negotiate vendor maintenance contract (FLOW C)
-
Plan launch across departments in 12 different sites (FLOW D)
Senior Unit of Effort: Launch new product line in all stores (FLOW D)
Subordinate Units:
-
Packaging design (FLOW B)
-
Coordinate shelf space and logistics (FLOW C)
-
Update internal training guides (FLOW A)
-
Analyze early sales trends for basic insights (FLOW B)
-
Plan launch across departments in 12 different sites (FLOW D)
Senior Unit of Effort: Coordinate forward deployment of critical spare parts (FLOW D)
Subordinate Units:
-
Confirm delivery dates with vendors (FLOW A)
-
Allocate parts based on risk tiers (FLOW C)
-
Route shipments via air/sea hubs (FLOW B)
-
Create cross-unit coordination protocols (FLOW D)
​
Quick Case Study
Scenario: A project to automate invoice processing (senior Unit of Effort) includes several smaller tasks including:
-
Gathering invoice samples
-
Training an OCR model
-
Designing validation rules
-
Testing in a live environment
Takeaway: Each of these is a subordinate Unit of Effort, potentially classified differently (e.g., FLOW B for data gathering, FLOW C for model training, etc.). The project overall might be FLOW D because of the integration and change management required.
Common Mistakes
-
Treating every task as its own FLOW classification without considering the project’s aggregate complexity
-
Assigning the FLOW level of one hard subtask to the entire Unit of Effort without evaluating the full picture
-
Forgetting that a FLOW C level effort may contain FLOW A and FLOW B tasks
Red Flag Indicators
-
“This task is just FLOW A” – but it’s actually a subtask of a complex initiative
-
Treating every Unit of Effort as independent
-
FLOW level jumps erratically during execution without explanation
-
Planning efforts focus only on the top-level objective, not its component efforts
-
Senior Units of Effort are routed to teams who only handle Junior level FLOW efforts
-
Stakeholders assign FLOW classification without decomposing the Unit
-
Delays or confusion during handoff because no one defined the internal structure
-
Efforts stall due to hidden interdependencies between sub-units
-
Team members report “I didn’t realize that was part of my task.”
Key Diagnostic Questions
•What smaller efforts must be completed to finish this Unit?
•Are any of the subordinate efforts FLOW C or FLOW D?
•Does this Unit of Effort require integration across multiple teams or systems?
Local Application Prompts
•Break down a current initiative into its sub-units. What FLOW level is each one?
•Choose one senior Unit of Effort. Would reclassifying it based on its sub-units change how you prioritize or staff it.
​
Alignment Risks
-
Misclassification due to focus on only the senior or junior level
-
Resource misallocation by over or underestimating complexity
-
Decision paralysis from failing to delegate sub-units appropriately
​
Systems Design Anchors
When designing systems, always structure them modularly – recognize that any large Unit can and should be decomposed. FLOW classification helps you assess each layer for routing, tooling, or governance needs.
​​
Role Implications
Analysts: Should evaluate sub-units independently to ensure proper scoping.
Leaders: Must recognize when a Unit appears simply but has embedded complexity.
Executors: Benefit from clarity around whether their assigned effort is a stand-alone task or part of a larger whole.