What survived is the system


The Loop

Every week, close one loop.
Fix one friction. Take back a bit of time.


You have a system that stop being used. Everyone does.

A handoff checklist that ran for a quarter and then, sometime over the summer, just stopped being used. Nobody killed it. Nobody sent an email to stop using it. The form is still sitting right there.

You notice it the way everyone notices it. Something goes wrong that the checklist was built to catch, and someone says, wait, didn't we used to do this?

And then comes the relaunch. Ten minutes at Monday's meeting. A fresh copy of the doc with today's date on top. "We're going back to this." Heads nod. It get used for three weeks. Then it falls away again, faster this time, because now it's a thing that gets pushed to the side.

I've watched that cycle enough times that I stopped believing the problem was discipline.

Here's what I look at instead. Pull up the checklist. Count the lines people are still filling in. On an eleven-line handoff form it's usually two to three. Who's covering. Where the ticket is. Nobody is enforcing those two. People kept them because the next team asks for them when they're missing.

That's your system. Those two lines. The other nine were fluff, and fluff drifts away on its own.

So don't start from the eleven. Start from the two.

Say the two lines are the standard now. It changes nothing, they're already doing it, and it turns a slip into a decision.

Then find the first line that was fluff. Not who dropped it. Which one, and why. It's almost always one of two things. Nobody could say what the line was for, or it lived in a document instead of in the ticket where the handoff actually happens. Those are two ways a step dies. Attach the reason, or move the step. Don't put it back bare.

Put that one line back. One. Inside the tool the team already uses. And give it to someone who didn't build the original, because the original author looks at that form and sees eleven lines. A new owner sees one.

Then wait. Two weeks. If the line holds, add the next. If it slips, you moved it to the wrong place.

Notice there's no meeting in any of that. The system comes back the way it left. One line at a time. Most of the team won't even register it.

Now it's your turn:

Pick one system you already know slipped. Write down what's still running. It's a shorter list than you want it to be, and it's the only honest place to start.

One ask: Hit reply and tell me the one step your team kept doing after the rest fell away. I read every one.

- Jonathan

​Unsubscribe · Preferences · Schedule A Clarity Call​

600 1st Ave, Ste 330 PMB 92768, Seattle, WA 98104-2246

The Automation Loop

A short Tuesday brief on fixing ops chaos, so you're not the system. Built from real operator failures. Subscribe now to reclaim your most precious asset - time!

Read more from The Automation Loop

The Loop Every week, close one loop.Fix one friction. Take back a bit of time. Most teams don't lose the thing that worked when they grow. They bury it. Three people ran intake on instinct. One person looked at a request and knew, in about four seconds, what it was and how fast it needed to move. No form. No queue. Just someone who'd seen enough of these to know. Then the team grew to twenty, but instinct doesn't scale on its own. So somebody wrote it down. Forty fields. Every exception from...

The Loop Every week, close one loop.Fix one friction. Take back a bit of time. I've been thinking about the teams whose tools actually work. Not the teams with the best tools. The ones where the tool just runs, without anyone maintaining it. They share something you can see right away. They didn't buy the tool to fix the system. They built the system first. Only then did they find a tool that fit it. That order matters more than the tool selection itself. Here's a concrete picture of what it...

The Loop Every week, close one loop.Fix one friction. Take back a bit of time. I've been thinking about the fixes that last. The ones a team keeps using six months later without anyone reminding them. They have one thing in common. They're simpler than the problem they solve. Not simpler to explain. Simpler to do. And that's harder to build than it sounds.Here's why. When you can finally see the whole problem, you want to cover all of it. Every case. Every exception. Every "but what about...