Hire me

I’m a builder who came to developer relations through engineering. Before Snyk I led full-stack engineering teams at Nielsen and HPE. In 2007 I founded daloRADIUS, an open-source network access management platform (RADIUS) for ISPs and Wi-Fi hotspots that once ranked in SourceForge’s top 300 of roughly 150,000 projects and is still in active community development nearly two decades later. At Snyk I grew from developer advocate to leading Developer Relations and Community, combining people leadership with hands-on research, tooling and education.

Today most of my work sits where AI agents meet security: measuring how reliably models find vulnerabilities, disclosing flaws in MCP servers and agent tooling, and turning that into guidance developers can use. The constant is the same: get hands-on, explain what matters and bring what I learn back to the people building the product.

I fell in love with computers at ten, writing QBasic on DOS 3 and doodling lines of code in my school notebooks when I should have been paying attention in class. As a teenager I ran my own single-node dial-up BBS on RemoteAccess and DESQview from 1996 to 2001, then fell hard for Linux with Red Hat 5 on a laptop I still own. I did old-school sysadmin work for friends and for my own home servers, lived on IRC, and may have been active in a hacking group that shall remain unnamed.

My first job was technical support at an ISP, where I was promoted twice in my first year. From there I moved through Linux and networking, telecom and kernel work, and engineering management. Along the way I contributed to and translated open-source projects, wrote for FreeSoftwareMagazine and founded daloRADIUS in 2007. That path is why I care about developer experience at every level: I’ve been the person on the support line, the sysadmin, the kernel developer and the manager.

Roles where I can set direction, build alongside the team and make a tangible difference to a product and the developers who use it. That could be a leadership role such as VP or Head of Developer Relations, a senior developer experience or advocacy role, or product management for developer and agentic experiences, grassroots adoption and product-led growth.

I’m most interested in developer tools, AI and agent platforms, and infrastructure, where technical depth is the price of entry and developer trust decides adoption. The problem and the team matter more to me than the title.

A team that is technical enough to earn engineers’ respect and focused enough to move business outcomes. At Snyk I lead Staff Developer Advocates and Security Relations leads across the US, Europe and APJ. I’ve mentored and promoted advocates, and refocused the team as our audience shifted from developers broadly to AI security practitioners and agentic developers. I’ve also run DevRel inside both Marketing and Engineering organizations, so I know what changes when the team’s mandate shifts from awareness to technical influence.

Today I organize the team around three areas: community advocacy, Forward Research and Growth Engineering. I build programs to outlive my involvement: Snyk Ambassadors continues under Snyk’s Customer Advocacy team, and Snyk Advisor graduated from DevRel into the core product. My operating bias is a few clear bets, adoption and retention over vanity reach, and making sure what we learn in the field gets back to product.

Yes, roughly 60/40 between people leadership and individual contribution. I architected Snyk VulnBench end to end, from the agent harness and vulnerable code corpus to the reporting pipeline, and it’s open source under Apache 2.0. I’m credited on 43 GitHub security advisories from my own security research, including recent ones in MCP servers. This year I disclosed an invisible-Unicode technique that could hijack Gemini CLI agent skills.

I’ve written three books on Node.js secure coding and maintain open-source security tools. I build intentionally vulnerable apps to teach MCP and Agent Skills attack vectors, and I ship internal tools with Claude Code, Cursor and Codex. Staying close to code makes the strategy and the education better.

I built communities before it was my job. At Nielsen I grew TheBigWebTheory, our R&D site’s community meetup, to more than 1,500 members and mentored engineers into public speaking and open source. At Snyk I founded Snyk Ambassadors and SnykLIVE from zero. The ambassador program started with eight people selected from 96 applicants and continues today under Snyk’s Customer Advocacy team, with ambassadors across major customer accounts and events worldwide. SnykLIVE was the team’s first video-based community presence and grew into an established, high-output show on Snyk’s YouTube channel.

I also led The Big Fix, Snyk’s community security fix-a-thon, as a DevRel program built together with the team. It won a DevRel Award for Best DevRel Initiative; in 2023 participants contributed more than 597,000 security fixes. Today my team runs the AI Security Engineer community and certification for practitioners securing AI-generated code and agents.

The Big Fix results

As a contributor first, not a sponsor. I volunteered in the Node.js Ecosystem Security Working Group before Snyk took on the ecosystem’s disclosure program, and I’m project lead for the OWASP CWE Tool and CWE SDK. I also co-authored the security chapter of the HTTP Archive’s 2022 Web Almanac and have written guest posts for the GitHub and Docker blogs.

