This uses Jira as an assumed environment for work tracking, but should apply to any work management system.

Definition of a Blocker

A clear policy must define what constitutes a blocker versus an “impediment.”

• Internal Impediment: Something the team can resolve themselves (e.g., waiting for a teammate to finish a review - this can be addressed within the team).

• External Blocker: A true blocker is usually an external dependency (e.g., waiting for a third-party API, legal approval, or a hardware delivery).

• Is it a block?: If the team cannot progress the item through their own actions, the item is officially blocked.

That being said, my rule of thumb is that any condition that stalls progress for more than 2 hours should be recorded: via right-click `Flag with comment` on the Kanban board. It may just be friction or some impediment, but without the record, we will likely struggle to understand trends and patterns over time.

Impact on Flow and Measurement

Kanban focuses heavily on Cycle Time and Work Item Age. A blocker policy should dictate how these are handled:

• The Clock Never Stops: We do not stop the clock on Cycle Time just because an item is blocked.

• Why? Because the customer doesn’t care why it’s late; they only care when it’s delivered. Stopping the clock provides a false sense of efficiency, destroys observability, and erodes trust.

• Blocker Age: Teams are encouraged to monitor “Blocker Age” as a leading indicator. If an item is blocked for longer than your 50th percentile cycle time, it needs immediate escalation.

Why can’t we use a swimlane or column to track blocks?

With a blocked column you lose a lot of critical information that helps you act effectively on not just individual blocks but block patterns and the overall work in progress.

If you care about flow metrics and diagnostics then a blocked column makes your work harder and less precise. It matters where work is blocked - and for how long - if you want to effectively address the causes of blocks. If you move it the moment you hit a blocker, you lose the data around cumulative impact (e.g. “we hit a block in review with 70% of tickets and it typically costs 3 days, which stretches out the cycle time of review”). Moving the item into another column also obscured the context of where the item came from (unless you dig for it). Where should it go back to when it gets unblocked?

With a blocked column you lose all of that information unless you do some complicated, unnecessary data querying to stitch it all together. Jira and other work management tools provide specific mechanisms (e.g. ‘flag’ and ‘flag with comment’) that allow you to record blocks without sabotaging your flow data or board rules for making efficient progress.

As an advisor, I care about how long items stay blocked. I care MORE about where the blocks are happening, and the impact of those blocks on the relevant stage. A block in planning is much cheaper than a block once we’ve spent weeks building a solution.

One of the easiest rules to maintain flow is to mandate that items should never go backwards on a board. It ensures progress is steady and the team can clearly understand progress at a glance. With a blocked column, your work items are potentially moving to and from your blocked column multiple times, and progress is impossible to understand without additional commentary. With a flag, I can see exactly where the item is blocked, and progress is preserved. In a tool like Jira, I also get a visual indicator on the blocked item, and I preserve my column WIP. It’s too easy to park a blocked item in a blocked column, then start a new task and preserve my WIP limit. My WIP hasn’t gone down, but I have a new task to pay attention to, and my block is easily forgotten.

Flag vs Label

Your other option is to either use flagging or a label, where flagging is a built-in capability that has a few advantages:

Blocker Clustering (Data Analysis Strategy)

Every time a blocker is identified or resolved, you shouldn’t just move on—you should capture the data. This is called Blocker Clustering.

• Track the “Why”: Categorize the reason for the block (e.g., “Vendor Delay,” “Missing Specs,” “Environment Down”).

• Track the “Duration”: Record how many days the item remained blocked.

• The Analysis: Periodically group these “clusters.” If 80% of your delays come from “Legal Review,” you have empirical evidence that the Legal process is your system’s primary constraint.

Blocker Policy

Explicit Escalation Paths

A policy is useless if it doesn’t tell the team what to do when a flag goes up. A policy typically includes:

• Level 1: Team attempts to resolve within 24 hours.

• Level 2: Scrum Master/Flow Manager/Outcome owner intervenes with outside stakeholders.

• Level 3: Leadership is notified of the specific “Cost of Delay” associated with the blocked item.

Blocker Tracking:

Track blocker data to identify common causes. Most blockers are common causes that should be systematically addressed.

Antipatterns - what to avoid:

• Lack of Clarity on What Counts as “Blocked”

  • Data Pollution: If one developer flags a 10-minute coffee break and another ignores a 2-day dependency, your “Blocked Time” metrics are meaningless noise.

  • Hidden “Tinkering”: Without a clear definition, we often “tinker” or “gold-plate” a task while waiting for info instead of flagging it. This is waste disguised as productivity.

  • Swarming Paralysis: The team doesn’t know when to jump in. In a healthy Kanban system, a “Blocked” flag is a flare for the team to swarm and help. If “blocked” is vague, the team stays in their silos.

  • WIP Limit Friction: It leads to arguments over whether a card should still count toward a person’s limit. This friction slows down the actual work.

• No Escalation Path for Extended Blockers

  • A “Blocker Graveyard”: Without a timer (e.g., “If blocked for >24 hours, notify the Lead”), work could sit for weeks. By the time they are unblocked, the context is lost and the code usually requires massive rework.

  • Learned Helplessness: If developers feel like their hands are tied and no one in leadership is helping, they stop caring. It destroys the “Stop the Line” culture essential to Lean.

  • External Priority Blindness: External teams or contributors won’t prioritize your needs if there isn’t a formal “nudge” from a manager or stakeholder. Without escalation, you are always at the bottom of their pile.

  • Predictability Collapse: Long-term blockers create “outliers” in your data. This makes your delivery dates look like a guessing game rather than a science, which ruins stakeholder trust.

• Blocks only raised in standup:

  • Massive Time Leakage: Waiting until the next morning to report a blocker means a task could sit idle for up to 23 hours. That is pure waste (Muda) in your Lead Time.

  • Status Report Syndrome: It turns the standup into a “confessional” rather than a tactical sync. Standups should be for discussing the fix, not discovering the problem.

  • Passive Culture: It encourages a “not my problem until tomorrow” mindset, where developers stop taking initiative to clear their own path the moment they hit a snag.

• Not measuring blocks:

  • The “Invisible Waste” Problem: You can’t manage what you don’t measure. Without “Blocked Time” data, you have no objective way to prove why a sprint or cycle failed.

  • Unfair Performance Metrics: If you don’t track blocks, the team just looks “slow.” Their Cycle Time blows out, and without data, management often blames “low productivity” instead of “systemic bottlenecks.”

  • Flow Efficiency Blindness: You lose the ability to calculate your Flow Efficiency (Active Work vs. Total Time). You might be “working” 100% of the time but only “producing” 20% of the time because of unmeasured waiting.

• Not tracking where blocks happen:

  • Whack-a-Mole Improvement: You know as a team you’re often blocked, but you don’t likely know where you’re blocked most often and why. You might try to pressure development or testing when the actual issue is a broken environment or a flaky API.

  • No case for support: If you can’t support a request with evidence, it’s unlikely that you can make a solid case for help or investment in a change.

  • No Root Cause Analysis: You miss out on Blocker Clustering—the practice of grouping blocks by category (e.g., “Environment,” “PO Clarification,” “Legacy Code”) to find the most expensive recurring issues.

  • Misallocated Resources: Without knowing which stage is most prone to blocking (e.g., Design vs. QA), you might hire more developers when what you actually need is a dedicated DevOps engineer to fix the build pipeline.

• Dedicated ‘blocked’ columns:

  • Breaks One-Way Momentum: Moving work backward destroys the “left-to-right” pull that drives progress and creates visual confusion about where work is stuck.

  • Hides “Invisible” WIP: Parking a card usually removes it from your Work-In-Progress (WIP) limit. This tricks the team into thinking they have capacity to start new tasks, leading to multitasking and mental overload.

  • Kills Urgency: If a blocked card isn’t “cluttering” an active lane, the team stops feeling the pain of the delay. Without that friction, there is no incentive for stakeholders to provide the missing info quickly.

  • Encourages Lazy Refinement: Having a “safety net” column makes it okay to start work that isn’t ready. It rewards poor planning and ensures that “Definition of Ready” is never taken seriously.

  • Games the Metrics: It allows you to “stop the clock” on Cycle Time. Your data might look fast on paper, but the actual time the customer waits for the feature (Lead Time) stays exactly the same. Age-in-column breaks when you move the ticket, so you lose track of critical data.

  • Fragments Context: Moving work back creates a “limbo” state. You lose the data on where the work actually stopped, making it harder to identify the cause and see the cause patterns.

Sane Defaults for Blocker Policy

Suggested Additional Policies and Practices

• Immediate Swarming: When a “Blocked” flag is raised, the team must treat it as a “flare”. Team members pause secondary tasks (e.g., minor refactoring, documentation) to check if they can immediately swarm and help clear the path, reinforcing the “Stop the Line” (Andon) culture essential to Lean.

• Active Definition of Ready (DoR) Enforcement: Strengthen the Definition of Ready to explicitly prohibit starting work (pulling a card into a WIP-limited column) if a known external dependency or required information is outstanding. This prevents “Lazy Refinement” and ensures the card is ready to flow.

Impediments and Blockers to track

• Slow Infrastructure: Dealing with sluggish build pipelines or unoptimized development environments.

• Testing Bottlenecks: Being stalled by a prolonged or inefficient testing phase.

• Technical Debt: Struggling to navigate and build upon a messy or outdated codebase.

• Missing Stakeholders: Lacking the necessary decision-makers or subject matter experts in critical conversations.

• Cross-Team Dependencies: Relying on external groups to deliver their work before your team can proceed.

• Individual Bottlenecks: Being forced to context-switch and start new tickets simply because you are waiting on a specific dependency.

• Meeting Overload: Having your calendar filled with meetings, leaving no uninterrupted time for focused execution.

Practical Example

Here is a step-by-step linear walkthrough of how a team might apply the rules and policies you’ve outlined for managing blockers on a Kanban board, with a practical example:

Scenario

Your team is working on a Kanban board with a work item currently in the “Development” column. However, progress is halted because of a delay in getting the required API key from an external vendor. The team follows the policies outlined above to manage this blocker effectively.

Step 1: Identifying the Blocker (Level One - Blocking Criteria)

• Policy in action: After 2 hours without progress on the work item, the developer working on the task identifies that they cannot continue without an API key for an external service. According to the Blocking Criteria policy, the developer tags the work item with ‘Add flag’ to indicate that it’s blocked, and comments the details.

• Effect: The developer logs the block which collects data on the condition, creates a visual queue, and maintains the integrity of the flow metrics.

Step 2: Recording the Blocker Context (Block Tracking Policy)

• Policy in action: The work item remains in the “Development” column but is flagged. The developer adds a note explaining (via Flag with comment) that the blocker is due to an external dependency (waiting for the API key from an external vendor). The type of blocker (external) and the root cause (waiting for API key) are documented.

• Effect: The Kanban card now shows its blocked status with a note: “Blocked due to API key delay (external blocker).” This ensures visibility and accountability, and the blocker remains within the workflow, preserving the flow metrics.

Step 3: WIP Limits and Time-Based Review (Level Two - WIP Limits and Ageing Items)

• Policy in action: The blocked work item continues to count against the team’s WIP limit to reflect its impact on the system. It still needs to be managed, and should remain in active context. After three days, the work item is still blocked. During the next stand-up, the team reviews the blocker and escalates it to higher level leadership for further attention.

• Effect: WIP doesn’t expand so capacity doesn’t become overloaded, and the developer pursues escalation to make progress, preventing a stall or unnecessary delay.

Step 4: Blocker Clustering (Actionable Blocker Policy)

• Policy in action: The same blocker occurs multiple times over a few weeks (e.g., waiting for API keys or similar external dependencies). During the retrospective, the team clusters these recurring external blockers. It discusses ways to manage external dependencies more effectively, e.g., setting up earlier API requests or creating a vendor management process.

• Effect: The retrospective reveals that delays in receiving external API keys have blocked several work items in the past. As a result, the team decided to build earlier communication with vendors as part of their planning.

Step 5: Escalation or Cancellation (Level Three - Blocker Cancellation and Restart)

• Policy in action: The work item is still blocked after seven days. The team holds a review and decides whether to cancel the work item (if it no longer has value) or deprioritize it until the external issue is resolved. In this case, they decide to keep it on hold and escalate the problem to senior management to intervene with the vendor.

• Effect: The team moves the work item to the backlog, documenting that it will be revisited once the API key issue is resolved. They ensure that any lessons learned (e.g., the need for better external dependency management) are incorporated into their workflow.

Step 6: Systemic Process Improvement (Blocker Clustering)

• Policy in action: The team identifies a recurring pattern with external blockers through blocker clustering and regular reviews. They propose a systemic improvement, such as setting up vendor agreements requiring API keys to be delivered at least two weeks before the work item is expected to be developed.

