Most days for the last 10 years, I can reach into my pocket for a small, galactic-looking object. It looks a bit like a tube with closed, rounded ends. Once out of my pocket, I can pull it apart into two pieces. One of them, previously within the object, is the tip of a pen. A Fisher Space Pen. It allows me to write upside down—or in space if I ever find myself there long enough to take notes.
There’s an old joke that NASA paid millions of dollars to develop this anti-gravity pen. Meanwhile, Russian astronauts just use a regular old pencil. While that’s not exactly the history, the core argument against an overly-complex solution resonates with people.
To reach developers, you might be tempted to over-engineer the solution: travel the world with the biggest booth in the expo hall, throw advertising dollars in the direction of a huge community, and shout from the rooftops (or internet equivalents) to spread the news of your developer product as widely as possible. But typical marketing tactics like that will fall flat with a technical audience. You can’t promote your way to developers; you need to educate and inspire them, which you do when you:
- Start with DX
- Treat Your Blog Like The New York Times
- Delete “In This Tutorial, I Will…”
- Guide Developers to Build
- Use Puzzillas from Mansilla at Events
- Think of Open Source as a Competitor
- Use Tools as Marketing
- Bypass Developer Ad Blockers with Sponsorships
- Developer Organizations Require Empathy
These recommendations comes from the short podcast series I recorded. Each episode is less than 10 minutes and discusses a chapter of Developer Marketing Does Not Exist. You can do most of the ideas in the book, podcast, and this post without getting on a plane or spending hundreds of thousands of dollars. So, let’s get started, aptly, with developer experience.
1. Start with DX
Developer experience (DX) is foundational. Even if you’re doing developer content, when you attract developers to your content and eventually to your product, they’re going to discover your developer experience.
If they have a poor experience, then you’re putting a lot of effort into attracting people when they’re going to just fall out and not do what you want them eventually to do. Of course, the idea of content is to attract people. But eventually, you want them to actually use the product.
While this seems counter to our philosophy of education first, you want to educate on topics that connect to the actual usage of your product. This makes the developer experience a really important piece.
Developer experience is the first (and longest!) chapter of Developer Marketing Does Not Exist… but is DX really marketing? I answer that and talk about the most important DX criteria in episode two of the Developer Marketing Does Not Exist podcast.
2. Treat Your Blog Like The New York Times
Blog posts are often the only thing people think of when they think of developer content. But do developers even care about company blogs? The posts you publish are the most likely way for a developer to find you in the first place—if you approach them in the right way.
It can be helpful to look at your blog as a publication. And the difference between a company blog and a publication is your focus. Instead of “here’s the latest from your company,” think about it like “here’s the latest information that someone who’s reading this publication might care about.”
Even though a developer might not use your blog as a publication, it can be really helpful to think about it the same way that The New York Times or any other publication that you might read thinks about it.
There are certain areas that you’d cover and others that you don’t. That’s what makes you a publication. Being able to understand what the right developers would want to see in a publication and then providing those.
More about how I recommend approaching blogs, along with how to find writers and how many posts to shoot for in episode three of the podcast.
3. Delete “In This Tutorial, I Will…”
How many tutorials have you seen that start, “In this tutorial, I will…” and then they jump right in? Another common line at the end of a tutorial is “Now I told you how to make the thing.” The structure of a tutorial involves more than just the steps:
- Explain the context
- Show the end result
- Walk through the steps (with headlines)
- Tell me what’s the next step
This structure is the same for every tutorial, though not every tutorial has to be identical. Stripe and Twilio experiment with the format, which I talk more about on the podcast.
4. Guide Developers to Build
Blog posts, tutorials, and now guides? You may be wondering about the difference. In fact, “guide” is a bit of a misnomer. You might see a getting started guide and think of a certain length. But that type of “guide” is basically a tutorial.
This type of guide is different. Done well, each one is its own little section of a site. Essentially you want to describe a problem that might not be entirely a developer problem. It’s a larger problem that requires a developer to be able to fix it.
A great example is Gremlin’s Chaos Engineering Guide. It tells a developer everything they need to know about implementing Chaos Monkey and chaos engineering in their team. It’s almost 20,000 words long with a bunch of different sections in it. It includes a tutorial, but the whole thing is not a tutorial. It’s a much bigger piece of content that attracts a lot more attention, gets links, and ranks much better.
And the way that we recommend doing it—which the Gremlin guide does—is through what I’ve called the Developer Content Mind Trick.
5. Use Puzzillas from Mansilla at Events
An event could be the first (or most impactful!) place that someone hears about your product or company. So you should go into an event with the same mindset as the rest of your content in order to attract developers.
Some of the best approaches I’ve seen from conference sponsors have included puzzles or similar contests of skill. Developers love to tinker with problems and figure out how things work.
If you can inspire them to grapple, you’re more likely to make a lasting impact. Sure, entice them with a prize, but it’s secondary to the experience.
Almost 10 years ago, when Neil Mansilla worked at the API management tool Mashery, he’d create such puzzles. You’d have to look in API headers and take the results from one API call and put them into another API call to solve them. When people would get stuck, guess where they would come to ask questions? The Mashery booth.
In the end, everyone who submitted the completed puzzle was entered into a drawing, resulting in a huge crowd around the booth, waiting to see which of the puzzle masters got the prize.
That’s a far cry from your typical expo hall booth.
6. Think of Open Source as a Competitor
What company doesn’t run on open source? While the web is all made of open source, not much of that is related to your product. So let’s think of how your own product does relate to open source projects.
Like most people, your product itself is likely not open source. But there might be a huge open source ecosystem around your product and the problems that your product solves also.
Much like the Developer Content Mind Trick, you want to think about how will a developer use open source instead of your product. So thinking of open source then, as a competitor, essentially to using your product paying, being a paying customer of your product.
In the open source and community episode, I further discuss how to use the Developer Content Mind Trick to think of open source as a competitor. I also explain that the developer currency is knowledge (and altruistic knowledge sharing).
7. Use Tools as Marketing
Tools are different from your product, just as using tools as marketing is different than having a great product.
A smaller tool that acts as more of an entry point to the next step of using your product can be really functional for developers. They want to share them and link to them. It gets awareness, not only from developers in general, but from the right types of developers who might go on to use your product.
Runscope did this and its founder, John Sheehan, had three rules that go along with using these tools for marketing:
- Don’t require a sign-up
- Do one thing well
- Make it free
The third one is how using tools as marketing is different from your product. While you might have a free trial or even a free version, eventually you want developers to use your product enough to be willing to pay for it.
I talk about two more rules to add to the Runscope playbook in the book and the companion podcast episode.
8. Bypass Developer Ad Blockers with Sponsorships
Developers are well-known for installing ad blockers. They even seem to have their own ad blockers built internally into their brains to filter out promotions. So how can you buy your way into interacting with developers?
Sponsorships are more likely to work with developers than advertising. When you find the right communities to sponsor and then show you’re there to support that community, answer questions if they have them, and that it makes sense for you to be involved in that community, you’re adhering to the developer currency of altruistic knowledge-sharing.
Sponsorships are a much smoother way to be able to work with developers and get the same sort of impact of advertising dollars, though I talk more about how you could use the same approach to improve actual ads on the podcast.
9. Developer Organizations Require Empathy
When it comes to your developer marketing organization (yes, I referred to it as developer marketing, even though it doesn’t exist), most people want to know, “What’s the least I need to get started attracting developers?”
You can begin publishing content if you want. But more often than not, the better avenue is to starting to think about how you want to reach those developers:
- What are their problems?
- What type of developer are they?
- What language(s) do they code in?
If you can answer some of those questions, you’ll have a much better chance of creating content that will actually matter to the audience you want to reach.
That empathy is a key piece, not only of your strategy to reach more developers, but what you look for in the roles that you put together in your marketing organization that happens to be trying to reach more developers. That is, in addition to determining where you fall on the developer marketing continuum.
Three Next Steps to Attract Developers
Blog post headings or book chapters titled “Introduction” or “Conclusion” waste an opportunity to summarize the posts, or to get a call to action after someone has read all the way to the end. Now that you’ve read through the nine ways to reach more developers with your content, what actions should you take? Here are three:
- Read the book
- Take action based on reading it (or at least skip to the last chapter which contains actionable steps)
- Reach out to EveryDeveloper
If you want to amplify what you’re able to do and help your team attract developers with authentic content, you really should do the third step and reach out to the EveryDeveloper team. This is what we do and we love working with developer companies like yours. Find us at everydeveloper.com.