Developer Marketing: An Insider's Guide with Actionable Tips

I spent about a decade in roles with various flavors of "software engineer" in the title.  After that, I logged time as a dev manager, CIO, IT management consultant, and dev trainer/coach.  I have occupied, supervised, or advised literally every role in the IT org chart.

So naturally, I founded a marketing company three years ago.

That weird career transition is a story for another day.  You see, I'm engaging in the editorial sin of unsolicited autobiography with an actual purpose.

I want you to understand that this guide comes, yes, from an understanding of marketing.  But, more importantly, it comes from a deep, deep understanding of the buyer landscape.

I'm going to walk you through the ins, outs, and subtleties of developer marketing.  And I'm going to do it from the unique perspective of a long-time insider that understands marketing.

First of All, Stop Generalizing the "Developer" Persona

Let's start with an easy one.  Easy to understand, at least.  It might be harder to initially wrap your head around it, since I see an industry antipattern in developer marketing.

• "Developers hate marketing and they're skeptical of it."
• "You can find developers on Stack Overflow constantly because they're obsessed with DIY solutions to technical problems."
• "Engineers won't buy anything without reading about it in depth and trying it extensively."
• "You know how programmers are; they hate meetings and will do anything to avoid talking to people."

I read and hear these sorts of statements all the time...in the context of one marketer talking to another.

Here's a fun exercise.  Zoom out a little and imagine you're reading a marine biologist talk about the lovable, but enigmatic octopus.

You won't be able to unsee this now.  The way marketers tend to talk about developers ranges between anthropological and reminiscent of animal biology.

This tendency toward overgeneralization, however, is nonsense.  And I'll drive that point home with two simple statistics:

1. Number of software developers in the world: 26.4 million.
2. Number of Australians in the world: 25.5 million.

From a quantitative perspective, these efforts to categorize software developers are like saying, "You know how marketing to Australians is—they all have pet kangaroos and carry around giant Crocodile Dundee knives!"

So stop generalizing software developers.  They aren't octopuses that you're studying, and there are too many of them to generalize even if they were.

To Understand the Marketer-Developer Relations Baseline, Understand Recruiters

While overgeneralizing developers as a demographic isn't productive, there are certain aspects of the developer experience that you could generalize: CS degrees, bootcamps, tech interviews, etc.  But the one that I want to productively generalize here is the developer experience with recruiters.

To put a little informal data behind it, I ran a poll of our authors (who are engineers).  I asked this question, with yes or no poll options:

 In the last month, has a recruiter reached out with a job that was ill-suited for your actual skills/experience?

100% of respondents said "yes."

Recruiters Become Insufferable for Engineers

To have software development experience or education is to become a juicy target for software recruiters.  As both a former target of this relentless, transactional outreach and someone who has employed it on the hiring side, let me explain briefly how it works.

Recruiters and recruitment firms are heavily commissioned.  And they earn their pay by charging the hiring authority a roughly 20% average of the hired candidate's first year of salary.  If we call the average developer's salary $100K for easy math, that means they get $20K for each arranged marriage.

Understand, also, that software development has been an employees' market for years and years.  This makes developers hard to find and hard to pry away from their current jobs.  This, in turn, incents the recruiters to blast out insincere outreach, constantly, en masse, without the most basic research.

Hey dudebro!  Our totally gnarly client is looking for a junior rockstar coding ninja that can pull request to the max! Preferred experience is 10 years in a technology that came out 3 years ago, and I'm sending this to you in spite of the fact that glancing at you on LinkedIn would have told me you have 15 more years of experience than are appropriate for this job. And they've got ping pong tables!!!! API me over that resume, and rock on!

And it only becomes more insincere (if less cartoonish) from there.  Almost any developer will be able to share a war story about recruiters fibbing to both parties about the job to make a placement or about a recruiter giving them a high pressure sale on a job that was clearly not a fit.

Now imagine a steady flood of this in your personal inbox, on LinkedIn, and on your phone's voicemail for years.

That's how something that seems like it'd be great—people constantly offering you job opportunities—actually becomes incredibly tiresome.

Marketers Can Easily Walk and Quack Like Recruiters

As I mentioned earlier, it's impossible to generalize software engineers' collective understanding of different business roles.  Some are well aware of the difference between marketing and sales, for instance.  To others, marketing, sales, and recruiters are a faceless crowd of slick-talking parasites, trying to trick them while feeding off of the value their software creates.

It really does run the gamut.

But if you're not careful, you can smell like a recruiter to even the friendliest, "every role brings value" corner of the software developer demographic.  And then, it's all over.