• Effect: In the future, this process improvement will reduce the frequency of similar external blockers and improve the overall flow of work.

How do you handle blocks?

With clear policies, a team can ensure that blockers are visible, escalated, and resolved efficiently. They can improve their process through regular retrospective discussions and blocker clustering, addressing blockers systematically. The system evolves to reduce similar blockers in the future, enhancing flow and predictability.

Hope this is helpful for you! I’d love to hear what you’d add or change to fit your needs

Blocker Playbook

1.8MB ∙ PDF file

Download

Download

Reference

https://www.prokanban.org/blog/whats-wrong-with-having-a-blocked-column

https://nkdagility.com/resources/blog/blocked-columns-on-kanban-boards-obfuscate-workflow-and-undermine-effectiveness

https://www.prokanban.org/blog/do-you-treat-internal-vs-external-blockers-differently

https://www.prokanban.org/blog/automating-the-impact-of-blocked-work-in-jira

https://www.thoughtworks.com/en-ca/insights/articles/how-to-tame-evil-dependencies

JQL example to find blocked issues

project = “[TODO]” AND labels in (TODO) AND statusCategory = “In Progress” AND (Flagged is not EMPTY OR issueFunction in linkedIssuesOf(”resolution = unresolved”, “is blocked by”)) ORDER BY updated DESC

This week, I want to share a sneak peek of an article I’ve written for the Lean Enterprise Institute’s LeanTech Journal - diving deeper into some of these concepts, and what they mean for an agent-supported ecosystem. I hope you enjoy it, and I hope it sparks some conversation.

Most organizations are still trying to apply AI to existing workflows: faster coding, faster document generation, faster analysis, faster search. This risks paving the cow path — making the existing process faster without asking whether the process still makes sense.

The deeper AI opportunity is organizational redesign.

Lean thinking has always embraced the concept of value streams — the flow of material and information to go from a customer need, to delivered customer outcomes. Mapping the flow will always be necessary and not disappear. There is no future where value streams stop existing. Inputs still need to be refined into outputs. Outcomes still need to be observed. Feedback still needs to inform and improve the next cycle. AI can change how value streams are designed, routed, measured, and improved, especially in organizations that have narrowly considered value streams as static flows.

The best value streams already operate more like the internet, and the application of AI in organizations should be more like the internet flow of information.

From token ring to dynamic routing

Traditional organizations often behave like early network architectures.

In token ring networking, information moves sequentially through every node. You do not get to the destination unless you pass through each point in the chain. Many software and business processes still work this way: intake, analysis, design, approval, implementation, review, release. Everything moves at the speed of the slowest constraint. This waterfall logic also applies, unfortunately, to many current value streams.

The internet routes dynamically. Instead of sequential management it uses simple protocols, distributed capacity, error correction, telemetry, and loose coupling to move packets reliably across an enormous, constantly changing network. The path matters less than the ability to reach the destination efficiently and resiliently, although the flow still must be governed by clear protocols, constraints, escalation rules, and feedback. Complex systems (human or otherwise) need this.

A dynamic pattern is increasingly relevant to organizations, which are, essentially, a network of capabilities. In organizations pursuing digitization, teams are nodes. Platforms are shared infrastructure. Policies, objectives, service levels, and constraints form the management plane. Information, data, and work coordination form the control plane. Agents increasingly operate in the data plane, executing work, routing requests, surfacing exceptions, and helping teams adapt.

Shifting to a dynamic value-stream network isn’t just a matter of changing a workflow diagram; it requires upgrading the organizational operating system. To successfully facilitate and support dynamic routing, an enterprise must establish and support enabling capabilities that allow for adaptable workflow, such as:

1. Technical & Architectural Enablement

● Loosely Coupled Architecture: Business capabilities and software must be modular (e.g., microservices, bounded contexts). If your systems are tightly coupled, your teams will be, too, forcing a return to static, monolithic coordination.

● A Unified Semantic Data Layer: For work to route dynamically, systems must speak the same language. This requires integrating your toolchain (from ideation to production) so metadata (status, priority, ownership) updates automatically across the network via APIs or a data mesh.

● Value Stream Management (VSM) Platforms: You need real-time visualization of flow metrics (lead time, cycle time, work item age, flow efficiency). If you can’t see the bottlenecks dynamically, you can’t address them or route around them.

2. Governance & Funding Evolution

● Capacity-Based Funding: Shift from project-based funding (which creates temporary, fixed structures) to funding persistent value streams. This allows teams to pivot their focus without needing a new business case approved by a steering committee.

● Automated Guardrails (Policy-as-Code): Trust requires verification. To eliminate manual approval gates, embed security, compliance, and quality checks directly into the operational pipelines. If a work item passes the automated tests, it has the “authority” to route forward.

3. Organizational Design & Culture

● Stream-Aligned Teams (Team Topologies): Organize people around the flow of value, not functional specialties. Teams should possess all the cross-functional skills required to take an idea from concept to cash.

● Capability Focus: In a modern enterprise, two roles matter more than ever: Product roles that deeply understand customer problems, and engineering roles that understand problem solving. Domain knowledge remains critical, but with shared context and small batches of work, capacity becomes far more flexible.

● Explicit Work-in-Progress (WIP) Limits: Dynamic routing fails if every pathway is clogged. Enforcing WIP limits across the network forces the system to signal when it’s at capacity, triggering the need to reroute or reprioritize work.

● Psychological Safety and a Blameless Culture: Dynamic routing inherently involves experimentation and local decision-making. If failures are punished, individuals will default back to the safety of centralized, bureaucratic cover-your-back processes.

With these conditions in place, the flow pattern shifts from: “How do we optimize this fixed sequence?” toward “How do we design a system that can dynamically route from customer need to customer outcome based on capability, capacity, reliability, and context?”

Value streams still matter — but their design evolves

AI does not eliminate value streams but makes them far more important.

A value stream still connects a trigger to an outcome. But the path through the system cannot be singular, fixed, or linear, and, in true lean organizations such as Toyota, this has never been the case for the complete flow of all material and information.

Different customers, domains, products, and services may need different combinations of capabilities at different times. Some needs may be satisfied through self-service. Some may require specialized teams. Some may be handled by agents. Some may require humans in the loop. Network-based value streams offer:

● Multiple concurrent paths to outcomes

● Modular capabilities serving different customer needs

● Dynamic routing based on capacity and capability

● Teams that can be bypassed when unreliable

● Shared services consumed through supply-and-demand dynamics

● Humans moving increasingly toward oversight, policy, design, and exception handling

In stable environments, effective paths may still become paved. A goat path can become a trail. A trail can become a road, and demand prompts a highway. Stability is valuable when demand is known and the path is clear.

But the old highways are not automatically the right highways to modernize. In times of disruption, organizations may need to build new routes rather than repaint the lines on existing ones.

The bottleneck will continue to move

For years, organizations complained that software was too slow, too expensive, and too low quality. But many did not actually address the underlying constraints. They did not invest enough in platforms, automated testing, deployment automation, observability, or flow measurement. They did not understand their value streams or how to improve them.

Now AI is accelerating code generation, but that does not automatically improve the system or the value stream. In many cases, the constraint was not writing code. The constraint was merge queues, review, governance, unclear requirements, brittle architecture, poor test coverage, deployment friction, and weak feedback loops.

AI can make this worse if organizations double down on a non-constraint.

The same pattern will repeat outside software. Purchasing, HR, administration, compliance, and other knowledge-work domains have decades-old processes, undocumented tribal knowledge, and weak process visibility. Many have not successfully implemented lean administration and examined their value streams, let alone applied AI-enabled flow.

If the human is the bottleneck because the knowledge lives only in someone’s head, AI will not magically fix the system. The work must first be made visible, structured, codified, and measurable.

Before smart homes, fix the plumbing

Many organizations want a smart home, but they have not fixed the plumbing.

AI depends on information flow (i.e., plumbing). If the underlying data, context, and process knowledge are fragmented, outdated, or inaccessible, AI has little reliable material to work with. The old rule still applies: garbage in, garbage out. Legacy data is the critical bottleneck, in existing value streams or AI-enabled ones.

Before the current AI wave, data mesh — assigning data to specific domains — was one of the major enterprise topics. Then AI captured attention, and many organizations moved on, but the underlying need for decentralized data did not disappear. If anything, AI makes it more urgent and context more important. The quality, structure, ownership, and retrievability of information determine what AI systems can safely and usefully do.

Consider the risk of AI micro-optimizations atop legacy flows. A project involving multiple enterprise and legacy platforms was plugging in an AI solution over the top. The system had high usage but poor architecture: disconnected tools, weak retrieval, and difficulty getting useful answers from the available material. It was easy to use but ultimately delivered no value. We can’t simply sprinkle AI on top of existing systems and expect magic. To reach high leverage, we have to rebuild the information architecture so knowledge can actually be retrieved, used, and cultivated.

To transform with AI, many organizations face an information rebuild: plumbing, architecture, context, ownership, and flow.

The Cloud revisited

There is a recent precedent for this transition: cloud infrastructure.

Before infrastructure as code, many organizations depended on engineers who knew the manual steps. Those steps lived in heads, runbooks, tickets, and wiki pages. Over time, the work was codified into playbooks, automation, and tools such as Terraform, Ansible, and Kubernetes. That made infrastructure more repeatable, scalable, and transferable.

The same pattern is likely with agents: At first, everyone builds their own. Then duplication becomes obvious. Common skills, reusable agents, shared patterns, and agent-as-code approaches emerge. Eventually, teams converge around standard capabilities that can be understood, improved, governed, and reused.

The AI maturity curve is familiar to cloud:

1. Tribal knowledge

2. Documented steps

3. Repeatable playbooks

4. Automation

5. Shared platforms

6. Dynamic, observable, self-service capability

AI does not skip those stages. It compresses the timeline and raises the cost of ignoring them.

Questions for lean practitioners

Lean practitioners must get beyond the generic “Where can we add AI?” to questions specific to strategy, process, and measurements that clearly identify the highest potential for AI to deliver value:

Strategy Level

Focuses on long-term direction, value definition, macro-constraints, and overarching governance. It defines what success looks like and sets the boundaries for the entire system.

● Which customer outcomes matter most?

● Which value streams are most constrained?

● Where has the bottleneck moved?

● Which old assumptions about cost, capacity, or sequencing are no longer true?

● What management-plane policies, objectives, and service levels should guide the system?

● What lagging indicators define success?

Tactics Level

Bridges the gap between strategy and execution. It focuses on systemic design, cross-team coordination, infrastructure, tool integration, and structural optimization.

● Which capabilities should be modular, reusable, or self-service?

● Where do we need dynamic routing instead of fixed handoffs?

● Where are teams manually coordinating what software or agents could route?

● Where is information fragmented across tools?

● What middle-loop metrics show whether the system is improving?

● What questions should the data answer?

Operations Level

Deals with ground-level execution, immediate workflow visibility, task-specific automation, and real-time monitoring to keep the system flowing smoothly.

● Where is work still trapped in human memory?

● Which tasks are repeatable enough to codify?

● Which decisions require human judgment?

● Which agents need to be visible on the process map?

● What data is required for flow and continuous improvement?

● What leading indicators reveal problems early?

● What telemetry is needed to detect flow breakdowns?

● How does each measurement help people ask better questions?

A useful frame is outer-loop, middle-loop, and inner-loop measurement. The outer loop focuses on lagging outcomes. This is your strategic feedback loop of continuous improvement at organization scale. The inner loop focuses on leading signals closest to the work. This is your operational feedback loop of continuous improvement at team and individual scale. The middle loop connects local learning to broader system improvement. This is your tactical feedback loop of continuous improvement at cross-team or portfolio scale. By intentionally building these loops you create the “control plane” that sophisticated networks use to self-manage, adapt, and operate at peak performance and resilience.

The lean opportunity

AI will reward organizations that understand flow (i.e., lean organizations that already understand and optimize their value streams). It will penalize organizations that do not.

The companies that benefit most will not simply attach AI to existing processes, but use AI as a forcing function to make work visible, codify knowledge, clarify value streams, improve data quality, redesign constraints, and build dynamic systems that can sense, route, learn, and adapt. Beyond the basics, AI should prompt you to reevaluate not only the value stream, but the value-stream network. With the rise of software factories and engineering “shifting left,” we have new opportunities to imagine how work can flow across organizations, just like at the advent of electrification.

Lean has a powerful role to play here. But the conversation needs to move beyond “AI use cases” and toward AI-enabled operating models. Beyond task automation and toward value-stream redesign. Beyond individual productivity and toward networked capability.

The future organization may look less like a hierarchy of functions and more like the internet: simple rules, dynamic routing, observable flow, resilient nodes, modular capabilities, and continuous feedback.

The value stream is not going away. It is becoming more and more like a dynamic, adaptable, reliable network.

