Why does this still require me?

The trigger

Repeatedly making the same decision, answering the same question, collecting the same data, producing the same output, or solving the same class of problem is a signal. The useful question is no longer “How can I do this faster?” It is “Why does this still require me?”

Choose the right mechanism

Automation is one response, but not the only one. Some work needs a reusable tool. Some needs a clear owner and delegated decision rights. Some benefits from AI assistance. Some should remain human because the judgment, risk, or context cannot be reduced safely.

Use an escalation ladder

• Document it when the work is rare but the context is easy to lose.
• Automate it when inputs and decisions are stable enough to encode safely.
• Make it self-service when other people repeatedly wait for the same execution.
• Move it into a platform when multiple teams need the same dependable capability, ownership, and feedback loop.

Not every documented task deserves automation, and not every automation deserves a platform. Move up the ladder only when repetition, risk, and shared demand justify the additional ownership.

Design for absence

A high-leverage system should continue producing a useful outcome when its original author steps away. That requires more than code: explicit inputs, visible state, understandable failure modes, and a path for exceptions that still need judgment.

A practical review

• Frequency: Does the same work recur often enough to justify a system?
• Variation: Which parts are stable, and which still require contextual judgment?
• Failure cost: What happens when the workflow is wrong, late, or unavailable?
• Ownership: Who can understand, operate, and improve it after the author steps away?
• Feedback: How will the system expose exceptions and show whether it remains useful?

The standard

Personal output is not the only measure of progress. A stronger measure is how much useful work continues without requiring the same person to repeat the same intervention.

Evidence boundary

This note documents my personal engineering heuristic, adapted from my public LinkedIn post. It is not a claim about a specific employer, system, adoption level, or measured outcome.