Operations problems look like tool problems. They almost never are. Here's the order I actually work in, and why.
Most teams don't have a tool problem. They have a system problem, and the system is usually held together with Slack threads, screenshots, and someone who knows where the file is.
Nobody's sure who owns the next step, so things wait in someone's inbox or a Slack thread.
why does this take so long every single time?
honestly, no idea. it's just how we've always done it
😮💨 2Before I look at a single tool, I talk to the people doing the work. What's breaking. Where things get stuck. Who owns what, and who thinks they own what.
The gap between how the org thinks it works and how it actually works is where the answer usually is. That's the gap I look for.
This usually takes a week of short conversations across the team. Nobody is on the spot. Nobody has to present. I'm just listening for the patterns nobody else has time to listen for.
From the conversations, I build a map. The real one. Not the org chart. The map of where work actually flows, where it stalls, where ownership is fuzzy, where handoffs drop the ball.
I show it back to the team. People recognize themselves in it, and the conversation gets easier from there. Now we're not arguing about how things should work. We're looking at how they do.
This is where the real scope of the work gets defined. Sometimes it's smaller than expected. Sometimes much bigger. Either way, we both know what we're solving before I touch anything.
Now we build. Asana, Notion, Airtable, whatever the right answer is for your team. I'm fluent in the tools, but the tools are the easy part. The hard part is making the system fit the way your team actually works, not the way a vendor's demo video says they should.
I build with the team, not at them. The people who'll use the system are in the room while it's being built, which is how you get adoption that actually sticks.
Documentation gets written as we go. SOPs, handoff playbooks, the things that make the system survive turnover. Not after the fact. Alongside.
A system nobody knows how to use is the same as no system. Training is part of the work, not a postscript.
I train the people who'll own this after I'm gone. Live sessions, recorded walkthroughs, and a 30-day check-in to fix what didn't quite land.
The goal isn't that you need me forever. The goal is that you don't.
Most teams blame Asana or Notion or Airtable when the real problem is that nobody agreed on how to use them. The tool change doesn't fix that. The agreement does.
A beautiful system nobody uses is a worse outcome than a messy system everyone trusts. I build for the team that's going to live in it, not for the demo.
SOPs get written while the work is happening, not after. That's the only way they actually reflect what people do.
The people doing the work know where it's breaking. My job is to listen carefully enough to hear it, then make a system that respects what they told me.
If your team can't run the system without me, I haven't finished the work. The handoff is part of the build.