"Developers don't need more hype, they just need a reason to care about your product."
Hello! I’m Tessa Mero, Director of Developer Advocacy, Developer Security at Checkmarx. Who am I really though? Aside from enjoying fitness and cooking, I’m someone who absolutely loves being part of communities and building communities, and I spend a lot of my free time doing that too. This is why Developer Relations is such a natural fit for me. :)
At Checkmarx, we have a whole suite of application security products. Just to name some that I’m involved in: Developer Assist, which helps developers secure code as it’s being created, including AI-generated code, directly in IDE and CLI workflows. We have Checkmarx One, our application security platform for capturing software risk, eliminating attackable risk, and governing security across the software development lifecycle. And we have Checkmarx Fusion, which is part of our next-generation approach to code security scanning.
You are asking if DevRel is Marketing, Engineering, or Product? The answer is Yes. Lol.
Developer Relations can sit within any of those teams, as long as the leader responsible for DevRel understands the function, fully supports it, and trusts the team to do its job. I’m very lucky to have that at Checkmarx.
At each previous companies, I’ve sat within a different department, and I’ve seen DevRel work well in all of them. Currently, I sit within the Product Marketing function, where we work very closely with both the marketing and product teams. I also will be working closely with sales and engineering.
To me, the most important part of DevRel is being able to work cross-functionally and act as a liaison between teams, while also representing the needs of developers. That ability to connect people, feedback, and priorities across an org is one of the most critical parts of internal DevRel related work.
I’ve only been at Checkmarx for a little over a month now, so I’m still learning the organization, the product, and where I can have the most impact. The most important thing for me right now is listening and starting with the low-hanging fruit: our current users. I want to understand how developers are using our product, what they’re experiencing, what they love about it, and what frustrates them. I’m also learning what our internal teams are trying to accomplish, what’s important to them, and where I can best align myself.
For pushing back, I can speak more from my experience at previous companies. Sometimes internal teams just don’t see things from the developer or user perspective. Bringing data, examples, and proof of what works and why can help make that perspective more visual and get everyone on the same page.
This one is interesting, and it’s a big part of why I was brought into Checkmarx. Checkmarx has been around for about 20 years and has historically been an enterprise-first company, where accessing the product typically started with contacting Sales. More recently, we’ve introduced a free trial for Developer Assist and free credits for Checkmarx One, which gives us a new opportunity to engage directly with developers.
We also launched our Discord community at https://checkmarx.com/discord. It’s still very new, so we’re in the early stages of growing it. It’s open to developers who want to talk about application security, current users of our products, and developers who are interested in trying them out.
If you’re reading this, come join us and hang out! Introduce yourself and tell me how you’re approaching security in your applications. I’m still learning a lot myself, and I love hearing about how other developers are handling security in their own workflows. :)
Since I’m still fairly new at Checkmarx and we’re still in the weeds of working on various campaigns and launches, I’ll share an example from a previous company. I’m very proud of helping run our Hacktoberfest sponsorship (for multiple years). It gave us the opportunity to get our open source project in front of a global developer audience of 100,000+ registered developers and brought in a large amount of new contributors. We also saw devs help work through existing PRs and become more involved in the project overall.
What I’ve learned from campaigns and similar initiatives is that you have to give developers a reason to participate. (Just like building a community too). It can’t just be focused on awareness. If you create an easy, meaningful way for developers to get involved, they may be more likely to engage and stick around. And eventually become advocates for your community or product.
If a developer can’t figure out how to get started with your product within a few minutes, there’s a good chance you’ll lose them. That’s why things like simple quickstart docs, short video demos, written tutorials, and sample apps are such an important part of the developer experience. They help developers get to that first “aha” moment as quickly as possible.
The next question is: How are they supposed to know whether your product is a good fit for them (or their team)? That’s where free tiers, trials, and credits become important. Developers want the ability to try something themselves before having to make a larger commitment.
At previous companies, I’ve seen plenty of developers start with a free or trial account using a personal email address, then later come back through their company with a paid account. A free user may not represent revenue on day one, but they could be the person who eventually brings that product into their organization. Making it easy to test and try it out, onboard, and experience the value quickly is a huge part of developer adoption.
Since I’m still fairly new at Checkmarx, I don’t have a favorite piece of content I’ve shipped here yet. (Although I do have a presentation I’m shipping later today for the DevOps Experience conference!). However, I’m most excited about a new LinkedIn newsletter I’m working on called “Inside the AI-DLC”. I just finished the first issue, not published yet. It’s been exciting as it gives me the opportunity to research, learn quickly, and turn what I’m learning into thought leadership specifically for developers navigating the AI development lifecycle. There’s so much changing right now around how AI is affecting the way we build and secure software, and I want the newsletter to make those conversations useful and approachable for developers.
Issue #1 is coming soon and you can subscribe here: https://www.linkedin.com/newsletters/7507817930877779969/. I haven’t promoted it yet, so yall may be the first set of subscribers! <3
We also have a lot more developer content and demos in the works that I’m really excited about. :)
“Is DevRel working?” can mean very different things depending on what problem the team is trying to solve. DevRel works in two directions: bottom-up, where we meet developers where they are and help them become users, and inside-out, where we learn from current users and bring that feedback back into the company to improve the product and Developer experience.
There are a lot of things you can track, like community growth, engagement, metrics on content, product signups, trial usage, feedback, and adoption. But I care most about whether developers find value in the product and moving further in the developer journey with us. Are they trying it? Are they using it? How is the developer retention? Are they bringing it into their teams or companies?
Of course there are several vanity metrics, such as follower counts, impressions, community size, etc. But those numbers don’t mean much if developers aren’t engaging with the product or finding value in it. DevRel should be able to connect its work to meaningful business outcomes, which is also why alignment with Sales, Product, Engineering, and Marketing is important.
I think about this from the perspective of when I was a developer adopting new tools to make my workflows faster. I was always the person who skipped through the long explanations and went straight to the code samples. I like written tutorials, but I want them to get me to something I can actually copy, paste, run, and experiment with as quickly as possible. These days, “Copy Prompt” is becoming the new “Copy Code”.
Developers want to see something working before they invest the time to learn everything about it. Give them a demo, a sample app, a code snippet, or a prompt they can try themselves. Like I’ve said before, getting developers to that first “aha” moment is where the real magic happens. :-)
I haven’t met many developers who get excited about being marketed to. You can absolutely market to developers, but it shouldn’t feel like traditional marketing. I think it comes to one thing: showing value.
Why should they care about your product? What problem does it solve? Will it make their work easier, their workflow faster, or save them time? Can they learn it quickly without adding more complexity to an already busy workload?
If you can answer those questions clearly, briefly, and then actually show that value through a demo, code sample, tutorial, or something they can try themselves, that’s a win. Developers don’t need more hype, they just need a reason to care about your product.
Kathy explains the same idea of what DevRel is about: showing value. Making the developer the focus instead of the product. Instead of showing the product, make the developer feel like they learned something, solved a problem, or improved their workflow in some way. If our product helped them get there, that’s where the value really shows!
I first came across HackerNoon through other devs sharing tutorials/blogs on social media. I just recently subscribed to the Hackernoon AI & ML newsletter, and excited to get content in my email. Now that I’m checking out more content on HackerNoon, I see there’s a lot of interesting content, especially around AI and topics that overlap with the work I’m doing now.
Okay, I could make a LONG list of people I admire. Everyone has different strengths and things they excel at, but to name just a few:
Lee Robinson: He works on ML at SpaceX now, after previously working at Vercel. Lee is a great example of what I mean when I talk about “providing value” to developers. He has a way of taking something technical, explaining it through very short videos or posts, and getting developers genuinely excited about it. Have you ever opened a Developer Relations job posting and seen something like, “We’re looking for the next Lee Robinson”? Well, I have… dozens of times, literally!
Angie Jones: Angie previously was the Global VP of Developer Relations at Block, and is now the VP of the Agentic AI Foundation. She is incredibly consistent when it comes to creating content, building community around that content, and showing developers why what she’s teaching is worth learning. She’s a great example of how education and community can work together.
Aditya Oberai: He currently leads DevRel at Appwrite, and to me, he really represents the “relations” in “Developer Relations”. He’s genuine and authentic in a way he engages with developers, isn’t afraid to share his opinions publicly, and knows how to turn a skeptical (or upset) user into an advocate by listening to their perspective and changing their perspective. He’s something I look up to and a great example of what Developer Advocacy should look like. (There’s a million more great things to say about Aditya, but gotta keep this brief).