top of page

Principle 21:
FLOW as a Lens

This principle integrates all others into a single way of seeing work and complexity. FLOW becomes not just a framework for classification, but a universal lens for thinking, designing systems, and navigating uncertainty across domains.

Summary

All Units of Effort, regardless of scale, function, or domain, can be understood, managed, and optimized through the FLOW lens. This framework is not just a tool for classification – it is a system for seeing, thinking, and acting with clarity in complexity.

​

Examples

Unit of Effort: Hospital patient discharges

  • FLOW A: Routine discharge for a post-op patient with no complications, following checklist

  • FLOW B: Coordinating the same-day discharge of multiple patients with no complications, following checklist

  • FLOW C: Discharging a patient whose stability is uncertain, requiring collaborative medical judgement

  • FLOW D: Discharging dozens of patients simultaneously due to a system-wide evacuation requiring ad-hoc protocols

  • FLOW S: Discharging a rare case (e.g., high profile political figure) requiring extensive coordination and confidentiality

​

Unit of Effort: Running a university course

  • FLOW A: Uploading content and opening LMS for a typical 20 student section, following a fixed agenda

  • FLOW B: Managing a high enrollment honors section with rotating lecturers and additional discussion sessions

  • FLOW C: Managing a capstone course which covers a lot of highly complex materiel

  • FLOW D: Managing a course that has been moved to fully remote status, requiring redesign of content delivery, grading, etc.

  • FLOW S: Managing a course that is being delivered in partnership with a Government agency, requiring special tech

​

Unit of Effort: Wildfire response

  • FLOW A: Extinguishing a small fire at the edge of a rural zone

  • FLOW B: Coordinating simultaneous suppression of five fires in a single region

  • FLOW C: Suppressing a small fire that is emitting toxic smoke and has created a hazmat situation

  • FLOW D: Responding to a massive fire outbreak that threatens multi-county critical infrastructure 

  • FLOW S: Responding to a fire that is dangerously close to a nuclear power station, triggering multi-agency protocols

 

Quick Case Study

A defense logistics team reclassifies every project, task, and dataset using FLOW. Meetings shift from abstract status updates to actionable FLOW level conversations – “This is FLOW C work, let’s isolate the complexity” or “We’ve overloaded a FLOW A pipeline with FLOW C tasks.” Clarity emerges. Priorities align. Performance improves.

​

Common Mistakes

  • Treating FLOW as a static label instead of a dynamic diagnostic lens

  • Using FLOW only for operations, rather than applying to communications, learning, design, etc.

  • Forgetting that all FLOW levels interact – effective work requires layered coordination

​

Red Flags

  • You’re overwhelmed by complexity but can’t pinpoint the cause

  • Your organization repeatedly applies the same solution to problems of different FLOW levels

  • Tasks are misrouted or mis-prioritized, leading to delays or burnout

 

Key Diagnostic Questions

  • What FLOW level best describes this Unit of Effort right now – and why?

  • Are we mixing FLOW levels in ways that are causing dysfunction?

  • What is the dominant FLOW level in this process, and is it being treated appropriately?

 

Local Application Prompts

  • Take any initiative you’re leading today. Classify each component by FLOW level. What patterns emerge?

  • In your next team discussion, ask: “What FLOW level are we operating in right now?” and adjust your strategy accordingly.

​

Alignment Risks

  • Applying a FLOW A mindset (procedural) to FLOW D work (System Design)

  • Designing systems without FLOW D awareness, making future FLOW B and C work harder

  • Under-resourcing FLOW S cases due to their unique, hidden nature

​

Systems Design Anchors

  • Build dashboards, workflows, and org charts that visually reflect FLOW levels

  • Use FLOW labels in SOPs, role definitions, and project briefs

  • Anchor planning and feedback loops around FLOW dynamics, not just timelines or budgets

​

Role Implications

Leaders: Must learn to see FLOW at every level and create environments that manage it deliberately

Analysts: Become FLOW stewards – improving clarity, routing, and alignment

Educators, Designers, and Strategists: Apply FLOW not just to what they do, but how they teach and evolve systems

​

© SolveBoard 2026

bottom of page