From community to CX systems.
At my core, I want to help people. Over time, that turned into a more specific conviction: when customers struggle digitally, the problem is usually not the person. It is the system around them.
I came to customer experience through community, long before “community” or “CX” were job titles. I started building websites at 13 and learned the internet from the inside out: forums, IRC, file-sharing scenes, and web design boards where reputation was earned by being useful. I’ve been self-taught from the beginning, and that mindset still shapes how I work.
In cybersecurity, I spent years volunteering, moderating, and helping build communities around independent creators such as NahamSec and Unsupervised Learning, and companies such as Bugcrowd and HackerOne. It gave me a front-row seat to how people actually experience products: where they get stuck, what they misunderstand, and how much invisible labor they take on just to keep moving.
At the same time, I was building the technical foundation underneath that work: web development, systems thinking, security research, writing, and digital operations. That combination is what eventually pulled me into CX.
What I kept seeing was not customer error. It was a fragmented post-sales experience asking customers to do work the system should have done for them.
Customer experience, to me, is the product behind the product: onboarding, the help center, the docs, the community, the support flow, the self-service layer, release communication, the AI on top of it, the handoffs between teams, and the expectations around all of it.
Most companies design the core product intentionally. The post-sales layer grows around it unevenly.
That is the layer I work on.
I look for the places where context disappears, where ownership is fragmented, and where customers get stuck between teams, tools, or surfaces. Then I fix the infrastructure underneath and align cross-functional teams so the experience works as one system.
I have a strong bias toward improvement. Most customer experiences are more fixable than they look, and small changes at the right layer can have outsized effects. That matters even more now, as AI and agents increase what a good system can do — and expose the cost of weak foundations just as quickly.
The best CX work does not live neatly inside one function. It lives between them. That is where I do my best work.
Where I've done it.
Before CX became the center of my work, I spent a decade building and breaking web apps, automations, and digital systems for startups and independent clients, including work on the front end of Federacy, a pentest and bug bounty platform.
That technical foundation matters because the work I do now sits at the boundary between strategy and systems.
At Bugcrowd, I owned the researcher experience across Zendesk, Discord, and Discourse. I unified three help surfaces into an intent-based architecture that reduced ticket volume by 10% and repeat questions by 25%.
That work sharpened my view of post-sales systems as architecture, not just support operations.
Where I am now.
At ExtraHop, I own community, knowledge, self-service, and AI across a cloud-native cybersecurity platform serving thousands of enterprise security teams.
This is where I’ve been able to apply the full shape of the work: architecting the post-sales layer across multiple customer-facing surfaces and making it hold operationally.
Swarm is how I take that work beyond one company: helping B2B SaaS teams design post-sales systems that connect strategy, tooling, and ownership instead of leaving them fragmented across functions.
Every Monday, 4,500+ readers who care about security, technology, community, and the internet as a place to build a life.
The newsletter started from the same instinct that drives the rest of my work: make useful things easier to find, easier to understand, and easier to act on.
Every two weeks, I publish a detailed walkthrough of a real company’s post-sales experience: what works, what breaks, and what the underlying system appears to be optimizing for.
It is one of the ways I make my thinking public.
How I think.
Move the work upstream
I do not fix broken experiences only where they appear. I trace them to the layer causing them, then fix the cause there.
Treat post-sales as one system
Support, knowledge, community, self-service, AI, and operations do not work well as isolated workstreams. They work when they are designed as one connected experience.
Build compounding loops
The goal is not just to resolve issues. It is to create feedback loops where customer signal improves knowledge, knowledge improves self-service, and recurring friction gets removed at the source.
Turn fixes into infrastructure
A good fix should survive org changes, staffing changes, and time. I care about ownership, maintenance, operating rules, and systems that keep working after the initial rescue.
Outside of work.
Outside of work, I’m a family man who loves cooking, usually without a recipe, though I can follow one when needed. I read widely about how other operators think and work. I enjoy biographies, documentaries, classic anime, hip-hop, and, from time to time, metal.
If any of that resonates.
The best way to start is the CX Architecture Audit. Or read the Resources and see how I think before you decide.