When mapping is an isolated event, it decays the moment the team leaves the mapping session.

As we say: The mapping is more important than the map.

Maps of a changing landscape age like milk.

The mapping sticks around as new connections, perspectives, ideas, visualizations, and confidence.

With digital tools and whiteboards, we gain the ability to keep that map alive and evolving, but it’s a losing battle unless we build enabling capabilities into workshops and workflow.

From isolated exercise to living practice

AI is changing the landscape faster than ever. By taking on artifact creation, data synthesis, and action integration, AI is finally enabling value stream management to shift from a periodic ritual into a continuous, living practice—one that reflects the system as it actually is today, not as it was three months ago during the off-site.

Just like AI localized in a coding assistant tucked into a developer’s IDE isn’t going to deliver impact at the global system level, AI just used to create meeting notes isn’t going to revolutionize Flow Engineering. It needs to be embedded into the engine for management and systemic optimization. The more we offload the heavy lifting to machines, the more human the process becomes.

Shifting the human role from cartographer to problem-solver

In Flow Engineering, the Five Maps—outcomes, current/future states, dependency, and roadmap to action—provide a blueprint for workflow transformation. Historically, drafting these required immense coordination overhead. Teams could be intimidated or exhaust themselves on the act of drawing before they ever got to the act of thinking.

Multi-modal AI can now automate the initial drafting of these maps by synthesizing existing documentation and process data, or following a collaborative analysis session. The map arrives ready for analysis, or emerges through conversation.

• When the team isn’t worn down by logistics, they have the cognitive energy to ask the harder questions: where is flow actually breaking down, and why? We can spend more time, more efficiently and effectively, digging deeper into the root causes and conflicts that create the conditions we see.

AI can support facilitation, creating more space and clarity for what humans can foster in a mapping workshop:

• Identifying opportunities for clarification or highlighting potential conflicts

• Navigating politics and nuanced perspectives

• Fostering engagement and contribution

• Picking up on weak or strong signals like facial impressions and posture

Beyond the Workshop

Finding the real constraint, not just the nearest one

One of the most dangerous failure modes in optimization is the local fix. You speed up one part of the pipeline and create a pileup at the next bottleneck. The problem moves downstream; it doesn’t disappear.

In Flow Engineering, we find this through Rapid Value Stream Mapping, using data and the experience of the team to surface hot spots we can diagnose with Dependency Mapping.

AI enables this through system-wide telemetry and predictive analytics. By analyzing patterns in lead time, rework, blockers, cycle time, and wait states across the entire end-to-end system, it surfaces the true constraints—the ones that are invisible to the naked eye when you’re looking at one team’s data in isolation. The result is an investment that optimizes the whole stream, not just the part that was loudest in last quarter’s retrospective.

Today, this looks like using Gen AI to create deterministic code, but increasingly AI is capable of running a playbook and making judgement calls with clear guidance, supported capability, and continuous learning - just like we need with the humans in the loop today.

What does it look like to have an AI Flow Engineer monitoring flow across your value streams?

AI in Flow

Reducing friction at both ends of the lifecycle

The humanity of a value stream is often buried under coordination overhead and rework. AI acts as an enabler at both ends:

• Upstream, product teams are using AI to synthesize fragmented feedback into clear, actionable requirements. This reduces cognitive load on engineering and cuts the frustrating, costly rework caused by ambiguity before a single line of code is written.

• Downstream, AI automates the toil—test generation, release notes, log analysis—that clogs QA and deployment bottlenecks. Engineers get faster feedback loops and more time for the work that actually requires human judgment and innovation.

Increasingly, AI is translating manual efforts into code, freeing human capacity for dynamic, varied, and complex work that needs a human to chew on.

• When we’re not too busy sawing, we can step away to sharpen the saw, and maybe choose a different tree.

Space for the work that matters

We are operating in a landscape more complex than ever before. That landscape requires more than just AI managing flow, data, and visualization. It requires humans with the tools to create and act on insight. To design, imagine, experiment, and revolutionize. To Reach beyond iteration and increments.

When AI handles data synthesis and the mechanical work of mapping and measuring, it creates space for what humans do best: striving, pushing, imagining, collaborating - but most of all, leading. AI can help us understand the odds, but we need to be placing the bets.

By using Flow Engineering supported by AI, we can offload what we can, to focus on what we must.

Watch this space, I’ll be sharing what works as I find it!

If you want to hear more, I’ll be presenting on the topic at Flowtopia Live on June 24 but I’d also love to hear from you directly!

In the analogy of the three plane view of an organization as a network: Lean has been strong in the management plane (leading the work), and the data plane (doing the work) - but less visible in the control plane, the coordination, signaling, organization, and information flow that connects management to data - leadership to the work.

Lean tech has been around since the 1990s. The fundamentals haven’t changed. Why are we just now establishing a dedicated focus to it?

Despite all the benefits, the clarity of the principles, the existing foundation of lean, and countless case studies, it’s still very challenging for most people to grasp and assemble the ingredients, recipes, techniques and tools of lean in tech. ‘Tech’ being the knowledge work, software development, IT, and digital contexts that are woven into everything we now do. The promise of automation has skyrocketed, and with it we either amplify the good or the bad. It’s critical now more than ever to build lean into our tech investments and activities to ensure we amplify the good.

It’s challenging to grasp because tech makes it deceptively easy to build, and the invisibility of critical tooling makes it hard to see the supporting machinery that makes it easy to build the right way. When you walk the floor of a factory, you can see precision applied to quality controls, the visual aids, the safety mechanisms, and the tools of improvement, all readily at hand. That may seem like a stark difference to tech, where artifacts and code sit hidden behind an array of interfaces, but the real value and challenge in either domain is invisible. The information flow, learning, value, leadership, communication, continuous improvement behaviours are largely unseen. The supporting tooling and guardrails should be enabling performance and quality but when they do their job well they remain hidden. When we focus just on the movement of an item of work, we miss the fact that what enables that movement and supporting its quality are systems, principles and processes that we can easily ignore.

It may seem that tech is fundamentally different from physical manufacturing, healthcare, or construction, but all these domains just operate along a spectrum that identifies a focus of our efforts. In tech, we may easily think of building new things, a developmental focus on change, and increasing variation, but we also need the opposite end of the spectrum - operational focus - in different areas. We need self-healing systems informed by anomaly detection, stability and scalability - just as much as we need the next new thing.

Lean doesn’t inform just one end of the spectrum - value, clarity, learning, pull and flow apply everywhere. We want more variation in discovering new innovations, and less variation in operational management.

What truly matters is identical between the two domains: Time is real, value is real, cost is real. The time horizons may vary, the attribution of value may vary, and the unit economics may vary, but these differences aren’t nearly significant enough to establish a distinction.

Waste changes from physical scrap to cognitive load and toil. Tech focuses on “Cost of Delay” while manufacturing focuses on “Unit Cost.” There’s a difference of focus from “Conformance to Spec” to “Fitness for Purpose.” - again, along a spectrum that also applies to tech. To succeed, information flow must be elevated to the level manufacturing dedicates to material flow.

These are distinctions without meaningful difference. Most flows and aspects of work are the same: Vision to strategy. Prospect to customer. Incident to resolution. Idea to production. Order to onboarded. Value, flow, feedback, and learning are critical and identical to both contexts.

Shared Core Principles

• Customer Value: Every action should be adding or supporting value to the customer or user.

• The Pull System: Never start work until there is a clear “pull” from the next step in the chain. In a factory, it’s a bin; in digital, it’s a prioritized queue.

• Continuous Flow: Aim for “Single Piece Flow.” Don’t batch 1,000 widgets; don’t batch 50 features into one deployment. Flow of activity, artifacts, and information.

• Jidoka (Autonomation): Build quality into the process. In a factory, the machine stops if it detects an error; in digital, the CI/CD pipeline fails if the tests don’t pass.

• Pursuit of Perfection: Innovation and continuous improvement rely on systems supporting rapid feedback and learning.

Required Enabling Supports:

These are the parts easily missed in tech, and perhaps taken for granted in the world of atoms:

• Organizing Around the Customer: Because digital work seems technically important, we incorrectly organize teams by technology, component, or function, rather than customer needs. The best tech companies treat every dependency as a customer, fulfilled by self-service.

• Early and Rapid Testing: Because code seems cheap we tend to dive right in, but “building quality in” requires extensive automation and testing techniques that few invest in. Acceptance testing, contract testing, and testing assumptions are all too rare.

• Flow Measurement: Measuring age, cycle time, lead time, work item profile, work in progress (WIP), and throughput help balance load and capacity. It empowers data-driven insight, fast adaptation, and continuous improvement. It facilitates forecasting and avoids painful estimation and compromised commitment.

• Visualizing the Value Stream: The iterative, spiralling nature of digital work and rework seems to negate a simple depiction of flow - but by aiming to represent even the complex we begin to simplify and improve.

• Reducing WIP and Focus on Finishing: It’s easy to start work when we can assign a task, but WIP is tremendously expensive and hard to manage. Being blocked just amplifies the problem - we start something new.

• Full Kit: In digital contexts, we often start work not knowing how it might be delivered. We lack testing to tell us when we’re off track. Digital infrastructure is often manually configured, unreliable, poorly managed and seen as secondary to features. It often blocks work and creates rework or confusion.

• Information Flow: Low-value meetings are a failure of information flow and empowerment, yet our staff’s calendars are packed to the gills. Repeated syncs, big-room planning, and discussions without decision plague many tech organizations. We fail to invest in getting the right signal to the right person in the right position to act.

• Loose Coupling: The most innovative early manufacturers leveraged electricity to decouple their stations previously tethered by pulleys - to organize in service of flow. The digital equivalents leverage patterns that break coupling and increase adaptation, resiliency, and scale.

Identical Human Behaviors

• Gemba (The Real Place): Managers and supporting staff must go to where the work happens. In physical, it’s the shop floor; in digital, it’s tracing an idea’s path to production or replaying incident response. Mapping the value stream is even more important when the work isn’t easy to trace. Increasingly management activities are supported by AI, allowing humans to lead and teach more intentionally, supported by data.

• Kaizen (Continuous Improvement): Small, daily changes and experiments by everyone, everywhere. Big transformations and reorganization is a last resort. Ask “how do we fix this friction today?”

• Respect for People: Lean assumes the person doing the work is the expert. Whether they are turning a wrench or writing a script, they should own the improvement process and critical decisions they are closest to.

• Standardized Work: Defining the “best way we know today” to perform a task so that any deviation is immediately visible as an opportunity to learn, and cognitive load is optimized.

Universal Benefits

• Faster Feedback Loops: Reducing WIP allows you to find mistakes in minutes rather than months.

• Increased Agility: Less “Inventory” (physical or digital) means you can pivot your strategy without losing millions in “sunk” work.

• Higher Quality: By focusing on “Built-in Quality,” you stop “inspecting” quality at the end and start “creating” it at every step.

• Employee Engagement: Workers feel empowered when they have the tools to solve their own bottlenecks.

The “frontier” of Lean today lies in the integration of these two worlds. Digital twins, digital agents, robotics, game engines, 3D printing, augmented reality, and smart devices have all come to blur the lines between the physical and digital. As AI enters the workspace, the need for Lean thinking becomes even more urgent. Luckily with lean we have the models, mindsets, methods, and metrics to amplify the good. We need principles to ensure that technology augments human capability rather than sideline it.

Whether you are moving atoms or bits, the core remains the same: Respect the person, enable flow, and never stop learning.

I’d love to hear from you: Is lean a specific focus in your organization? Is it taken for granted? Is it a relic?

Repetition is mechanical. It is doing the same activity, in the same way, expecting the same output. It’s a closed loop—motion without progress.

• This is the ‘try harder next time’ sprint retro, or mechanically progressing through work items

Iteration, by contrast, is cybernetic. It implies a learning process that changes the system.

• This is the retro with commitment to change the system, using learning to make adjustments, and using current conditions to change approaches

The Steersman vs. The Locked Wheel
Consider the origin of the word cybernetics: kybernetes, the Greek word for “steersman.” (or captain, pilot, navigator)

A steersman doesn’t lock the wheel in one position and hope for the best. That’s repetition: the same direction, minute by minute without adaptation. They constantly adjust based on the wind and waves.

In a business context, a strategy document written in January and followed blindly until December is a locked wheel. Real leadership is steering- measuring the error signal from the market and adjusting resources dynamically. It’s not just the strategy but the full deployment and implementation based on the conditions on the ground. If you aren’t adjusting the system, you aren’t iterating, you’re just repeating.

The Governance Loop
We see the difference clearly in how organizations handle requirements.

• Repetition: A team sends a document for approval, it gets rejected for a missing field or some standard, they fix it, and send it back. This is re-work. It can feel like “collaborating,” but it’s actually just waste.

