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.
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.continuous-improvement - promotion of recurring findings into skills, checks, or templates.
1---2name: push-out3description: Moves recurring DevOps and operational work out of individual memory, manual execution, ticket queues, and team-local practice into documented procedures, repo standards, shared platforms, self-service controls, and adaptive feedback loops. Use when reducing toil, designing an improvement roadmap, deciding what to standardize or automate, assessing where operational work currently lives, pruning prose documentation duplicated by code/config/tests/policy-as-code/architecture-as-code, or asking how to move work from humans into durable systems.4---56# Push-Out78> **Purpose**: Move recurring operational burden outward from fragile human9> execution into durable system capability.1011> **Improvement Trio**12>13> - `defect-shift-left`: move defect detection earlier.14> - `push-out`: move recurring operational work outward.15> - `bring-down`: move bespoke code down into reusable capability.1617> **Core Directives**18>19> 1. **Push work, not responsibility.** The owner remains accountable; the20> execution path moves into a more durable layer.21> 2. **Evidence before rank.** Assign no push-out rank without observed proof.22> 3. **Delete before pushing.** Remove unnecessary work before documenting,23> standardizing, automating, or platforming it.24> 4. **Standardize before automating.** Automation over ad hoc practice25> industrializes confusion.26> 5. **Self-service needs guardrails.** A platform without the guardrail set —27> policy, validation, permissions, audit, observability, and rollback —28> exports toil to users.29> 6. **Feedback closes the loop.** Dashboards and metrics are not improvement30> until they trigger action.31> 7. **Executable sources beat prose duplicates.** When code, config, tests,32> schemas, CI, policy-as-code, or architecture-as-code already define the33> operational truth, keep prose only for intent, ownership, rationale,34> external constraints, trade-offs, rollback notes, and links to that source.3536---3738## 1. Push-Out Ladder3940The ladder names where recurring operational work currently lives.4142| Rank | Location | Work lives in | Evidence |43| ---- | -------- | ------------- | -------- |44| **0** | Individual memory | Heroics, tribal knowledge, manual clicks | "Ask Alice", no runbook, no repeatable input/output |45| **1** | Team procedure | Runbook, checklist, documented handoff | Another team member can repeat it manually |46| **2** | Repo standard | Template, script, CI job, policy, config convention | The repo enforces or strongly guides the path |47| **3** | Shared platform | Golden path, reusable workflow, managed internal primitive | Multiple repos/teams consume the same capability |48| **4** | Self-service control | Guardrailed workflow developers can run without ops handoff | Users trigger it safely; the guardrail set exists (Directive 5) |49| **5** | Adaptive system | Metrics and feedback change the system | Thresholds, reviews, or automation drive continuous improvement |5051```52push-out distance = target rank - current rank53```5455Higher is not always better. Choose the target by frequency, risk, toil cost,56blast radius, and number of dependent teams.5758---5960## 2. Target-Rank Heuristics6162| Condition | Minimum target |63| --------- | -------------- |64| Rare, low-risk internal task | Rank 1 |65| Repeated task inside one repo/team | Rank 2 |66| Repeated task across repos/teams | Rank 3 |67| Frequent developer-facing request or ticket queue | Rank 4 |68| High-volume, high-risk, regulated, or incident-prone path | Rank 5 |6970Do not push work to Rank 4 or 5 unless the lower-rank foundations exist or are71created in the same change.7273---7475## 3. Push-Out Protocol76771. **Define scope.** Name the product, repo, platform, teams, environments, and78 time window.792. **Inventory recurring work.** Find manual steps, tickets, approvals,80 incident repeats, deploy chores, dashboard checks, and hand-maintained81 config.823. **Question necessity.** Delete work that no longer serves a real purpose.834. **Locate current rank.** Assign rank 0-5 with evidence.845. **Choose target rank.** Justify by frequency, risk, blast radius,85 compliance, toil cost, and dependency count.866. **Compute distance.** Target rank - current rank.877. **Choose the next move.** Emit one action that advances exactly one rank.888. **Gate and retire.** Prove the new path works, then remove same-scope manual89 duplicates.9091Prioritize by:9293```94priority = push-out distance x frequency x risk x blast radius x toil cost95```9697If many candidates compete, apply `system-optimization` to find the constraint98before improving adjacent work.99100---101102## 4. Move Patterns103104| Move | Use when | Action |105| ---- | -------- | ------ |106| **0 to 1** | Knowledge is tribal | Write owner, inputs, outputs, runbook, rollback |107| **1 to 2** | A runbook repeats | Convert to script, template, CI job, config schema, or policy |108| **2 to 3** | Many repos copy the same practice | Extract shared workflow, platform primitive, or golden path |109| **3 to 4** | Platform team is still a ticket queue | Add self-service UI/API/CLI with the full guardrail set (Directive 5) |110| **4 to 5** | Self-service exists but does not improve | Add SLOs, trend review, alert thresholds, incident learning, and removal loop |111112**Documentation pruning pattern:** when prose documentation repeats behavior,113rules, setup, policy, or architecture that is already enforced or derivable114from code, config, tests, schemas, generated output, CI, policy-as-code, or115architecture-as-code, do not create a second source of truth. Verify the116executable source covers the same scope, then replace the prose duplicate with117the smallest useful note: why it exists, who owns it, where the executable source118lives, and which external constraint or trade-off is not visible from the code.119120When the move concerns deployment safety, apply `ci-cd-reliability-architecture`.121When the move concerns check placement, apply `defect-shift-left`. When the122move concerns duplicated custom implementation, apply `bring-down`.123124---125126## 5. Anti-Patterns127128| Anti-pattern | Correction |129| ------------ | ---------- |130| Automating an undocumented process | Document and standardize first |131| Platform team as ticket queue | Push to guardrailed self-service |132| Self-service without policy or rollback | Add the full guardrail set (Directive 5) |133| Dashboard called improvement | Define threshold, review cadence, and action |134| Tool adoption treated as maturity | Score the operational outcome, not the product installed |135| Golden path with no adoption signal | Measure usage, escape hatches, and support load |136| Manual approval called governance | Replace with policy-as-code where technically possible |137| Keeping manual duplicate forever | Retire same-scope duplicate after proof |138| Prose repeats an executable source of truth | Keep intent/rationale/ownership/link; delete the repeated mechanics |139140---141142## 6. Output Contract143144Emit results in this shape:145146```147Scope: <product/repo/platform/team/environment/time window>148Mode: Assessment | Improvement | Roadmap149Decision: Keep manual | Delete | Document (→1) | Standardize (→2) | Platformize (→3) | Self-service (→4) | Adaptive (→5)150Summary: <2-4 sentences: main toil source, best next push, key risk>151Verification: <metrics, logs, workflow search, runbook check, or Not run + reason>152153Work map:154| Work item | Current rank | Target rank | Distance | Evidence | Decision | Confidence | Next action |155| --------- | ------------ | ----------- | -------- | -------- | -------- | ---------- | ----------- |156157Priorities:158| Rank | Work item | Why now | Push-out move | Validation | Duplicate to retire |159| ---- | --------- | ------- | ------------- | ---------- | ------------------- |160161Gaps:162<Missing evidence, unknown ownership, absent metrics, excluded work, or risks>163```164165---166167## 7. See Also168169- **`defect-shift-left`** - move defect detection earlier.170- **`bring-down`** - move bespoke code down into reusable capability.171- **`system-optimization`** - bottleneck and waste analysis before improvement.172- **`ci-cd-reliability-architecture`** - pipeline safety and deployment reliability patterns.173- **`continuous-improvement`** - promotion of recurring findings into skills, checks, or templates.
l-gevity