You automated a mess. Now it's a fast mess.

Yesterday, Perry Coghlan posted something that stopped my scroll. Some context on why it stopped me: Perry and his wife run one of the most successful retail arbitrage reselling businesses in existence, at last look approaching ten million dollars a year in Amazon sales. He's also a member of this community, and he was prepping a talk for a seller retreat when he wrote this:

"One of the best ways to find that 90 percent is to look for where the work piles/stacks up. When you find a pile you found a bottleneck or lack of flow. Fix the flow by eliminating the non-value adding activities and you'll suddenly find you're more efficient."

I quoted it because it names a pattern I keep seeing in small businesses trying to adopt AI. And then Perry landed the second half:

"A guiding principle in lean management is to fix the process FIRST then automate. If you automate something first you're just making a bad/wasteful process easier without fixing the root cause."

When someone running an eight-figure operation tells you where the money hides, you listen. I've watched clients ignore this exact principle. I've ignored it myself, and I'll show you the receipts below. So this issue is the whole arc: the problem, how to spot it in your own shop, and how to fix it.

The problem

An operator gets an AI subscription. Genuine excitement, genuine skill-building. Then they spend hours building things that are neat but don't move the needle. A dashboard nobody checks twice. A summarizer for a report nobody reads. A chatbot answering questions nobody asks.

That's the visible version. The subtler, more expensive version: they automate a real process, but a broken one. The intake form that asks for information twice now gets filled by AI twice. The approval chain with two pointless sign-offs now routes at machine speed through both. Nothing got better. The waste just got faster, and now it's wrapped in software you maintain.

Automation is an amplifier. Point it at a good process and you multiply value. Point it at a mess and you multiply mess, with a subscription fee on top. The AI didn't fail. The aim did.

Why does this happen to smart people? Because building with AI is fun, and fixing processes is not. Automating feels like progress: there's a demo at the end. Deleting two steps from your intake flow has no demo. It's just Tuesday, but quieter. Our brains chase the demo.

