How to Do Developer Marketing That Doesn’t Suck

Today we’ve got a special guest on the blog — Ceci Stallsmith! If you were at API Mixtape 2023, you got to see her in action as a speaker. If you missed her talk, you’re in luck, because today’s post is covering the same topic: how to create developer marketing that doesn’t suck. 

Take it away, Ceci: 

This post explores specific ways to make your developer marketing notably not bad — maybe even good! Read on to learn about what to do (and what to avoid) to hit the mark with your developer audience. 

Things to avoid: the bad 

Bad 1: Tone-deaf content

💫 Join the movement, create customer magic, drive success, better-together, instant innovation, unleash the power, the platform of platforms. 💫

Phrases like these are why people say that “developers hate marketing.” Tone deaf copy is, in my opinion, the greatest offender in the world of bad dev marketing. 

You can always tell when marketing content was written and built by someone who doesn’t think about, talk to, or understand what motivates developers.

Example 1:

if(developer.isGood()) {
 while(developer.looksForJob()) {
  return yourCompany.hires(developer);
 }
}

If you show this hiring plea to most developers, especially “good” ones, it feels overly try-hard. It looks developer-y, it’s code! But it repels. You could say this is “code-washed” — the marketer thinks they’re speaking the developer’s language, but their assumption is in error.

Example 2:

Companies often hire B2B marketers with track records of successfully marketing to enterprise buyers. Sometimes these marketers use phrases like “strategic alignment” and “drive success” and “join the movement” and “create customer magic.”

Those aren’t inherently bad words.

They are actually great words for enterprise software buyers. In fact, I took most of them from the Salesforce homepage! But these aren’t words you hear from most developers. If you need to market to both enterprise buyers and developers, consider having different “venues” for doing so (a separate blog, a community of developer users, etc.), along with creating different style guides for each audience. 

Example 3:

Companies hire a big-budget, brand-heavy marketing agency, who then comes up with things that look and smell “developer-y.” They probably put brackets <> or slashes // in front of the logo or on pages developers will see. Again, they aren’t actually talking to developers, they’re just doing things that feel “developer-y” to them. It’s like adding Helvetica to a page on your site to appeal to designers — because designers like Helvetica, right? 

Developers come in many flavors

One more note before I turn the tables: there are many, many types of developers. “Developers” aren’t one, single audience. There are frontend developers, backend developers, data engineers, and DevOps, to name a few. Even within those buckets, developers have varying language preferences, levels of seniority, and expertise. “Developers,” without any qualifications, is not a valid audience. If you’re targeting developers, dial in an understanding of what types of developers you’re working with. 

Good developer marketing copy is concise, uses language that your target audience uses, and focuses on their actual pain points. Good developer marketing is done by people who work with, get feedback from, and understand developers. 

I wish I could share some cringe examples out in the wild…but that would be too cruel. Let’s look at good examples instead:

AWS: I have a lot of respect for AWS’s product marketing. They aren’t as cute as some companies in the dev space, but they are gloriously straightforward. The copy cuts right to the value, with no jargon. Knowing their user, they are not afraid to expect their audience to do some reading. If you’re feeling lost, copy AWS’s style and you’ll instantly be in better shape. 

Vercel: Vercel’s homepage is another example of great audience awareness and quality product marketing. Unlike AWS, they bring a bit of personality to the table. The copy doesn’t get lost in personality, though — it tells us right away (1) who the product is for and (2) what it can do for me. Again, no jargon that makes my eyes glaze over.  

Now – let’s look at the two examples together through the lens of understanding your audience. AWS and Vercel are trying to attract different types of developers. Vercel’s homepage is super smooth and focuses on getting straight into the action. They’re nicely packaged up and make me feel like I could use their product, even without being an expert. 

If AWS used Vercel’s homepage vibe, it would frustrate users. Vercel is targeting individuals who want to bypass the hassle of setup. Their focus is on developers of varying skill and experience levels, who are looking for a solution that internal stakeholders can use without it being too technical to access. AWS, on the other hand, is not trying to position itself for beginners. Their content is deeper, more descriptive, and more heavily technical — right off the bat.

Bad 2: Do nothing

Developers hate marketing, so let’s just not do it. 

Actually, a number of very successful developer companies have taken this approach.

There are companies that “do” this and succeed, so I want to be careful on this point. Here’s my thesis: even if your company doesn’t have a marketing team, you are doing marketing. Marketing is how you show up to the world, the way you talk to the industry and users, and the way your product gets discovered. You don’t need a card carrying marketer in order to “do” marketing. 

But, if you don’t have anyone who: 

1. Carries the brand or cares about how the company looks and feels to outsiders
2. Can effectively position the product (explain what it does and why use it on a website, blog, etc.)
3. Can help the company win more developers over 

Then it’s time to figure out how to do developer marketing. This can mean hiring DevX, or “growth!” or actual marketing, I don’t care what you call it.

Worst case here: 

1. If you build it, they usually won’t just come (unless you built OpenAI or a product with ridiculously good product-market fit) 
2. You look messy and inconsistent externally, which doesn’t engender trust
3. Some developers can use your product, but a lot of them either never hear of it or, if they do, they find it confusing or unappealing and move on quickly

So, consider your company. Who might be doing “developer marketing” without the official role? How can you enable them to do it more? If you do hire a marketer, but feel that you’ve been doing a decent job with your developer brand, make sure that the new marketer sits down with each of your shadow marketers to understand the look, feel, and language of your “developer brand.” Some of the best marketers I’ve met don’t have marketing titles. They’re DevRel, widely read CEOs, devs or PMs on Twitter/X, and developers who frequent and write on HN. 

Bad 3: Try to out-market a weak product

