This article is based on Chris Churilo’s insightful talk at the Developer Engagement Summit. As a DMA member, you can enjoy the complete recording here.
Selling a developer tool is a challenge like no other. Developers aren’t swayed by flashy ads or aggressive sales tactics – they want tools that genuinely solve their problems and make their lives easier. That’s why a bottoms-up approach is so important.
By focusing on empowering developers to experiment, build, and succeed on their own terms, you create advocates who’ll champion your tool from within their organizations.
I’m Chris Churilo, VP of Developer Relations, technical content, and marketing at Zilliz, and over the years, I’ve learned this the hard way. I’ve made plenty of mistakes trying to engage with developers – some small, some pretty major. But those missteps taught me some of the most important lessons about what works (and what doesn’t) in developer marketing.
In this article, I’ll walk you through six of the biggest mistakes I’ve made or seen others make when trying to sell to developers. From gating content to overly salesy tactics, we’ll dig into why these approaches fail and how to do better.
You’ll get insights, laughs, and, hopefully, a roadmap for building trust and driving success with your developer tool.
Let’s jump in and make sure you don’t fall into the same traps I did!
Mistake #1: Gating all content
If you’re marketing to developers, here’s one big mistake to avoid: gating all your content. Seriously, don’t make it hard for developers to access what they need. Let me share an example of when I learned this lesson the hard way.
We had a great downloads page for our open-source project. You didn’t even need to go to our website to download anything – GitHub made it super easy – but we went a step further and created a dedicated page optimized for search engines. That way, when people Googled how to download our stuff, they’d land on our page.
I had included an optional form on the page. The idea was that if someone wanted to, they could fill it out – but there was no obligation. After all, it’s open source!
Teresa Garanhel
Well, my demand generation colleague wasn’t thrilled about this. She wasn’t hitting her MQL (marketing-qualified lead) targets and decided to make the form mandatory without telling me.
The next morning, I woke up to 13 hours of hate mail from our community. People were furious. “This is open source! How dare you gate this!” they wrote. So, I confronted my demand gen colleague. Her response? “We have obligations to our board. They gave us funding, and we need to hit our numbers.”
This was a turning point. I had to explain why this approach doesn’t work for developer-led marketing. Developers value open access. They’re used to transparency and self-service, and they don’t appreciate being forced to jump through hoops for something they can easily get elsewhere – like GitHub.
Make forms optional and offer value
We immediately removed the mandatory form. Instead, I made the opt-out even more obvious by putting a large "X" on the left side of the form, making it clear that filling it out wasn’t required.
But here’s the twist: I added a reason for them to fill it out.
The form now said, “Want stickers? Fill this out!” Developers love swag, so it gave them a compelling reason to engage. We also added a ton of resources – guides, how-tos, and useful content – all available without requiring people to fill in a form.
The results were incredible. Even though the form was optional, about 95% of visitors chose to fill it out. Why? Because they saw value. We weren’t just asking for their information; we were giving them something useful in return.
The lesson: Don’t take without giving
The backlash taught me an important lesson: developers are repulsed by the idea of giving you something – like their email address – when you’re giving them nothing in return. Open source is about openness. If they can get what they need on GitHub without hassle, they’ll wonder why you’re making it harder.
So, don’t gate your content without a good reason. And if you do, make sure you’re offering something genuinely valuable. It’s a win-win approach that builds trust and goodwill.
Mistake #2: Letting the exec team lead developer events
Let me tell you about another big mistake: handing the reins of a developer-focused event to your executive team.
We once planned a roadshow aimed at our users. The idea was to pack the event with hands-on training, deep dives into code, and tangible takeaways – but then the exec team got involved. They insisted on leading the talks. The CEO opened the event. The CTO followed with a presentation. The VP of Product gave a roadmap overview.
And what happened? Our audience – the developers – quickly checked out. Within minutes, most of them were in the lobby with their laptops. Why? Because they weren’t there for five hours of corporate presentations. They came for hands-on training and the chance to engage with the tools directly.
The lesson: Focus on developer needs
This experience drove home a critical lesson: when planning developer-led events, you have to think like your audience. Developers don’t care about roadmaps or executive panels – not at this stage of their journey. They’re there to learn, build, and see if your product can genuinely solve their problems. They want to get their hands on the code and see it in action.
Convincing executives to step back isn’t easy, but it has to be done. I’ve had to have these tough conversations, explaining that while their intentions are good, their approach doesn’t align with what developers want. You’ve got to frame it in terms of outcomes: If we prioritize training and hands-on sessions, we’ll build trust, engagement, and long-term loyalty.
Here’s a great example. A friend of mine, who works for Zoom, recently started hosting developer meetups. His exec team wanted to kick off the event with a CEO keynote followed by an executive panel. I told him, “Don’t do it. Trust me, it’ll be a disaster.” Thankfully, he took my advice and convinced the CEO to deliver a short, five-minute intro instead.
The result? Their first meetup drew over 250 attendees, and the event was a hit. The focus stayed where it needed to be – on the developers, their needs, and the value they could gain from engaging with the product.
Mistake #3: Building a community and only talking about your product
This one’s a classic mistake. You decide to create a community – maybe with a series of meetups, an influencer program, or something similar – and it’s all about your product. You name it after your product, and every event or discussion is focused solely on your product because, naturally, your product is super important, right?
But here’s the thing: after one or two events, no one comes back. Why? Because it’s boring.