At best, they'll ignore you.  At worst, they'll put your content on blast somewhere before you know what hit you.  And it's because you've created one of the few things that can unite this disparate demographic: an opportunity for shared catharsis at a near-universal downside of their chosen career.

I'm mentioning all of this to help you understand the persona that sits on your content briefs.  To really understand them.

Developers aren't "just left-brained" and they aren't born with some natural aversion to content marketing or marketers.  They're just relentlessly assaulted by patronizing insincerity, and they're exhausted by it.

So when you, a non-developer, write a blog post called "10 Reasons Every Developer Should Be on Github," you're inadvertently re-creating for them the experience of inbox spam.

You need to avoid that.  Consider insincerity, knowledge-faking, manufactured enthusiasm, and fluff to fall under a common, cardinal sin to avoid: reminding them of recruiters.

How to Segment the Developer Persona (and How Not To)

Having established deal-breaking pitfalls, let's dive into how you should approach things.  Let's talk about segmenting the overly-broad developer persona.

A few options might come immediately to mind.

• Segment by years of experience: "junior developer" and "senior developer."
• Or, maybe segment by org chart roles: "developer" and "architect."
• How about tech stack?  Rails developers, enterprise Java developers, or web vs backend developers.

Making those distinctions is better, but it's not how I'd go about it if you really want to nail segmentation.

To really nail it, get on the calendar of one or two engineers in your organization.  I say this because you've got some collaboration to do.

Work with Engineer Colleagues to Establish Personas

I don't mean to sound contrarian, but I promise that you don't understand your buyers' org charts as well as you think.  I've been a CIO, and as an IT management consultant, I actually helped actual organizations construct actual IT org charts, and I still find the complexity and variance dizzying.

Are developers influencers or gatekeepers?  Does an architect report to a dev manager or to someone else?  Do directors make purchase decisions, or only the CTO?

The answer to all of these questions is "yes."

Helpful?  Great, that's why you need help.

See if you can find engineers in your organization or in general that have resume experience at companies that look like your ideal clients.  This immediately takes you from abstract speculation to concrete examples.

Interview those folks to get a sense of what those org charts looked like, who made decisions, who owned budget, etc.  Create avatars of your buyers, influencers, gatekeepers and committees based on those interviews.  That will help you understand buying dynamics so that you can work backward toward the reader persona of your content.

Then Work With The Engineers to Segment by Beliefs about Software Development

This is where you should segment further.  But not by demographics—by psychographics.  (Here's a quick primer, if that's a new term for you.)

You want to understand what your prospective users and buyers believe about software development.

For instance, consider these questions that expose fault lines in the software development world:

• Agile: god-send, or corporate cringe?
• Is a computer science degree important?
• TDD: table stakes for professionalism or overrated?
• Is Javascript the assembly language of the internet, or is it the sloppy language of wood glue and baling wire?

I cannot tell you how powerful it will be to find patterns in how your buyers and users feel about these issues.  In many cases, you'll have an even split, but when you find the ones where one opinion correlates with enjoying your offering, you've just struck gold.

Consider, for instance, how the psychographic segmentation of "agile skeptic" can make your content creation picture crystal clear.

• Chase virality on Hacker News and Reddit with contrarian "agile is dead" pieces and earn a deluge of new fans if one takes off.
• Drive engagement on social media by asking people to vote on, say, whether things constitute "agile fails."
• In organic search, look for questions/keywords associated with researching agile so that you get the first bite at the persuasion apple for tomorrow's buyers.

But to accomplish this, you need engineers' input.  You need them to explain not just the org chart at companies like your ideal buyers, but to explain what engineers at companies like that tend to believe about software development.

Building a Content Plan

So paired with engineers to advise you, and segmentation in your pocket, how specifically do you create a content plan?  Here are some specific suggestions.

1. Start With Organic Search: What Questions Do Members of Your Segment Ask?

We generally recommend organic search as the bedrock of any developer marketing content plan.  It's the blue chip play in your content portfolio, and perfect for avoiding the so-called "flatline of nope."

To come up with a solid backlog of topics, figure out what questions your audience asks of the search engine.  These should include both topics relevant to your product and also relevant to what your audience believes and is curious about in the developer world.

This becomes the top of your funnel and how you meet a good chunk of your audience: with content specifically designed to answer their questions, walk them through tutorials, and generally help them.  With organic content, I strongly suggest outsourcing and guest blogging so that you can publish as quickly as possible.  The best time to write an organic blog post was two years ago, and the second best time is today.

2. Lay Out Strong Opinions That Bind Your Audience to You

