Principle 5: Supported by Subordinate Units
This principle explains that many Units of Effort rely on smaller supporting units that exist solely to enable the larger objective. Recognizing these relationships prevents duplication, clarifies dependencies, and helps align effort at the correct level.
Summary
A Unit of Effort could potentially be broken into smaller Units of Effort that help fulfill its objective. These subordinate Units do not stand alone – they exist in service of a higher Unit’s completion. Understanding this layered structure is key to managing complexity, assigning tasks, and optimizing workflow.
Unit of Effort vs. Attribute
Unit of Effort (UoE)
Definition: A distinct and trackable packet of work that has it’s own objective, scale, and complexity.
Traits:
-
It contributes meaningfully to a larger objective.
-
It can be assigned, routed, or evaluated on its own.
-
It may contain subordinate units or several attributes.
Examples:
-
Completing a market analysis.
-
Processing a purchase request.
-
Negotiating a contract.
​
Attribute
Definition: A feature, requirement, or action that is part of a UoE but not large or independent enough to stand alone.
Traits:
-
Often administrative or procedural in nature.
-
May influence the complexity of the UoE, but does not define it.
-
Typically, doesn’t require dedicated tracking or assignment.
Examples:
-
Filling out a justification form.
-
Including a specific clause in a contract.
-
Clicking a compliance checkbox
-
Attaching a required document
Unit of Effort vs. Attribute: Summary
-
A Unit of Effort is a chapter.
-
An Attribute is a sentence, formatting rule, or footnote inside the chapter.
-
This distinction helps prevent misclassification and avoids over-fragmentation of tasks, which is crucial when applying FLOW to systems, workflows, or process optimization.
​
Example
A large contract award (Unit of Effort) might be supported by several subordinate units.
-
PR Review
-
Market Analysis
-
Negotiation Memo
Each of these is a smaller, supportive Unit of Effort (in the context of a large contract) which feeds into the successful execution of the main contract award. Each could be independently provided a FLOW classification.
​
Common Mistakes
-
Treating all Units of Effort as independent. Not recognizing hierarchy causes duplication or misassignment.
-
Ignoring dependencies. A senior Unit of Effort might stall because a junior Unit of Effort hasn’t been completed.
-
Forcing FLOW classification at the attribute level. Over-classifying minor sub-units (attributes) confuses rather than clarifies.
Red Flag Indicators
-
People say “Why are we doing this task again?” or “I thought someone else already did that.”
-
Multiple units report progress independently but are all working toward the same unacknowledged higher goal.
-
Unit objectives conflict due to lack of awareness of the overarching Unit of Effort they support.
Key Diagnostic Questions
-
What is the primary Unit of Effort we are trying to advance?
-
Are there supporting Units of Effort feeding into it?
-
Could any of the units we’re tracking be rolled up into a senior Unit of Effort?
-
Have we assigned FLOW levels to the right layer of the structure?
Local Application Prompts
-
Pick any project or deliverable. Break it down into all its supporting Units of Effort.
-
Classify each one into FLOW A-S.
-
Now regroup them under their parent unit and assign FLOW to the senior Unit instead.
-
Can the work be reorganized so that senior Units have junior Units that are consistent in their FLOW classification?
​
Alignment Risks
-
Misalignment between the FLOW classification of a parent Unit and its components.
-
Teams assigned to junior Units without understanding the senior Unit’s objective.
​
Systems Design Anchors
-
Design workflows that visually nest junior Units under senior Units.
-
Define handoff points between Units to prevent fragmentation.
-
A handoff point is the clear moment or condition when one Unit of Effort is considered “complete enough” to be handed to the next system/person/team for further action.
-
Without clear handoff points:
-
Work gets stuck in limbo
-
Teams don’t know when to start
-
Units overlap or duplicate effort
-
It becomes hard to track responsibility or progress
-
-
In the context of FLOW, let’s say your senior Unit of Effort is to “Award a large PR”, and it’s supported by several junior Units, each with their own handoff point.
-

*(x) indicates their position in the hierarchy. (1) is junior to (2) which is junior to (3)
•Incorporate checklists or dependency tracking to show what sub-Units must be complete before the senior Unit can move forward.
​
Role Implications
Managers: Must think at the senior Unit level, ensuring dependencies are tracked.
Analysts or Contributors: Should understand how their tasks contribute to a broader outcome.
System Architects: Should map relationships between Units to support traceability and FLOW logic.