Principles in Practice
How SWARM emerged by letting the work lead
Recently, I heard something on a podcast that stuck with me:
Always refer back to your principles in everything you do.
At the time, it sounded obvious. Almost generic. But it lingered longer than most advice does. Not because it was new, but because I realized I had already started doing it without fully noticing.
Writing the SWARM principles changed everything
When I first articulated the principles behind SWARM, I wasn’t inventing anything. They had always been there, guiding decisions implicitly. Writing them down didn’t create new values. It externalized instincts. That shift mattered more than I realized.
Once the principles were named, they stopped being abstract ideas and became reference points. Not rules. Not constraints. Just anchors I could quietly return to.
Over time, I noticed something subtle. I wasn’t trying to apply the principles. I was recognizing them in the work.
Seeing the work trace back to the principles
That recognition started showing up everywhere.
When I write a Substack post, I can usually feel which principle it’s expressing.
“This one hits Authentic.”
“This one leans into Reduction.”
The same thing happens in design work. A layout decision might clearly be Reduction. A structural shift might be Emergent. A messy exploration might be intentionally Nonlinear.
This simple awareness removes a surprising amount of friction.
Instead of asking “Is this good?” or “Is this enough?”, the question becomes:
“Is this honest to the principle it’s expressing?”
That’s a much lighter question to carry.
How this shows up in SWARM itself
SWARM is probably the clearest example of this in practice. The recent evolution of the protocol wasn’t planned. It emerged naturally once the principles were explicit.
Authentic
SWARM is still grounded in how I actually think and work. It hasn’t been abstracted into something generic. That authenticity is what makes it transferable without feeling hollow.
Reduction
As SWARM deepened, the language became simpler. Fewer labels. Less explanation. It’s easier to describe now than it was months ago. That’s a good signal.
Nonlinear
The language shifted away from steps toward loops and phases. This wasn’t semantic polish. It was an acknowledgment of how the work actually happens. You don’t complete SWARM. You return to it.
That shift also led to a small but meaningful change in language. What I originally called the SWARM Grid gradually became the SWARM Loop. Not as a rebrand, but as a correction. “Grid” implied structure and coverage. “Loop” better reflects revisiting, learning, and movement over time.
The name changed because the behaviour was already there.
Emergent
Over time, it became clear that SWARM had a stable core, with many possible ways it could be applied. That distinction wasn’t planned. It emerged through use.
Modular
A loop is a module. Not a step. You can enter anywhere. You can stop anywhere. Nothing breaks.
Thinking in loops made this clearer. Each loop stands on its own, but also connects to the others. You don’t need the whole system every time. You just need the right phase for the moment you’re in.
None of this was forced. The principles didn’t shape SWARM from the outside. They revealed the shape that was already forming.
Principles as a way to validate the work
One unexpected benefit of this shift is that it gave me a way to validate my own work without relying on external reinforcement.
Instead of looking to momentum, feedback, or performance metrics to decide whether something “worked,” I can check for alignment internally. I can ask whether the work is actually true to the principle it appears to be invoking.
That validation isn’t about quality or success. It’s about coherence. If a piece claims Reduction but still feels cluttered, I know there’s more to remove. If something moves toward Emergence but feels overly controlled, I know I’m constraining it too early.
The practice itself is simple.
After finishing a piece of work, I pause and ask quietly:
Which principle did this express?
There’s no judgment in that question. No attempt to correct or optimize. Just awareness. And more often than not, that awareness alone is enough to gently course-correct the next move.
Principles as practice, not doctrine
The mistake I see often is treating principles like a checklist. Something to satisfy. Something to optimize against.
That’s not how this works.
For me, principles function more like a compass than a map. I don’t consult them before every move. I notice them after, and that noticing gradually sharpens intuition.
That’s made decisions lighter, communication clearer, and the work feel more coherent across writing, design, and systems.
I didn’t become more disciplined.
I became more aligned.
And that, it turns out, compounds.
As SWARM has settled into this loop-based form, I’ve started offering SWARM Loops as an async clarity exercise. Teams or founders bring a problem, I take it away and spend a few focused hours working through it, then return a short clarity report outlining what matters, what doesn’t, and where the leverage likely sits.
If you’re curious, you can read more at cardeo.ca.