Working with engineers to help you, you've discovered what your audience believes—their psychographics.  Working with key folks internally, use those to define some controversial opinions that will endear your audience to you.

With these opinions in place, define some (mildly) controversy-courting posts to write and share.  For instance, if you sell a tool that enables remote or asynchronous code review, you might schedule a post along the lines of "It's Time to be Honest: Pair Programming is Overrated."

This style of post becomes another way to bring audiences in and bind them to you, but this time through social media share and syndication.  Publish these on your blog, promote them, syndicate them to sites like DEV and DZone, and submit them to sites like Hacker News and Reddit.

With this style of post, you can outsource them to guest authors, but I'd suggest finding internal folks to do it, if possible.  This might be dev rel folks working for you or internal engineers.  This style of content is closer to your brand, and lets you position your people as columnists that can build a following.  (Brands, rather than individuals, tend to attract followings in the dev world).

3. Define Pain-Dream-Fix for Your Offering

With two flavors of top of the funnel content in your back pocket, let's move to the middle of the funnel.

Again, working with the engineering folks you've partnered with, sit down and talk through pain-dream-fix.  How does your product make the developers using it more awesome?  What's in it for them?

Here where we're more in the territory of product marketing, you want to tell these stories.  You can do this as case studies, but if at all possible, I'd suggest doing it with blog posts.  With the aforementioned asynchronous code review tool, write a post that shows users how to navigate a code review workflow on Github that, oh, by the way, just happens to use your tool.

In an ideal world, you can draw readers directly to these posts with the right organic strategy.  But a lot of you reading don't have the kind of product that neatly generates use cases that correspond to great keywords.  So plan to get eyeballs on this content with backlinks from your organic posts and controversy-courting direct shares.

This is another kind of post that you can outsource, but are often better doing internally, if at all possible.  It tends to have a non-trivial learning curve for the author, and with freelance software engineers, they're going to pass that cost right on to you.

4. Create Collateral to Help Your Champions Make the Sale

At some point, you've sold your audience.  The engineers reading your content trust your brand, like your offering, and have perhaps even concluded a trial.  That's incredibly important.

But it's also, in all likelihood, not the end of the story.  Rather, it's just the start of your sales cycle, where some combination of your sales reps and the engineers have to sell their leadership on opening the purse strings.

Address this with content.  Case studies are great, obviously.  But you can also create blog posts, emails, webinars, and other pieces of collateral to help both the developers and your sales team convince the monetary buyer.

If the engineer is sold on your remote code review tool, she'll appreciate a blog post about how to manage up when it comes to such tools.  I have firsthand experience with this, since I literally still earn royalties on a course I made six years ago, helping engineers sell tools and practices to their management.

Of course, you need collateral for your sales reps.  But don't sleep on enlisting enthusiastic engineers to help you with the sales process.

5. Create a Developer-Savvy Promotion Plan

You've now got all of the content components in place.  Organic posts on your blog will bring a steady supply of traffic, and your opinionated posts will bring in spikes of it, while endearing your audience to you.  From there, you're building trust as developers interact more with you.

But you want to make sure that you're creating and distributing content efficiently.  You want to work with the engineers helping you, again, to understand your audience's digital haunts.  And you want to get content to those channels as regularly and easily as possible.

Here is a quick list of things to do to wring everything out of the content.

• Identify syndication-driven and share-driven sites where your audience hangs out, and form a plan as to which content to promote there (definitely all of your shareable content, but be leery of syndicating organic content).
• Comb your posts for good quotes that you can turn into graphical pull quotes.  This helps SEO in organic posts and it also gives you material for social media.
• With the posts that you write, brainstorm what sorts of questions they might answer on Q&A sites like StackOverflow and Quora.  Especially with organic posts.  If you can do it helpfully and as a good citizen, add links back to your posts as answers or comments.
• If you have the bandwidth, have someone in your organization make videos, facing the camera, where they talk through the points covered in blog posts.

These are just a few of the things you can do, but it should get you started.

Developers Are the Key to Developer Marketing

If you've noticed a theme throughout this post, it's that I've advised having your software engineer collaborators sitting with you through all of this planning.  That's no accident.

It's become common for developer tools companies to enlist engineers to write content.  That's old hat.  But having them participate in keyword research and content strategy is relatively uncommon.

I know that it's uncommon because it's what Hit Subscribe does for its clients, and it's proven to be a massive differentiator as we've grown over the last few years.  At every stage of our process, we involve engineers —subject matter experts—because of their deep understanding of the nuances of reaching the audience from which they hail.

So as you create and then execute your plan, make sure you're involving engineers at every step.