This can work in enterprise and consumer land — you can out-market a weak product in the short run. Influencers can push thousands of units of products before consumers realize that they’re wasting money. Sales teams can close annual subscriptions that might not renew.

But with developer products…you can’t do the same thing. The user (developer) is too intimate with your product and too picky to deal with junk. If the product isn’t there, fix that first. This sounds obvious, but sadly isn’t at many companies. 

One big exception: if you’re building an ecosystem, you can have a bad platform API and acquire developers if you are winning them users. This can be abided. But you can’t have a weak developer tool and expect marketing to solve that problem. 

So, don’t:

• Over promise
• Avoid investing in documentation or DevX 
• Try to be super cute without delivering value

Bad 4: Forget about the other audiences

Developers don’t build in a vacuum. Product managers, security teams, procurement, legal, etc. are all part of the process — don’t forget them. They can be surprising champions! Beware of alienating these audiences. Give them on-ramps with your product, even a landing page or friendly blog post that helps them understand why they should want to hang out with you. Giving a non-dev audience the chance to look cool championing your product is a win. 

Developers tend to consume developer products, but other stakeholders do access them and block or approve their use. A couple of examples of companies that have kept secondary audiences in mind:

• When it comes to Twilio, developers care about the API for sending texts, but a product manager is worrying about deliverability and ability to send to WhatsApp — both audiences need to be won over.
• Figma (I know, designer product, but hang with me) has done an excellent job with extending to non-design audiences. The core product is readily accessible to non-designers (unlike many other design tools), so the non-core user still has a great experience in Figma. And FigJam is their product for everyone, bringing periphery or secondary users in as newly minted product champions.

So, what’s good? 

Good 1: Show, don’t tell

The consummate thing to learn about developer marketing is “show, don’t tell.” Developers want to build and they’re a sophisticated audience. Your goal is to unblock them with marketing, and literally showing the product in action is one of the best ways to do that. 

Show the code snippet. Show the product doing something. Help the developer “get it” and they will get started.

Example 1: Retool. ReTool’s homepage shows the drag and drop power of their product in action, front and center. The video is even partially above the fold, so users barely have to scroll to see the mini-demo.

Example 2: WorkOS showcases their APIs and language support:

Example 3: Astral. Maybe my favorite example, here’s a screenshot from the Astral homepage. They’re demonstrating just how fast RUFF (a Python linter) runs with a literal speed test — excellent showing.

Good 2: Your marketing site matters, but your docs REALLY matter

Say what you want, Stripe has built the most iconic developer brand of the last decade. What made them so amazing? My take: docs.

Great docs:

1. Are clear and well written, well ordered, and have good information architecture. It is really easy to end up with hairy, messy docs that are too long and hard to parse, or don’t explain enough. Invest here. 
2. Have excellent samples to pull from quickly. Again, unblock your audience. If they want to try it out, make it easy for them. Add links to a product like Codesandbox or Replit to let people try the product out right away.   
3. I defer to ReadMe’s guidance on building great docs. They do it for tons of companies and Greg is one of the most thoughtful DX people in the business. 

Good 3: Be succinct

This is the opposite of the first “bad,” which is to be tone-deaf, and is also part of what makes for good docs, but it needs to be repeated. Be ruthless about marketing copy. Eliminate jargon and business lingo. Speak plainly. Be technical. Speak like your audience.

How can you do this?

1. Conduct user interviews. It’s so basic, but if you have developers who use your product, then interview them, understand them, and literally record their words. Make sure your copy matches their tone (as a group). So many companies don’t talk to users. Don’t be that company!
2. Use the Hemingway tool to trim your writing down. Or try an AI writing tool. There are a lot of them right now. Somehow I didn’t use one to write this post and feel like that was a little dumb. 
3. Run content by your dev team. If they cringe, edit. 

Good 4: High-value content marketing

Fluffy content marketing like listicles are not going to pay off for your team. Do content marketing like Fly.io, Honeycomb, or Earthly.dev.

What makes it good?

They’re serving up steaks. Their writing is technical and they understand what they are talking about. There aren’t paragraphs of fluff to wade through in order to get something of value. It’s harder to write technical content with depth, but will drive your content engine: fueling impressions, SEO boost, and overall growth of your audience. Writing puff pieces to try and fill a content calendar won’t get you anywhere.

Fly.io has great content. These articles are specific and they explain how to solve a real problem. Best of all, they are not written for SEO bots, but for real humans. Here’s a great example — this is a 25 minute read, but with a lot of real, valuable information. Yes, SEO will pick it up because there are keywords in it, but that post is written for a human to consume.

Good 5: Provide a variety of on ramps 

Provide everything from drag and drop or copy/paste integration options to totally raw endpoints. Why? Developer use cases vary. 

Stripe is, again, a great example here. They have options and instructions for everything from adding payments with no code to building the full, robust, customized integration with their APIs. You might be surprised to find that often the people using the no or low-code options for your product are actually highly technical developers! Your product is often a small step in a bigger project, and making it really easy to integrate with or build on can help them move on to other technical challenges. 

Your audience may also have different levels of skill and/or desire to build with your product. Be ready for both! Provide:

• Samples of varying level
• Quick starts
• Copy paste options 

See Stripe’s many levels of getting started:

And Plaid’s quick-start guides:

Let’s conclude

I hope this guide is helpful! What else would you add to the list? Any further sins or virtues of developer marketing that you consider?

Send us your examples of excellent developer marketing — whether you’ve built them as a team, or you’re admiring them from afar! We want to showcase more companies succeeding at this work. Don’t be a stranger: [email protected].

Thank you, Ceci! 

If you want to learn more about Ceci, you can check out this post in its original home, browse the rest of the Calyx Consulting Substack, check out the Calyx Consulting site, or follow Ceci on X.