What is developer relations, you ask? The simple definition: It’s the process of building and interacting with a developer community. But this definition belies the fascinating complexity of the red-haired stepchild that developer relations can be—which is why it may be its own department within a software company. But it more likely plays a role as part of the marketing team. Or it’s assigned to a tech evangelist, or it may be split across more than one cost center.
While much is written about how DevRel is not marketing (which is true), the reality of DevRel is that the role is often under-resourced. Practitioner marketing can help developer relations.
You say developer, we say practitioner
What organizations, businesses, and DevRel professionals themselves often lose sight of in developer relations is a strategy to apply tech evangelism to create a multi-sided economic platform. This economic platform takes advantage of two types of user populations: paying customers, and developers whose interest in your offering motivates them to create third-party platforms that surround your product with an ecosystem. This makes your product more attractive to new customers, and more sticky. DevRel is a critical business strategy that supports a company’s growth and economic health by maximizing market share.
What interests us about this strategy is that it relies on a third-party developer, an expert, a practitioner—to accept and build upon a company’s product. While we aren’t experts in DevRel, we are experts in practitioners and practitioner content marketing—and so, we wade in.
Oh, the humanity
As with anything involving a person, we highly recommend beginning with persona development of the types of developers you need to attract. An approach that focuses on diversity will ensure that you cast a wide net, that you have room for developer creativity, and that you will get feedback and interaction that isn’t just more people drinking your Kool-Aid. Your ecosystem will be stronger for it.
However, even with a diverse source of developers, there may be some audiences that you need first, more, or that are easier to attract. Chances are your marketing team can help you research and build a persona. Or, you can find a firm or consultant that can focus on your DevRel requirements.
The developer experience
Reaching your developers isn’t your biggest problem. What to do with them when they come to you is your biggest problem. Before you invest in outreach, remember that they need a good developer experience in order to stick with you. This begins with your developer portal.
There are a few key steps you need to take to create a successful developer portal strategy and deliver a supportive developer experience:
- Create a budget: Cost centers aren’t fun. But remember that the role of developer relations is directly linked to top-line increases. DevRel is leading an important, sustained, revenue growth strategy. Fight for budget.
- Taxonomy is important: The structure of the content found in your portal is just as important as the content. Create a fit-for-purpose information architecture that is predictable, intuitive, and also flexible.
- Assume multiple entry points: Like most things marketing, you can’t deliver your message in just one form. In the case of your developer community, you have to be able to provide the information they need in multiple formats so that it doesn’t matter how they come to it. Docs will only work for existing API users. Use cases don’t give enough detail for the developer diving deeper, and promotional content won’t get someone to “hello world.”
Making use of practitioner marketing strategies, content, and authors
You aren’t necessarily selling something to your developer community, so you may feel like a practitioner marketing strategy misses the mark. You aren’t using content to persuade your developer community toward anything. However, you do want them to stay.
Practitioner content marketing has one underlying principle that makes it an effective strategy for marketing—the empathy practitioners have with a developer audience. And that empathy IS something you need to harness in developer relations. Sit back and let a practitioner from outside your organization empathy-write the content you need to keep your developer community engaged and developing.
- Documentation: Your internal developers are probably great at documentation—but they are often documenting for another in-house developer. For the developer new to your platform, that’s probably not so useful. Enter a practitioner—another developer from outside your organization who can write documentation from the perspective of someone new to using your platform—content that is technically sound and empathetic.
- Use cases: Use a practitioner who can write from experience. Someone who can write tailored content with specific common examples, including vertical markets you want your developers to develop for.
- Blogging: Practitioner blogging is the best peer-to-peer communication channel to share how to leverage tooling. And a good practitioner blog will get to the nitty-gritty and talk about the real-world challenges of implementing frameworks and APIs.
- Running code samples: Again, nothing proves like social proof. If an outside developer can pull together compiled and running examples of the API in action with existing apps, your nube developer will be convinced they can, too.
- How-tos/Walkthroughs/Code samples: Let a practitioner outside your organization deploy their developer empathy and expertise to create step-by-step examples or modifiable source code that developers can use to build the skeleton of their application.
- Case studies: If you can find a practitioner who has used the technology, then run—don’t walk—to them and beg them to write about it before you assault your new community with the potential of your platform.
The good news is that building a developer portal is mostly a science (with the exception of promotional material and running samples). But it does require a lot of effort. That is why we offer turnkey developer portal creation services so that organizations that need a credible and quality destination for developers (without selling to them directly) are not left with a developer portal which is more of a risk than a benefit.