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 looks like when the order is wrong.
A team buys a project management tool to fix their handoff problem.
They stand it up in a week. Big launch. Training sessions. Everyone's in the tool.
Six months later, two things are now true.
First: they have a project management tool.
Second: they still have the handoff problem.
The tool didn't fail them. It's doing exactly what tools do.
It's tracking the handoff status.
It just can't fix what's underneath... nobody agreed on who owns the transition.
That was a system question. They bought a tool instead of answering it.
Now the tool is the system. Which means it carries all the weight the system was supposed to carry.
And weight like that breaks tools.
Two things the teams that get this right do well:
The first: They answer the system question before they open the vendor demo.
Who owns this handoff? What does done mean at each stage? Where does it break and why?
Once those questions have answers, tool selection is fifteen minutes, not three months.
The second: They use the tool to make the system visible, not to replace it.
The tool shows who has what, what stage it's in, what's blocked.
It surfaces the system. It doesn't become it.
When the tool goes down on a Thursday, the team still knows what to do.
Three moves:
First: Before the next tool conversation, name the system.
Specifically. Who owns each step. Where it hands off. What done means.
If you can't answer those in plain language, the tool will make the confusion official.
Second: Ask one question about your current tools.
If the tool went down for a week, could the team still function?
If yes, the tool is doing its job. It's supporting a system that can run without it.
If no, the system lives in the tool. That's fragile.
Lock-in: Let the tool be optional. As a test.
A system that can run manually for a week is a system the tool actually fits.
A system that can't is a system that exists only inside the software.
10-minute challenge:
Pick one tool your team uses every day. Ask: what would break if we couldn't use it for a week?
What breaks tells you whether you have a tool supporting a system, or a system trapped inside a tool.
Forward this to someone whose team is looking to buy a new tool to solve an ops problem. The tool question always comes second. Sometimes it comes third.
Unsubscribe · Preferences · Schedule A Clarity Call
600 1st Ave, Ste 330 PMB 92768, Seattle, WA 98104-2246
