Supporting decentralized, transparent decisions that enable faster flow of value

1. What is a Flow Decision?

A Flow Decision is a deliberate, documented choice made to improve the flow of change or value within and across teams. Unlike traditional top-down decisions or untracked team-level adjustments, Flow Decisions are:

  • Grounded in user needs and real-world context
  • Made using a lightweight advice process
  • Shared transparently using a Flow Decision Record (FDR)
  • Reviewed and evolved over time—not set in stone

2. Why Flow Decisions matter

In fast-moving organizations, decisions about team structures, boundaries, ownership, and responsibilities are often made informally—or not made at all. This leads to:

  • Conflicting priorities
  • Repeated work
  • Missed user needs
  • Friction between teams

Flow Decisions help by:

  • Maximizing alignment without central control
  • Reducing ambiguity in how we respond to user needs
  • Increasing momentum by making structural evolution part of everyday work

3. When to make a Flow Decision

Use a Flow Decision when you hit a structural friction point—a signal that flow is blocked or unclear. Common triggers include:

  • Ownership is unclear across teams
  • Work keeps bouncing between teams
  • A team is trying to serve too many users
  • One service has diverging or conflicting needs
  • You’re considering splitting, combining, or changing team responsibilities

Ask yourself:

“Are we making a decision that affects how value flows across people, teams, or services?”

If yes—consider creating an FDR.

4. Anatomy of a Flow Decision Record (FDR)

Each FDR should be concise and structured for clarity and action. Here’s a basic format:

Field Description
Title A short, descriptive name
Context What triggered this decision? What flow issues or needs are in play? See Flow Decision Triggers
Decision What are we trying, changing, or clarifying?
Advice Gathered Who was consulted? What input did they offer?
Expected Impact What will this decision change or enable? What risks exist? See Flow Descision Outcomes
Approach What is the proposed approach to addressing the decision? See Flow Decision Approaches
Owner Who is responsible for shepherding this change?
Start Date / Review Date When will this be active? When will we review it?
Evaluation plan What evidence will we use to evaluate the decision? See Flow Decision Metrics
Status Proposed, Accepted, Rejected, Implemented, Evaluated

5. Making the decision: Use the Advice Process

Flow Decisions are made with input, not by consensus.

  • Identify stakeholders: Who might be affected? Who has relevant expertise?
  • Seek advice early: Give people a chance to contribute insight or raise risks
  • Own the decision: The proposer decides, incorporating feedback transparently

This approach builds trust and speeds up progress—without falling into design-by-committee.

6. Communicating and acting on the decision

Once the FDR is finalized:

  • Share it visibly: (e.g. FDR board, dashboard, Slack/Teams post)
  • Link it to your roadmap: (Now–Next–Later)

Support the decision with necessary changes, such as:

  • Reassigning responsibilities
  • Adjusting team interactions
  • Clarifying policies or agreements

7. Reviewing and evolving FDRs

Each Flow Decision should be reviewed regularly:

  • Has the expected impact been realized?
  • Are the risks or trade-offs acceptable?
  • Do we need to evolve, extend, or reverse the decision?

Build a cadence for reviewing active FDRs (e.g. monthly) and let teams reflect on what’s working.

8. Example FDR (Fictional)

Title: Split the Data Services Team into Two Stream-Aligned Teams

Context: Data Services team is overloaded, serving multiple business domains with competing priorities.

Decision: Split into two stream-aligned teams: one focused on Product Analytics, one on Operational Reporting.

Advice Gathered: Consulted domain leads and platform architect. Consensus that focus would improve responsiveness.

Expected Impact: Reduce delivery delays, clarify ownership, and improve domain-specific expertise.

Owner: Head of Data Engineering

Start Date / Review Date: April 15 / June 15 Status: Proposed

9. Start Small, Learn Fast

  • Flow Decisions don’t need to be perfect—just intentional and transparent.
  • Start with one or two real FDRs.
  • Keep them lightweight
  • Share and reflect openly
  • Use each one to improve your playbook

10. From signals to strategic action

Flow decisions don’t come out of nowhere. They’re usually preceded by signals—early indicators that something’s slowing down, unclear, or misaligned.

🔍 Flow Decision Signals

These are the friction points and early warning signs observed in team interactions, delivery patterns, or user feedback. They don’t always require immediate action—but they’re worth watching.

Examples of Flow Decision Signals:

  • Work keeps bouncing between two teams
  • A team is frequently interrupted by another for support
  • Two teams regularly deliver conflicting outcomes
  • Users report inconsistent service experiences
  • Ownership of a capability or decision is unclear
  • There’s a growing backlog of handoffs or dependencies
  • Re-org fatigue: “We already tried that” without clarity on what changed

Categories of Signals:

  • 👥 Interaction strain (collaboration fatigue, misaligned touchpoints)
  • 📦 Delivery misalignment (unclear outcomes, unmet needs)
  • 🧠 Cognitive load indicators (context switching, rework, burnout)
  • 🔁 Repeated exceptions (edge cases becoming the norm)

🧭 Flow Decision Radar

The Flow Decision Radar is a facilitation tool used in workshops or retrospectives to surface, cluster, and visualize signals across multiple teams or services. It helps teams and facilitators answer:

  • Where are signals strongest?
  • What kind of signals are we seeing?
  • Are these isolated or systemic?
  • What’s worth investigating further?

How it works:

  • Use a radar-style chart or Miro board
  • Plot observed signals in categories or zones
  • Group similar observations
  • Discuss which might indicate a Flow Decision Trigger

Think of the radar as your early detection system for where structural misalignments are starting to emerge.

⚡️ Flow Decision Triggers

A Flow Decision Trigger is a moment where signals have accumulated—or clarity has emerged—enough to justify action.

Triggers are thresholds, not just observations. They suggest:

“We’ve seen enough to make a call, or at least explore an option.”

Common Flow Decision Triggers:

  • A service or capability has no clear owner
  • A platform team is unable to meet the needs of its internal consumers
  • A single team is pulled in opposing directions by multiple stakeholders
  • A persistent dependency or interaction friction is blocking delivery

🗺 Connecting to the Flow Decision Roadmap

Once a trigger is recognized, the team (or steward) creates a Flow Decision Record, and places it on a shared Now–Next–Later Flow Decision Roadmap.

This roadmap:

  • Visualizes active and upcoming decisions
  • Tracks dependencies and review dates
  • Helps coordinate incremental structural evolution

You might also mark:

  • Emerging Signals: Watchlist items
  • Proposed Decisions: Being explored or advised
  • Active Decisions: In effect
  • Under Review: Being evaluated or evolved

Decisions shouldn’t pile up in a backlog—they should flow, just like the work they support.

🔄 Feedback Loops & Review Cadence

  • Review the Radar and Roadmap together in regular Flow Clinics
  • Use reflections and outcomes to refine your radar categories
  • Track signal-to-impact patterns over time to improve foresight