Principle 18:
Optimization Is Relative to FLOW Level

Summary

Optimization is always relative to a defined Unit of Effort and the system in which it operates. A solution that optimizes one Unit may cause inefficiency at another level unless explicitly aligned across layers of the FLOW structure.

 

Examples

Unit of Effort being Optimized: Responding to customer service emails (Mixed FLOWs)

Change Made: AI autoreplies are added to reduce response times.

Result: Response time improves for FLOW A cases, but complex or sensitive cases (FLOW C) now get generic responses, causing escalations and brand risk

Lesson: Optimizing a Unit of Effort without regards to FLOW creates downstream cost

 

Unit of Effort being Optimized: Low-dollar purchase requests

Change Made: A Fast Track button skips full review

Result: Teams begin using Fast Track for low dollar purchase requests with complexity, overwhelming monitors who now have to issue fixes due to oversights

Lesson: Local speed gain creates oversight risk upstream

 

Unit of Effort being Optimized: Team meeting setup

Change Made: A standardized format and template is required for every meeting

Result: Meetings run more smoothly at team level, but innovation-focused teams (FLOW C) feel restricted and skip   meetings altogether

Lesson: Optimization imposed on FLOW A and B level meetings clashed with the flexibility needed at FLOW C.

 

Unit of Effort being Optimized: Onboarding sessions

Change Made: Condense five sessions into one fast-tracked training video.

Result: Entry-level employees now lack context for FLOW C scenarios later, requiring expensive remediation.

Lesson: Local efficiency sacrificed long-term comprehension

 

Unit of Effort being Optimized: Ticket categorization

Change Made: Auto-routing based on keywords to reduce manual triage.

Result: Misrouted tickets cause backlog in FLOW C security and infrastructure teams due to false positives.

Lesson: Without FLOW-Level awareness, automation pushed cost upward

​

Quick Case Study

A procurement team automates the review process for small simple purchase requests (FLOW A) to reduce processing time. While it seems efficient locally, the change creates a bottleneck upstream, as FLOW C policy review teams are overwhelmed by an influx of borderline requests that now bypass initial scrutiny.

​

 

Common Mistakes

• Over-optimizing the local task without understanding upstream or downstream consequences

• Applying the same optimization logic to all FLOW levels

• Failing to define the boundaries of the Unit of Effort before optimizing

 

Key Diagnostic Questions

• What is the defined Unit of Effort for this optimization?

• Who is affected before and after this Unit of Effort, from the local level point of view?

• Are you pushing complexity downstream or upstream?

• What’s being reused, repeated, or delayed structurally?

• Can this be broken into parallel tracks or modules?

​

 

Local Application Prompts

• Take a recurring process you’ve improved. Identify whether you defined the Unit of Effort first.

• Reflect on a change that improved local performance but caused issues elsewhere – what FLOW levels were involved?

​

Alignment Risks

• Siloed improvements can create hidden friction between FLOW levels.

• Misaligned KPIs (e.g., speed over accuracy) can degrade performance of senior Units of Effort

​

Systems Design Anchors

• Map interdependencies before applying optimizations

• Ensure any automation, delegation, or streamlining respects the FLOW level structure

• Implement feedback loops to detect downstream consequences early

​

Role Implications

Leaders: Should prevent local optimization from undermining strategic senior Units of Effort

Analysts: Should always define the boundaries of what is being optimized.

Managers: Should evaluate improvements through a system lens, not just a team lens