Why big companies dodge this one (and you can't)

I spent two decades in enterprise IT before running small businesses, and here's what struck me when Perry invoked lean management: big companies pay entire teams to do what he described in two sentences.

Enterprises institutionalize the pile-hunt. They run continuous improvement programs, process excellence teams, operational audits. Some go full kaizen or Six Sigma: dedicated people whose entire job is walking the operation, finding where work stacks up, and killing wasteful steps before anyone automates anything. When a Fortune 500 rolls out automation, there's usually a process owner somewhere who had to sign off that the process deserved automating in the first place. It doesn't always work (I watched plenty of expensive software get bought to paper over processes nobody fixed), but the immune system exists. Someone is paid to notice the pile.

Small businesses have no such immune system. There is no process excellence team. There's you, at 9pm, with an AI subscription and a feeling that you should be "doing something with AI." Nobody upstream asks whether the process you're about to automate deserves to exist. That's the compounding problem: we have the same broken-process risk as the enterprise, more tool access than ever, and zero institutional guardrails between the two.

Here's the reframe that matters: those enterprise programs are mostly discipline, not headcount. A kaizen program at its core is somebody regularly walking the floor asking "why is this pile here?" You can't hire a continuous improvement team. You can absolutely steal their one move. The rest of this issue is that move, sized for a business where the process excellence team is you and maybe your spouse.

Battle scars

Theory is cheap, so here's what this pattern has personally cost me. My agent and I run automations across three businesses, and we've earned every one of these the hard way.

The automation that "ran" for eight days without running. One of my nightly evaluation pipelines, the one that scores buying opportunities for my resale business, went dark for eight days. The scheduler showed green every night. Green meant "the job completed a turn," not "the job did the work." A config change upstream had quietly disqualified the run, and since "ran and found nothing" looks identical to "never ran," nobody noticed. Eight days of opportunities, unscored. The lesson we wrote down afterward: wired and producing are different claims. Now our systems answer two separate questions, "did it run?" and "what did it produce?", because conflating them is how you lose a week without feeling it.

The worker that kept running last month's code. Another pipeline kept misbehaving after we'd already fixed the bug. Turns out a long-lived background worker had been alive for nineteen days, happily executing the old code from memory while the fixed version sat on disk. We'd automated, felt done, moved on. The automation kept sprinting in the wrong direction for three weeks. Fast mess, textbook edition.

The pipeline I rebuilt instead of copying. Here's the one we got right, eventually. My land services company had a lead-management pipeline built on my previous AI stack. It worked, mostly, held together with notification sprawl and scripts nobody wanted to touch. When we moved it to the new system, the tempting move was to copy the plumbing over. Instead we sat down and separated what the old system knew (why the SMS quiet window exists, which follow-up cadence customers tolerate, what language converts) from what it merely was: schemas, scripts, duct tape. We kept the knowledge and rebuilt the flow clean. The rule that came out of it: prior builds are insight, not substrate. The lessons transfer. The plumbing doesn't have to.

Three scars, one shape. Every one of them is Perry's point wearing different clothes. The process, or the proof the process worked, wasn't fixed first. The automation just made the gap harder to see.

How to identify it

Perry's diagnostic is the best one I know, and it costs nothing: look for the piles.

Walk your operation, physically or in your software, and find where work stacks up. Piles are honest. They don't care about your org chart or your tooling story. Where things accumulate, flow died:

• Unanswered messages pooling in an inbox
• Orders waiting on a once-a-day batch step someone runs "when they get to it"
• Boxes staged by the door because labeling happens in another room
• Quotes sitting in "draft" because approval lives in someone's head
• A spreadsheet tab named "TO PROCESS" with 400 rows

Now the AI-specific test. For anything you've automated or are about to, ask two questions:

1. Does this feed a pile or drain one? If your automation produces output that lands in a queue a human still slogs through, you built a faster pile-maker.
2. Would I design this process this way from scratch? If the honest answer is "no, but that's how we've always done it," you're about to pour concrete over a bad floor plan.

And a tell from my own screen time: if you've spent more hours building the automation than the process costs you per month, you didn't automate. You went on a hobby retreat with extra steps. I say this with love, as a man who once did exactly that.

How to fix it

The sequence is the fix. Lean people have said it for decades; AI just raised the price of ignoring it.

1. Find the pile. Biggest one first. Not the most annoying process, not the most fun to automate. The one where the most value sits waiting.

2. Fix the flow before you write a single prompt. Every step in that process gets one question: does this add value a customer would pay for? Kill duplicated data entry, approvals that never say no, handoffs that exist because of who used to work there. This is subtraction, not addition. Most processes lose a third of their steps and nobody misses them.

3. Then automate what's left. Now the AI has a clean target. This is where it shines: the repetitive, well-defined work that survived your subtraction pass. Automating a clean three-step process is a weekend. Automating a dirty nine-step process is a career.

4. Give every automation a heartbeat. My eight-day blackout rule. Any system that's supposed to produce output on a schedule needs a check that answers "did it run?" separately from "what did it produce?" This can be as dumb as a daily line in a log you actually look at, or a calendar reminder to check the output exists. Silence must be distinguishable from success. If absence of output looks like a quiet day, you will eventually lose a week to it. I'm proof.

5. Watch where the pile moves. Fixing one bottleneck reveals the next. That's normal, that's the game. The pile relocates; you follow it.

Do this today, not someday

The 30-minute version, in order:

• (10 min) Write down your three biggest piles. Physical or digital. No fixing, just naming.
• (10 min) For the biggest one, list every step between "work arrives" and "work done." Mark each step: value, or habit?
• (5 min) Pick the one habit-step you can delete this week without asking anyone's permission.
• (5 min) For anything already automated: check it actually ran in the last 48 hours. Don't check the dashboard that says it's scheduled. Check the output.

Delete the step. Verify the output. Then decide what AI gets pointed at next. The uncomfortable summary: the best AI move in your business this quarter might be deleting four process steps and automating nothing. The subscription can wait. The pile can't.

Where's the biggest pile in your operation right now? Hit reply and tell me. I read every one, and the best answer might become a future issue.

— Justin