Push-Out
Purpose: Move recurring operational burden outward from fragile human execution into durable system capability.
Improvement Trio
defect-shift-left: move defect detection earlier.push-out: move recurring operational work outward.bring-down: move bespoke code down into reusable capability.
Core Directives
- Push work, not responsibility. The owner remains accountable; the execution path moves into a more durable layer.
- Evidence before rank. Assign no push-out rank without observed proof.
- Delete before pushing. Remove unnecessary work before documenting, standardizing, automating, or platforming it.
- Standardize before automating. Automation over ad hoc practice industrializes confusion.
- Self-service needs guardrails. A platform without the guardrail set — policy, validation, permissions, audit, observability, and rollback — exports toil to users.
- Feedback closes the loop. Dashboards and metrics are not improvement until they trigger action.
- Executable sources beat prose duplicates. When code, config, tests, schemas, CI, policy-as-code, or architecture-as-code already define the operational truth, keep prose only for intent, ownership, rationale, external constraints, trade-offs, rollback notes, and links to that source.
1. Push-Out Ladder
The ladder names where recurring operational work currently lives.
| Rank | Location | Work lives in | Evidence |
|---|---|---|---|
| 0 | Individual memory | Heroics, tribal knowledge, manual clicks | "Ask Alice", no runbook, no repeatable input/output |
| 1 | Team procedure | Runbook, checklist, documented handoff | Another team member can repeat it manually |
| 2 | Repo standard | Template, script, CI job, policy, config convention | The repo enforces or strongly guides the path |
| 3 | Shared platform | Golden path, reusable workflow, managed internal primitive | Multiple repos/teams consume the same capability |
| 4 | Self-service control | Guardrailed workflow developers can run without ops handoff | Users trigger it safely; the guardrail set exists (Directive 5) |
| 5 | Adaptive system | Metrics and feedback change the system | Thresholds, reviews, or automation drive continuous improvement |
push-out distance = target rank - current rank
Higher is not always better. Choose the target by frequency, risk, toil cost, blast radius, and number of dependent teams.
2. Target-Rank Heuristics
| Condition | Minimum target |
|---|---|
| Rare, low-risk internal task | Rank 1 |
| Repeated task inside one repo/team | Rank 2 |
| Repeated task across repos/teams | Rank 3 |
| Frequent developer-facing request or ticket queue | Rank 4 |
| High-volume, high-risk, regulated, or incident-prone path | Rank 5 |
Do not push work to Rank 4 or 5 unless the lower-rank foundations exist or are created in the same change.
3. Push-Out Protocol
- Define scope. Name the product, repo, platform, teams, environments, and time window.
- Inventory recurring work. Find manual steps, tickets, approvals, incident repeats, deploy chores, dashboard checks, and hand-maintained config.
- Question necessity. Delete work that no longer serves a real purpose.
- Locate current rank. Assign rank 0-5 with evidence.
- Choose target rank. Justify by frequency, risk, blast radius, compliance, toil cost, and dependency count.
- Compute distance. Target rank - current rank.
- Choose the next move. Emit one action that advances exactly one rank.
- Gate and retire. Prove the new path works, then remove same-scope manual duplicates.
Prioritize by:
priority = push-out distance x frequency x risk x blast radius x toil cost
If many candidates compete, apply system-optimization to find the constraint
before improving adjacent work.
4. Move Patterns
| Move | Use when | Action |
|---|---|---|
| 0 to 1 | Knowledge is tribal | Write owner, inputs, outputs, runbook, rollback |
| 1 to 2 | A runbook repeats | Convert to script, template, CI job, config schema, or policy |
| 2 to 3 | Many repos copy the same practice | Extract shared workflow, platform primitive, or golden path |
| 3 to 4 | Platform team is still a ticket queue | Add self-service UI/API/CLI with the full guardrail set (Directive 5) |
| 4 to 5 | Self-service exists but does not improve | Add SLOs, trend review, alert thresholds, incident learning, and removal loop |
Documentation pruning pattern: when prose documentation repeats behavior, rules, setup, policy, or architecture that is already enforced or derivable from code, config, tests, schemas, generated output, CI, policy-as-code, or architecture-as-code, do not create a second source of truth. Verify the executable source covers the same scope, then replace the prose duplicate with the smallest useful note: why it exists, who owns it, where the executable source lives, and which external constraint or trade-off is not visible from the code.
When the move concerns deployment safety, apply ci-cd-reliability-architecture.
When the move concerns check placement, apply defect-shift-left. When the
move concerns duplicated custom implementation, apply bring-down. When the
question is which artifact owns the fact rather than whether prose duplicates
an executable source, apply zero-copy-requirements.
5. Anti-Patterns
| Anti-pattern | Correction |
|---|---|
| Automating an undocumented process | Document and standardize first |
| Platform team as ticket queue | Push to guardrailed self-service |
| Self-service without policy or rollback | Add the full guardrail set (Directive 5) |
| Dashboard called improvement | Define threshold, review cadence, and action |
| Tool adoption treated as maturity | Score the operational outcome, not the product installed |
| Golden path with no adoption signal | Measure usage, escape hatches, and support load |
| Manual approval called governance | Replace with policy-as-code where technically possible |
| Keeping manual duplicate forever | Retire same-scope duplicate after proof |
| Prose repeats an executable source of truth | Keep intent/rationale/ownership/link; delete the repeated mechanics |
6. Output Contract
Emit results in this shape:
Scope: <product/repo/platform/team/environment/time window> Mode: Assessment | Improvement | Roadmap Decision: Keep manual | Delete | Document (→1) | Standardize (→2) | Platformize (→3) | Self-service (→4) | Adaptive (→5) Summary: <2-4 sentences: main toil source, best next push, key risk> Verification: <metrics, logs, workflow search, runbook check, or Not run + reason> Work map: | Work item | Current rank | Target rank | Distance | Evidence | Decision | Confidence | Next action | | --------- | ------------ | ----------- | -------- | -------- | -------- | ---------- | ----------- | Priorities: | Rank | Work item | Why now | Push-out move | Validation | Duplicate to retire | | ---- | --------- | ------- | ------------- | ---------- | ------------------- | Gaps: <Missing evidence, unknown ownership, absent metrics, excluded work, or risks>
7. See Also
defect-shift-left- move defect detection earlier.bring-down- move bespoke code down into reusable capability.system-optimization- bottleneck and waste analysis before improvement.ci-cd-reliability-architecture- pipeline safety and deployment reliability patterns.zero-copy-requirements- which artifact owns a fact, before pruning the duplicate.continuous-improvement- promotion of recurring findings into skills, checks, or templates.