• Iteration: The team gets rejected, but then changes the template or the intake process so that the error is impossible next time.

Repetition fixes the instance; iteration fixes the flow.

Iteration vs Operation

Change for the sake of change can easily exhaust or overwhelm an environment, so it’s important to make time to synthesize learning and apply change when capacity and appetite allows. In a Flow Engineering program, we typically change the environment rapidly and intensively soon after mapping (3-6 months). We then observe the environment under operation and make space for stabilization for another equal period (3-6 months). Then we synthesize observations and look for new opportunities by repeating the program. Balance consistency and pushing boundaries to maintain stability and psychological safety.

• Iteration to improve and change needs space and tolerance for failure and experimentation. Build in capacity, WIP controls, reflection and recovery.

• Consider the audience and contributors: If the menu changes every week, that might not make your customers happy. Balance the supply and demand of change.

Status vs Strategy

Look at your calendar this week. How many “Status Update” meetings show up?
If everyone simply lists what they did yesterday, and no decisions are made to change what happens tomorrow, that is repetition. You’re just reading the news to each other, and that robs you of progress that compounds with every iteration that weighs on the participants.
If the meeting unblocks a constraint, avoids a conflict, or reallocates resources based on new data, that’s iteration.

Applying Iteration

Repetition is a circle; you end up exactly where you started, just a little more tired. Iteration is a spiral; like a spiral staircase: you circle back, but you are at a new level of capability.

Flow Engineering has iteration built in. The intentional loop is always focused on improving the system of work based on its current conditions:

1. Define target outcome

2. Evaluate current state

3. Analyze negative conditions

4. Design future state interventions

5. Plan and execute improvements

Any looping model (OODA, PDSA, Cybernetics, Ishi, even sprints) will drive progress if applied with the intention of improving, rather than just repeating a cadence.

How many patterns are you seeing repeat across your organization that you’d love to change?

As we settle into the early weeks of 2026, ask yourself: Is your organization spiraling upwards, or just spinning its wheels?

If you suspect you’re caught in a loop of repetition, let’s break the circle. I’m opening up a few slots for a free Flow Exploration Call this month. We can look at where your flow is stalling and identify one actionable change to turn repetition into progress.

Instead of aggregating teams into those four broad categories based purely on throughput and stability metrics, the 2025 research identifies seven distinct team profiles (or archetypes) through cluster analysis. Teams may be characterized by “Foundational challenges” (survival mode with process gaps, high burnout) or as “Harmonious high-achievers” (excelling in well-being, delivery, and outcomes).

2025’s DORA report highlights that we have to look beyond simple metrics to understand performance, and that downstream results don’t tell us much about upstream conditions.

"Simple metrics are not enough. We identified seven distinct team profiles, each with a unique combination of performance, stability, and well-being. This model provides a nuanced way to understand your teams’ specific challenges and create tailored pathways for improvement"

What I like about these archetypes is that they zoom to the appropriate level for putting DORA’s data and recommendations to use. Organizations are not best understood or improved as monoliths, and the highest balance of impact and autonomy is the team, so I think it’s a great idea to profile teams rather than organizations. It allows us to understand performance where we can most quickly impact it.

"This approach moves beyond isolated numbers to reveal seven common team profiles, each telling a deeper story about the interplay between performance, well-being, and environment"

So that begs the question: Which type are you in right now?

1. Foundational Challenges (10%)

These teams are stuck in survival mode. They face significant gaps in processes, environment, and outcomes, with consistently low performance and high levels of burnout and friction. AI likely represents yet another capability they can’t leverage, but they may get distracted and disheartened by trying.

2. The Legacy Bottleneck (11%)

Teams here are in a constant state of reaction. Unstable systems interrupt their work and undermine their morale. The data shows significant challenges with software stability and a high volume of unplanned, reactive work. For these teams, AI isn’t an amplifier of value; it’s more likely a source of more downstream chaos.

3. Constrained by Process (17%)

These teams are running on a treadmill. Despite having stable systems, their effort is eaten up by inefficient processes, leading to high burnout and low impact. This is where the value of Value Stream Management (VSM) is most needed. If you apply AI here just to generate more code, you aren’t solving the problem; you’re just exacerbating the process bottleneck.

4. High Impact, Low Cadence (7%)

This is the danger zone. These teams produce high-impact work and feel effective, but they are trapped in a low-cadence model with high instability. Speed without stability is a dangerous and unsustainable proposition. Without the right safety nets—like platform automation and small batches—AI in this environment will only accelerate the next outage.

5. The Stable and Methodical (15%)

These are the steady artisans of the software world. They deliver high-quality, valuable work at a deliberate and sustainable pace. While their throughput is lower, their stability is high. For these teams, AI serves to reinforce their craftsmanship rather than just rushing the process. They have opportunities to accelerate quality delivery via AI.

6. The Pragmatic Performer (20%)

Like the high-achievers, these teams deliver work with impressive speed and stability. Where they differ is engagement; their work environment is functional and sustainable but may lack the deep “human spark” or engagement drivers of the top tier. AI here is an engine for efficiency, maintaining a steady cadence of valuable output.

7. The Harmonious High-Achiever (20%)

This is what excellence looks like—a virtuous cycle where a stable, low-friction environment empowers teams to deliver high-quality work sustainably and without burnout. These teams show positive metrics across the board, from well-being to product outcomes. In this environment, AI isn’t just a tool; it’s a seamless part of a high-velocity, high-quality reality.

Start Where You Are

The 2025 DORA is a step towards a more nuanced conversation about performance and assessment, but averages lie, and context is king. By moving away from the blunt instrument of Elite vs. Low comparisons and toward these seven archetypes, we have a new data model that more closely reflects the reality of software delivery in real organizations, at an effective level of granularity. Organizations are not monoliths; they are ecosystems of distinct teams, each facing unique constraints—from the Foundational Challenges of survival mode to the Harmonious High-Achievers.

Ultimately, this research serves as a critical reminder that you cannot fix upstream friction with downstream metrics. Whether a team is constrained by process or trapped in a legacy bottleneck, the path to improvement isn’t about blindly chasing higher throughput. It is about diagnosing the specific profile of the team, understanding the interplay between well-being and stability, and designing a custom roadmap to remove the impediments to flow.

Key Takeaways

• Granularity Over Generalization: The shift from four performance levels to seven clustered archetypes proves that simple metrics regarding speed and stability are insufficient for diagnosing team health. Measuring the interaction between performance, environment, and well-being gives us a deeper understanding.

• AI is an Accelerator, Not a Fix: For teams in the “Harmonious” or “Pragmatic” clusters, AI amplifies value. For those in “Legacy Bottlenecks” or “Foundational Challenges,” AI merely accelerates chaos and technical debt. You cannot automate your way out of a broken process.

• The Team is the Unit of Change: High-level organizational metrics obscure pockets of high friction. To improve organizational performance, you must zoom in to the team level, identify their specific archetype, and grant them the autonomy to solve their unique constraints.

Don’t Guess Your Archetype—Map It

Are your teams truly “Harmonious High-Achievers,” or are they “Constrained by Process” and burning out while trying to look the part? Blindly adopting AI tools or standardized agile frameworks without knowing your starting point is a recipe for waste.

If you are ready to move beyond vanity metrics and understand the real friction points slowing your organization down, you need to understand how your teams actually perform with the work they do today. Use Flow Engineering to diagnose your archetype, map your value stream, and target the specific bottlenecks preventing your teams from reaching a state of AI-enabled flow.

It’s one of the most legendary mantras in leadership. On the surface, it sounds proactive. It sounds empowering. It implies that you trust your team to handle things and that you want to foster autonomy.

But it’s often incredibly wasteful.

The big problem with leaders brushing off direct reports with this phrase is that I believe problems are far more important to align to leadership than solutions are.

When you force your team to package every problem with a solution before they can speak up, you aren’t creating efficiency. You’re creating a filter that blocks valuable signals, introduces delay, and encourages waste.

The Waste of “Empowerment”

I’ve seen too many teams solve problems that had nothing to do with their mandate because they were discouraged from raising the issue to leaders, or worse, encouraged to “DIY” a solution just to seem like they’re not complaining.

This approach generates waste in three specific ways:

• The Wrong Problem: Contributors spend time solving problems that shouldn’t be solved at all, or at least not right now.

• The Wrong Context: They solve problems that could be solved faster or better by another group (e.g., upstream or platform teams).

• The Wrong Solution: Without leadership context, they build a solution that doesn’t fit the broader strategy.

• The Wrong Scope: Should it be a quick fix or a major investment?

• The Wrong Time Horizon: It may be the right fix for 6 months from now, but today it’s unaffordable.

It is incredibly demoralizing for a contributor to find a problem, invest energy into solving it, and then bring that “win” to leadership only to have the value questioned. Or to be told, “That problem wasn’t actually a priority.”

That isn’t empowerment. That’s sabotage.

The Architecture of Truth

A great point was raised in the discussion of this topic by Dr. Koby Glass, who noted that when leaders demand only solutions, they are signaling: “We don’t have the architecture to absorb truth.”

If you want to decentralize decision-making and action, you can’t just demand solutions. You need to ensure your people are solving the right problems in the best way they can be solved.

If a team member spots a fire, you don’t want them to wait until they’ve built a fire truck to tell you. You want to know there’s a fire so you can decide if it needs a truck, a bucket, or if it’s a controlled burn you planned strategically.

Information flow is critical. You need feedback from the front lines to inform your process, capabilities, and operating model. If you shut off the flow of “problems,” you shut off the flow of reality.

Full Kit Problem Triage

So, what is the alternative? You don’t want a culture of complaining, but you do need a culture of signal processing.

If you want true flow, you need full kit problem triage and resolution, along with constraints that enable speed and confidence.

1. Encourage the Signal: Make it safe to raise problems early. This is “shifting left” on management—catching defects in the workflow before they become expensive incidents or waste.

2. Align on Value: Before anyone builds a solution, align on the value of the problem. Is this worth solving now?

3. Empower the Solution: Once the problem is validated, clarified, located, and prioritized, then delegate the solution.

If those systems are in place—if you have the architecture to absorb truth and triage effectively—then you can delegate away with confidence.

But simply saying “bring me solutions” is a shortcut. And in flow engineering, there are no shortcuts that help you skip understanding.

Goldratt sums it up here with his unique perspective by focusing on the value of problem solving skill and developing intuition rather than finding what he calls “superb solutions”:

He highlights the underlying value in problem solving: “How do we activate the brainpower, the intuition, and translate it into feasible solutions?”

Skipping forward to (or even driving towards) the solution may deliver a short term win and seriously compromise long term capability and value.

This is not new, people have said this many times before, but if you’re like me, you often take these things for granted, and there’s a ton of value in thinking more deeply about the condition - before we see it pop up again in the wild.

It’s worth reflecting on your own environment and asking: “How am I creating the conditions for effective problem understanding (rather than just problem solving)?

Speaking of problem understanding and deep thinking - the Flow Leadership Retreat is happening very soon!!

The Flow Leadership Retreat is happening February 8-13 in Cancun, and there’s just 6 spots still available

Early bird ending Dec 1st! Act now!

Start Seeing Your Signals, and Acting Effectively

If your intuition tells you that solutions are hiding the real problem or the larger opportunity, tools like value stream mapping can give you a much broader view of where the real problem lies, and what the problem is made of.

If your teams are burning out on “solutions” that don’t move the needle, it might be time to map your value stream and see where the signals are getting blocked.

Get in touch to start building an architecture that handles the truth.

MIT’s earlier study focused on the enterprise named organizational challenges like flawed integration, lack of deep workflow adaptation, and misallocation of resources (such as focusing on sales and marketing AI tools instead of back-office automation).

Another highlight from MIT was that a great deal of AI value is realized informally through employee-driven “shadow AI” rather than formal pilots.

DORA’s report also highlights the vaccine to all the AI risks revealed by reports to date: Value Stream Mapping

Value Stream Mapping provides visibility across large swaths of the organization and insight into where AI will provide the highest ROI.

This doesn’t come out of nowhere. DORA has included practices like Value Stream Mapping for years now, and it’s always been a key capability along with Visual Management generally in driving high performance. Thoughtworks, a platinum sponsor of the report, has listed Path to Production Mapping as a key capability since 2022 (in the top spot!). In their content, they highlight the main point of caution that has been ignored by almost everyone looking for developer productivity from AI:

There’s been so much talk about AI accelerating development, it’s about time we had some conversation and data about how accelerating outside your constraint is a bad idea.

So, what?

AI use and integration is just spreading and accelerating, and pressure is mounting to make the right investments. If you want to make those investments really matter, let’s chat about how you can quickly get a view of your value streams and value stream network, to plug in AI where it will have the greatest ROI for you and your organization.

