-
Notifications
You must be signed in to change notification settings - Fork 0
Leverage Lab in Plain English
Owner: Bill Eisenhauer Last Updated: August 7, 2026 Status: 🚧 Living guide Contributors: Bill Eisenhauer
The short version: Faster coding does not always mean faster delivery. When one part of the system speeds up, work may simply pile up somewhere else. The job is to find what now sets the pace, improve it, and then look again.
Software delivery is a chain of connected activities. A team chooses what to build, prepares the work, builds it, checks it, releases it, and helps people use and own it.
The slowest important part of that chain sets the pace of the whole system. This is the constraint.
Agents can make building much faster. That is useful, but it can also move the constraint to product decisions, testing, review, release, adoption, or ownership. More code is not more value when the rest of the system cannot handle it.
flowchart LR
A["Choose the outcome"] --> B["Prepare the work"]
B --> C["Build"]
C --> D["Check"]
D --> E["Release"]
E --> F["Use and own"]
In prose: work moves from choosing an outcome through preparation, building, checking, and release. It creates value only when someone uses it and an owner can support it.
A pull request is not the final result. Neither is a deployed service, a new framework, or a vendor delivery.
For Leverage Lab, work counts when it is:
- accepted against clear evidence;
- connected to the real product and operating environment;
- used by the people it was meant to help; and
- owned by someone who can maintain it.
This is what the simulator calls an accepted and owned outcome.
| Stage | Plain meaning |
|---|---|
| Shape | Decide which outcome matters and why |
| Full Kit | Make the work ready enough to begin responsibly |
| Build | Create the change |
| Verify | Check that it is correct, safe, and useful |
| Integrate / Release | Connect it to the product and put it into service |
| Adopt / Own | Help people use it and give it a long-term owner |
Any one of these stages can limit the whole system.
| Clue | What it means |
|---|---|
| Queue | Work that has piled up at a stage. A large queue shows pressure, but does not prove that the stage sets the system's pace. |
| Effective capacity | The amount of good work a stage can pass in a week. The simulator calculates it as sustainable capacity × first-pass yield. |
| Coverage | How much of the stage is visible in the available data. Low coverage means less confidence in the diagnosis. |
Read the clues together. Start with stages that have low effective capacity. Look at the queues around them. Then use coverage to decide how much you trust what you see.
The first diagnosis is a best current guess, not the answer. The result of a learning cycle provides stronger evidence.
- Define the result that really counts.
- Look at the full path to that result.
- Name the stage most likely to set the pace.
- Protect it from overload and avoid wasting its time.
- Make one focused change.
- Predict what should happen before running the test.
- Watch accepted outcomes, queues, age, rework, and human effort.
- Record what happened and find the next constraint.
The focused change is called an intervention. It may add capacity, improve information, automate checks, limit new work, support adoption, or simply collect missing data.
Kitting means making work ready enough before committing it to delivery. The goal is to prevent avoidable stops after work has begun.
A useful kit may answer:
- What result are we trying to create?
- Who can make decisions when questions arise?
- What systems and people does the work depend on?
- What access, data, and tools are needed?
- How will we know the result is acceptable?
- Who will release, support, and own it?
- Which unknowns are we choosing to accept?
Kitting is not an attempt to predict everything. If the team needs to learn before it can commit, create a small discovery task with a clear question, time limit, owner, and decision at the end.
The useful question is not simply, “Should a human or an agent do this?” Ask two questions instead:
- How clearly can we check whether the work succeeded?
- How costly or difficult would a mistake be to reverse?
Agents are a good fit when the goal and checks are clear and mistakes are easy to contain. People should keep more control when the goal is unclear, judgment matters, or the consequences are serious.
As agent output grows, human attention may become the constraint. Product decisions, risk review, security, integration, and ownership do not become free just because implementation is faster.
An outside partner adds useful capacity only when the organization can absorb and own the result.
The organization should define the interface for contribution: access, engineering standards, review, acceptance, release, escalation, and handoff. The partner can keep control of its own internal operation as long as it works within that interface.
There are two kits:
- the relationship kit, reused across engagements; and
- the work kit, prepared for a specific outcome.
That is kitting applied not just to a work item, but to the relationship itself.
No. Scrum, Kanban, or another delivery method can still organize daily execution.
Leverage Lab adds a different question: Where will an investment improve the result of the whole system now? Once a change is chosen, the team can deliver it through its normal workflow.
The simulator is a small teaching model. It is not a forecast, company assessment, or complete copy of a real engineering organization.
It teaches a few important relationships:
- local output can rise while accepted outcomes stay flat;
- the most visible queue may not be the real constraint;
- missing data can lead to the wrong investment;
- interventions can help in one combination and hurt in another;
- agents and partners create downstream work as well as capacity; and
- a successful change can move the constraint.
Easy mode shows more of the model's answer. Hard mode asks you to read incomplete evidence before the result is revealed. Neither mode claims to know what would happen in a real company.
Make the real finish line clear. Look at the whole path, not only the team producing the most visible output. Find the part most likely to set the pace and run one measured improvement. Give humans, agents, and partners the context and checks they need before work starts. Count value only when the result is accepted, used, and owned. Then look again, because fixing one constraint changes the system.
Go deeper: Operating Hypothesis · Kitting and Wait States · Human-Agent Delivery System · Flow Discovery and Intervention Rig · Constraint Learning Loop · Simulator Model