I've been thinking a lot about patterns. Not product decisions. Not roadmaps. Personal patterns - the kind that shape how I show up, whether I notice them or not.
After years of building - companies, systems, communities - I can see my own fingerprints. The rules I follow. The traits I default to when no one's watching.
And as I step back from one chapter and look at what comes next, I want to write them down. Not as fixed truths, but as a snapshot. A way of seeing the operating system I'm running on today, before it inevitably shifts again.
So here it is. The shape of me, right now.
I build to make sense of the world. Not just to ship - to understand. Sometimes that means a product; sometimes a tool, a system, or a sketch. The act of making something tangible out of something abstract is how I think.
I care about whether the work is real - not just well-presented. About how people behave when the strategy deck runs out and there's nothing left but decisions. About whether we're chasing outcomes or just the appearance of them. That idealism is a strength, and sometimes a liability.
I play long games. I started a Minecraft community at 17 that's still running - that's not nostalgia, it's just how I naturally operate. Trust compounds. So does work that lasts. I'm not chasing the biggest audience; I'm building a body of work worth keeping.
I run on high agency and carve through ambiguity. I move when I see a gap, pick up the thread when ownership's unclear, bring focus when priorities clash - not because it's always my job, but because it needs doing.
I switch altitudes fast. One moment I'm working with founders on direction and trade-offs; the next I'm on a customer call, reviewing designs, or testing a release minutes before it ships. That switching isn't distraction - it's how I connect strategy to detail, spot gaps, and keep momentum alive.
I write to create clarity. I talk things through to explore; I write to refine. Writing shows the gaps, sharpens the thinking, and aligns the team. It's not content. It's a tool.
I trust accumulated context over process. I'm not a playbook PM. I synthesise fast, arrive at a direction before the framework says I'm allowed to, and back it with years of pattern recognition built from real signals. In scaling-stage orgs that gets called skipping the process. In early-stage ones, it's the thing that keeps you moving.
I lean on systems when they're needed - not for their own sake, but when a lightweight structure will create clarity and enable others to move faster. The point isn't control. It's making sure the team adds up to more than the sum of our parts.
I believe in small, high-trust teams. Not 50 people and a wiki full of process - a handful of sharp minds, shared context, and the trust to disagree, decide, and deliver.
I need momentum. Not busyness. Momentum - progress that resolves tension. When ambiguity drags, I ship something to get things moving: a doc, a decision, a release.
I look after my energy. Deep work and deep rest - enough slack in the system to think clearly and act intentionally. When I feel stretched, I don't grind harder. I reset how I'm working.
In practice: I talk to customers obsessively but don't wait for perfect signal before moving. The solution sometimes has to come before the problem is fully articulated - that's not bad practice, it's often how real innovation starts. Revenue is the most honest feedback loop. Foundations compound; features don't.
Early-stage is where I'm most at home. Messy beginnings are where the opportunities are - do things that don't scale until you must, wear multiple hats, stay close to customers. The first 10 customers teach more than the first 10 features.
On teams: hire people who figure things out, not people who follow the process well. Context over control. Trust is the only currency that compounds. Quality people attract quality people - get the foundations wrong and you'll be managing to the lowest bar you set on day one.
The instincts that make early-stage work fast can become liabilities as teams grow - not because they're wrong, but because they don't transfer. Systems and process exist to distribute context that used to live in one person's head. Knowing which stage you're in, and what that stage actually needs, changes everything about how you work.
I get my hands dirty - coding, customer calls, digging into detail. I think in systems but ship in increments. I prefer small teams that move fast over big ones that move slow. I value clarity over consensus - and write like I talk. I stay close to the work because that's where the truth lives.
I'm most useful before the playbook exists. When a product exists but product-market fit doesn't. When there's more to figure out than there is to follow. That's the brief I'm built for.