If you’re thinking: "Yeah, I know VSM is important and valuable, and I want that visibility, engagement, and measurement, but I’m not any closer to getting it done” I have a lot to share to help you over the hump. Beyond Flow Engineering, the community of practitioners and facilitators has been building up new practices, templates, and guidance to support you!

Value Stream Mapping is an essential capability, but it doesn’t have to be intimidating, chaotic, exhausting, or unproductive. If you want to start benefiting from Value Stream Management, get in touch with me right now!

To see how DORA and Value Stream Mapping go together in further detail, check out Andrew & Rob’s session earlier this year:

Helen’s post highlights the current confusion/conflation of Value Stream Mapping and Value Stream Management, but it’s great to see a higher level of awareness and the data now reflected in DORA’s research to support what we’ve been saying since the early days of the VSMC.

Read the VSM Excerpt here:

Dora State Of Ai Vsm Value Stream Management

3.17MB ∙ PDF file

Download

Download

I’ll leave you with a great challenge posed by the DORA team:

And we can go even further: Can you draw your full End-to-End value stream on a whiteboard?

The GROW Model and Flow Engineering seem like different tools for different jobs. One helps individuals discover their path forward through structured conversation. The other maps and optimizes how work flows through organizations. But they’re entirely complementary, allowing you to apply Value, Clarity & Flow at various scales.

GROW: A Framework for Clarity

The GROW Model guides people through four stages: Goal, Reality, Options, and Will. It’s straightforward by design: helping individuals and teams articulate what they want, face current challenges honestly, explore possibilities, and commit to action.

• The coachee drives the conversation.

• The coach facilitates discovery.

How GROW Maps to Flow Engineering

Here’s where it gets interesting. Each stage of GROW aligns with specific Flow Engineering practices:

Goal

Define what you want to achieve. Goals should be clear and often follow the SMART criteria; specific, measurable, achievable, realistic, and time-bound.

• Outcome Discovery & Mapping (Target Outcome Definition, validated by Benefits, achievable and realistic via Obstacles)

Reality

Examine the current situation honestly, understanding where you stand in relation to the goal, identifying relevant facts and challenges.

• Outcome Discovery & Mapping (general context gathering, surfacing pains, questions, ideas, and goals)

• Current State Value Stream Mapping (documenting existing process steps, handoffs, cycle times, and wait states to understand where work actually happens today)

• Dependency Mapping (identifying blocking relationships, resource constraints, and upstream/downstream impacts that affect current performance)

Options (or Obstacles)

Explore all possible strategies or ways to overcome obstacles to reach the goal, encouraging creative thinking and ownership.

• Outcome Discovery & Mapping (general & initial obstacle gathering focused through the lens of the defined outcome)

• Dependency Mapping (analyzing which dependencies can be eliminated, parallelized, or managed differently to create new possibilities)

• Future State Value Stream Mapping (designing improved processes with reduced waste, faster flow, and clearer handoffs)

Will (or Way Forward)

Commit to specific actions and define the next steps to move toward achieving the goal.

• Flow Roadmap (prioritization, batch sizing, ownership assignment, and measurement criteria)

Beyond Individual Coaching

GROW works beautifully for personal development and leadership coaching. It addresses mindset, motivation, and decision-making. But it doesn’t tackle the systemic issues; the workflows, bottlenecks, and organizational constraints that either enable or block progress.

That’s where Flow Engineering comes in. It maps the invisible currents of work: how value moves through the organization, where it gets stuck, and what accelerates or impedes progress. It relies on tangible artifacts (value stream maps, flow metrics, dependency graphs) that expose inefficiencies and guide improvement.

Leave a comment

Why Not Both?

Personal clarity without systemic support fails. Flow optimization without individual buy-in and contribution stalls.

• GROW creates the readiness and commitment for change at small scale

• Flow Engineering provides the structural improvements that make change sustainable & systematic

For consultants, this means coaching individuals while simultaneously improving the systems they work within. You’re facilitating insight and redesigning flow. You’re bridging human potential and organizational capability.

Making It Work

Effective organizational improvement isn’t about choosing between coaching people or fixing flow. It’s about doing all that and more:

1. Use GROW to regularly help teams define clear outcomes and face reality

2. Map current state to understand systemic constraints

3. Explore options through both creative thinking and dependency analysis

4. Build roadmaps that assign ownership, set priorities, and define measurements

The leader who masters both amplifies impact dramatically. You’re not just helping people think differently or making processes better. You’re creating environments where clear intentions flow through well-designed systems.

Change stops being fragmented. It becomes coherent movement; aligning people, purpose, and process into actual progress.

Want to explore how these frameworks work together in your organization? That’s exactly what Flow Engineering workshops are designed to do.

The world of knowledge work and software product development where I spend my time is notoriously difficult to measure, which is why I like to share models that can add some clarity to thinking and communication.

It’s all too tempting to fall victim to the streetlight effect (we often search for things where it’s easiest to see). It leads us to focus on what’s easy to see & measure rather than what leads to value and the outcomes we’re hoping to realize. This often results in measuring things like utilization, efficiency, activity, and outputs rather than effects, outcomes, and value.

Knowing that, one question I hear constantly from clients who struggle to feel confident in their measurement is: “What should we measure?”

I want to make a dent in answering that question, by placing some critical measurement in context. This is more important than ever now that “doing” is trampling “done” in every enterprise I talk to - thanks to generative AI. So much attention is being paid to “inner loop” activities - ignoring the broader needs of the organization. Utilization still dominates much of the attention under the streetlight, especially now that just using AI seems to be a target of many leaders. Busyness isn’t just a bad proxy for progress, it often just gets in the way, distracts you, or sucks up energy you could be using to innovate and problem solve.

In answering “What should we measure?”, the first thing to note is always the ever-frustrating: “It depends.” There’s no getting away from it. This is why we start Flow Engineering with Outcome Mapping. There’s a mountain of things we could and should measure, but what’s most important is always relative, and it should be our focus. Outcome Mapping allows us to distill the possible down to a clear focus. It’s another reason working backwards is so critical. Measurement is a necessary, non-value-added activity. We should be very clear about where, why, what, & how we measure for this reason, and be able to justify how it helps deliver positive results.

In order to more clearly and deliberately measure, it’s been valuable for me to segment measures into different contexts to more effectively communicate what we’re aiming for, and how we can ensure we’re building a cohesive model of measurement. This brings me to the loop model:

Loop Contexts

Key dimensions: strategy/tactics/operations, leading & lagging, operating model implications, working backwards, example metrics, flow & quality vs value/outcomes/impacts and more.

Given this view of the landscape and a target outcome, “What should we measure?” can be formed up by working from the outer loop back to the inner loop. We want to see some global effect, which leads us closer and closer to local activity that will contribute to it. For example:

1. We want to see revenue rise in a given market segment or product, [outer]

2. which leads us to performance of the relative products, [outer]

3. which leads us to our ability to improve those products, [middle]

4. which leads us to the performance of the teams delivering those products, [inner]

5. and the teams those products depend on [inner]

The metrics we choose to focus on are the ones we identify as the most strongly correlated with improving performance, ideally associated with our performance constraint.

Metric Examples by Loop

Three reasons this is important today:

• Development is not your bottleneck - measuring flow only at the inner loop tells you almost nothing about “getting things done”

• Measuring without a clear connection to the outcome you’re aiming for is a recipe for distraction and disorientation

• To connect efforts to effects, you need to be able to effectively plot clear connections from what you’re doing to what you’re aiming for

Let’s look at each loop context in further detail:

Outer loop

Lagging, Strategic: Activity happening across portfolios and roadmaps

Cadence: Monthly/Quarterly

Focus: portfolio and business outcomes (months–quarters), allocation and strategic flow.

• North Star metric movement and guardrails (e.g., retention, engagement, reliability), OKR attainment and confidence progression.

• Customer outcomes (NPS/CSAT/CES), churn/retention, expansion (ARPU/NRR/GRR), revenue and margin per product/value stream.

• Portfolio WIP and flow time for epics/capabilities, cost-of-delay realized/avoided, time-to-market for strategic bets.

• Investment mix adherence (run/grow/transform), innovation rate, technical debt service ratio, capacity allocation vs actuals.

• Program/ART predictability, cross-stream dependency lead time, reliability posture (error budget consumption) at portfolio level.

Key decisions: Funding shifts, capacity allocations, initiative sequencing

Middle loop

Tactical, Enabling: Activity happening within portfolios and value streams

Cadence: Biweekly/Monthly

Focus: product team discovery + delivery (days–weeks), validating bets and delivering predictably.

• Hypothesis-to-decision cycle time, experiment velocity, percent of roadmap items validated before build, confidence score at commit.

• Adoption/activation of shipped features, time-to-first-value, depth of use (WAU/MAU ratio, retention cohorts), task success rates, UX friction metrics.

• Release frequency and batch size, planned vs unplanned work ratio, sprint/PI goal attainment, forecast accuracy, dependency aging and blockage time.

• Value stream flow distribution (new features vs defects vs risks vs debt), carryover rate, rework rate, story acceptance latency.

• Quality-in-stage (defect containment by environment), regression escape rate, observability coverage for new features.

Key decisions: WIP policies, dependency reduction, batch-size limits, prioritization

Inner loop

Leading, Operational: Activity by individuals within teams

Cadence: Daily/Weekly

Focus: rapid developer/service feedback (minutes–days), optimizing build–test–deploy flow and reliability.

• Deployment frequency (per service), lead time for changes (PR open → prod), change failure rate, mean time to recover.

• Build success rate, flaky test rate, unit/integration/e2e pass rates, time-to-red/green (TDD cycles), PR review turnaround, merge queue time.

• Trunk/branch health (batch size, rebase conflicts), feature flag latency to exposure, rollback/redeploy time, hotfix rate.

• Flow time and cycle time per work item, WIP, queue age, flow efficiency, handoff count.

• SLO/SLI adherence (availability, latency, error rate), error budget burn, incident frequency/severity, escaped defect rate.

Key decisions: Stop-the-line fixes, swarming to unblock, Kanban WIP updates, test/deploy pipeline repairs

How they connect

• Inner loop improves speed and stability, enabling tighter middle-loop experiments and smaller, safer releases.

  • Think of breathing, heart beat: Autonomic activities

• Middle loop translates strategy into validated increments, reducing waste and increasing predictability for outer-loop commitments.

  • Think of movement, exercise, eating, hygiene: Action & management activities

• Outer loop sets outcome targets and investment constraints that shape middle-loop choices and inner-loop standards.

  • Think of bucket list, investments, work and leisure: Investment & sustainability activities

Each layer is interdependent in different ways: Strategy and vision defines what we invest in, but if we haven’t automated operations, we’ll never get time to execute strategy effectively.

If you can’t breathe you shouldn’t worry about your long term goals. This is why investments in automated testing, pipelines, APIs, interfaces, and integration are critical. If you had to intentionally (manually) breathe, you’d never get a chance to think and act strategically.

Here’s my TL;DR: The right metric at the wrong level is noise; the wrong metric at any level is harm. Anchor strategy (outer loop) to economic outcomes, tactics (middle loop) to flow constraints, and operations (inner loop) to queue health and reliability.

While we’re on the topic, let’s tackle two more questions beyond “what should we measure?” that I think are even more important:

“Why should we measure?” - this may seem obvious, but if you take a moment and think of the answer, it goes deeper than responsibility, knowing what’s going on, and improvement. Measurement has profound impacts on behaviour, culture, incentives, morale, and even satisfaction. Done poorly, it can wreck motivation, and done well, it fuel engagement.

“How should we measure?” - this may seem like it’s included in “what”, but it’s importantly different. Is all the data going to be open and visible across teams? Are we reporting on it at too long or too short a cadence? Should it be privately reviewed or publicly reviewed? Do we prioritize qualitative measures over quantitative? Leading over lagging? Do we have principles or strategy behind our measurement practices? Do we pick a north star and let everyone align in their own way?

As my friend mentioned on the draft post: “Measuring in a bunch of places without a theory of cause and effect means you are ultimately just trying to make sense of noise.” It’s important that any measurement practice be attached to a systematic view of your organization and ecosystem, with full knowledge of the forces at play when you pick a target, or try to balance several against each other. We work in complex, adaptive systems that don’t lend themselves to simple measurement.

What I’ve seen work well in software in tech are a few simple practices, informed by Value, Clarity, and Flow:

• Only measure what you’re prepared to act on. If a metric change off trend or target doesn’t result in investigation or action, it’s just noise

• Act within a PDSA loop: Plan by setting a target or hypothesis, Do by making a change, Study the effects, Act accordingly and repeat

• Measure something you can impact or respond to, and at an interval that you can correlate your actions to effects

