DevRel Strategy - A Comprehensive Guide

So, DevRel Strategy?

So, you want to build a DevRel strategy? Great choice! This comprehensive guide will walk you through everything you need to know about creating and implementing effective Developer Relations strategies. And I mean everything - from understanding where DevRel sits in your org to measuring its impact and scaling your community. We've been covering DevRel Strategy in our Fundamentals section already, but this post goes way deeper. We'll use frameworks like OKR(A) to measure success (more on that here) and real-world examples to show you what works (and what doesn't).

A well-crafted DevRel strategy isn't just a nice-to-have - it's the foundation for building strong relationships between your company and the developer community, driving adoption, and fostering innovation.

Here's the thing: without a solid strategy, you're just throwing things at the wall and hoping something sticks. We've all been there, but that's not what we want. What we want is a clear, actionable plan that helps you build meaningful relationships with developers while delivering real value to your organization.

Grab a coffee (or tea, I don't judge), and let's dive in. We've got a lot to cover and it will take some time.

---

What is a 'DevRel Strategy'?

There is no one definition of what a DevRel Strategy is. Instead, it's a collection of activities, initiatives and goals that align with the overall objectives of the Developer Relations team.

A DevRel Strategy is:

Great, now we know what a DevRel Strategy is we can start to think about how to create one.

---

Key components of a DevRel Strategy

This post will cover the following key components, click on each to jump to the section. I highly recommend reading them in order to get a good understanding of the DevRel Strategy process.

1. The Beginning
2. The Objective
3. Audience & Needs
4. Developer Journey Map
5. Timeline & Milestones
6. Feedback Loops
7. Measuring Success & Reporting
8. Community-Centric Approaches
9. Content and Education Strategy
10. Hiring
11. Tools and Tech

---

The Beginning: Where are we?

Understanding Where DevRel Sits

Before defining objectives, it's crucial to understand where DevRel sits within your organization. Based on my survey of 30 companies and protocols acting in crypto, web3 and AI, the organizational placement varies significantly:

Center of Developer Relations in Organizations

The survey results show an even split between Marketing and Engineering departments as the primary homes for DevRel teams, followed by Product Management. Some organizations have established DevRel as its own independent department, while smaller percentages operate within Customer Support and Growth.

But how do you know where to put your DevRel team?
Here are some questions that can help you decide:

• Do you have a product that needs to be adopted by developers?
  Maybe you should put DevRel in Engineering to get the developers to use your product and give them the best possible onboarding and enablement experience. Engineers are the ones who build the product after all. And the

• Do you have a community that needs to be built and nurtured?
  Maybe you should put DevRel in Marketing and work on content, community and events.

• Do you have a need for education and enablement of developers?
  Maybe you should put DevRel in Product Management to create the best possible onboarding and enablement experience.

• Do you have a need for evangelism and promotion of your product, protocol or company?
  Maybe you should put them in Marketing to promote it.

• Do you have a need for technical support and customer success?
  Maybe you should put them in Customer Support to provide the best possible support to your developers.

Remember: This is just a starting point to help you understand where DevRel can sit in the org. We will cover some of these questions in more detail later.

---

Primary Focus Areas

Okay, so we know where DevRel sits in the org. Now, what are they doing? If you're someone who's been around DevRel for a while, you'll know that the focus areas vary significantly. Many times the people you're talking to will tell you they do "everything" and it's hard to get them to focus on one thing. This is what you want to avoid. Make sure to focus on what's important for your product, protocol or company.

My research revealed the primary focus areas of Developer Relations teams and you can tell its very diverse:

Okay, but how do you know what to focus on? This is where you need to do your research. It's important to understand your audience, your product, your company and your goals. You need to speak to both, internal stakeholders and external developers.

• If you're one of the founding members of the company and there is no product yet, you need to focus on education and community.
• If you're a bit further down the line, you can start to focus on evangelism and product.
• And if you're a mature company with a well established product, you can focus on community and content, content, content.

Usually this is one of the first steps in a 30-60-90 day plan, but we'll cover that in more detail later.

Now we first need to define our objectives.

---

Chapter One: The Objective

The objective is the foundation of any DevRel strategy. Without clear objectives, you cannot effectively:

• Move forward with coherent initiatives
• Know what you're working towards
• Hire the right people
• Allocate appropriate budget
• Measure success

Your objectives should be specific, measurable, and aligned with both business goals and developer needs. In the following sections we will cover how to define your objectives and how to structure them. Let's start with the strategic side of things:

Setting Strategic Direction

Set sail! You know where to go, right? Oh you don't? Well...

The strategic direction of your DevRel strategy is crucial. It's obvious, right? Your DevRel objectives need to address at least the following three key areas. Depending on your specific situation you may need to add others, but these are a good starting point and should always be considered because they are essential to your success, growth and impact.

Now that we know at least where to go, let's talk about how to get there, which route to take and how long it will take:

Planning Horizons

Structure your objectives across multiple timeframes. When working on your objectives, you should always consider the impact to later stages. Try to avoid setting objectives that are too short-term, as this can lead to a lack of long-term vision. You don't want to end up with a mess of initiatives that don't align with each other. But also avoid setting objectives that are too long-term; on the other hand this can lead to a lack of focus and impact.

Ah, and btw: Don't be afraid to pivot!. If there is one thing I've learned in my career, it's that you need to be flexible and adapt to the situation if something isn't working. If you're not, you'll not move forward. You'll lose momentum. You need to be laser focused and can't afford to be distracted by trying to fix what isn't working in the first place.

Let's take a look at some examples. Take these with a grain of salt, they are just meant to give you an idea of how you can structure your objectives. It's important to note that the timeframe can vary significantly depending on your specific situation:

Critical Success Factors

To achieve these objectives, focus on:

1. Clear Value Proposition

Your value proposition is the foundation of your DevRel strategy. It's what makes developers want to use your platform, engage with your content, and ultimately become advocates for your product. Without a compelling value prop, you're just another voice in the crowd - and trust me, that crowd is getting louder every day. Let's break down how to craft a value proposition that actually resonates with developers (and no, "we're the best platform ever" doesn't count). Here's what you need to focus on:

Value Proposition based on the DevRel Book

2. Strong Foundations

Strong foundations are like the bedrock of your DevRel strategy. Without solid documentation, reliable support, and quality educational resources, even the best value proposition will crumble. Think of it as building a house - you wouldn't start with the roof, would you? Let's break down what makes for truly robust DevRel foundations. Here's a detailed look at the key components that will keep your developer relations program standing tall:

Based on my research, documentation and code samples are the clear winners here - making up over 70% of what companies offer to developers. What's the first thing we all do when checking out a new tool? We hit the docs! APIs and SDKs follow closely behind, showing how companies are really focusing on making their tools developer-friendly. But it's not just about having them, it's about having them in the right format and making them easily accessible. More on that later.

Here are the key activities you should focus on to build strong foundations:

3. Community Investment

The community is the heart of any DevRel program. It's where developers come to learn, share, and collaborate. This is also one of the hardest things to get right, but when done well, it can be a powerful driver for growth and success. Often times you'll hear 'yeah, we just need to build a community' - but it's not that simple. You need to invest in it, you need to nurture it, you need to have a plan for it - and you need to have TIME for it. So carve out time to engage with your community.

4. Continuous Improvement

DevRel is all about continuous improvement - you can't just set it and forget it. You need to constantly gather feedback, measure your impact, and adapt your approach based on what you learn. This is where having good tracking and measurement systems in place becomes crucial. Let's break down the key areas. We will cover this in more detail later.

---

Setting Clear Objectives

Now that we've covered how to understand where DevRel sits in the org and what the primary focus areas are, we can define our objectives. Your DevRel objectives should align with your company's overall goals while serving the developer community.

When setting objectives, we can leverage both strategic and tactical frameworks. At a strategic level, OKRs help us set ambitious goals, while SMART criteria ensure our tactical execution is well-defined.

For tactical execution, let's break down the SMART framework:
Let's sing a song

👉 For a deeper dive into goal-setting frameworks and how to implement them in your DevRel strategy, check out Brendan's excellent post about OKRs, Actions and SMART goals here. Thanks Brendan!

---

Defining Your Objectives

With our understanding of SMART objectives and the OKRA framework, let's explore the key strategic questions that will help shape your specific objectives. These questions ensure your objectives are both impactful and achievable:

1. Company Alignment

   • How does this objective support the company's current strategic priorities?
   • What specific business metrics will this objective impact?
   • Which stakeholders need to be involved or consulted?
   • How does this align with other departmental goals?

2. Developer Impact

   • What tangible benefits will developers gain?
   • How will this improve their workflow or productivity?
   • What pain points are we specifically addressing?
   • How can we validate the impact through both qualitative and quantitative metrics?

3. Resource Planning

   • What team capabilities are needed to achieve this objective?
   • What tools or infrastructure must be in place?
   • What timeline is realistic given current resources?
   • What dependencies need to be considered?

---

Example Objectives

Let's look at some example strategic objectives for a Developer Relations program. Remember that your specific objectives should align with your company's stage, resources, and goals. Focus on IMPACTFUL objectives first, expand scope later.

Here are some example strategic objectives across different focus areas:

These strategic objectives provide direction for your DevRel program. Later in this article, we'll cover how to measure progress against these objectives using the OKRA framework and specific metrics.

---

Chapter Two: Understanding Your Developer Audience

Great. We now know what we're doing and why we're doing it. Now we need to understand who we're doing it for... One of the most common pitfalls in DevRel is saying you're "targeting developers" without further specification. This approach is too broad to be effective. Your developer audience is diverse across multiple dimensions:

Developer Segmentation Framework

To effectively understand and target your developer audience, you need a structured approach to segmentation. The framework consists of four key filters. Each filter will help you understand your audience from different perspectives. And remember, you don't have to use all filters for each segment.

Applying the Framework

Great. Now we know how to segment our audience. But where do we get the information from?
This requires adopting a data-driven, product-focused mindset to gather insights from multiple sources.

Put your Product Manager hat on and start asking questions 🎩

For each segment identified in your canvas, you'll want to build a comprehensive understanding of their needs, behaviors, and constraints. Consider these key questions to develop a complete picture:

• What motivates them in their work?
• What tools and resources do they currently use?
• What are their skill gaps and learning needs?
• How do they evaluate and make technical decisions?
• What demands compete for their time and attention?
• What constraints affect their work (budget, infrastructure, culture)?
• Where do they typically seek information and community?

Feel free to use this Developer Segmentation Canvas to help you understand your audience:

---

Validation Criteria

After you've identified your segments, you'll want to challenge and validate their viability by asking these questions.

1. Is the segment relevant to our business?
2. Is it a large enough segment?
3. Is it a valuable enough segment?
4. Can we target this segment with our current resources?

Once you've validated your segments, you can start to create personas.

---

Creating Developer Personas

Now that we've identified and validated our segments, it's time to bring them to life through personas. Developer personas help us move beyond abstract segments to create realistic representations of our target developers. They're not just demographic data points - they're stories that help us understand the humans behind the code. They help your entire team align on who you're building for and ensure your strategy resonates with real developer needs.

Personas are a way to personalize your targets and humanize them. Depending on your segments, you should define 2-4 personas. Tessa Kriesel

Developer Persona Canvas Example (download the blank template here. Thanks to DevRel Book)

Each persona should include:

Developer Positioning

Once you understand your audience, you need to position your product or platform effectively. Answer these key questions:

1. Value Proposition

   • What type of product are you offering?
   • What specific problems does it solve?
   • How does it make a developer's life easier?

2. Differentiation

   • Why should developers choose your solution?
   • What makes your offering unique?
   • How does it compare to alternatives?

3. Success Criteria

   • What does success look like for the developer?
   • How can you help them achieve their goals?
   • What metrics matter to them?

---

Key Takeaways

Understanding your developer audience is more than just market research - it's the cornerstone of an effective DevRel strategy. We've covered how through proper segmentation, persona development, and positioning, you are able to create a clear picture that informs every aspect of your program.

Let's recap the key takeaways:

Cool! We've covered a lot of ground. I know some of this is a lot to take in and it might be overwhelming, but don't worry, the puzzle will soon start to come together. With a solid understanding of who our developers are, we can now move on to mapping their journey - from first discovery to becoming active community members and advocates.

---

Chapter Three: Developer Journey Map

Now that we understand who our developers are, let's map out their journey. A Developer Journey Map isn't just another fancy marketing tool - it's your blueprint for understanding how developers move from first discovering your product to becoming active users and advocates.

Beyond the Traditional Funnel

Forget the traditional marketing funnel - developer journeys are rarely linear. A developer might jump straight from discovery to implementation, or spend months in evaluation before making a decision. Your job is to support all these paths.

The Five Stages of the Developer Journey

Let's break down the key stages most developers move through. Remember - these aren't rigid boxes, but rather common patterns we see:

👀 It's very interesting to see how the 'classic customer journey' map differs from the developer journey map. I highly recommend reading Mapping the Customer Journey for Developer Products by Haley Massa if you want to learn more.

Making it Real: Touchpoints That Matter

Every interaction a developer has with your product, documentation, or community is a touchpoint. Some you control, others you don't. Understanding both is crucial:

Now that we know what touchpoints are important, let's map out the critical touchpoints for each stage of the developer journey.

---

Mapping Developer Touchpoints

For each stage of the journey, consider these key touchpoints. The following bit will be a bit 'dry' and text heavy, but I promise it's worth it. Bookmark this chapter (click on the heading to get a link), come back to it and use it as a reference when planning your touchpoints.

The DevRel Book has a great chapter on this topic, I recommend reading it.

Let's go through each stage and identify the key touchpoints:

Discover Stage

The discovery stage is where developers first encounter your product, often while actively searching for solutions to their problems. Your presence needs to be visible and compelling across multiple channels.

Evaluate Stage

During evaluation, developers assess if your solution fits their technical requirements, budget, and long-term needs. Transparency and comprehensive information are crucial.

Learn Stage

The learning stage is critical - developers need resources that help them understand and implement your solution effectively.

Build Stage

During the build phase, developers need reliable tools and support to implement your solution into their projects.

Scale Stage

As developers scale their usage, they need resources focused on optimization and enterprise-grade implementation.

---

Identifying and Removing Friction

Cool, we've mapped out the journey and the touchpoints. Now we need to identify and remove friction points. In my experience, this is one of the most important parts of the journey map. If you can identify and remove friction points, you'll be able to move developers through the journey much faster and with a better experience.

You can grab the Product Manager hat again 🎩 - but this time you also need some detective skills 🕵️‍♂️.

Follow these steps to identify and remove friction points:

Key Success Metrics in the Developer Journey

We will cover tracking metrics in more detail later, but for now, make sure to track metrics like these (again, these are examples, you need to adjust them to your specific situation):

Putting It All Together

Now that we've mapped out the journey, let's recap what makes a successful Developer Journey Map:

With our journey map in place, we can now move on to planning the timeline and milestones for implementing our DevRel strategy.

---

Chapter Four: Timeline & Milestones

Alright, we've mapped our developer journey - now let's talk about how to actually implement all of this. Having a clear timeline with defined milestones is crucial for any DevRel strategy, especially when you're just getting started.

The 30-60-90 Day Framework

The first 90 days in DevRel are critical - whether you're starting a new role or launching a new initiative. This period sets the foundation for your long-term success and impact. When creating your 30-60-90 day plan, remember that shorter is better. Rather than getting lost in lengthy, AI-generated plans, focus on concise, actionable items that will move the needle. Follow the KISS principle (Keep It Simple, Stupid) by being clear and specific about what you want to achieve. Think of this plan as a flexible guideline rather than a rigid rulebook. Your goal is to maintain focus on what matters while being able to adapt as you learn more about your developers' needs and company dynamics.

---

Detailed Timeline Breakdown

Let's get specific about what you should focus on in each phase. Again, it's important to remember that this is a flexible guideline. Everything you can find here is to spark your imagination. The best way to come up with your own plan is to grab a piece of paper, a pen, a coffee/tea and a good long think.

But for now, let's dive into the details:

---

First 30 Days: Building Your Foundation

This is your learning phase. Don't rush to implement everything at once. Instead, focus on:

Days 31-60: Building Momentum

Now that you have a solid foundation, it's time to start implementing:

Days 61-90: Showing Impact

The final phase is about demonstrating value and scaling what works:

---

Beyond 90 Days: The First Year

While the first 90 days are crucial, let's look at what comes next. Again, this is a flexible guideline.
Don't be afraid to pivot, but make sure to have a well prepared plan in place before you do.

---

Building Network Effects

One crucial aspect of your timeline planning is understanding how to create and leverage network effects. As Nader Dabit points out, "the more people building in an ecosystem, the more people build in that ecosystem."

Building Bridges in Your Timeline

When planning your milestones, consider incorporating these bridge-building activities:

Identifying and Nurturing Superstars

A critical part of your timeline should include identifying and supporting your community superstars. These are the developers who:

Resource Allocation Over Time

To support these initiatives effectively, consider this resource allocation framework:

This progressive approach helps you build strong foundations while gradually scaling your community impact.

---

Setting Realistic Milestones

Now that we've figured what to do in the first 90 days, we need to set realistic milestones. And by realistic, I mean really realistic. Don't shoot for the stars. When you've been around for a while, you certainly have heard someone say 'Let's postpone the retro (again)'. You don't want to be that person. You want to be the one that develops, learns and delivers.

So: Your milestones should follow the SMART framework we discussed earlier.
Here's how you could structure them:

Adjusting Your Timeline

Remember that timelines need to be flexible. Here's when to consider adjustments:

With a solid timeline in place, you're ready to start implementing your DevRel strategy.

Next, let's talk about how to build effective feedback loops to ensure you're moving in the right direction.

---

Chapter Five: Feedback Loops

Let's talk about feedback loops - the engine that keeps your DevRel program running smoothly. Think of them as your early warning system and innovation driver rolled into one. Without proper feedback loops, you're essentially flying blind.

The Developer Advocacy Feedback Loop

Okay, let's say you're a Developer Advocate (we will cover other roles later). In this case, your role isn't just about external outreach - it's about creating a two-way street between your company and the developer community. Here's how this loop works:

---

Types of Feedback Loops

Let's break down the different types of feedback loops you should establish:

Understanding Different Loop Types

When implementing feedback loops, it's important to understand how different types serve different purposes. Let's break these down:

Each type of loop serves a specific purpose in your DevRel strategy:

Feedback Loop Characteristics

For feedback loops to be effective, they need certain key characteristics:

Implementing Effective Loops

Each feedback loop type requires specific implementation strategies:

Optimizing Your Feedback Loops

To ensure your feedback loops remain effective:

Feedback Channels

Let's explore the various channels you can use to gather developer feedback effectively, using the developer journey stages as our guide to understand which channels work best at each phase of developer engagement.

Different feedback channels are most effective at different stages of the developer journey:

Let's cluster these feedback channels into four main categories:

Remember to match your feedback channels with your developer personas and journey stages. Different developers prefer different engagement methods - a startup developer might prefer quick Discord chats, while an enterprise developer might engage more through formal methods.

I hope this deep dive into feedback loops has given you a solid foundation for implementing them in your DevRel strategy. While we've covered a lot of ground - from different types of loops to implementation strategies and channel optimization - remember that the most effective feedback system is one that's tailored to your specific situation. Take these frameworks and examples as a starting point, then adapt them based on your unique developer community and organizational needs. I am sure you will find your own way to the best possible feedback system for your situation.

---

Chapter Six: Measuring Success & Reporting

Understanding DevRel Metrics

Let's face it - metrics have been a contentious topic in DevRel for years. While some argue that DevRel impact is too qualitative to measure, the reality is that showing concrete value is more important than ever.

Through my research and studies in DevRel metrics, I've found that measuring success in Developer Relations presents unique challenges. While traditional business metrics like sales figures or Marketing Qualified Leads (MQLs) are straightforward, DevRel often has longer-term, qualitative impacts that aren't easily captured by conventional metrics.

My studies have identified two primary categories of metrics:

Evaluating Metric Effectiveness

My research has revealed clear patterns in what makes metrics effective or potentially detrimental:

Content-Specific Metrics

Favorable Metrics

Metrics that provide a more definitive depiction of the DevRel team's reach, engagement, and influence are deemed 'favorable'. These metrics are essential for tracking community growth, measuring the impact of content and educational resources, and assessing overall brand visibility within the developer ecosystem.

When selecting metrics, it's important to focus on those that provide meaningful insights into your DevRel efforts.\ Here are key metrics across different aspects of Developer Relations:

These metrics help demonstrate the tangible impact of DevRel initiatives while providing actionable insights for program improvement. When tracked consistently, they create a comprehensive picture of your DevRel program's effectiveness and its contribution to broader business objectives.

Detrimental Metrics

Detrimental metrics in DevRel emphasize easily quantifiable aspects over actual value provided to the developer community. These metrics can mislead teams by prioritizing surface-level measurements over meaningful engagement:

---

Key Metrics Frameworks

The North Star Metric

A North Star metric serves as the primary measure of success for DevRel initiatives, providing a clear focus for the team's efforts. While specific metrics vary by company and product, they should reflect meaningful developer engagement and align with business objectives. Here are key supporting metrics that often contribute to a DevRel North Star:

---

Kim Maida's Keystone Framework

This framework ties metrics directly to business value through four key areas. It provides a structured way to measure and communicate DevRel value. Let's break down each area:

To implement this framework effectively:

1. Define your keystone metric (e.g. registered developers)
2. Assign relative values to each stage
3. Track progression through the funnel
4. Calculate combined business impact
5. Adjust and refine over time

Remember that developers may cycle through these stages multiple times as they deepen their engagement with your platform. The framework helps capture this cumulative value creation.

---

Example OKRs

Based on the OKRA framework, here are examples with SMART key results. Please note that these are just examples, and you should adjust them to your specific situation. It doesn't make sense to work on SDK adoption if your SDK is just a simple wrapper around an API.

Wait, I need to zoom in a little for this one 🔎

Okay, cool. You get the point. Now back to the examples:

By setting clear objectives that align with both company goals and developer needs, you create a foundation for a successful DevRel strategy that delivers measurable value to all stakeholders. The key is to balance lead metrics (measuring work output) and lag metrics (measuring outcomes) based on your team composition and organizational structure.

Educational Impact Assessment

Based on my research with, quoting Fontão et al. (2021), successful DevRel programs should measure educational impact through:

Practical Implementation

Great, we've covered a LOT of theory. It's time to use it in practice.

Here's how to get started:

1. Identify your company's key business objectives
2. Define metrics that show DevRel's contribution
3. Set up measurement systems and baselines
4. Report regularly on progress and learnings
5. Iterate based on what you discover

Remember: The goal isn't perfect measurement, but rather showing clear progress toward business goals while maintaining authentic developer relationships. If you notice constantly lagging/red metrics, you need to ask yourself why and adjust your strategy accordingly asap. Do not hesitate to pivot.

I will create a dedicated blog post on this topic soon.

Please get in touch with me if you would like to chat about this or read my Thesis on this topic.

---

Chapter Seven: Community-Centric Approaches

Understanding Community-Centric DevRel

A community-centric approach puts developers at the heart of your DevRel strategy. Instead of pushing products, you're fostering an environment where developers can learn, share, and grow together.

---

The Power of Network Effects

When developers connect and collaborate around your product, they create a powerful network effect that drives adoption:

The Network Effect in Developer Communities

When developers help other developers, your platform benefits from a powerful network effect:

---

Identifying and Nurturing Community Superstars

Every thriving developer community has its superstars - highly engaged members who significantly impact community growth and health.

Building a Developer Champions Program

Your most active community members are your best source of honest feedback and potential future employees. You should get to know them as much as possible. You should also consider offering them meaningful benefits to keep them engaged and motivated. Need alpha testers? Need speakers? Need contributors? Go and ask your superstars. They will be happy to help and be seen at the same time.

Here's how you could structure your champions program:

---

The Hiring Advantage

Oh, want to hear a secret? Come closer:
One often overlooked benefit of a community-centric approach is talent acquisition.

Your superstar community members make ideal candidates for hiring because they already have deep product knowledge, proven technical expertise, and demonstrated cultural alignment with your organization. They also bring built-in credibility within the community, having established themselves as trusted voices and contributors. So next time you're thinking about how to grow your community, don't forget to consider the talent pipeline it can provide.

---

Investing in Community Growth

Building a strong developer community requires consistent investment in:

Measuring Community Success

Track these key metrics to gauge community health:

Key Takeaways

1. Put community value before product promotion
2. Identify and nurture your superstar members
3. Create clear paths for recognition and growth
4. Listen to your power users' feedback
5. Consider community members for hiring opportunities
6. Measure and celebrate community success

---

Chapter Eight: Content and Education Strategy

Building on the community-centric approach we discussed in Chapter Seven, content and education form the backbone of any successful DevRel program. Great developer content isn't just about what you write - it's about creating the right content, for the right audience, at the right time in their journey. As we'll explore in this chapter, a well-planned content strategy complements your community efforts and sets the stage for the advanced topics we'll cover in subsequent chapters.

The Four Pillars of Technical Content and the Diátaxis Framework

The Diátaxis framework is a systematic approach to technical documentation that identifies four distinct types of documentation, each serving a specific purpose and audience. I highly recommend taking the time to fully digest the framework and how it can be applied to your use case. It will help you create a more comprehensive and effective content strategy. Feel free to get in touch with me if you would like to discuss this in more detail. I also can cover this in a later post if enough people are interested.

But for now, let's explore the four pillars of technical content:

Implementing the Diátaxis framework effectively requires careful planning and coordination across your content team. Start by mapping your existing content to the four pillars, identifying gaps and opportunities. Create a content calendar (more on this in the 'Tools' section) that balances the different types of documentation while maintaining consistency in voice and technical accuracy. Regular content audits help ensure materials stay current and relevant. Most importantly, establish feedback loops with your developer community to continuously refine and improve your content strategy.

Remember that great technical content is an iterative process - start small, measure impact, and scale what works. Let's move to the next step, where we will explore how to discover the right content to create.

---

Content Discovery Methods

Discovering what content to create is both an art and a science. And I mean it, it requires a deep understanding of your developer audience and creativity combined with data-driven insights. The key is to systematically identify knowledge gaps and pain points while staying aligned with your strategic goals. Let's explore some proven methods for discovering high-impact content opportunities:

(Did you notice it's a feedback loop again? It's all about listening.)

---

Breaking Down Barriers to "Hello World"

It is crucial to make the onboarding process as smooth and frictionless as possible. The faster developers can achieve their first success, the more likely they are to adopt your platform. Follow the Diataxis framework to create a comprehensive onboarding experience by providing clear, concise, and actionable ways to get started. I highly recommend a "Get started in 5 minutes" guide. This does not have to be a full fledged tutorial, but rather a collection of copy-paste examples and links to more in-depth guides so the "Discovery" phase is as frictionless as possible.

Focus on these key areas:

---

Content Creation Strategy

Let's talk about the different ways to create content.
In this article, I won't go into the different types of content, but rather how to structure your content team. It's your job to figure out if you need written content, video content, podcasts, etc.

Let's explore the available content options so you can make an informed decision based on your specific needs and resources.

Content Types

Internal vs External Writers

So, you've decided on the type of content you want to create. Now, you need to decide if you want to use internal or external writers. Remember, the goal is to create high-quality content that resonates with your audience. So it makes sense to use internal writers for the important core content and external writers for more niche content.

Also: Don't forget about your community superstars! IMO, they are one of your best sources of externally created content.

Content Quality Checklist

It's important to remember that the quality of your content is of highest importance. Here's a checklist to ensure your content meets high standards:

• Technical accuracy: Verify all technical details and code samples.
• Code testing: Test code examples in relevant environments.
• Clear explanations: Use simple language and logical flow.
• Consistent style: Follow style guide and maintain voice.
• SEO optimization: Include relevant keywords and meta data.
• Regular updates: Review and refresh content periodically.

---

Measuring Content Success

Once you have a working content strategy in place, you need to measure its success. Otherwise it's just a guessing game (there are many professionals out there who prefer to "vibe check" instead).

We have covered this in the Metrics chapter, so here's a quick recap on what you could measure:

---

Key Takeaways

Thats about it for the content and education strategy. You can check the references at the end of the post for more in-depth guides on each topic. Let's recap the key takeaways:

1. Have a clear vision and get it by doing a proper internal kick-off.
2. Create content that maps to your developer journey stages and personas
3. Balance educational content types (tutorials, guides, reference docs, etc.)
4. Focus on quality over quantity and maintain high standards
5. Set up clear measurement frameworks from the start
6. Track key metrics and iterate based on data and feedback
7. Build a sustainable content creation process with the right team mix

---

Chapter Nine: Hiring

DevRel roles require a unique blend of technical expertise, communication skills, and community-building abilities. Understanding the different roles and their requirements is crucial for both hiring managers and candidates. Let's explore the different roles, responsibilities and skills needed for each before we dive into the hiring process:

The pillars of DevRel

Overall, DevRel consists of four pillars where each role contributes to the overall success of the program. Grouping them together helps to find a way to group similar activities together.

These four pillars provide a framework for organizing DevRel activities and understanding how different roles contribute to overall program success. Each pillar represents key functions that, when working together, create a comprehensive developer relations strategy.

DevRel activities in each pillar

While these pillars provide a useful framework, it's important to recognize that DevRel activities often transcend these boundaries. For instance, a technical blog post might primarily serve as advocacy, but could simultaneously support marketing initiatives and provide educational value. The key is understanding that while activities may span multiple pillars, their primary classification often aligns with the strategic intent behind their creation. This overlap actually strengthens the overall DevRel program, as initiatives can serve multiple objectives while maintaining clear strategic focus.

Below is a comprehensive overview of how different activities typically align with each pillar:

Activity Focus Areas

The radar charts below illustrate different focus areas within DevRel roles, showing how activities and responsibilities can vary based on team objectives:

One important side note I think is worth mentioning:
It's important to note that understanding these different focus areas is crucial for both hiring managers and candidates. It helps ensure role expectations align with organizational needs and individual strengths. Seriously, take the time to understand these areas and make sure you're hiring for the right fit. If you already have BD people handling outreach, you don’t want to hire a ‘Developer Advocate’ just to send them to conferences. Instead, consider hiring a Developer Relations Engineer who could focus on more technical enablement work that aligns better with your team’s needs.

The images are from the DevRel Job Titles and Career Progression Report (read it!)

---

Understanding DevRel Roles

Oh, this is a fun one. Try to ask anyone working in DevRel what they do and you will get a different answer every time.
Some of them even say they're a 'DevRel', but they really are a 'Developer Advocate'.

And some are are this:

Let's continue...
Based on my own experience and academic research, DevRel roles typically fall into these categories. We will go into more detail in a bit.

(Note there are more DevRel related roles out there, like 'Community Manager', 'Developer Educator', 'Solutions Engineer', etc.)

---

Core Skills

When you're hiring for a DevRel role, you want to make sure the candidate has the core skills that are most important for the role. It highly depends on the stage of the company, too. In the beginning you might want to hire a more generalist who can do a bit of everything and has founder experience. The more mature the company gets, the more you want to hire specialists who can focus on a few key areas.

---

Defining Role Requirements

We know about the different nuances of the different roles - now we need to have clear role definitions when looking for candidates. It helps align expectations, enables targeted candidate searches, and ensures effective evaluation.

The process of defining role requirements typically involves three key phases.

• First, conduct a thorough needs assessment by working closely with stakeholders to identify key responsibilities, define success metrics, and ensure alignment with the company's current stage.
• Next, create a detailed role specification that outlines technical requirements, required experience level, primary focus areas, and how the role will integrate with existing teams.
• Finally, establish clear success metrics by defining relevant KPIs, setting expectations, establishing evaluation criteria, and planning a growth path for the role.

This should help you find candidates who can truly drive value for your DevRel initiatives.

---

Building an Effective Hiring Process

The hiring process for DevRel roles should be thorough and well-structured, while aligning with your existing HR practices.
Here's a suggested framework that you can adapt to your needs:

Assessment Areas

When evaluating candidates, pick some of these key areas:

• Technical Proficiency

  • Understanding of your tech stack
  • Previous development experience
  • API/SDK knowledge
  • System design understanding
  • Documentation capabilities

• Communication Skills

  • Written communication (blog posts, documentation)
  • Verbal communication (presentations, videos)
  • Teaching ability (workshops, tutorials)
  • Social media presence
  • Community engagement history

• Strategic Thinking

  • Program planning experience
  • Metrics and KPI understanding
  • Resource prioritization
  • Problem-solving approach
  • Business acumen

Interview Process Structure

The following is a suggested and tested structure - adapt it to align with your hiring practices and team needs.
Note: It doesn't make sense to ask a DevRel marketing focussed person hardcore tech questions while it totally makes sense to ask a DevRel Engineer about their side projects and prior Engineering experience. You get the point.

1. Initial Screening

   • Resume review focusing on relevant experience
   • Portfolio assessment (content, talks, community work)
   • Brief technical background check
   • Cultural alignment preliminary assessment

2. Technical Evaluation

   • Code review or small technical project
   • API design discussion
   • Documentation writing sample
   • Technical presentation
   • System architecture understanding

3. Communication Assessment

   • Mock presentation or workshop
   • Writing exercise
   • Community scenario roleplay
   • Stakeholder communication simulation

4. Team Fit

   • Cross-functional team interviews
   • Culture and values alignment
   • Collaboration style assessment
   • Working style discussion

Evaluation Framework

Having just the right questions is not enough. You need to make sure to also be able to evaluate the candidates properly - in the best case without help of AI (yet), as the individual journey and experience is so important.

Use these points as inspiration:

Remember that hiring processes should be consistent across candidates, documented and transparent, flexible enough to accommodate different backgrounds, and regularly reviewed and improved based on outcomes. (don't forget the retro, folks)

You also can read into the way a16z or Coinbase do it for more inspiration.

Post-Hire Integration

Last but not least, don't forget to get the new hire up to speed asap. In my experience, the best way to do so is by having clear 30-60-90 day objectives, team and stakeholder introductions, product and technical training, a streamlined community introduction strategy, and early wins identification.

Unpopular Opinion:
Some don't want to hear this, but if you note it's a bad hire, try to let them go asap. (Try to fix things first, obviously) It's a lose-lose situation if you don't. Eventually you'll be both unhappy. Plus: it's a waste of time and money.

---

Chapter Ten: Tools and Tech

This will be the last chapter and a short one, as it's a bit more of a general overview.
A special thanks to the DevRel Collective for maintaining an extensive awesome-devrel list of tools, which helped inform this chapter.

Essential DevRel Tooling Categories

Most tools offer free tiers or startup programs. Start with essential tools and expand as your needs grow and budget allows.

When selecting tools, consider key factors like API availability for automation, integration capabilities with your existing tech stack, data portability options, scalability to support growth, budget limitations, and your team's familiarity with the tools to ensure smooth adoption and efficient usage.

---

Last words

What took you so long to get down here?, hah!

Phew, we made it! This guide turned out way longer than I initially planned, but I hope it provides a solid foundation for building your DevRel strategy. Whether you're just starting out or looking to level up your existing program, remember that DevRel is a marathon, not a sprint.

Throughout this guide, we've covered everything from understanding your developer audience to measuring success, but perhaps the most important takeaway is this: DevRel is about building genuine relationships with developers while delivering real value to your organization. It's a delicate balance, but when done right, it's incredibly rewarding.

A few final thoughts:

• Start small and iterate. You don't need to implement everything at once.
• Listen to your community. They'll tell you what they need if you pay attention.
• Stay authentic. Developers can spot insincerity from miles away.
• Measure what matters, not just what's easy to measure.
• Take care of your DevRel team - they're the bridge between your product and the developer community.

I'd love to hear about your experiences implementing these strategies or any questions you might have. Feel free to reach out to me on Twitter/X or GitHub.

And hey, if you've read this far - thank you! I know it's been a long journey through this guide. If you found it helpful, consider sharing it with others who might benefit from it. The DevRel community grows stronger when we share knowledge and lift each other up.

Keep building awesome things! 🚀

So long
Fabian

---

Sources & Credits

Articles

• https://www.leaddevrel.com/p/how-to-craft-a-great-developer-relations
• https://www.tessakriesel.com/devrel-strategy-breakdown/
• https://devrelbook.substack.com/p/youre-targeting-developers-so-is
• https://www.devrel.agency/developerjourney
• https://medium.com/codex/developer-relations-the-developer-journey-map-36bd4619f5f3
• https://medium.com/@haleymassa/mapping-the-customer-journey-for-developer-products-9787935997fb
• https://dx.tips/first-90
• https://www.developermarketing.io/the-science-behind-feedback-gathering-from-developers/
• https://draft.dev/learn/devrel-harnessing-the-power-of-community-feedback-for-product-development
• https://glaforge.dev/talks/2020/08/06/the-developer-advocacy-feedback-loop/
• https://daily.dev/blog/optimizing-developer-feedback-loops-guide-2024
• https://filestage.io/blog/feedback-loops/
• https://fiveandahalfstars.ninja/blog/2023/2023-06-01-a-comprehensive-devrel-metrics-guide-part1
• https://fiveandahalfstars.ninja/blog/2023/2023-06-05-a-comprehensive-devrel-metrics-guide-part2
• https://fiveandahalfstars.ninja/blog/2023/2023-06-15-a-comprehensive-devrel-metrics-guide-part3.html#_the_solid_framework_kim_maidas_keystone_framework
• https://www.swyx.io/measuring-devrel
• https://jmeiss.me/posts/talk-about-devrel-metrics/
• https://www.atlassian.com/agile/agile-at-scale/okr
• https://www.atlassian.com/blog/productivity/how-to-write-smart-goals
• https://maida.kim/how-to-measure-the-value-of-developer-relations/
• https://servingdevelopers.com/2019/02/17/budgeting-for-developer-evangelism/
• https://draft.dev/learn/the-network-effect-in-devrel-how-community-centric-models-boost-software-adoption
• https://developerrelations.com/developer-experience/approaching-developer-education
• https://developerrelations.com/developer-experience/breaking-down-barriers-to-hello-world
• https://www.devrelx.com/post/content-for-developers-what-and-how
• https://www.learnwithjason.dev/blog/get-hired-devrel/
• https://developerrelations.com/how-to-get-a-job-in-devrel
• https://www.linkedin.com/pulse/hiring-within-developer-relations-how-successfully-define-owen-parker-jgirc/
• https://developerrelations.com/announcements/looking-at-devrel-job-titles
• https://developerrelations.com/wp-content/uploads/2023/05/hoopy-devrel-job-titles-report-may2023.pdf
• https://a16z.com/the-hiring-process
• https://barmstrong.medium.com/35-ways-coinbase-hires-develops-and-retains-great-people-cbfdf93b1c5c
• https://github.com/devrelcollective/awesome-devrel

Images

(if not mentioned below the img themself)

• Cover BG by Daniel Falcão on Unsplash
• Value Proposition by DevRel Book
• Developer Audience by Muhammad Raufan Yusup on Unsplash
• Developer Journey by Pawel Czerwinski on Unsplash
• Timeline & Milestones Photo by Tony Reid on Unsplash
• Feedback Loop Photo by Visax on Unsplash
• Metrics Photo by Maxim Berg on Unsplash
• North Star Photo by Dana Andreea Gheorghe on Unsplash
• Content and Education Strategy Photo by Robin Neufeld on Unsplash
• Hiring Photo by Google DeepMind on Unsplash
• Tools and Tech Photo by Laura Ockel on Unsplash