-
Notifications
You must be signed in to change notification settings - Fork 0
Flow Discovery and Intervention Rig
Owner: Bill Eisenhauer Last Updated: August 6, 2026 Status: 🚧 Working practice Contributors: Bill Eisenhauer
The simulator develops causal intuition. The rig turns that intuition into a shared view of a real delivery system, a bounded intervention, and evidence about what actually governed outcomes.
A constraint-learning strategy depends on being able to see enough of the system to form a useful hypothesis. Most organizations do not begin with a clean end-to-end model or instrumentation. They begin with partial telemetry, local dashboards, competing explanations, and people who each see a different part of the work.
The answer is not to map the entire enterprise or wait for perfect data. Start broadly and lightly, locate a probable constraint, then improve the resolution only around that part of the system. The resulting intervention remains a hypothesis until system outcomes supply evidence.
This practice combines the collaborative mapping sequence described by Steve Pereira and Andrew Davis in Flow Engineering with constraint management, Full-Kitting, and execution signals described by Steve Tendon in The Book of TameFlow and Standing on Bits. Leverage Lab extends that synthesis to delivery systems containing humans, agents, platforms, and outside partners.
flowchart TD
A["Define the accepted and owned outcome"] --> B["Map the current end-to-end flow"]
B --> C["Locate the probable constraint"]
C --> D["Trace only dependencies affecting it"]
D --> E["Design and Full-Kit one intervention"]
E --> F["Describe the intended future state"]
F --> G["Assign action, measure, and owner"]
G --> H["Run a bounded learning window"]
H --> I["Issue a learning receipt"]
I --> J{"What governed outcomes?"}
J -->|Moved| B
J -->|Unchanged or uncertain| C
In prose: define value at the accepted-and-owned boundary, map a representative current flow, investigate the likely constraint, and prepare one intervention. Describe what should change, assign ownership and evidence, run the learning window, and remap from what happened.
| Artifact | Question | Minimum useful content |
|---|---|---|
| Outcome Map | What valuable future are we trying to create? | Outcome, beneficiaries, benefits, obstacles, next decision |
| Current State Value Stream Map | How does value actually move today? | Real steps, roles, touch time, wait time, rework, finish boundary |
| Constraint-Focused Dependency Map | What causes or protects the probable constraint? | Relevant teams, decisions, information, tools, interfaces, and capabilities |
| Future State Value Stream Map | What should this flow look like after the intervention? | Near-term target state, changed mechanism, expected effects |
| Flow Roadmap | How will we test the change? | One or a few sequenced actions, measure, owner, and review date |
The artifacts are disposable representations, not deliverables to admire. Their value comes from creating a shared mental model and enabling a better decision. Preserve them only while they continue to support learning.
A Current State Map should cover the complete path to an accepted and owned outcome, but at low resolution. It is a way to find a promising place to investigate, not proof that the largest box or queue is the governing constraint.
Once a probable constraint is identified, increase resolution only there:
flowchart LR
A["Low-resolution value stream"] --> B["Probable constraint"]
B --> C["Local sub-flow"]
C --> D["Decisions"]
C --> E["Information"]
C --> F["Teams and partners"]
C --> G["Tools and environments"]
D --> H["Intervention hypothesis"]
E --> H
F --> H
G --> H
In prose: the end-to-end map supplies context. A focused dependency trace then examines the decisions, information, contributors, and capabilities that affect the suspected constraint. This avoids both local optimization and exhaustive dependency theater.
The rig preserves three different statements:
- perceived constraint: what currently attracts attention;
- probable constraint: what the available map and evidence suggest; and
- governing constraint: what the completed learning window indicates actually limited accepted outcomes.
This language keeps a collaborative map from becoming an oracle. A map may contain estimates and lived experience; the intervention supplies the stronger test.
Not every constraint is a bottleneck to remove. A delivery system also needs deliberately designed constraints.
| Constraint type | Purpose | Human-agent examples |
|---|---|---|
| Enabling | Make the preferred action easy | Paved paths, self-service environments, authoritative context, templates, evaluators, playbooks |
| Governing | Make an unsafe or system-damaging action difficult | WIP limits, permission boundaries, Full-Kit admission, risk-tiered review, release policy |
In stable, repeatable work, governing constraints can protect consistency and safety. In uncertain work, enabling constraints provide direction without pretending the path is already known. A productive agentic workflow usually needs both: enough freedom to explore and enough boundaries to make consequences observable and controllable.
Full-Kitting illustrates the combination. It governs entry into committed flow while enabling sustained execution after entry.
Implementation telemetry is not enough when progress depends on decisions and coordination. Observe the feedback loops through which exceptions reach people with authority.
Useful signals include:
- decision and escalation latency;
- how often escalation paths are exercised;
- whether the signal reaches everyone required to resolve it;
- work-item age and post-commitment blocked time;
- first-pass acceptance or percent complete and accurate;
- rework and flowback reasons;
- human clarification, review, and integration demand; and
- adoption and durable ownership after release or handoff.
These are system signals, not individual performance measures. Their purpose is to reveal where work or information waits and where management attention can change the outcome.
Foundations, internal platforms, developer tooling, and partner-delivery capabilities are supportive value streams. Their customers are the core streams that deliver value to external users.
flowchart LR
S1["Shared foundations"] --> P1["Core product stream"]
S2["Builder experience"] --> P1
S2 --> P2["Core product stream"]
S3["Partner capability"] --> P2
P1 --> C["Customer outcomes"]
P2 --> C
C -. adoption and flow evidence .-> S1
C -. adoption and flow evidence .-> S2
C -. ownership evidence .-> S3
In prose: supportive streams provide reusable capabilities to core product streams. Their leverage is demonstrated by better customer-facing flow, adoption, and ownership—not by the volume of tools, frameworks, or external code they produce.
The preferred interface is pull-based and increasingly self-service. If every use of a shared capability requires a ticket, meeting, or specialist intervention, the support stream may become the very dependency it was intended to remove.
| Agents can help with | Humans remain responsible for |
|---|---|
| Assemble event data and draft the observed workflow | Define the valuable outcome and system boundary |
| Identify long waits, aging work, rework, and anomalous paths | Reconcile conflicting perspectives and incentives |
| Generate questions and candidate dependency traces | Decide which risks and unknowns are acceptable |
| Simulate or compare proposed future states | Commit scarce capacity and decision authority |
| Maintain maps as telemetry changes | Accept evidence and assign durable ownership |
The mapping conversation is part of the intervention. Agents can reduce the cost of constructing and refreshing the representation, but shared understanding cannot be delegated entirely to the representation.
- Choose one important, recent, representative outcome.
- Trace it from request to accepted use and ownership.
- Mark touch time, wait time, rework, and important decisions.
- Name the probable constraint and confidence level.
- Trace only the dependencies that affect that constraint.
- Full-Kit one bounded intervention and predict its system effect.
- Execute through the existing Sprint, Kanban, or other delivery workflow.
- Issue a learning receipt and remap what changed.
This can begin with estimates and workshop evidence. Instrumentation becomes the intervention when the missing data is likely to change the next decision.
The additional source material does not require a more complicated simulator today. The existing model already teaches its central lessons:
- added implementation capacity can create downstream pressure;
- context, verification, integration, adoption, and ownership can govern outcomes;
- interventions interact with prior choices;
- incomplete telemetry can misidentify the constraint;
- the constraint can move; and
- partner output is useful only when the organization can absorb it.
Adding economic value, dependency topology, multiple constraint types, decision-loop latency, or network maps now would make the simulator look more realistic while making its causal lesson harder to inspect. Those ideas belong in the field rig until repeated play or facilitation exposes a specific teaching gap.
Current decision: Keep Leverage Lab as a bounded mental model, not an enterprise digital twin. Add a mechanism only when it teaches something users repeatedly fail to discover with the current model.
Related: Constraint Learning Loop · Kitting and Wait States · Human-Agent Delivery System · Simulator Model · Sources and Further Reading