• Prioritize your measurement based on strategy and needs. If you already have a goal, then focus on that before trying to create a general system of performance measurement. It’s very politically expensive to craft a grand measurement system while results are waiting, and your customers (be they external or internal) are waiting for a single answer or progress on one axis

• Avoid using metrics to understand the system or map directly to performance, rather use metrics as additional sensing capabilities, and observe trends considering a broad variety of conditions (staffing, seasonality, etc)

• Rather than trying to balance a complicated combination of metrics, choose a north star for each loosely coupled domain and let the organization navigate towards improving it

I’d love to hear from you what questions remain, what you’re trying, and what seems to be working or not.

If you’d like me to come talk to your team or company about measuring for flow, please send me an email at steve@visible.is!

Bonus: If you’ve read this far, check out the deck that inspired the post here

In the episode, Andrew and I talk about why mapping workflows is so important, especially in today’s fast-moving software world, and how the five-maps method of Flow Engineering makes it easier for teams to see the big picture, align on goals, and create better flow. We also explored how AI may support mapping sessions in the future — and how collaboration, trust, and shared understanding remain the key needs.

Here are some of the key themes we covered:

• Why mapping matters: Knowledge work is often invisible, which leads to gaps between contributors and decision-makers. Visual models help everyone agree on “what we’re doing and why.”

• Five maps for value, clarity, and flow: We walk through Outcome Mapping (defining the “why”), value-stream maps, and forward-looking “future state” maps that help teams uncover obstacles and plan next steps.

• Practical, not prescriptive: Flow Engineering is designed to fit into busy schedules and complement existing practices, rather than adding overhead.

• AI’s emerging role: From virtual facilitators to smarter tooling, AI can enhance mapping — but it can’t replace genuine collaboration and conversation.

If you’re curious about reducing complexity, aligning stakeholders, and helping your team work with more ease, I think you’ll enjoy it.

👉 Watch the full video on YouTube here or listen on any podcast platform!

What do we not talk about enough that you wish we’d cover? I’d love to hear your thoughts and questions:

Today’s leaders face a growing challenge that threatens to overload even the most capable: delivering ambitious results while guiding teams through complexity and constant change. Traditional management models built on control and rigid planning can’t keep up. They create friction, slow down progress, and burn out talent, because the distance between plans and conditions is too far.

Flow Engineering offers a different path.
By bringing visibility and measurement to your flows of work, you can intentionally and directly influence how work is happening, and get ahead of your deadlines, rather than seeing the mad dash or death march patterns common with large batches.

Instead of managing work, draw focus to how work as a whole moves through your organization. By improving flow, you accelerate outcomes for the business while making work more engaging and sustainable for your people.

By starting small: With a game, an example flow, or a single flow of work, you can scale change at your own pace, and invest just where you see the largest ROI as you go. No big bets, big batches, or big risk.

Here’s how it transforms leadership - whether you’re setting strategy as an executive or running a team:

1. From Command to Facilitation

• Executives: Build cultures of trust and autonomy that distribute decision-making across the organization.

• Managers: Set clear goals and provide aligned resources, then empower teams to innovate and deliver without micromanagement.

• Results: Flow of decision and action accelerates.

2. Seeing the Whole System

• Executives: Gain a systemic view of bottlenecks and dependencies that slow down delivery.

• Managers: Spot local blockers—handoffs, delays, communication gaps—and fix them before they stall momentum.

• Results: Flow of information and feedback improves.

3. Continuous Improvement as a Capability

• Executives: Embed learning and adaptation into the organization’s DNA, making change a core competency with small batches and rapid feedback.

• Managers: Use feedback loops and flow metrics to make small, frequent improvements that compound over time.

• Results: Flow of progress and performance builds over time.

4. Engagement Through Flow Conditions

• Executives: Reduce turnover and increase performance by fostering environments that prevent burnout with minimal friction and measured WIP.

• Managers: Match challenges to skills and create space for focus, boosting motivation and creative problem-solving, using flow distribution.

• Results: Flow of effort and activity doesn’t collapse under load.

5. Aligning Vision with Execution

• Executives: Ensure strategy translates into real-world results by connecting priorities to delivery.

• Managers: Help teams see how their daily work contributes to the bigger picture, creating clarity and commitment.

• Results: Flow from vision to execution to delivery to outcome is an unbroken thread.

Beyond these shifts, Flow Leadership involves various different dimensions to consider and clarify:

• Frontiers and fundamentals: Improving your current state to deliver your future options

• Tools and methods: Visualizations, collaborative mapping, measurements give you visibility and understanding you’ve been missing

• Technical and social: Technology needs to address limitations, and mapping allows you to understand where they are and how they’re manifested today

• Internal and external: With a clear value stream network map, you can master your entire landscape and operating model

• Enablement and governance: Flow Engineering empowers contributors and leaders to build controls and supports that address specific needs, not speculation or prescription

• Flow of work & information: Mapping reboots your efforts to understand how work and information really flows, so you can intervene where it matters most

The Bottom Line:

• For executives, flow accelerates strategic outcomes, improves feedback, visibility, and measurement. It reduces risk, improves adaptability, and builds resilience.

• For managers, flow simplifies leadership, removes friction, and makes success and improvement repeatable. It creates a language for describing how work is happening that connects activity to results.

Embracing flow as a first-class consideration transforms leadership at every level—from managing chaos to orchestrating harmony. It equips you to drive sustainable change with clarity, consistency, and measurable impact.

Here’s why it’s needed:

If this isn’t the first of my writings you’re seeing, you’re going to say something immediately: This isn’t just an AI problem.

You’re absolutely right.

We don’t just need AI Flow Engineers, we need Flow Engineers for every effort we’re undertaking.

So then, why does an AI Flow Engineer matter?

As I always remind myself: Meet people where they are.

Everyone is focused on AI, so if you want their attention, you’re going to have to step into the frame.

But this isn’t just bandwagon jumping. It’s a critical need.

Companies and teams are wasting months and millions on injecting AI either upstream or downstream of their constraint, and it’s only making things worse.

More AI output means more AI supported work to deal with the volume of crap being churned out everywhere.

Simon has touched on a growing need I’ve seen across many organizations: the need to move beyond isolated AI experiments and fragmented micro-optimizations, and instead take a holistic, systems-level approach to making work flow better.

The post sparked several conversations - with clients, colleagues, and operators - all circling the same core challenge: are we getting value here?

The answer isn’t more effort.
It’s not AI supported effort.
It’s better flow. Better flow where it matters most.

Inspired by Simon’s post, here’s the why, what, and how of this emerging need - and why it could be the key to unlocking real, sustainable performance in the age of AI.

The AI Flow Engineer: A New Kind of Role for a New Kind of Work

Many organizations find themselves working harder than ever - yet still struggling to move the needle where it counts.

Strategic goals are well-intentioned, but execution stalls. Teams are talented and eager but overwhelmed. Defined processes never meet reality. Despite significant investment in tools, systems, and transformation initiatives, bottlenecks and inefficiencies persist.

This isn’t because people aren’t working hard.
It’s because nobody owns flow.

Why Flow Matters More Than Ever

In every organization, across every function, work flows - or it doesn’t. It gets passed between teams, enters systems, awaits approvals, loops back for revisions, gets deprioritized, or gets stuck.

Most businesses aren’t lacking in energy, intelligence, or effort.
What they lack is flow visibility, clarity, and informed action.

This is where we believe a new kind of role is not just useful - but essential.

The AI Flow Engineer

If we really think AI can improve flow and outcomes, the answer isn’t everyone owning the problem. When everyone owns something, nobody owns it.

Focus drives results.

Flow Engineering for AI

The AI Flow Engineer’s mission is simple but essential:
Make the work work better.

This is done by:

• Mapping how work actually flows - across teams, tools, and processes

• Identifying what’s slowing it down - constraints, blockers, misalignments

• Aligning stakeholders around what truly matters

• Rapidly prototyping AI-powered solutions to remove bottlenecks

• Enabling repeatable, scalable improvements through automation and shared understanding

The result? Less friction. More focus. Measurable acceleration.

Where This Role Fits - and Why It’s Needed

This role is not confined to a single department. It’s designed to oversee activity and respond to impediments to flow and value. That means:

• Sales & Revenue Operations
  Accelerate quoting, approvals, and onboarding with intelligent workflows.

• Customer Support & Success
  Automate triage, follow-ups, and feedback loops to reduce cycle time.

• HR & Talent
  Streamline hiring flows, employee onboarding, and internal mobility.

• Finance & Procurement
  Eliminate delays in approvals, budget tracking, and vendor management.

• Product & Engineering
  Improve coordination across product lifecycle, from ideation to launch.

• Marketing
  Align campaign workflows across content, data, and digital execution.

Every function in a modern business has work moving through systems, tools, and people. In too many cases, that movement is unnecessarily constrained, invisible, or both. This role makes flow visible, and then makes it better.

How It Works in Practice

Flow Engineering operates in two distinct but connected phases:

1. Flow Mapping & Strategic Alignment

The AI Flow Engineer begins by running structured, high-impact mapping sessions with cross-functional teams. These sessions:

• Clarify the outcomes that matter most

• Visualize how work actually flows today

• Identify blockers, wait times, and misaligned priorities

• Facilitate agreement on what needs to change, and who owns what

It’s not just process mapping - it’s a collaborative reset that helps teams understand where they are and align on where they’re going.

2. AI-Powered Prototyping & Automation

Once the flow challenges are clear, the AI Flow Engineer builds working prototypes of solutions - using best-fit tools, including:

• Visual platforms like n8n, Make, or Workato

• Large Language Models (LLMs) like Claude, GPT-4, or open-source agents

• Custom code, APIs, and scripts where needed to go beyond the limits of low-code tools

These prototypes are built fast - typically in 3–5 days - and are designed to show measurable impact immediately.

The list of things that support performance - that companies DON’T invest in - is a mile long!

Once validated, the solution is handed off to the business for scaling, while the AI Flow Engineer moves to the next opportunity.

Why Traditional Roles Can’t Fill This Gap Alone

You might be wondering: Don’t we already have operations teams, enablement, or IT to handle this?

Here’s the difference:

• Operations teams often focus on executing within existing constraints, not redesigning the flow itself.

• Enablement teams support adoption and training but don’t always have the mandate or skills to support real changes. ← this is the closest match

• IT and dev teams are stretched thin, focused on large systems, not lightweight, iterative improvements.

• Consultants can diagnose problems but rarely build and test real solutions on the ground.

The AI Flow Engineer bridges all of these, acting as a strategic facilitator, systems architect, and hands-on builder all in one.

The Superpower of Expert Facilitation

One of the most overlooked elements of this role is expert facilitation - the ability to bring stakeholders together across silos, build shared understanding, and create psychologically safe spaces to surface real challenges.

The AI Flow Engineer guides teams through ambiguity, asks the right questions, and creates momentum, turning tension into clarity and action.

In many ways, the conversation is the catalyst. The prototype is the proof.

How It Transforms the Business

Organizations that embrace this role see transformation at multiple levels:

🚀 Faster Delivery

• Reduce lead times by 30–80%

• Eliminate unnecessary handoffs, approvals, and rework

• Accelerate time-to-value for customers and stakeholders

💰 Smarter AI Investments

• Deploy automation where it actually solves flow constraints

• Avoid “random acts of AI” that increase complexity or risk

• See 10x ROI by focusing efforts where they move the needle

🤝 Stronger Alignment

• Get diverse teams aligned on outcomes, not just tasks

• Surface hidden dependencies and misaligned incentives

• Build a shared language of “flow” across departments

🧠 Embedded Capability

• Create reusable playbooks and automation patterns

• Train teams to recognize and solve their own flow problems

• Embed “flow-first” thinking into the culture

Success Isn’t Just a KPI, It’s a Shift

This role measures success in tangible ways:

• Number of value streams improved

• Working prototypes delivered

• Time and cost savings achieved

• Stakeholder alignment and adoption

• Cultural momentum toward flow-first, automation-enabled work

But perhaps the biggest shift is intangible:
A business that feels more confident, focused, and capable of executing on its vision.

Final Thoughts: A Role Built for the Now

Flow Engineering is not a role — but the need for ownership and dedicated attention is a recognition that needs are changing, and the way we lead, design, and deliver work must change too.

We no longer live in a world where strategy and execution can be separate.
We no longer win by scaling effort; we win by scaling intelligence.

This role is about helping organizations move from complexity to clarity, from motion to momentum, and from isolated automation to intelligent flow.

If your teams are working hard but struggling to make progress -
If your AI investments aren’t delivering the impact you hoped for -
If you want your business to move smarter and faster, not just louder -

…it’s a clear way to make flow a priority.

As always - I’d love to hear your thoughts

Do you see a space for a role dedicated to internal AI investments in work flow?

And many many thanks to Simon for doing the heavy lifting on this!

Also cool

