Towards An Integrated Developer Marketing

April 01, 2023

Who are we talking to?

At Gatsby a perennial, fierce debate centered around the question: who are we talking to?

Various groups within Gatsby each had different answers:

Open source engineers were quite comfortable having topical conversations in public -- responding to Github issues and pull requests, and chatting in community Discords with whoever showed up there.
Developer relations folks, usually converted engineers with strong communications skills, thrived at talking to individual developers in scalable ways: writing documentation, building code samples and starter projects, recording video, broadcasting on Twitter, and so on.
Solutions engineers who worked with our customers got really good at talking to technical leads. Over time we learned how to pull knowledge out of their heads and turn it into best practice guides, technical deep dives, and reference architectures.
Traditional marketers tended to feel most comfortable talking to project stakeholders (in our case content authors, demand gen, security, IT) and decision-makers (in our case marketing leaders, agency owners, and the CTO), via business-focused case studies and webinars.

After years of watching, participating in, and moderating these debates, I now think that all of these groups are right:

In the beginning, all Gatsby users were open source enthusiasts and hobbyists building personal sites, so we needed open source contributors who could answer community members' questions 1:1 (thanks Mike and Lennart!)
When we started a company, we still needed (1), but we also needed DevRel to talk to developers at scale through blog posts, articles, podcasts, documentation, etc. (thanks Jason and Megan!)
When we started building a cloud SaaS, we still needed (1) and (2), but we also needed marketing to build a mailing list and start reaching software buyers. (thanks Linda and Aron!)
When we started scaling our sales efforts, we still needed to do (1), (2), and (3), but we also needed sophisticated technical marketing aimed at tech leads, so we started to pull in our customer success team to help (thanks Ben and Grayson!)

Putting it all together

When you combine all of these perspectives, the end result looks something like this:

Developer tools users and customers have a spectrum of personas, ranging from pure technical to pure business: from open-source & developer enthusiasts, to IC engineers and hobbyists, to tech leads (who lead and champion a project), to project stakeholders (who need to be bought into the project), and business decision-makers (who control budget).
Different groups internally (open-source engineers, DevRel, solutions engineers, traditional marketers) naturally speak in different ranges along this spectrum, with associated content types.
These ranges are distinct, with significant overlap

Integrated developer marketing occurs when these groups work harmoniously together to create a complete journey for users and customers.

Do you need integrated developer marketing?

Quite possibly, you don't!

Until you have two dozen customers paying you five figures, you probably don't have solutions engineers or know best practices. (Though if founders or other have strong opinions they should share them!)
Until you are building a product that you'll charge for, you probably don't need a marketer to build deep audience engagement (although you should still build a mailing list and send updates!).

But, by the time you hit Series B or C, it's common to have the opposite problem -- fragmented marketing.

In these orgs, two or three different groups coexist, but with strongly differing opinions. They maintain an uneasy peace. Conflict flares occasionally, triggered by budget discussions, incoming or outgoing marketing execs, or ongoing campaign messaging.

How fragmented developer marketing gets worse

In addition to being bad for morale, fragmented developer marketing leads to another problem. When companies hit series B or C, they want to scale out their marketing organization, hire a senior marketing exec, and give them a large budget.

But...what to do with it?

DevRel isn't noisy internally, and in any case senior leadership doesn't really see how that function would scale much beyond a couple folks. Maybe they add a dedicated community manager alongside the chief evangelist and docs engineer.

Marketing is noisy internally, so it's easy to deploy the money there. The CMO starts adding folks in a variety of areas -- organic, paid, growth, demand gen, product, partner, content, events, PR, analyst relations....

And now the pendulum swings in the opposite direction.

Since the ratio of non-developers to developers in marketing has increased substantially, the company's communications start to sound more corporate and less developer-focused.

DevRel folks notice this shift, and get demoralized. And the developer community notices that the company isn't broadcasting much on the channels they pay attention too.

On the other side, marketing now has a lot of resources, and they start aiming straight for their target -- the buyer. Their efforts meet with some success, but a lot less than they were hoping for. They reach some buyers, who kick the decision over to the tech folks, who scratch their heads.

Yes, they've heard of this technology, but it seems mostly like a Silicon Valley thing. They can't really figure out how they'd put the pieces together in an organization like theirs. And if they went with it, it would be their necks on the line.

Thanks for the introduction, the buyer's tech folks tell the business leader. It's promising technology, but we're not sure it's there yet, at least for our company. We'll keep an eye on it, though.

This pattern repeats across dozens of opportunities. Deal cycles drag out. Pipeline grows linearly, not exponentially. 18 months after they started, the marketing exec sends a company-wide Slack message. I've been incredibly grateful to be part of our journey....

To resolve fragmented developer marketing, lean on sales and solutions engineers

The group with the power to resolve the marketing team's conflicts, ironically, does not sit in the marketing organization at all.

To resolve their standoff, marketing needs to focus on the tech lead. Numerically, there are many more tech leads than business buyers. They're also easier to reach, and have the ability to build small projects and proof of concepts without needing approval.

They may even be open to having conversations to people having Sales in their title, as long as they believe those conversations will yield useful information. (Understanding the attention-for-useful-information-trade is a fundamental principle of marketing to engineers)

And if their initial projects are successful, they may be willing to introduce you to others in their organizations.

Problem is, marketing doesn't really know how to talk to this tech lead.

Sure, DevRel knows how to talk to IC engineers. But this person has problems IC engineers don't: whiteboarding architecture, figuring out scalability, performance, custom integrations...
Buyer messaging doesn't work either: they don't even listen to your promised benefits until they can figure out how your product would work for them.

The solution to this dilemma typically lives in the sales and solutions engineering orgs.

Over time, as a developer tools company grows, the sales engineering org builds up a list of the most common technical concerns, and how to resolve them. Meanwhile, the solutions and success engineers get a sense for the key business benefits that the salespeople promised, and figure out how to help customer tech leads deliver it.

Getting knowledge out of engineers' heads

The tricky part is making that knowledge legible. Sales and solutions engineers don't typically maintain this kind of information in sorted and organized lists. Their knowledge is encoded inside custom presentation decks, one-off Github repos, their emails, and their heads.

Sales and solutions engineers tend to be relationship-driven, mentally bucketing knowledge in terms of individual customers. So it's more useful to start by asking them who their three most recent customers were, and what problems those customers faced, than for a ranked list of the problems all of their customers face.

Talk to a few folks, and you can make a list of the top 8-10 topics, concerns, and benefits that tech leads who might consider your product are thinking about.

You also have just met a number of folks with real-world insight into how those topics have played out on a concrete level, and how your product helps.

Turning knowledge into content

You'll want to start by taking one or two topics where the "solution" story is compelling, and getting one of your sales or solutions engineers on a webinar, or to write a blog post.

The important thing is that these materials must be deeply technical. They should start with the problem, but they must show your tech lead prospects how to work through to a solution. Lists of business benefits are nice, but not sufficient.

Once you've hit the first couple quick wins, keep working through the rest of your topics.

Sales will be happy that marketing has material that answers the questions their prospects are asking.
DevRel will be grateful you're creating marketing campaigns that speak to developers.
Marketers will be happy you're coming up with technical verbiage and stories they can adapt and repurpose.

Conclusion

Resolving fragmented developer marketing, and moving towards integrated developer marketing, doesn't happen in a day, or a month. But you've made a start.

Thanks to Quinn Slack, Dustin Schau, Neha Varshneya, and Woody Selick for feedback