Before you build anything, find out which recurring tasks should not exist at all. Most teams skip this. It is why their automations feel as heavy as the processes they replaced.
Most companies that automate still feel like they are running the same heavy processes. Just faster.
Because they are.
They automated everything. Including the work that should have been deleted. The result is an efficient system doing things that should not be done at all. The effort that went into those tasks did not transfer to something valuable. It was preserved.
Before any automation begins, apply one test to every recurring task in the process.
For every report, every dashboard update, every weekly data pull, every meeting output, every file that gets generated, ask: if this had stopped six months ago, would anyone have noticed?
Not would it have been inconvenient. Not would someone have had to ask for it. Would anyone, client, colleague, manager, have actually noticed it was missing?
Three outcomes:
No: delete it immediately.
Maybe, put it on a two-week watch list. Run the process as normal but do not send or publish the output. See if anyone asks for it. If nobody does in two weeks, delete it.
Yes, a client would have called, it stays.
That test sounds simple. The results are not.
In most engagements, 30 to 50 percent of recurring tasks fail the test.
Work done carefully. Done consistently. Done every week by capable people who believed it mattered.
Some recurring work will have been generated by a project that ended 18 months ago, and continued because nobody cancelled it. Some will have been started by a previous team member, and the current team has been maintaining it without knowing who it was originally for. Some will be a report that a manager once asked for during a difficult quarter, never cancelled, and has not looked at since.
Here is what gets found: the 12-slide weekly report that goes to a distribution list of 14 people, none of whom reference it in any decision. The dashboard that was built for a product launch, still updated every Monday, for a product that launched and stabilised two years ago. The data reconciliation that runs between two systems, because nobody ever connected the integration that would have made it automatic. The approval step that was added during a compliance review, never removed, and now sits in the middle of a process that no longer requires it.
The emotion when this lands is not relief.
It is something closer to grief. For the hours spent. For the care taken. For the belief that it mattered.
The team realises they have been spending significant time, sometimes hours per week, sometimes more, on work that no longer served any purpose. That realisation is heavy before it becomes useful.
Name this directly. Do not rush past it. It is real, and it is normal. Most capable teams that run this exercise go through this moment. The teams that go through it come out the other side with a clearer picture of where the real work is than any process map could give them.
What replaces the grief is not relief, exactly, but precision. The team stops defending the process. They can see it clearly, what it actually costs, what it actually produces, what would happen if each part of it disappeared. That clarity is the foundation everything else gets built on.
What you remove matters more than what you automate.
If the build starts without The Kill List, the team is designing automation for a process that still contains unnecessary work. The automation inherits that weight. The new system is faster. But it is still doing the wrong things.
Teams that skip this step typically build systems that feel almost as heavy as the ones they replaced. The speed improvement is real. The sense of relief is not. The team keeps feeling like the process is burdensome because parts of it still are, they just run faster now.
The other cost is financial. Every automated task has a build cost. Automating a task that should not exist means paying to build something that should have been deleted.
The Kill List is not a survey. Not a workshop exercise. Not an audit spreadsheet completed remotely.
Sit with the person who runs each recurring task. Walk through the last three months. For each output: who asked for this last month? What would have happened if it was not delivered? Can you show me a decision that referenced it?
The questions are simple. The answers take courage to give honestly. Most people, when asked directly, know which of their recurring tasks are real and which ones they have been producing out of momentum.
Take half a day per process. Most engagements have two or three core processes. A full Kill List audit takes one to two days of that kind of conversation.
What comes out of it is smaller than what went in. That is the point.
Once the unnecessary work is gone, what remains is the actual process: the tasks that genuinely exist because someone would notice if they stopped.
That process is smaller than most teams expected going in. The bottlenecks are clearer. The automation scope drops. The build time shortens. The result is more likely to hold because it was built on what is real.
The Kill List is one of three audit tools used before any build begins. The others, The Shadow and The Leak Finder, map what actually happens at the desk and where information is leaking time. Together they produce the only reliable foundation for a build that works.
The full audit methodology, The Shadow, The Leak Finder, and The Kill List, is in the implementation guide.
| Answer | Action |
|---|---|
| No | Delete immediately. Do not automate. Do not discuss. |
| Maybe | Two-week watch list. Run the process but withhold the output. If nobody asks, delete it. |
| Yes, client would call | It stays. Map it for automation only after the other two categories are cleared. |
In most engagements, 30 to 50 percent of recurring tasks fall into the first two categories. The build that follows is smaller, faster, and more likely to hold.
Priyankka Wadhwa is the Founder of Let's Execute AI. Her practice works with companies in the United States and India, not as advisors, but as the team that maps, builds, and hands over. She does not deliver strategy. She delivers working systems and the people who can run them.
Two hours. The audit tools. A clear list of what to build, and what to remove.
Book the Diagnostic →