About
The system around the work decides what the work becomes.
I work that idea out here, in public.
I build and lead technical teams for a living. I have spent my career standing up new things inside a big company, and I write about what it takes to make the work actually ship. Before tech, I was a Marine. I am also a dad, and half of what I know about communication I learned at the dinner table.
Marine vet · 15 years on the technical side · Builds technical teams inside a major CRM vendor
What I write about
Essays work through an argument. Frameworks are meant to be used Monday morning. Field notes are what I noticed in the work.
I write from the technical side because that is where I work. The readers who get the most out of it are not all technical. They are the ones responsible for turning an idea into something that holds up after they walk away.
Why I write it down
Most of what decides whether technical work ships gets settled in rooms with no notes: how the problem came in, what tradeoffs nobody said out loud, what everyone thought done meant, who owned it after. The same decisions come up everywhere, and nobody writes them down.
Writing is the test. A position that survives being stated plainly is one I can operate from. One that does not was a preference, not a principle.
The day job
I sit on the technical side of the table: design, proof, and delivery rather than quota. I build teams that work with big organizations on AI and data problems. I keep my role and employer vague on purpose. The ideas have to stand on their own, not on an org chart.
I do not publish customer outcomes, confidential architecture, or employer-owned frameworks. Everything here is built from operator knowledge.
The Marine Corps came before the tech career. It taught me that a plan nobody can execute is not a plan.
