Kaizen Improvement

/kaizen

Help the user build a continuous-improvement practice into how they or their team work. Core principle: many small improvements beat one big change, and preventing an error at design time beats fixing it every time it recurs. This is a standing habit, not a project -- if the user wants to map and redesign a process once, that is process-optimization.

The Four Pillars

Diagnose which pillar the user's situation needs; most conversations lean on one or two.

1. Continuous Improvement (Kaizen proper)

Small, frequent, verified changes that compound.

• Make the smallest viable change that improves the process, one at a time.
• Verify each change worked before starting the next -- a change nobody checked is a superstition, not an improvement.
• Always leave the process slightly better after touching it: fix the confusing step you tripped on, update the stale instruction, delete the obsolete field.
• Refine in passes: first make it work, then make it clear, then make it efficient. Never all three at once -- batched improvements cannot be verified and get reverted wholesale when one part fails.

Coach the user away from "big cleanup week" thinking. Big-bang overhauls fail because they need everyone's buy-in at once and cannot be rolled back partially.

2. Error-Proofing (Poka-Yoke)

Design the process so the mistake cannot happen, instead of asking people to be careful.

The escalation ladder -- always push the fix as high up as feasible:

1. Eliminate: remove the step where the error occurs (best)
2. Constrain: make the wrong action impossible (a form that rejects bad input, a template with required fields, removing access nobody should have)
3. Detect early: a checkpoint that catches the error immediately, close to where it happens
4. Warn: checklist or reminder (weakest -- use only when 1-3 are impractical)

When the user describes a recurring mistake, ask: "What would make this error impossible rather than less likely?" "People should just be careful" is the signature anti-pattern of pillar 2. If the fix is a reminder email, keep climbing the ladder.

3. Standardized Work

Once something works, write it down and make it the default.

• Consistency beats cleverness: follow the established way unless the new way is significantly better AND the team agrees to switch.
• The standard lives where the work happens (in the template, the checklist, the tool), not in a document nobody opens.
• Document WHY, not just what -- steps without reasons get skipped the first time they are inconvenient.
• A standard is the current best known way, not a law: it exists precisely so the next improvement has a stable baseline to improve on.

4. Just-In-Time (Build Only What Is Needed)

• Solve the problem in front of you; delete "we might need this someday" work.
• Add process, tooling, or structure only when the pain is real and observed, not anticipated.
• Wait for a pattern to appear three times before building the general solution for it.
• "Good enough today, better tomorrow" -- ship the adequate version and let the improvement loop catch the rest.

Running the Improvement Loop

The deliverable of this skill is usually a lightweight recurring routine. Design it with the user:

1. Cadence: pick a small fixed slot (15-30 min weekly beats a quarterly half-day).
2. Capture: one running list where anyone logs friction the moment they hit it. No triage at capture time.
3. Pick ONE: each cycle, choose the single highest-friction item. Resist batching.
4. Change + verify: make the smallest change that addresses it; define before changing how you will know it worked.
5. Standardize or revert: if it worked, fold it into the standard; if not, revert without ceremony.
6. Track the log: keep a visible list of improvements shipped -- momentum is the fuel of the whole practice.

For each cycle you help run, deliver a short artifact: the friction item chosen, the change, the verification signal, and the updated standard.

Red Flags to Call Out

• "We'll fix it properly later" -- later never comes; take the small improvement now.
• A retro or review that produces action items with no owner, no verification, and no follow-up -- that is a venting session, not an improvement loop.
• Fixing a recurring error with training or reminders when a constraint is available.
• "I prefer to do it my way" against an existing working standard.
• Building process for problems nobody has hit yet.

Fences

• One-off mapping and redesign of a specific process: use process-optimization.
• Structured root-cause analysis of a single incident: run 5-whys thinking inside this loop, but a deep one-time investigation belongs in process-optimization.

Usage

/kaizen $ARGUMENTS