What the trades taught me about systems
Find the constraint, define the measure. Then build.
I came to the trades from the business side, not the field. Working with contractors changed how I think about systems more than anything else.
Here’s the short version: find the constraint, define the measure, then build.
Everything is a flow
A home-service business is a chain:
call → job → invoice → payment
When something feels broken, it’s usually one link in that chain, not the whole thing. Jobs aren’t getting closed out. Invoices sit. Payments lag. Everyone feels the pain everywhere, but it starts in one spot.
Find the constraint
The temptation is to fix everything at once: new software, new process, new meeting. Usually that just adds noise. A sync is not progress.
The better move is to ask: where does the work actually get stuck? Fix that one spot first. Then look again, because the bottleneck moves.
Define the measure
Before building anything, I want to know how we’ll tell if it worked. Not a feeling. Something you can check.
Check for the artifact, not the checkbox. “We trained the team” is a checkbox. “The office can do it without asking” is the artifact.
Then build
Only after those two steps do I build a tool, and AI makes the building part much faster than it used to be. But fast building on the wrong problem is just a faster way to waste a week.
What I took from it
- Systems over hustle. Working harder on a broken flow doesn’t fix the flow.
- Facts over assumptions. Go look at the real work before guessing.
- Keep it simple enough that the people doing the work can run it without you.
The contractors I’ve learned from are some of the most practical people I know. They don’t care how impressive a tool is. They care whether it works on a Tuesday afternoon when the phones are ringing. That’s the bar I try to build to.