In a previous post I told you to draw the 2x2, find the small automation hiding in your top left corner, and build that one. This one is about the month after it ships, because that is where most first wins die.
If you missed it: You Can't Start on Third Base — on why the right AI move for most companies is a single small win, and a framework for finding the right one.
How a First Win Usually Dies
It works on day one. Everyone is pleased. Then an edge case shows up in week two and the output looks wrong once. The person it was helping stops trusting it, goes back to doing the work by hand, and does not tell anyone — because reverting to the old way never feels like a decision worth announcing. Three months later the automation is still technically running. Nobody is using it. Nobody said so out loud.
Nothing failed, exactly. It was abandoned, quietly, and the difference matters because the fix is different. Failure is an engineering problem. Abandonment is an ownership problem.
Abandonment Is an Ownership Problem
An automation is software, and software needs an owner. Not a team, a name. When the first break happens — and it will — the question is whether it gets fixed in a day or sits for three weeks. That first break is where trust is won or lost. Fix it fast and people learn the thing is reliable and looked after. Let it sit and everyone quietly concludes it was a toy, and you do not just lose this automation. You poison the well for the next one.
The two automations we built internally — the meeting transcripts and the hiring screener — are both still alive. The honest reason is not that we built them perfectly. It is that each one has a named owner, and when something looked off, fixing it was somebody's actual job that week.
The Playbook for the Month After It Ships
Give it one named owner. The person whose time it saves is usually the right answer, because they notice problems first and they have the most to lose if it dies.
Write the number down. Track the hours it saves for the first month — roughly is fine. You need it to know whether the win is real, and you will need it again when you make the case for the second one.
Treat the first three breaks as urgent. Whatever your normal priority process is, the early failures of a new automation jump the line. You are not fixing a bug. You are establishing whether your company believes in this stuff.
Tell the company. A working automation nobody hears about earns you nothing. Once it has held up for a month, share the number at your all-hands or in whatever channel everyone actually reads. The second automation gets approved a lot faster when everyone watched the first one work.
Know When to Kill One
Not every first win should survive. If the automation gets a real owner and a fair month and people still route around it, kill it, and say why. Take the lesson about why it did not fit and move on. A drawer full of half-running automations nobody trusts is worse than none, because it teaches your team that this stuff does not work. Your team will trust the next one more because they watched you kill a bad one.
Nothing in this playbook requires hiring anyone. It takes a name, a number, and a serious first month.
The Exercise This Week
List every automation, script, and integration already running in your company — including the ones from before AI was a headline. Then ask two questions of each one.
Does it have a named owner? If not and nobody uses it — kill it this week.
Is it useful but orphaned? Give it a name.
What is running in your company right now that nobody owns? That is the gap worth fixing before you build anything new.
Sep 2, 2026
AI
AI
AI