The community has recognized that work with the OpenJS Foundation’s Pathfinder for Security award and three years as a GitHub Star. Partnerships last when both sides get real value, so I bring work the ecosystem needs, not a logo request.

My favorite is Snyk Advisor, which I led from launch through its breakout growth phase. It gave developers a free, searchable health score for open-source packages, covering security, maintenance, popularity and community, right at the moment they were choosing a dependency. Within three months it was Snyk’s largest website traffic generator, and by Q1 2021 it drove 37% of new website visitors and more than 500 monthly signups.

Before that, I conceived and built a WebPageTest integration that brought Snyk vulnerability data and HTTP security header analysis into a tool web developers already used every day. Within five months it was Snyk’s top referral traffic source, and over two years it stayed the company’s second-largest. Both follow the pattern I look for: meet developers where they already work and make the first useful moment free.

Make something useful enough that developers come back without being asked, connect it to a clear path to value, then measure what happens. And plan for success: a growth tool that works should graduate into the product. Snyk Advisor did. I mentored the teammate who carried it forward, and its package-health insights now reach the API and the official Snyk MCP Server, so the same data serves AI agents as well as people.

Vuln Cost followed the same arc inside the editor. The VS Code extension surfaced dependency vulnerabilities as developers coded, recorded 28,500 installs on its archived Marketplace listing, and its capabilities carried into the official Snyk Security extension.

Package health in Snyk MCP · Vuln Cost on GitHub

I don’t stop at the headline. Every finding should end in something a developer can run or change. In 2019 I showed how npm lockfiles could be abused to inject malicious packages, then built lockfile-lint so teams could enforce trusted sources in CI.

The same thread runs through my agent-security work. I built anti-trojan-source to catch hidden-character attacks in source code, and in 2026 showed that invisible Unicode can hijack AI agent skills. For MCP, disclosures fed into a public evaluation framework for MCP server security and practical guidance for building secure MCP servers.

Software supply-chain incidents are the recurring one. When a worm or a hijacked maintainer account hits npm, developers need to know within hours whether they’re affected and what to do, while the facts are still moving. I’ve written Snyk’s public analysis during incidents like the node-gyp self-propagating npm worm and the keyv compromise, working alongside security analysts as the investigations unfolded, and followed up with a Shai-Hulud post-mortem on building a more resilient supply chain.

What I’ve learned: lead with what developers should check and do right now, separate what’s confirmed from what’s suspected, and update in public as the facts change. During an incident, being useful fast is what builds trust.

The developer increasingly has an AI agent as a co-worker, and often as the first reader of your docs. That changes the job. Your product has to be discoverable and usable by agents through MCP servers, agent skills, clean APIs and docs a model can follow, and your advice has to hold up when an agent acts on it unsupervised.

It also raises the bar on evidence. At Snyk I research how reliably AI agents perform security tasks (VulnBench) and what goes wrong in the agent ecosystem, from malicious skills to vulnerable MCP servers. DevRel teams that can test, measure and publish what agents actually do will earn the trust that marketing claims no longer get.

Forward Research is the research arm I built inside DevRel. It measures how reliably AI models and coding agents perform security tasks, and how the way an agent is built changes the result. It doesn’t replace the vendors’ benchmarks; it supplies the independent, repeatable evidence developers and security teams need before they trust an agent with their code.

The output is public and reusable: Snyk VulnBench is open source with an arXiv paper, and we partnered with Snyk’s R&D teams on benchmarks such as VulnBump, for AI dependency upgrades. It belongs in DevRel because in the AI era, credible evidence is the most persuasive developer content there is, and what we learn feeds straight back into the product.

In 2023 I built ContentGPT, an AI-assisted platform for outlines, drafting, keyword planning, FAQs and security-incident articles. It cut production time and helped the team produce more than the external content agency it replaced, and the approach carried into the team’s later Claude Code-based content tooling.

I also built a Mastra-based tool that helps evaluate hundreds of conference CFP submissions. And I run much of my own leadership work through an LLM-operated markdown knowledge graph that digests meetings, tracks commitments and drafts follow-ups. The rule I hold to: AI does the drafting and the legwork, and people own the judgment and the facts.

I start by using the product myself, looking for friction from discovery through continued use. At Snyk my research and user-zero feedback have improved Snyk Code detection, including secret-detection rules and false positives and negatives, and I give ongoing feedback on the Snyk CLI’s developer experience.

