Every engineering team I've led had work that nobody chose. It arrived one request at a time: a weekly report someone asked for once, an approval step added after one bad incident, a manual check that outlived the system it protected. Each item made sense when it started. Together, they quietly filled the week.

AI makes it tempting to keep all of it and just run it faster. A script fills in the report. A bot answers the ticket. An agent clicks through the approval. The work looks lighter, but nothing has changed about whether it was needed.

I think of this as the difference between toil and value. Toil is work that is manual, repetitive, and grows with volume without making the product or the team any better. Value is work that changes an outcome for a customer, a system, or a decision. Automating toil can be useful. Removing it is usually better.

Here is the five-step order I use with my teams before we automate anything.

Start with one plain question: if this task stopped tomorrow, who would notice, and what would go wrong?

For example, take a weekly status report that each team lead fills in for leadership. Ask who reads it and what decisions it drives. Sometimes the honest answer is that one person skims it, and the real need is to hear early when a delivery is at risk. That need can be met with a short risk note when something changes, instead of a full report every week whether anything changed or not.

The same question works for operations. For example, an on-call engineer might restart the same service every few nights because a known alert fires. Automating the restart feels like progress. But the work exists only because the underlying fault was never fixed. The better outcome is a service that doesn't need restarting.

Asking what the work is for isn't about blaming whoever set it up. Most processes were reasonable answers to a past problem. The point is to check whether that problem still exists in the same form.

Tip: For any task you want to automate, write one sentence: "This exists so that ___." If you can't fill the blank, or nobody would miss the result, that task is a candidate to stop, not to automate.

Once you know what a task is for, sort the work around it. In my teams we use a simple test. A task leans toward toil if it is:

For example, in an IT service management setup, resetting access for the same group of users every month because their permissions expire on a fixed schedule ticks most of those boxes. Reviewing whether a new access request should be approved at all does not. It needs judgment and context.

This sort matters because it tells you where AI belongs. Judgment-heavy work, like a design review or a hard staffing decision, usually benefits from AI as an assistant, not a replacement. Toil is where you should first ask whether the task can disappear, and only then whether it can be automated.

Tip: Run the five-point toil test on your team's top ten recurring tasks. Anything that scores four or five is worth a conversation about removing it before anyone writes a script for it.

When a task fails the "what is it for" question or scores high on toil, you have three options before automation: cut it, merge it, or shrink it.

Cut means stop doing it. For example, an approval step for low-risk configuration changes that every reviewer approves without comments isn't adding control. It is adding waiting. Replacing it with clear guardrails and an audit trail often protects the system better than a rubber stamp.

Merge means combining tasks that serve the same outcome. For example, three dashboards owned by three teams that all track the same service health can become one shared view with one owner.

Shrink means keeping the outcome but reducing the effort. For example, a 40-field incident form can often become five fields that capture what people actually use in the review, with the rest filled in later only when needed.

The hardest part is usually not technical. It's agreeing that something can stop. I've found it helps to run a short trial: pause the task for two or four weeks, tell the people who might depend on it, and see who asks for it back. If nobody does, you have your answer.

Tip: Pick one task to pause for two weeks instead of automating it. Announce the pause, name who to contact if it's missed, and review what you learned at the end.

Some work survives every question. It serves a clear outcome, it can't be merged away, and it is already as small as it reasonably gets. That is the work worth automating, and AI can help a lot with it.

For example, once a team has cut its ticket categories down to the ones people really use, AI can route and summarize incoming tickets well, because the categories now mean something. Before that cleanup, the same automation would only have sorted tickets into buckets nobody trusted.

The order matters. Automating first locks in the current process, including its waste, and makes it harder to change later because now there is code, owners and alerts around it. Simplifying first means the automation is smaller, easier to test, and easier to remove when the need changes again.

Keep a clear check on whatever you automate. Decide upfront how you'll know it is working: fewer reopened tickets, fewer manual follow-ups, or less time spent by a named role. If you can't measure it, you can't tell automation from extra moving parts.

Tip: Before approving any automation, ask for two things: the outcome it serves and the measure that will show it's working. If either is missing, simplify the work first.

One cleanup won't hold on its own. New requests keep arriving, and each new tool brings new chores. Questioning the work has to become a normal part of how the team runs.

A few practices have worked for me as a manager and director. Give engineers explicit permission to challenge a process, and thank them when they do, even if the answer is to keep it. Add one standing question to retrospectives: "What did we do this sprint that we shouldn't have to do next sprint?" Review recurring meetings and reports once a quarter, the same way you'd review cloud costs.

It also helps to make toil visible. For example, a platform team can tag tickets as toil or project work for a month. The point isn't precision. It's giving the team a shared picture of where its time goes, so the conversation is about data instead of feelings.

As a leader, your part is to protect the time this takes and to accept that some things will be stopped that you once asked for. When the team sees you cut your own pet report, they'll believe the invitation is real.

Tip: Add "What should we stop doing?" to your next retrospective agenda, and commit to acting on at least one answer before the following one.

AI is a powerful way to take load off a team, but it doesn't choose what the load should be. That is still a leadership job.

The order is simple: ask what the work is for, separate toil from value, cut, merge or shrink what doesn't earn its place, and then automate what remains with a clear measure of success. Each step makes the next one easier and cheaper.

You don't need a big program to start. One report, one approval, one recurring alert is enough to show your team that the goal isn't to do more work faster. It's to do the right work, and less of it.

Tip: Judge your automation work by the hours your team gets back for meaningful work, not by the number of tasks you've automated. Sometimes the best automation is the task you deleted.

Hit reply and tell me: what's one task your team stopped doing, instead of automating it? I read every answer.

One more from today's sponsor, which helps keep Tiny Big Spark free:

Keep going, one small spark at a time.

Erwin