Unmasking Dev Rel

Brendan Graetz, 2023

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

In this preso, we’ll cover:

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Dev Rel, the function
Dev Rel, the politics
Dev Rel, the role
Career paths
Is Dev Rel for you?

The Function: Dev Rel

What Dev Rel does

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Developer Journey

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Sequence of stages
Funnels with conversion rates
Touchpoints: Content, code, activities
Friction points
Internal and External
DX research:
- UX research

Developer Journey /2

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Some of these touchpoints are internal - which you create or author yourself in the devrel team. The others are external - which you don’t really have much control over, but can influence indirectly But there’s no cheat sheet which tells you what all these touchpoints should be, and how to design them. Neither is there a cheat sheet which tells you what all the friction points are. So the dev rel team has to discover that, and a great way to do that is to do a form of UX research, called DX research. Where DX stands for “developer experience”. So back to the dev journey. Think of it as a series of funnels, where one is connected to the next The job of dev rel here is to increase the conversion rate of each of these funnels For those of you who have prior experience in sales or marketing, you’ll be thinking, “Now this is my jam” But for those of you who have a developer or engineering background, these are gonna be new concepts for you. We’ll circle back to this later on in this preso, regarding career paths.

Core Components

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Developer Segmentation
Developer Personas
Developer Journey Map
Hello World Sequence(s)
Information Architecture

Dev Marketing

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Notoriously hard audience to market to
- ad-blockers, spam filters
Provide value

Devs are a very very difficult target audience, when it comes to marketing. It is quite hard to find devs that allow ads or marketing emails to get in front of their eyeballs. Their game is pretty strong. Some devs go as far as to create a personal VPN just to get rid of ads … so you’re up against the very best. That being said, it is not impossible. In my opinion, when marketing to devs, you simply cannot use easy options ... the ones that marketing typically employs on other audiences. By easy, I email generic things like email marketing campaigns, or buying online ads. Instead you have to skip those low value adding tactics, and jump straight into the high value adding stuff. In a nutshell, you have to provide value. The formula for this is: (1) Identify a pain point, (2) figure out how to use your tech to solve their problem, (3) and then describe how to do this in an article, video, code example, or something else. That’s what distinguishes, in my opinion, generic marketing from dev marketing.

Dev Marketing /2

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Channels

Social media
Chat/ fora
SEO
Content products
Community

Dev Education

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Channels

Articles
Videos
LMS/ Course
API docs
Code examples
Stackoverflow

Dev Education /2

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Activities
Office hours
Run workshops
Community calls
Q&A on interactive channels

Dev Success

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

DX research
Dev Journey → optimise
Dev Friction Points → identify
Information valve
Broadcast → L1
Feedback → L2
Bidirectional → L3

OK, so now you’ve gotten the dev’s interest in your tech, and you’ve even taught taught them how to use your tech. What comes next? At this point we want the dev to build something on top of your tech. Something that is beyond a hello world, and beyond a proof-of-concept - a real app with real users and real value. This is where dev success comes into play. When using new tech, a dev will inevitably get stuck, or get frustrated, because they could not make something work properly, or they took too much time to figure out how to make it work. Dev rel wants to know about these friction points, so that they can be eliminated where possible, or otherwise provide workarounds, alternate solutions, etc. By doing so, the interesting thing is that it has a positive feedback loop back into both dev marketing, and into dev education. In order to do this, there are a couple of interesting concepts that I’d like to talk about (1) The first is DX research. That’s developer experience research. This is a specialised form of UX research, where instead of general users, you are specifically looking at dev. Here dev rel will conduct interviews, focus groups, usability studies, etc. The goal is to understand friction points, and do so without guesswork - and instead actually extract insights from real developers using your tech. This is crucial, because you, in dev rel, are likely to be so familiar with your own tech, that you are effectively blinkered, to the point that you’ll be unable to see many of the problems - even the obvious ones. (2) The second is the information valve. At a basic level, dev rel broadcasts information - from in the company out to the community. If that is all dev rel does, the team is not very mature yet. The next level up is to get feedback from your developer community. DX research is one way to do this - but there are many other techniques that can be employed. If dev rel does both broadcast and feedback that is great, and the dev rel team is relatively mature. The next level up from this is to make the information valve, that is bidirectional, and connect it into a single feedback loop. This is all about designing information flows and optimising them. If dev rel does this, the dev rel team is rare, and I’d even say industry leading - because most do not get to this level. I’ll expand a bit more. In this scenario, dev rel essentially takes on the form of a proxy, sandwiched between the engineering team and devs in the community, and its role as a proxy is to facilitate that information loop by filtering, prioritising, amplifying et cetera.

The Politics: Dev Rel

How a Dev Rel team operates within an organisation

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Organisation Structure

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Organisation Structure

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Team name, job titles

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Developer Relations
Developer Advocacy
Developer Experience
Developer Evangelist

Product vs Platform

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Platform → Definite need
Product → Maybe need

Events vs Content

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Very common misconception

Educate Up

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Exec team’s understanding
Educate up → Opportunities
Metrics → Exemplary
Achievements list