I’ve owned product outcomes directly too. As an engineering manager at Nielsen my team built and launched a new insights product in three months, and earlier I was product manager for a hotspot and ISP platform I designed from scratch. I bring developer feedback, product data and engineering reality together, then work with engineering and design to prioritize and check the results.

Against what each program is trying to change, and with adoption and retention weighted above raw reach. I think in three layers: are we noticed (reach), do developers come back and go deeper (engagement and adoption), and does it change the product and the business (influence).

In practice: for AI advocacy and community, returning participants and membership growth across meetups, events and the newsletter; for the AI Security Engineer certification, developers certified and the channel they came through; for Forward Research and security evaluations, citations, analyst mentions and LLM share of voice (how often AI assistants surface and cite our work); for Growth Engineering, adoption, popularity and the product signals those tools bring in. Snyk Advisor, for example, had targets for indexed pages, new visitors and acquired users. I pair the numbers with developer feedback and am honest about attribution: DevRel influences more than it can claim.

Mostly on what counts as output. Top-of-funnel content, another tutorial or another explainer, is rarely a good return anymore, especially when an AI agent reads it before a developer does. The work that compounds is what developers and their agents actually run: demos and apps, an MCP server or agent skill that users connect, and benchmarks and evals that show how tools really behave. In 2014 content was king. In 2026, code is.

I also disagree with measuring DevRel like a marketing channel. When I reset my team’s strategy at Snyk, we moved from top-of-funnel goals to activation and retention, and built our own tracking for citations and LLM share of voice to see whether our work is actually being referenced. If a program can’t show that it changed what developers do, it’s a cost, not a channel.

Optimizing for content volume. For a long time DevRel was a top-of-funnel engine, and I leaned into it: in 2023 I built ContentGPT so the team could produce more, faster. It worked on its own terms, but it taught me I was optimizing the wrong thing. Once AI made content cheap for everyone, more articles stopped moving developers, and an agent often reads them before a person does.

When I reset my team’s strategy, we moved our effort to what only we could make: original research and benchmarks through Forward Research, and tools developers run through Growth Engineering. The lesson I keep: measure the outcome you want, not the activity that’s easiest to count.

As a bridge that carries evidence both ways. My research and user-zero feedback have gone into Snyk Code rules; tools my team built, like Snyk Advisor, graduated into the product; and I’ve been a go-to for competitive intelligence and technical positioning that helps field teams in conversations with security and platform teams.

With engineering I can go deep on the technical detail; with product I bring developer feedback and data; with marketing I turn research into stories that hold up under scrutiny. Shared goals and honest feedback make it work.

Show your work, be truthful about limitations and make the material useful even when someone does not buy a product. As a maintainer and security researcher, I know developers notice when an example hasn’t been tested or a claim goes further than the evidence. When I publish benchmarks, the methodology and data go out with the results, and our own product is reported as accurately as everyone else’s. Trust is earned in those details.

JavaScript and Node.js developers, open-source maintainers, application security practitioners, and people building with AI agents and developer tools. Before Snyk I worked across Linux infrastructure, networking and telecom, and full-stack web, so I’m comfortable from kernel modules to React front ends.

I’m most interested in products where technical depth and an accessible developer experience both matter.

Yes. I’ve taken part in more than 250 speaking engagements, from conference keynotes to meetups, podcasts, webinars and hands-on workshops: JSNation US, WeAreDevelopers World Congress, OWASP Global AppSec EU and AI Native Dev among them. I lean on live demos to make a technical problem concrete, and adjust the depth to whoever is in the room, whether that’s practitioners, engineering leaders or a product team.

Full speaking archive

Listen first, then ship something. In the first weeks I’d talk with the team, customers and developers, use the product myself end to end, and review the data to understand what the business needs. From there I’d pick a small set of bets with clear outcomes, agree on them with the people who will execute, and aim for one visible early win. A real fix, a tool or a program in market builds more credibility than a strategy deck.

I look for the overlap, because helping developers solve real problems is what builds the trust and adoption a business needs. Snyk Advisor and The Big Fix both worked because they were useful to developers first. When interests diverge, I’m transparent about the trade-off and bring evidence from the community into the decision rather than papering over it.

No. I’m excited by the tools and platforms developers build with: agentic coding and AI experiences, developer tooling, web infrastructure and cloud platforms. Some of my most-used open source isn’t security at all, like dockly, a terminal UI for Docker, and Node.js CLI apps best practices. Security is a deep area of expertise I bring along with developer education, product thinking, community and technical storytelling.