Part 6. The Pilot Nobody Notices: Rolling Out Your First Automation Without Calling It One
Part 6 of 10 in a series on affordable automation for small local governments.
You picked your boring project. Congratulations—that was the hard part. If you followed Post 5, nobody in your building is currently excited about it, which means you did it correctly. Now comes the part where a surprising number of small governments manage to sabotage a perfectly good pilot before it produces a single result: the rollout.
Here is what you have to avoid: Someone announces, at a staff meeting or in a memo with a subject line like “Exciting New Automation Initiative,” that the town is implementing automation. People who were not consulted immediately have opinions. The employee whose task is being changed hears about it secondhand and assumes, reasonably, that this is the first step toward not needing that employee. IT gets nervous. Someone asks if this was budgeted. By the time the actual tool goes live, it is carrying the weight of an announcement it never needed to have, and every hiccup in week one gets read as evidence that the whole idea was a mistake.
The fix is almost insultingly simple: stop calling it automation.
Give It a Boring Name, Because It Is a Boring Change
Nobody needs to know that the permit-status emails are now triggered by a workflow rule instead of typed by hand. What they need to know is that permit-status emails go out, which they might reasonably experience as a minor process update rather than a strategic initiative. Frame the rollout in terms of the task, not the technology. “We’re changing how status updates go out” invites a shrug. “We’re implementing an automation pilot” invites a committee. You want the shrug.
This isn’t about hiding anything. If someone asks directly what changed, tell them plainly. It’s about not manufacturing a reason for people to be anxious about a task that, before you touched it, nobody found interesting enough to be anxious about in the first place.
Tell the People Whose Day Actually Changes; Skip Everyone Else
There is a specific, short list of people who need to know before launch: whoever currently does the task by hand, whoever supervises that person, and whoever would field a complaint if something went sideways. That's usually three to five people in a town this size. Everyone else finds out by noticing that something got a little smoother, if they notice at all.
This matters more than it sounds like it should, because the person doing the task by hand is the one who can quietly kill your pilot in week one if they feel ambushed by it. Talk to them first, and talk to them like colleagues, not test subjects. Ask what currently goes wrong with the manual version. Tell them what the new version does and, just as importantly, what it doesn’t do. Automation that quietly fails is far more damaging to trust than automation that was honestly described as imperfect from the start.
Build In the Two Weeks When It’s Allowed to Be a Little Broken
Every automation, even a boring, well-chosen one, has a rough patch: an edge case nobody anticipated, a field that doesn’t map the way you thought, or a resident whose situation doesn’t fit the template. Decide in advance that the first two weeks belong to that rough patch and that the manual process stays alive and ready during that window as a safety net, not a backup plan you hope you don’t need.
Practically, this means the person who used to do the task manually keeps half an eye on the automated version’s output for those two weeks, catching what it misses before a resident does. It means you don’t schedule the rollout the week before a council meeting where you’d want to brag about it. And it means that when something does go wrong (something always does), the response is “we caught that; here’s the fix,” not a scramble to explain why the automation initiative already has a bug.
The Payoff: The Best Pilots Are the Ones Nobody Can Quite Date
Ask your staff in three months when the new process started, and the good outcome is that nobody remembers precisely. It just became how things are done, sometime back there, without a ribbon-cutting. That fuzziness is not a failure of documentation. It is the actual goal. A pilot that lands so smoothly it doesn’t generate a memorable “before and after” story is a pilot that worked. The ones people can date exactly are usually the ones that broke publicly first.
This is also, quietly, how you build the political capital for the next one. Nobody argues with expanding “the thing we already do,” and by the time you're ready to automate something slightly more visible, you'll have a track record instead of a pitch.
Your Homework Before the Next Post
Write down, for the project you picked in Post 5, exactly three names: the person whose task changes, their supervisor, and whoever handles complaints if it goes wrong. Draft the one sentence you’ll say to each of them before launch. This is not an announcement; it’s just a heads-up. If you can’t explain it in one sentence, the project is bigger than the “boring” test from Post 5 allowed, and it’s worth going back and picking a smaller one.
That's the whole rollout plan. It fits in a paragraph because it's supposed to.
Next up: Proving It Worked Without Bragging About It—the quiet, honest way to measure whether your pilot actually did anything before you take it to the council.
About the Author: Layne Thompson is Senior Vice President at JMA Resources, Inc., where he leads Growth, Innovation, Research, and Development initiatives. With more than 30 years of experience spanning military service, federal leadership, private industry, and local government, he is passionate about helping communities implement practical, cost-effective technology solutions that deliver real results.
Layne previously served as Borough Manager for the Borough of Mechanicsburg, Pennsylvania, from December 2022 through December 2025.
