-
Notifications
You must be signed in to change notification settings - Fork 0
Kitting and Wait States
Owner: Bill Eisenhauer Last Updated: August 6, 2026 Status: 🚧 Working practice Contributors: Bill Eisenhauer
Working definition: Kitting is the discipline of doing enough informational and coordination work before commitment that foreseeable missing context, access, decisions, evidence, and ownership do not interrupt the work after it enters flow.
The effects came before the vocabulary. Bill Eisenhauer experienced work stopping for missing decisions, environments, dependencies, and ownership over many years of software delivery. TameFlow supplied a name—Full-Kitting—and a system-level explanation for what those interruptions do to flow.
Leverage Lab uses that intellectual lineage explicitly. It then asks a newer question: what does readiness mean when execution may be performed by humans, agents, or an outside partner, while acceptance and durable ownership remain organizational responsibilities?
TameFlow separates Touch Time, when an item is actively progressing, from Wait Time, when it remains inside the process without progress. Its Full-Kitting practice belongs primarily to informational flow: gather and coordinate what is knowable, create shared understanding across business and engineering, and decide what is fit to enter committed execution. The practice is intended to protect operational flow once work starts, not merely to produce a requirements artifact. TameFlow's Four Flows discussion and its treatment of business and engineering decisions during Full-Kitting make that connection explicit.
Three distinctions matter:
- Kitting is not certainty. A volatile environment cannot be designed away in advance.
- Kitting is not big up-front design. Preparation should be risk-adjusted, right-sized, and close enough to commitment to remain useful.
- Kitting is not throughput by itself. Reducing wait removes WIP and multitasking pressure; throughput improves when that change lets the governing constraint use more of its sustainable capacity.
This is broader than a backlog-refinement meeting or a universal Definition of Ready. It is an operating policy about what the organization will commit, what it will leave upstream, and which uncertainties deserve a separate discovery cycle.
Not all waiting can—or should—be eliminated. The more precise goal is to keep foreseeable waiting outside committed flow, where an item remains an option rather than active WIP.
flowchart LR
R["Request or opportunity"] --> K["Kit upstream"]
K --> G{"Ready enough for this risk?"}
G -->|No| D["Clarify, obtain, or run bounded discovery"]
D --> K
G -->|Yes| C["Commit and pull"]
C --> T["Touch: execute and verify"]
T --> O["Accepted and owned outcome"]
T -->|Unforeseeable discovery| S["Swarm, decide, and record learning"]
S --> T
S -. improve future kits .-> K
In prose: a request is prepared upstream until it is ready enough for its risk. Predictable gaps keep it outside committed WIP. Unforeseeable discoveries during execution are handled collaboratively, and the learning changes future kit policy.
The failure pattern is the inverse:
flowchart LR
A["Premature commitment"] --> B["Missing input discovered"]
B --> C["Wait or switch context"]
C --> D["More WIP and coordination"]
D --> E["Restart, rework, or flowback"]
E --> B
In prose: an item admitted with foreseeable gaps stops after commitment. People or agents switch context, queues grow, and resumption adds coordination or rework. The item can look active while producing little progress.
A Full Kit should not become a ceremonial checklist applied identically to every item. The useful question is:
What must be true for this kind of work, at this level of consequence, to make sustained progress once we commit it?
A software-delivery kit may include:
- intended outcome, economic reason, and non-goals;
- named decision-maker and durable owner;
- authoritative context and applicable standards;
- known interfaces, dependencies, and affected consumers;
- access, data, environments, and tool permissions;
- acceptance examples, automated checks, or an evaluation rubric;
- risk classification and required review path;
- release, adoption, support, and rollback expectations; and
- unresolved assumptions that are acceptable to carry into execution.
The last item prevents false confidence. A kit makes residual uncertainty visible; it does not claim to remove it.
When the organization cannot responsibly kit an implementation, the answer is not indefinite analysis. Create a small discovery item with its own:
- decision or question;
- timebox or evidence budget;
- owner;
- evidence to collect; and
- exit criterion: commit, reshape, defer, or stop.
That makes learning executable while protecting the delivery system from a large, ambiguous commitment.
| Executor | Readiness emphasis | Failure prevented |
|---|---|---|
| Human team | Shared intent, decision access, dependency coordination, and acceptance evidence | Clarification queues, context switching, and avoidable rework |
| Agent | Bounded task, authoritative context, permissions, tool contract, evaluator, and escalation rule | Plausible but unusable output, unsafe action, and human review overload |
| Outside partner | Commercial outcome, system interfaces, engineering standards, in-flight review, named internal owner, and transfer evidence | Second-class code, late integration surprise, and permanent dependency |
Kitting can materially derisk partner delivery, but it does not derisk the partner in every sense. Selection and a small evidence-producing engagement must still establish capability, reliability, security posture, and working compatibility. Kitting derisks the interface between organizations: it makes inputs, decisions, quality evidence, review capacity, and ownership obligations explicit before external output begins to accumulate.
A statement of work is therefore the contractual boundary, not necessarily the operational kit. The usable kit also needs a way into the codebase, a continuous route to internal review, and an owner who can accept and maintain the result. If those conditions are absent, partner output can consume more scarce internal capacity than it adds.
An organization can define the conditions under which outside work enters its product and becomes acceptable, releasable, and owned. It should not ordinarily need to dictate every aspect of how the partner manages its own people or internal operation. The durable target is the interface between organizations.
Those expectations are negotiated rather than imposed after work begins. They should influence partner selection, be tested through a small evidence-producing engagement, and appear in the statement of work and acceptance model where appropriate.
Partner delivery therefore needs two nested kits:
| Layer | Reuse | What it establishes |
|---|---|---|
| Relationship kit | Reused across engagements | Contribution interface, access and security, engineering standards, paved road, decision rights, review capacity, escalation, ownership, and handoff protocol |
| Work-item kit | Specific to an outcome | Commercial intent, scope and non-goals, dependencies, acceptance evidence, risk, release expectations, and named owner |
The relationship kit creates a stable operating environment within which individual work can be prepared. A useful Partner Delivery Kit might include:
- a concise operating charter with responsibilities and decision rights;
- an executable development environment, repository path, CI checks, and representative examples;
- relevant architecture maps, standards, and known integration hazards;
- a Full-Kit and statement-of-work template;
- an in-flight review and escalation protocol; and
- a handoff protocol that defines operational readiness and declining partner dependency.
The strongest onboarding artifact is not a large handbook. It is an executable paved road that lets a partner produce a small, acceptable change quickly. Its health can be observed through time to first accepted change, first-pass acceptance, clarification and internal-review demand, kit-related blockers, and partner dependency after handoff.
Too little structure creates review, integration, and ownership debt. Too much imposed process creates expense and compliance theater. The aim is the minimum set of shared constraints needed to protect quality, security, flow, and durable ownership while preserving the partner's useful autonomy.
That is kitting applied not just to a work item, but to the relationship itself.
Useful signals include:
| Signal | Question it helps answer |
|---|---|
| Post-commitment blocked time by reason | Which foreseeable prerequisites are still being discovered too late? |
| Flowbacks and rework attributed to kit gaps | Where did execution have to reverse or repeat? |
| First-pass acceptance | Did the kit make success evaluable? |
| Kit churn after commitment | How often are intent or boundaries changing in flight? |
| Time from request to ready | Has upstream preparation become its own unmanaged queue? |
| Human clarification and review demand | Are agents or partners displacing work onto a scarce internal resource? |
| Partner dependency after handoff | Did external output become internally owned capacity? |
Do not optimize a metric in isolation. A high “percent fully kitted” can be theater; a long ready queue can become stale inventory; a short ready time can hide premature commitment. Read the signals together with WIP, throughput, work-item age, flow time, and the current constraint.
- Do not commit work with a known, material prerequisite missing.
- Define kit expectations by work type and consequence, not one universal template.
- Make exceptions explicit: record the urgency, the missing condition, its risk, and the person accepting that risk.
- Give discovery work a bounded outcome instead of disguising it as implementation.
- Record why committed work waits, then change the kit only when recurring evidence warrants it.
- Revisit the policy when the constraint moves; preparation itself can become excessive or constrained.
The simulator's Full Kit stage represents readiness as real capacity, and Improve context readiness models one possible investment in it. The model is intentionally simpler than the practice described here. In a real delivery system, Full-Kitting is both an upstream workflow and a cross-functional decision discipline.
This page also explains why adding agent or partner capacity can be harmful in the simulator: more implementation is not leverage when poorly kitted work converts downstream judgment, review, integration, or ownership into the active constraint.
Related: Operating Hypothesis · Flow Discovery and Intervention Rig · Human-Agent Delivery System · Simulator Model · Sources and Further Reading