The 20 percent automation cannot close is the part that pays you

Source: Dev.to

A reader asked the sharpest question I have seen this month:

What kind of problems fall into the 20 percent that still needs a senior?

Most automation pitches answer the opposite. They sell the 80 percent that was always going to work, and they stay quiet about the part that breaks careers.

So here is the honest answer, from the enterprise stacks I audit across DACH automation deployments.

The 80 percent is the easy promise. The 20 percent is the whole engagement.

What the 80 percent actually is

The 80 percent is the work that has a shape.

• A clear input, a known rule, a predictable output.
  Invoice in → line items out.
  Lead in → enrichment out.
  Ticket in → routed ticket out.

This work should be automated without apology. It is repetitive, well understood, and a human doing it by hand is waste.

If a vendor is still selling you the automation of the 80 percent as the hard part, they are selling you the easy thing at the price of the hard one.

What the 20 percent contains

The 20 percent is not a smaller version of the 80 percent. It is a different kind of problem. In every audit it breaks into four classes:

• Judgment under ambiguity – No rule exists because the situation is new. Someone must weigh trade‑offs that the system was never told about.
• Exceptions with real consequences – Edge cases that touch money, a regulator, or a customer relationship built over years.
• Context that lives in a head, not a database – The reason a client gets an exception, the history nobody wrote down, the tacit knowledge no field captures.
• Decisions that need a name on them – When it goes wrong, accountability must land on a person, not a workflow.

Each of these reports as a “normal task” to an automation, but none of them truly is.

Why teams automate the 20 percent anyway

The pressure is real, and I understand it.

The 80 percent is automated, the savings are visible, and the natural next ask is to push for the rest. The demo of the 20 percent always looks fine, because a demo runs the happy path, and the happy path is the part of the 20 percent that behaves like the 80 percent.

So the team ships it. Then a real exception arrives—the one with money on it—and the automation handles it with the same confidence it handled an invoice.

That is the moment a senior should have been holding the decision, and was not.

What that failure costs

• When the 80 percent fails, you lose developer hours.
• When the 20 percent fails, you lose the thing that does not come back on a retry: a regulated decision made without review, a key account handled like a routine ticket, a judgment call the system was never qualified to make, made at scale before anyone noticed.

The cost is not in the error count. It is in which errors they are.

The honest posture

• Automate the 80 percent ruthlessly. Free your seniors from it completely.
• Then do the harder work: find the boundary where the 20 percent begins, and build the stack so it calls a human at exactly that boundary, with the context already gathered and the decision framed.

The goal is not to automate the senior away. It is to make sure the senior is spent only on the 20 percent that is actually theirs, and is never bypassed on it.

A team that gets this right looks slower on the org chart and is far safer in production. A team that automates the 20 percent to look fully autonomous is one exception away from the incident that ends the project.

What this write‑up does not hand you

I run the boundary version of this in client engagements: pinpointing where the 20 percent starts in a given stack, forcing a workflow to recognise it has crossed into judgment territory, and escalating to the right senior with the right decision.

I am not pasting those details here, and the reason is honest. The boundary is specific to each company’s risk, and a copied recipe gives a team false confidence that it has drawn the line correctly when it has not.

Drawing that line wrong is the failure. The discipline is in drawing it right.

One question for you

Look at your own automation.

Find the place where it stops asking a human and starts deciding alone, and ask whether that line was drawn on purpose or by accident.

If it was drawn by accident, tell me in the comments what kind of decision sits on the wrong side of it. I will reply with the question I would ask first to find out whether it belongs in your 80 percent or your 20 percent.