This is one of my personal bugbears. Within a company, usually only the dev rel team truly understands its own function. Throw back to the org chart shown earlier. The other teams usually have an incomplete understanding of the devrel practice area, the roles, the responsibilities, the activities, the contributions, and the value it brings. And this includes the exec team as well. As far as internal challenges go, this one is evergreen - there’s always a need to educate up. Always look for opportunities to do so. One really good way to do this is to set up metrics for the devrel team, be exemplary in how good the your metrics game is. Because when you’re educating up, you have more to prove. And dev rel has to always be educating up. Another really good way to do this is to maintain an achievements list, and log any significant accomplishments as the team makes them happen.

The Role: Dev Rel

What you do when you are in Dev Rel

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

A day in the life

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Support
Meetings
Code examples
Prep for next workshop/ webinar
Strategy

Task planning

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Most planned → Most ad-hoc
Reprioritisation frequency → High
Scrum vs Kanban vs Checklists
Eisenhower matrix → Get good

Another impact of dev rel being such a multi-faceted role is that time management becomes very crucial. Prepare for your planned tasks and priorities to get disrupted weekly, and sometimes even daily. At a company level, you might be asked to use scrum with sprint planning, or similar. That works really well for software engineering, because you can plan ahead of time, sometimes even months in advance. Dev rel does not work that way. I wish it did, but in reality it is much more chaotic, and you have no choice but to be reactive. So when planning, always include buffer for the inevitable unplanned action items. But there is a method to the madness, if you can find it. I have a couple of techniques that help. (1) The 1st one. When scrum and sprint planning starts to fall apart, identify the situation, and swap to kanban temporarily, as it allows the team to be more reactive. Also regardless of whether you are doing scrum or kanban or something else, I’ve found that the best way to keep track of everything is to simply keep checklists. I personally keep markdown checklists simple text files, and that’s my secret sauce to productivity. (2) The 2nd technique. Keeping track of what tasks you are doing is fine, and re-prioritising them is also fine. But problems start to creep in when you make poor decisions about the new priorities. It’s tricky, because you cannot go for the most important first. Neither can you go for the most urgent first. But there’s a simple chart called the Eisenhower matrix - just employ this every time you need to prioritise a set of tasks, to get the best outcomes.

Strategy

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

What to do → Known
How to do → Unknown
Many stakeholders → Balancing act
Internal decentralised influence → Politics
Checklists
Flow charts
RACI matrices

Another impact of dev rel being such a multi-faceted role is that you have a lot of stakeholders. Are you sensing a pattern here? The work that dev rel does likely has indirect impacts on all of engineering, product, marketing, and sometimes even sales and legal. Since dev rel has so many diverse stakeholders, stakeholder management is paramount. You might know what you need to accomplish, but how you do those things is unknown … and this is where strategy comes into play. Dev rel needs to be good at roping in stakeholders from different functional areas within the company, to get them all on the same page. I think my favourite tool for this is the RACI matrix, which helps you to map out stakeholders very definitively, and check your blind spots. You may also want to use checklists and flowcharts to aid communication. And some of you might be thinking - isn’t this sort of stuff for management with MBAs etc. Yes you’re right, generally speaking. But in dev rel, even if you’re not a manager yourself, you’ll need to know and use this stuff.

Support

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Help developers → Mission
Dedicated support → Non technical
1-to-1 support → Repurpose for 1-to-many

Operations

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Visible ← Least time
Conference/ meetup/ hackathon
Workshop/ webinar
Invisible ← Most time
Creating content
Dev experience design

Career Paths: Dev Rel

Who becomes Dev Rel

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Organisation structure (recap)

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

From programming

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Software engineer background
Pros
Already can code
Already understand target audience
Cons
Coding skills will atrophy
Hard to pick up
- events skills
- marketing skills

Coming from a software engineering background, and transitioning into Dev Rel is probably the most common path. There are pros and cons. Creating code examples and other materials for developers is going to be quite easy for you, since you already know how to code. Also, the target audience basically is you, and you know yourself well. (Hopefully!) For example, when you need to put yourself in the shoes of a target segment or persona, you can do so much more easily, because you can draw from your own past experiences. What are the negatives? It is quite likely that you’ll go from writing code at a much more advanced level, to code that is much easier, so your ability in that skill will get weaker over time unless you continue to code outside of work. The other is that you will likely have to get good at a skill that you have not practiced much before, namely marketing, being at events, et cetera.

From marketing

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Marketing/ events/ community backgrounds
Pros
- Already have events, community management, marketing skills
Cons
- Need to learn to code
- Need to understand target audience

Jack of all trades

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Juggle diverse skill sets
Juggle diverse stakeholders
“Jack of all trades, master of none”
Breadth vs depth

