Developer relations: earning trust at scale
Developers are a different kind of buyer. They don't respond to marketing promises. They respond to clarity, credibility, and usefulness. Building a developer relations function that actually drives adoption requires understanding that difference and designing everything around it.
Why developer relations is misunderstood
Most companies treat DevRel as a marketing function with a technical veneer. They hire developer advocates to speak at conferences, write blog posts, and build demos. Some of that is useful. Most of it doesn't move the needle on adoption.
The companies that do this well treat DevRel as a trust-building function with a long time horizon. The goal is not visibility. It's credibility. Developers need to believe that your product is worth their time before they'll invest in learning it, integrating it, or recommending it to others.
Documentation: your most undervalued asset
Documentation is almost always treated as an afterthought. It gets written by engineers who are already on to the next thing, or by technical writers who don't fully understand the product. The result is documentation that covers what the product does but not how to use it effectively.
I use the Diátaxis framework as a starting point: distinguishing between tutorials (learning-oriented), how-to guides (task-oriented), reference material (information-oriented), and explanations (understanding-oriented). Each serves a different need at a different moment in the developer journey.
What good documentation does
It reduces time-to-value for new users. It answers the questions that would otherwise go to support. It signals that the people behind the product respect the developer's time.
The ROI on documentation investment is consistently underestimated. Every support ticket that doesn't get created, every integration that succeeds without friction, every developer who recommends your product because getting started was easy: all of that traces back to documentation quality.
Community: relevance over reach
A developer community is not a mailing list or a Slack workspace. It's a group of people who share a problem, a tool, or a domain, and who find genuine value in connecting with each other.
Most developer community efforts fail because they optimize for size instead of depth. A thousand members who barely engage is worth less than a hundred who actively help each other, contribute back, and bring in new members through genuine recommendation.
Events and conference strategy
Conferences and meetups can be powerful or a complete waste of budget. The difference is whether you have a clear objective beyond 'presence': are you learning, recruiting, building relationships with a specific segment, or validating a positioning hypothesis?
I help companies decide which events are worth attending, what success looks like for each, and how to turn one-off interactions into ongoing relationships.
Open source: intentional or not at all
Open source is not a marketing checkbox. Contributing to or sponsoring open source projects only creates value when it's aligned with your product strategy and your target community.
The questions worth asking before any open source engagement: does this put your product in front of the right developers? Does it credibly signal expertise in the domain you want to own? Does it create a contribution surface that attracts the kind of engineers you want to hire or partner with?
What intentional open source looks like
It means choosing projects and ecosystems where your contribution is meaningful, not peripheral. It means maintaining what you open source, because abandoned repositories actively damage credibility.
Done well, open source engagement strengthens technical reputation, builds relationships with influential community members, and creates a feedback loop that improves the core product.