The playbook is short: automate the task, keep the person, and count the win in hours handed back to the team. Our standing rule is zero people replaced, and it means what it says. AI augments the team you have, and the roster on the last day of an engagement matches the roster on the first.
Leaders sometimes hear that as a values statement and brace for a talk about hearts and minds. It is a performance decision. The knowledge an automation project needs most lives with the people doing the work today, and they share it in proportion to how safe they feel. A guaranteed roster is what makes it safe to talk. Without one, the people who understand the work have every reason to stay vague, and the project proceeds on guesswork.
Why make zero people replaced a standing rule?
Because your people can tell the difference between a rule and a mood. A mood is what most organizations offer: reassuring noises at the kickoff, then a reorg months later that everyone quietly connects to the new software. Change with a clear shape is survivable. What corrodes candor is the stretch of uncertainty when nobody will say whether the software is aimed at a given job, and after one round of that, nobody brings you a use case again.
A rule behaves differently. It gets stated from the top and in writing, and it can be broken in public, which is what gives it weight. We ask leadership to say it before anyone sees a tool: nobody loses their seat because of what we build together. Target selection sharpens once aiming the software at a person is off the table. And what people tell you changes almost immediately, because a worried employee’s safest move is to stay quiet about how the work actually gets done.
How do you pick targets that free hours instead of cutting jobs?
Aim at the task layer. A job is a bundle of judgment calls, relationships, exception handling, and a thick layer of repetitive chores stapled to the bottom. Automation belongs on the staples, and the good targets there share a shape. They recur, they arrive in volume, a patient person could write their rules on one page, and the people doing them today would happily never do them again.
A claims team might hand an agent the first pass on incoming documents, the sorting and the data extraction, while adjusters keep every decision that touches a customer. An operations coordinator might stop retyping orders between two systems that have refused to speak to each other for years. Both of those are slices. Neither is a job. The hours come off the bottom of many roles at once, and no single role empties out. An automation that empties a role was scoped wrong, usually by someone who never asked what else that person does all day.
The reverse test matters too. Be wary of any candidate that is mostly judgment, and treat any business case that only closes when the team shrinks as a person mislabeled as a task. We do not scope those. Before committing to a target, picture the build running perfectly for a full quarter and look at whose hours came back. Recovered time belongs in a backlog that finally moves. Time that shows up as a colleague with an empty afternoon means the scope was wrong, and that is worth catching before anyone writes code.
How do you bring a worried team along?
State the rule first, then hand the microphone to the people closest to the work. They find the best use cases, because they know which numbers get typed twice and which approvals sit in an inbox for days while a customer waits. The announcement needs less production than most leaders assume. A short note from the most senior sponsor does more than a town hall, as long as it states the rule in one sentence and gives people a way to nominate their own drudge work.
Our training runs on the same premise. In a hands-on bootcamp, each team picks from a preset catalog and builds one working system end to end in their own AI accounts, then keeps it. Your people walk away with the machinery and with the confidence of having built it.
Two habits carry most of the weight from there. Publish where the freed hours go, so the team watches the backlog shrink and the deferred work finally gets attention. And give your loudest skeptic a standing invitation to read the agent logs. Skeptics tend to make the most thorough auditors, and a skeptic who reads the logs and comes around usually brings the rest of the team along.
What guardrails does an agent need?
An agent is software that takes actions, which is exactly why it gets a fence. The AI agents and assistants we build for a team all ship inside the same set of constraints:
- A written job description: what it may do, and what it must hand to a human.
- A named owner. Every agent answers to a person, and that person knows it.
- Approval gates on anything that leaves the building: outbound messages, payments, changes to a system of record, anything a customer might see.
- Logs a human reads on a schedule, whether or not anything looks wrong.
- A kill switch that does not require a ticket.
The fence is there for the failure modes, and routine work passes through it all day without slowing down. A narrow agent with a named owner earns a team’s trust faster than a clever one with a vague charter. Most agents start in draft mode, where they prepare the work and a person sends it. The owner widens one gate at a time and reads the logs before opening the next, so an agent’s reach grows only as fast as the evidence that it can handle more.
What does the business get for keeping everyone?
The error-catchers, mostly. Automated systems drift. A vendor changes an invoice layout, and an extraction that ran clean for months starts writing fiction. The person who keyed those invoices for years is the one who glances at the output and flags the wrong number before a customer ever sees it. That person is the smoke detector. Cutting the role leaves the stove running with no one watching it.
You also keep the pipeline. The first project buys credibility, and credibility buys the next round of use cases from people who now volunteer them. Teams that have watched a colleague get automated out of the building tend to stop volunteering, and every project after that pays the tax. There is a quieter compounding as well: the employee who understands both the old way and the new system becomes the natural owner of the next build and the person who trains whoever comes next.
Measured ROI stays simple under this rule. Baseline the hours a task takes before the build, measure them again after, and watch where the recovered time lands, usually in the backlog and the quality work that kept slipping. None of this is charity. A shop keeps its crew and sharpens its tools because that is what keeps output high, and the intact roster is what keeps the automation accurate after we leave and what surfaces the next use case worth building.
The rule costs nothing to say and very little to test. Bring one drudge-heavy task, and bring your most skeptical employee. The first call runs 30 minutes at no cost, and no one’s role is up for discussion.