One phrase I like to use a lot in describing dev rel is that you need to be a jack of all trades. Not just in the skills and activities, but also in the ability to deal with different parts of the organisation (internal stakeholders), and also dealing with the community (external stakeholders). So it is quite the juggling act! Now that phrase, “jack of all trades” also comes with a second part, “master of none”. And this is where the hard work comes in. Let’s say that you are a software engineer, you’ll have a lot of depth in your skills and ability in writing software. That’s modeled by the blue strip - depth. Let’s say that you then transition into dev rel, you’ll have a lot of breadth in your skills and ability, spanning writing software, marketing, product management, and even sales. That’s modeled by the yellow strip - breadth. But what you really want is to maintain depth in one area, while expanding your breadth to cover all the other areas. That’s the green strips - breadth and depth. This is easier said than done, and something to consider about Dev Rel as a career path.

Figure out if Dev Rel is for you

Would you? Could you?

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

OK, so now that we’ve covered career paths, hopefully that has piqued your interest. You can come from a number of different backgrounds, and still make it into dev rel … some paths are harder, and therefore take longer than others. Maybe you thought that you didn’t have the right background before, and now you think that you might after all. But, right now you are doing something else altogether professionally. How do you go from inspiration, to something concrete, and transition into dev rel? In this section, we’re going to cover just that. Firstly, you’ve gotta be sure that you’re not merely inspired, but that you’re also actually capable of a role in dev rel. And secondly, you’ve gotta be seen by some company looking for dev rel talent, as someone who is going to fit into their dev rel team. This section will cover a few techniques that’ll help you to cover both!

Before we go into that, I’m going to check the chat to see if there are any questions.

Try before you buy

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

This role is hard
Test the waters
Hands on understanding

Code + write + video

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Most common, most time spent
Create a code example
Write an article stepping through it
Record a video demonstrating it
Publish & promote!

Speak

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Start with meetups
Talk about your Dev Rel target area
Challenge #1: Public speaking ← Dev
Challenge #2: Technical demo ← Other

The most externally visible part of Dev Rel is when you speak at tech meetups or tech conferences. The cool part is that you don’t need to already be in dev rel to do that - because anyone can speak at events, as long as their topic is relevant to that particular event. So pick any piece of tech that you are excited about. Maybe it is a programming language, or a dev tool, or a library, or a framework. Create a presentation about it, one that includes a live demo, and then submit it to the organiser of a tech meetup, and hopefully you get picked to speak. If you’re in, then turn up and deliver your preso and demo. If you come from an engineering background the public speaking is likely to be the more challenging part of it, otherwise, the demo is likely to be the most challenging part of it.

Again, the obvious rationale behind this about the work being done, and assessing your open ability to do these tasks. And the other rationale too, where you ask yourself: Did you enjoy the process of doing this? Or did you feel like it was a chore? When you get on stage and speak to an audience, did that feel OK? Or did you feel like maybe you should have just posted it online instead?

Hackathon

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Participate and submit ← Level 1
Analyse bounty design ← Level 2
Talk to Dev Rel about their roles ← Level 3

Another externally visible part of Dev Rel is hackathons. If you’re on a Dev Rel team, you’ll likely be attending, judging, mentoring, sponsoring, and even organising hackathons. If you have not yet been to a hackathon, this is finally your excuse to do so. Participate by submitting a project at a hackathon - your aim here is not to win, but to get the full event experience. But then you also take it to the next level - take a look at the bounties, how they have been structured by the event organiser, and by the sponsors. Also, there are almost certainly going to be Dev Rel professionals at the hackathon - go talk to them and ask them what it is like doing what they do. Maybe tell them that you are interested in Dev Rel yourself, and see what advice they give you.

Once again, ask yourself these questions: Did you enjoy the process of doing this? Or did you feel like it was a chore? When you speak to Dev Rel professionals, did you vibe with them? Did you feel like you could work in a team with one of them?

Dev Rel team in your company

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Already work in a tech company?
Formal/ informal dev rel team
Double hat
Temporary

So far it has been activities that anyone can do. This last one, however, only really is accessible if you happen to already work in a tech company, and that company happens to have a dev rel team. The task here is going to be described in much less detail, so that also means it is a bit more vague, because you’re going to have to tailor-make your approach based on individual circumstances in your company. But the basic idea is that you ask your manager to temporarily expand the scope of your roles and responsibilities. Specifically to include some activities that are performed by the Dev Rel team If you’re able to navigate that successfully, you’ll be able to continue on in your current role, but have a temporary additional workload where you get to try out Dev Rel, and assess if it is for you first hand, and even learn on the job. Kinda like an apprenticeship, one that you’ve carved out for yourself.

Once again, ask yourself these questions: Did you enjoy the process of doing this? Or did you feel like it was a chore? When you executed Dev Rel tasks within your company, did you feel like you accomplished something? Did you feel like you could work within your company’s Dev Rel team?

Wrap

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

In this preso, we have:

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Overview of Devrel
Function, role, and politics
Devrel and you
Explored possible career paths
Actions to figure out if Dev Rel is for you

There is a lot more:

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz

Value proposition
Audience
Dev decision makers
Dev plus, dev first
Organisation alignment
Metrics
Phases/ levels

Thank You!

Keep building!

🧍 Brendan Graetz 🌐 blog.bguiz.com 🕊️ @bguiz 🐙 @bguiz