🤯 Flow Engineering hit Gartner’s radar (apparently last year!?!) and we just found out about it via the wonderful curator of all things value stream Patrice Corbard 🤯

Also: I’ll be at ETLS - will you?

• Who should sponsor our book signing?! Let me know!

When people ask how I got into this line of work, they expect a story rooted in technology or business school. Each of those is part of the story, but they’re more like the trunk of the tree than the roots. Instead, I tell them it likely started when I was a teenager, working my first job at Pizza Hut. Aside from a paper route and other odd jobs, it was my first exposure to the world of work, process, and collaboration. The lessons I learned in a bustling kitchen would forge my sense of flow. Juggling distractions, blockers, WIP, SLIs, SLAs, conflicting priorities, politics and more, I developed an allergy to friction, waste, and delay - without even realizing it.

The Kitchen: A Crash Course in Chaos

Working at Pizza Hut wasn’t glamorous. On a Friday night, the kitchen transformed into a tornado of activity. Orders came in faster than we could read them, with huge spikes and momentary lulls sprinkled in between. Dough needed stretching, toppings were flying, ovens were full, and the phone never stopped ringing. Everyone had a role, but in the heat of the moment, those roles would blur. The separation between success and disaster was too close for comfort.

Looking back I realize that the kitchen wasn’t just chaotic—it was a living system. A complex, adaptive system. When one part broke down, the whole operation suffered. If the prep station ran out of cheese, the pizzas slowed down. If the ovens weren’t loaded efficiently, orders backed up. If the delivery drivers didn’t have clear instructions, customers waited too long. Every inefficiency was magnified under pressure, and they often cascaded.

Discovering the Power of Process

At first, it was overwhelming. But gradually, I started to see patterns. The best shifts weren’t the ones with the most skilled cooks—they were the ones where everyone flowed together. We developed our own shortcuts, signals, and routines. We learned to anticipate problems before they happened. We rearranged our stations to save precious seconds and wasted effort. We communicated constantly, adapting on the fly.

I didn’t know it at the time, but we were practicing the fundamentals of workflow optimization. We lived in the gemba, but regularly stepped back to see the whole value stream—tracing and retracing how an order moved from the phone call to the final handoff, and where we could shave off waste. I remember practicing until I could cut a pizza in 1.7 seconds (we would have races), finally besting the district manager, after months of learning on misorders and discards that your speed only matters if you cut correctly. There was a real culture of iterating, improving, and learning from every mistake.

From Pizza Hut to Flow Engineering

Don’t get me wrong, I was an ignorant teenager fumbling through a job I prayed to finish as soon as possible, but there were moments when you could sink into the work and run with it. Moments of flow. I can still feel it. Years later, as I moved into the world of software development I chased that feeling. In the absence of the structure of the kitchen, the established processes, and the clear value proposition, it’s very difficult to find that flow. I often felt it only to discover that I was running in the wrong direction. I was missing the value and clarity that make effective flow possible. The chaos of a busy restaurant is not so different from the complexity of a modern product development practice. Both are systems under pressure, both rely on clarity and value, and both succeed or fail based on their ability to adapt and improve.

The same mechanisms that enabled the kitchen: clear acceptance criteria, established process, platforms and standards, enabling constraints, and measurement-are clearly defined in all the highest performing organizations, and notably absent in struggling organizations.

These gaps in value, clarity, and flow are exactly what Flow Engineering is aimed at closing—a structured approach to making work visible, mapping processes, and enabling continuous improvement. Flow Engineering is about more than diagrams and metrics; it’s about understanding how people, tools, and information move together to deliver value. It’s about focusing on the most impactful issues, eliminating waste, and creating the conditions for teams to do their best work—even when things get hectic. They don’t get less hectic the longer you put them off.

Why It Matters

A busy restaurant will show you that disruption and disorder in complex adaptive systems is inevitable, but friction, confusion, and waste are optional. With the right mindset and tools, even the busiest environment can become a place of flow, learning, and growth. Whether you’re making pizzas or building software, the principles of flow, and the first steps are the same: focus on value, define your workflow, leverage systems, and never stop looking for ways to improve.

Flow Engineering gives teams a way to step back, see the big picture, and work together to streamline their processes. The goal isn’t perfection—it’s progress. And sometimes, the best time to learn is when the pressure is high.

As always: Start where you are, show progress, go further!

20% off the Flow Engineering Course!

🚨 Limited-Time Offer Extended! 🚨 The Flow Engineering Course is still 20% off—but not for long! Originally ending June 15th, this exclusive discount has been extended for a short time only. Don’t miss your chance to learn how to enhance collaboration and performance in large-scale organizations using a proven, systematic approach. Master five powerful mapping techniques to visualize workflows, identify constraints, and drive continuous improvement across teams.

Through hands-on exercises and real-world examples, you'll learn how to:

• - Align teams around clear, valuable outcomes

• - Map and measure value streams to identify bottlenecks

• - Analyze dependencies that impact performance

• - Design improved future states

• - Create actionable roadmaps for change

Get the course here

Have you already taken the course? I’d love to hear how you applied the learning

Leave a comment

Share

1. the leadership decided to immediately put a dedicated, empowered product team behind the Prime program;

2. the leadership also made it very clear that this was one of a small number of critical focus areas;

3. due to the many prior experiments related to shipping, much of the supporting infrastructure was already in place, and could be leveraged for this new offering; and

4. the new Prime PRFAQ clarified what was important and what was not, aligning people, and helping them understand the motivation and strategic context, and plan their work accordingly."
   

From 'The Product Model at Amazon' on SVPG - link below

This simplifies a ton that most companies are currently tripping over and will fumble over the next 5-10 years in their Project to Product shift and AI adoption

AI adoption will make this much, much worse.

What are the critical capabilities and behaviors hidden below the surface here?

1) the leadership decided to immediately put a dedicated, empowered product team behind the Prime program;

• first-principles thinking

• clear vision and strategy

• leadership principles

• decentralized decision making

• 2-way and 1-way door model

• decision records and processes

• clear decision ownership

• domain ownership and empowerment

• modularity of domain ownership

• dedicated focus

2) the leadership also made it very clear that this was one of a small number of critical focus areas;

• 'small number of critical focus areas'

• actual customer focus (not stakeholder, HIPPO or other proxy)

• narrative clarity

• leadership support - even if via 'disagree and commit'

3) due to the many prior experiments related to shipping, much of the supporting infrastructure was already in place, and could be leveraged for this new offering; and

• 'many prior experiments'

• 'supporting infrastructure' is a network of 'domain ownership and empowerment' providing platform capabilities that any team can leverage to get what they need to build differentiated value with little/no dependency

• when you build upon a platform foundation, you can move incredibly fast but also build just enough to test your idea

• you should be building just beyond your current reach, validating, then going further

• full stack should never be full stack - full stack should really be full kit

4) the new Prime PRFAQ clarified what was important and what was not, aligning people, and helping them understand the motivation and strategic context, and plan their work accordingly.

• clarity, clarity, clarity

• focus, focus, focus

• empowerment, empowerment, empowerment

• a single document containing all the most critical information to guide the effort, track progress, prevent drift, distraction & disorientation

Consider the implications for AI adding more noise and distraction to the existing landscape. Without a solid foundation of clarity, empowerment, and decision-making, you have a recipe for enormous waste and confusion…

From The Product Model at Amazon

The event started with big challenges, to frame the sessions ahead:

• How are technological advances and societal shifts reshaping your workplace?

• What can be done in education to better prepare the entering workforce?

• How can we better work / collaborate across tech-capable generations?

• How do we bridge, align, and combine different improvement approaches?

• What is the intersection of lean and UX?

Big rocks, but encouraging! These are questions many organizations and communities are grappling with in their own context.

The event was a series of open spaces to discuss various investments of the Lean community, like Adjacent Community Engagement, AI in the context of a Lean BOK, and “Go and See” efforts.

It was also my first “Go and See” experience in a Lean-focused organization, with a tour through the host company facilities at O.C. Tanner (an employee recognition company, with roots in manufacturing small batch awards). It was really impressive to see the openness (in every sense) on display as well as a demonstrated commitment to measurable continuous improvement. I highly recommend a tour if you really want to connect theory, practice, and real context. You can check out my new friend Rich’s company tour virtually or in person here.

Key Themes that Stood Out to Me:

• Building bridges: Between communities, practices, theories, and silos

• Give and Get Tours: Digital or physical, go and see the actual work happening - this is even more important with invisible, digital work. What may be even more important is giving tours. A tour is amazing motivation to tidy and organize, but it also requires everyone to think and talk about your processes from start to finish, almost like a productized services in itself.

• Play: Use games and simulations to teach, practice, design, and test

• Meeting people where they are: Seek to understand before being understood, and make it easy for people to make progress

• Invisible, variable work is still a small part of Lean (but lots of demand), though all the principles and practices apply when you understand the fundamental differences - this is the future of Lean and the most powerful application

What did I hear and see from the community? Consistent focus on and investment in learning for the purpose of solving problems, and emphasis on humanity and personal meaning and fulfillment at work.

I felt like my Lean education took off like a rocketship, hearing so many stories of transformation, asking questions to folks with 30, 35 years in lean environments, and getting feedback on ideas from my context in tech.

Speaking of that context in tech:

There is a lot of appreciation for tech and enthusiasm for what’s next in this community, but it does seem to be a small minority focus compared to the physical lean context.

There has been lots of work in the tech world to highlight the benefits of lean thinking and practices - to bring lean to tech:

• Accelerate by Nicole Forsgren, Jez Humble, Gene Kim (2018)

• The DevOps Handbook by Gene Kim, Jez Humble, Patrick Debois, John Willis (2016)

• Lean Enterprise by Barry O'Reilly, Jez Humble, Joanne Molesky (2014)

• The Phoenix Project by Gene Kim, Kevin Behr, George Spafford (2013)

• Continuous Delivery by Jez Humble and David Farley (2010)

• Leading Lean Software Development by Mary and Tom Poppendieck (2009)

• Implementing Lean Software Development by Mary and Tom Poppendieck (2006)

• Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck (2003)

… but I’m much less familiar with efforts from the Lean community to bring tech to Lean. I’ll be revisiting a few books to update my understanding:

• The Lean Tech Manifesto by Fabrice Bernhard and Benoît Charles-Lavauzelle (2024) - it’s in the mail!

• Lean and Technology by Paul Myerson (2017)

• Lean IT by Steven Bell and Mike Orzen (2010)

… let me know what I’m missing!

I think there’s a big opportunity there and there are definitely others who felt the same. We’ll be working together to bring more tech into the Lean space over the next year, so if you’re interested in sharing your perspective and experiences on what Lean can learn from tech, and how tech can be a part of lean organizations strategy, tactics, and operations - let me know!

I really had an incredible time meeting and listening to folks with decades more experience than me, who were so welcoming and inclusive of adjacent contexts - it was a wonderful experience. I’d recommend the event to anyone who’s looking to make a significant contribution to the future of Lean and Work.

Bonus Rare Treat:

A trip to Snowbird to visit the birthplace of the Agile Manifesto

Share

Leave a comment

Summer eBook Sale!

Our publisher, IT Revolution is having their annual summer eBook sale, and for a limited time only, you can grab a copy of Flow Engineering, along with a ton of other great titles, for only $6 in Canada, US, UK, and Australia. A few of my favorite IT Rev reads that are in the sale are Profound Knowledge by John Willis, The DevOps Handbook by Gene Kim, Jez Humble, Patrick Debois, John Willis, Nicole Forsgren, and Wiring the Winning Organization by Gene Kim and Steven J. Spear.

This summary is based on a recent video talk with the team at the GOTO Book Club, where we discussed the challenges of modern software development and how Flow Engineering can help organizations address them. The complexity of today’s software organizations has increased significantly, with teams distributed globally and involving a mix of suppliers, contractors, and full-time employees. The journey from an initial idea to delivering customer value now consists of complicated networks of activities, making it essential to find ways to bring clarity and focus to work. Value stream mapping is a powerful tool for this, but many teams find it difficult to know where to start, what to map, who to involve, and how much detail to include. The process can seem overwhelming, especially when time is limited and the practice feels specialized.

Watch the Full Video Here

There is often a disconnect between different roles and levels within organizations. Individual contributors may focus on immediate technical challenges, while those in higher-level positions are concerned with timelines, deliverables, and costs. These varying perspectives can create gaps in understanding, making it difficult to maintain a unified view of organizational goals and workflows. In knowledge work, unlike manufacturing, so much of the work is invisible, which makes identifying bottlenecks or inefficiencies even more challenging. We can feel issues, but we can’t often describe them, or know which one is the most impactful. People working side by side may have entirely different views of what is important, leading to further misalignment.

