I've watched the same solution show up in four completely different problems this month.
A supply chain bottleneck at my demand planning job. A volunteer coordination disaster at the nonprofit I am the executive director of. A product architecture decision in Pulley. A consulting framework for my practice.
Same pattern. Different uniforms.
This is what Musashi meant by "see the way broadly" — the principles that govern one domain usually govern them all. You just have to train your eye to recognize the shape of the problem underneath the surface details.
The copy-paste cascade
Here's a problem every small nonprofit knows, at least the ones who have large events: you create an event on Eventbrite. Title, description, dates, ticket tiers. Then you open Facebook and manually recreate the whole thing. Then your website CMS. Then Mailchimp. Then you draft social posts.
Same information. Five tabs. Ninety minutes.
The problem isn't the typing. It's that you're treating five downstream actions like five separate decisions when they're really one decision with five outputs.
This is a cascade failure. One input should trigger multiple coordinated outputs automatically. When it doesn't, you're not just wasting time — you're creating five chances for inconsistency, five points where someone can forget a step, five reasons your team burns out on admin work instead of doing the actual mission.
Pulley exists as a ready-made solution for this pattern, and the custom deployments I do through Groundwork take it further — optimized for the specific operation. But the pattern isn't about event software — it's about recognizing when you're doing the same work multiple times in different costumes.
The shape underneath
At my demand planning job, we had a planning system that required buyers to update forecasts in three different tools. ERP for purchasing. Excel for scenario modeling. PowerPoint for executive review.
Nobody called it a cascade failure. They called it "the process."
But it's the exact same shape as the nonprofit event problem. One decision — what do we think demand will be next quarter — expressed in three different formats because the tools didn't talk to each other.
The fix wasn't better training or more discipline. It was recognizing that three manual steps should have been one automated flow.
At my nonprofit, we had volunteer coordinators spending six hours a week copy-pasting names from signup forms into email lists, calendar invites, and door lists. Six hours to distribute information that already existed in one place.
I built an automation that does it in forty-five minutes or less. Not because we're geniuses — because we recognized the pattern from the supply chain work.
Running multiple ventures makes you dangerous
I wouldn't have seen these connections if I only ran a nonprofit. Or if I only did supply chain work. Or if I only built software.
The through-line showed up because I'm doing all of it at once.
This is the quiet superpower of running multiple projects in different domains. You start seeing the same frameworks everywhere. A procurement problem teaches you something about donor communication. A product architecture decision solves a consulting engagement. A nonprofit operations challenge becomes a deployable tool.
Most people think diversification is a distraction. They're wrong. Depth in one area makes you good at that thing. Depth in multiple areas makes you good at seeing patterns.
This is why I am now offering consulting, because I saw the same operational breakdowns in five different nonprofits that I'd already solved in supply chain planning. Vision Reset exists because I realized the strategic frameworks I was using to build software companies applied perfectly to organizational turnarounds.
The ventures aren't separate. They're perspectives on the same underlying systems.
Frameworks travel
Here's what I've learned works:
When you solve a problem in one domain, write down the framework. Not the tactics — the structure of the solution. Then look for that structure somewhere else.
Example: in supply chain, we used a concept called "decoupling points" — the place in your process where you stop building to forecast and start building to order. It's the moment you commit to specificity.
That same concept shows up in nonprofit event planning. When do you stop planning in general and commit to specific dates, speakers, and ticket prices? Commit too early and you can't adapt. Commit too late and nobody can promote it.
It shows up in software. When do you stop designing in abstract and commit to a specific technical architecture? Same tension. Same tradeoffs.
The framework travels because the underlying problem is about managing uncertainty and commitment. Supply chain just dresses it up in SKUs and lead times.
What this means for your work
You probably already do this without naming it. You solve something at work and apply the logic at home. You read about a framework in one industry and recognize it in yours.
The move is to do it on purpose.
Pick a problem you've solved recently. Write down what made the solution work — not the specific tactics, but the structure. Then look for that structure in a completely different part of your life.
If you run multiple projects, even better. Let them teach each other. The marketing problem in project A is probably a communication problem you've already solved in project B.
If you only work in one domain, borrow from others intentionally. Read about supply chain if you're in nonprofits. Study nonprofit operations if you're in tech. The best frameworks are portable.
The real insight
Systems thinking isn't about being smart. It's about recognizing that most problems are remixes of problems you've already solved.
Once you see the pattern, you stop starting from zero every time.
That's what "see the way broadly" actually means. Not that you know everything. That you've trained your eye to see the shape of the problem underneath the local details.
And once you see the shape, you know which tool to grab.