Find the Toil: The Required Work Discovery Method

This is Part 1 of the Toil Audit series, on using toil to decide where AI should go first.

The Wrong Question Produces a Wish List

Ask a room full of employees what parts of their job could be automated, and you'll get a list. It won't be a bad list. People are usually right about what feels tedious. But it will be a personal list, shaped by what each person happens to find annoying, what they've read about recently, and what a colleague mentioned last week. Ask ten people and you'll get ten mostly different answers, because "what could be automated" is really asking "what do you personally dislike," and personal dislikes don't cluster the way real business problems do.

A lot of stalled AI initiatives start right here. Leadership collects the wish list, picks the loudest or most visible item, automates it, and finds the impact smaller than expected. The task they automated was never the highest-leverage target. It was just the most mentioned one.

A Different Question: What Does the Job Require?

Justin Watt, co-founder and CEO of the workflow automation company Switchboard, offered a sharper question on a recent episode of the Using AI at Work podcast. Don't ask what could be automated. Ask this instead:

What does your job require, the work the business depends on you doing, that you would stop doing tomorrow if you could?

The shift is small in wording and large in effect. "What could be automated" invites speculation about technology. "What does your job require that you'd stop doing" invites an honest inventory of obligation: work that exists not because anyone enjoys it, but because the business needs it done and someone has to do it.

Put that question to a broad cross-section of people across different functions, and pay attention to what repeats. Any single answer sounds like a personal complaint. Across enough conversations spanning different roles and departments, a handful of required-but-unwanted tasks keep coming back.

Why Repetition Is the Signal

One person complaining about a tedious task tells you almost nothing. It might be a real problem. It might be one person's low tolerance for work everyone else handles fine. A single data point can't tell you which.

Several people, independently, naming the same kind of required work is a different kind of evidence. Reconciling data by hand. Chasing an approval through three inboxes. Re-entering information into a second system because the first one doesn't talk to it. When people in different roles describe that work in their own words, the task isn't personal. It's systemic: built into how the organization operates, and hit by anyone whose job touches that part of the process, whatever their tolerance for tedium.

That pattern is what this series means by toil. Not anything boring, but required, repetitive, unwanted work that shows up across people rather than as one person's complaint.

Google's Site Reliability Engineering practice has a formal version of the same idea. It defines toil as work that's manual, repetitive, automatable, tactical, devoid of enduring value, and that grows linearly as the service it supports grows. SRE teams measure toil and work it down instead of accepting it as the cost of doing business. The interview method brings that discipline to the rest of the company. Sales, finance, and HR all have their own toil. They've just never had a name for it.

What This Method Does and Doesn't Tell You

A toil-discovery process tells you where the systemic pain is: which required tasks are most widely and consistently felt as a burden across the organization. It doesn't tell you which one to automate first, what has to be in place to automate it successfully, or how to sequence the rollout so the first attempt builds momentum instead of stalling.

That's deliberate. Discovery and prioritization are different problems, and mixing them up is part of why so many AI initiatives pick the wrong starting point, usually the most visible toil rather than the most automatable. The next post in this series, Map the Handoffs, covers what has to be true about a piece of toil before it's ready to automate (clean handoffs, usable data, correct permissions), no matter how many people named it in the interviews.

Getting Started Without a Formal Interview Program

Not every organization has the bandwidth for a full round of structured interviews before taking a first step, and that's a reasonable constraint. A smaller version still works. Pick ten to fifteen people across at least three functions, and keep each conversation short:

1. Ask the core question, word for word: "What does your job require, the work the business depends on you doing, that you would stop doing tomorrow if you could?" Resist rewording it into "what would you automate?" The wording is the method.
2. Ask how often it comes up. Daily, weekly, at month-end? Frequency separates a recurring drain from an occasional annoyance.
3. Ask what breaks if it doesn't get done. This confirms the work is genuinely required and not just habit.

Then tally the answers by kind of task, not by person. Three people describing "fixing the CRM export," "cleaning up the pipeline report," and "re-keying deals into the forecast sheet" are naming one piece of toil, not three. Look for the categories that show up across functions, not the most dramatic single answer.

The signal will be weaker than a full, company-wide pass. It will still be a sharper, more defensible starting point than a general "what should we automate" brainstorm, because it asks about obligation instead of preference.

Whichever version you run, the move is the same: stop asking people what they wish a machine would do. Ask what the business can't run without, and listen for the answers that repeat.

Subscribe to get the rest of this series as it publishes: mapping the handoffs, prioritizing the toil map, and the SRE concept every business leader should know.

This article was drafted with AI assistance and reviewed and edited by Matt before publishing.

About the Author: Matt Shirel writes Praxis CTO, exploring what real technology leadership looks like for growing companies that have outgrown ad hoc decision-making. He brings over 20 years in enterprise IT — spanning infrastructure architecture, cloud strategy, and technology budget ownership — and works hands-on in applied AI, building multi-agent and RAG workflows with tools like n8n and AI coding agents. This discovery method, asking what the job requires rather than what could be automated, is the one he reaches for before recommending any AI initiative, because a strong pattern across interviews beats a single confident opinion every time.