Flow Engineering was developed to address these issues by providing a structured, approachable way to visualize and discuss work. The aim is to create a simple, shared mental model that everyone can understand, regardless of their role. This model helps teams see the full process from idea to delivery, identify where problems arise, and determine what actions to take. The approach recognizes that most organizations are constantly dealing with problems and competing priorities, and that few have the time to analyze their processes in depth.

Feedback from practitioners highlights that while value stream mapping is valuable, it is often time-consuming and exhausting, and teams struggle to act on the insights they gain. Flow Engineering addresses this by offering a minimal, approachable set of activities designed for teams that are already stretched thin. It is intended to provide leverage in environments where everyone is busy and under pressure, making it possible to fit process improvement into the existing workflow.

The framework expands on traditional value stream mapping by introducing a sequence of five visual maps. This structure is designed to make the process less intimidating and more actionable, especially in fast-paced digital environments. The maps help teams step back, see the broader context, and focus on the most important issues without requiring a significant time investment or specialized tools.

Flow Engineering connects directly to common workplace challenges. For teams overwhelmed by constant problems, it provides a way to see patterns and address root causes rather than just reacting. For organizations struggling with misalignment, the mapping process creates a unified view that brings together different roles and perspectives. The framework is intentionally minimal to fit into the reality of frequent meetings and ongoing demands, and it guides teams from mapping to action so that improvements are implemented, not just discussed.

It is not necessary to overhaul an entire organization to see benefits from Flow Engineering. Even small steps toward making work visible can reduce confusion, build alignment, and free up time for higher-value activities. The approach is designed to help organizations move from constant firefighting to a more proactive, continuous improvement mindset, making it possible to achieve better outcomes even in complex, high-pressure environments.

Are you feeling friction you can’t effectively see, share, and measure?

What’s stopping you from taking action to address it?

Don’t forget to use your education and improvement budgets wisely! The Flow Engineering Immersion course is a perfect way to make the most of a privilege we often take for granted. Sign your team up today, and start speaking the language of flow together

Focus on quantity (throughput, velocity, flow) vs quality (excellence, variation, accuracy) isn't so simple, and you can easily have enough of both with a little strategy, but there's an interesting parable I stumbled on (source below) that highlights the value of iteration:

"ON THE FIRST day of class, Jerry Uelsmann, a professor at the University of Florida, divided his film photography students into two groups.

Everyone on the left side of the classroom, he explained, would be in the “quantity” group. They would be graded solely on the amount of work they produced. On the final day of class, he would tally the number of photos submitted by each student. One hundred photos would rate an A, ninety photos a B, eighty photos a C, and so on.

Meanwhile, everyone on the right side of the room would be in the “quality” group. They would be graded only on the excellence of their work. They would only need to produce one photo during the semester, but to get an A, it had to be a nearly perfect image.

At the end of the term, he was surprised to find that all the best photos were produced by the quantity group. During the semester, these students were busy taking photos, experimenting with composition and lighting, testing out various methods in the darkroom, and learning from their mistakes. In the process of creating hundreds of photos, they honed their skills. Meanwhile, the quality group sat around speculating about perfection. In the end, they had little to show for their efforts other than unverified theories and one mediocre photo."

There's something special about choosing the focus that provides the most useful feedback, and there is also a side effect of being able to show yourself and others your progress along the way.

I think this is one of the most under-appreciated (and now at risk of being forgotten) benefits of agile, just doing more and more iterations. It's often lost now because we don't often have small teams iterating over and over on things. They build a feature for the pile and then move on to another, only to come back when there's an issue.

I think it's a symptom of trying to do to much, owning too much scope or supply chain, but also how we size and scope teams as well. There's an aspect of WIP limiting and cognitive load involved in the scope of our products and how we define the boundaries of domains and capabilities.

We've become victims of how much we can do in terms of breadth, at the cost of how much we can do in depth, and only the most disciplined organizations are ruthlessly limiting that scope to allow for the necessary depth and 'effective iteration'.

It could boil down to this: How likely are we to get it right the first time?

But the real question is: Are you willing to invest in your ability to get it right?

Parable source

• Value Streams compared to frameworks

• Flow Engineering and Value Stream Management

• Capabilities, JTBD, DDD, TOC, and Dependencies

• Risk Management

• OODA, PDCA, PDSA and Cybernetics
  

Let’s get into it:

Question 1: How are Value Streams categorized, and do they complement other methodologies or function as a standalone framework like ITIL?
A: Value Streams are just a model to describe the full flow of work that delivers value to customers or stakeholders. A model to visualize, measure, analyze, and optimize not just processes, but processes in the context of customers and the business. Unlike prescriptive frameworks like ITIL, Value Streams serve as a flexible lens to contextualize other methodologies. ITIL, SAFe, and many other frameworks have incorporated value streams as a model to put their guidance and practices in a meaningful context. Value Streams enable discussions about how changes impact work flow and value delivery, aligning technical and business perspectives. This makes them complementary, enhancing frameworks by providing a lens (flow in service of value) and a model (structure of representation and measurement) for what they’re meant to enable.

Leave a comment

Question 2: What is Flow Engineering, and how does it relate to Value Stream Management?
A: Flow Engineering refers to practices that optimize work flow, which can be within the context of Value Stream Management (VSM), but it can also just be making life better at the team level. While VSM focuses on continuous improvement of value delivery at a macro level, Flow Engineering can involve periodic (e.g., every six months) or continuous efforts to refine specific streams at the mid and micro levels as well. Implementation of Flow Engineering improvements often incorporate methodologies like Kanban for team or intake-level improvements, creating a bridge between macro and micro flow performance.

Leave a comment

Question 3: Is Value Stream Management or Flow Engineering a one-time process or part of ongoing lifecycle management?
A: Value Stream Management is a continuous process aimed at sustained improvement of flow and value delivery. Flow Engineering, depending on its scope, may involve periodic reassessments or ongoing refinements. Together, they support long-term lifecycle management, adapting to evolving business needs and process constraints.

Leave a comment

Question 4: How do other methodologies, such as Design Thinking and Jobs to be Done, integrate with Flow Engineering?
A: Value Stream Management can incorporate principles from methodologies like Design Thinking, Jobs to Be Done, and Domain-Driven Design - depending on the needs of the value stream or value stream network. For example, Jobs to Be Done helps identify and define value streams, while techniques like User Needs Mapping or Value Stream Network Mapping create a holistic view of processes, enhancing stream design and optimization. Design Thinking is helpful in both the initial Outcome Mapping efforts in Flow Engineering, as well as Future State Value Stream Mapping and Flow Roadmapping, which are all creative efforts.

Leave a comment

Question 5: Are business capabilities in Value Streams aligned with Domain-Driven Design?
A: Business capabilities in Value Stream Management share conceptual similarities with Domain-Driven Design (DDD), focusing on core business functions. While not identical, alignments with DDD and resources like BIZBOK are something I’m always interested in to try and connect Flow Engineering to other models and areas of practice.

Leave a comment

Question 6: How does Dependency Mapping contribute to Value Stream Management?
A: Dependency Mapping identifies relationships and constraints within a value stream, offering a deeper view into what may be causing constraints or friction. It serves as a starting point for broader Value Stream Network Mapping, enabling organizations to address inefficiencies and optimize flow across interconnected value streams. In many practices, Dependency Mapping is a way of visualizing and managing dependencies, whereas in Flow Engineering our focus is on addressing them - by mitigation, avoidance, or elimination.

Leave a comment

Question 7: Is the concept of bottlenecks in Value Streams aligned with the Theory of Constraints (TOC)?
A: The concept of bottlenecks in Value Streams closely aligns with the Theory of Constraints (TOC), emphasizing the identification and resolution of constraints to improve flow. While not strictly adhering to TOC, the principles are compatible, supporting a practical approach to process optimization. TOC is a very rich and mature ecosystem at this point, and in some cases it’s very strictly applied. As with most inspirations, we borrow what seems like the 20% that delivers 80% of the value.

Leave a comment

Question 8: How is risk assessment addressed in Value Stream Management, particularly with dependencies?
A: Risk assessment in Value Stream Management often focuses on constraints, such as bottlenecks, where dependencies pose clear risks. By narrowing the scope to these constraints, organizations can prioritize risk mitigation. Emerging tools and methodologies, such as those in advanced risk management frameworks, provide deeper analysis for dependency-related risks. On the subject of risk, Doug Boyce has been producing an interesting series on Risk Management and Flow Engineering.

Leave a comment

Question 9: Why not use OODA or PDSA/PDCA in Flow Engineering?
A: The issue I always find with these activity loops is a lack of vision and targeting. They each have an unstated (and too easily missed) dependency on a vision or target. OODA is dependent on clear mission objectives, training, and SOPs. PDCA began as quality control, but always relied on targets already in place.

This lack of defined vision or target makes it too easy to stay busy doing low value things or creating waste. Just doing actions efficiently and consistently doesn't necessarily create any value.

We could use OODA, PDSA, etc but I don't like either for what we’re aiming for in Flow Engineering: Effective Action. To me, the cybernetic model of target, assess, act, observe doesn’t require as much assumption or prerequisites. In short, you can use OODA PDSA PDCA if you already have a target outcome. Cybernetics includes it.

As with all things, if you don’t use the tool properly it won’t provide value. My argument is that OODA (etc) doesn’t tell you about the dependencies because they are assumed, and that invites misapplication. It’s not flawed, but it’s too easy to misapply.

Leave a comment

Have a question?

Ask in the comments or send me a message -

A question for you:

Which topic would you like to hear more about?

Not every meeting moves the needle.

I talked to Dhruv Agarwal on The Change Story Podcast about flow, and how it can get lost in all the ebbs and eddies of activity across organizations. Without taking stock of the jobs to be done by our rituals, cadences, and interactions we can end the week drained of energy or wondering why we once again got “nothing done”.

We discussed the importance of aligning collaboration with clear value and how value, clarity, and flow, serve as the bedrock for organizations seeking to improve performance. As enterprises navigate complex digital transformations and evolutions, a proactive approach is essential. A stitch in time saves nine. Before the year gets away from you, what would happen if you looked at your ‘collaboration transactions’ to see if you’re in the black or the red each month? It’s a great time to take stock and consider cutting, consolidating, or leveraging technology, particularly AI, to optimize workflows.

Topics

• Flow as a Transformative Mindset: The concept of flow can dramatically shift the way your team thinks about work.

• Busy vs. Productive: The distinction between being busy and being truly productive is crucial for teams to focus on what matters most.

• Collaboration vs. Disruption: Effective collaboration must be evaluated for its actual value rather than simply perceived as a positive force.

• Value Stream Mapping: Puts value stream mapping in context as a tool to streamline processes and identify waste.

• Value, Clarity, Flow: The trio of value, clarity, and flow works in tandem to improve organizational efficiency and effectiveness.

• Managing Stakeholder Perspectives: Aligning diverse stakeholder views and goals can mitigate conflicts and enhance decision-making processes.

• AI as an Agent of Change: The integration of AI tools should be handled thoughtfully to avoid adding friction and complexity to established workflows.

Takeaways

• Holistic Approach to Flow: Flow should be applied at multiple organizational levels, from individual tasks to large-scale initiatives. This holistic view enables a unified approach to problem-solving.

• Focus on Value First: Organizations must prioritize identifying and defining the value they aim to achieve, which serves as the guiding principle for all actions and decisions.

• Iterative Mapping: Continually refining value stream maps allows organizations to respond dynamically to process changes and newfound efficiencies, ensuring sustained improvement.

• Clarity for Reducing Noise: Achieving clarity within teams and across organizations reduces confusion, enabling staff to focus on high-value tasks rather than being overwhelmed by trivial activities.

• Testing Assumptions: It’s crucial for leaders to validate their assumptions about value not just within their perspectives, but by inclusive dialogues with team members to encourage diverse insights.

• AI Integration with Governance: As AI becomes increasingly integrated into workflows, establishing clear policies and guidelines is essential to ensure that their application contributes positively to organizational objectives.

• Continuous Learning Culture: Encouraging a culture that values ongoing learning, adaptability, and the evaluation of practices empowers teams to continuously enhance both individual and organizational performance.

The episode is out now on all streaming platforms. Have a listen and let me know what you think!

Only 4 days Left to Get 30% off!!

The clock’s ticking—there are only a few days left to lock in 30% off the Flow Engineering course before it goes live on April 15, 2025. If you're part of a large organization and looking to create real momentum in how your teams work and deliver, this is a great opportunity to start a conversation or create common language about performance improvement. The course walks you through the five key mapping methods to help you uncover friction points, align teams, and design smarter ways of working. Whether you're a leader, engineer, product owner, agile coach, or anywhere in the flow of work, you’ll gain a clear, actionable framework to drive meaningful improvements. With expert guidance and real-world examples, you’ll leave equipped to make an impact. Grab the discount while it’s still on the table—your path to better flow starts here.