Monday, October 21, 2019

Podcast: Matt Broberg talks Developer Relations

Matt Broberg is technical editor for opensource.com. In this episode, he takes us through what Developer Relation is, how to measure its value, the "soul" between the data points, and some of the ways in which DevRel roles can vary from company to company.



Listen to the podcast [MP3, 17:37]

Subscribe to Innovate@Open on your favorite podcast app.

[Transcript]


Gordon Haff:  Today, I'm here down at All Things Open in Raleigh with Matt Broberg, who's the technical editor of opensource.com. We're here today to talk about Developer Relations.
Let's start with something pretty basic. What the heck is Developer Relations?
Matt Broberg:  I wish that was as basic as you asked. To attempt to put it into a quick summary, Developer Relations is an organizational unit, a business unit that is tasked with relating to developers. I think that's the quickest way to summarize it. You might hear job titles of people in DevRel as we call it that are developer advocates or developer experience engineers.
There's a number of nuanced roles that end up falling into it. It is a bit of na ew definition of an organizational unit. There's a lot of discussion on whether it rolls into one of the traditional ones or if it lives on its own. Yeah, DevRel's a thing.
You'll see job titles for it all over, but exactly how it fits is very much up for discussion.
Gordon:  How is this different from where we were historically because obviously companies like Red Hat, Microsoft, and others, have certainly had developer programs for a very long time. Are things different today?
Matt:  I think they're wildly different. My understanding of the history of this is we have this sort of rise of the developer evangelist in the technology space. These people that were on stage speaking and other companies started to notice the impact these people had to the association with their brand, the excitement around the open‑source projects around the brand.
With time, evangelism became less of the goal. It was more advocacy around participation in either the open‑source or even closed source communities of a given project.
With respect to developer relations, the need for it has risen out of the inability for the traditional marketing and traditional project manager to relate to a developer and be able to communicate in their language the value they'll get from using certain technologies. I think of it, kind of similar to how DevOps has risen out of the need for Dev and Ops to communicate differently.
I do think of DevRel as something that the project management side of the house and the marketing side of the house are trying to find this new need and DevRel's filling it.
Gordon:  If somebody is doing DevRel, or of somebody's thinking about what Matt just talked about, that's sounds sort of like something I might want to do, how should they expect to spend their days?
Matt:  The day will depend on talking to the team that's hiring you about what it is and looking at the job description closely. DevRel does seem to be a catch‑all for a lot of different things in the developer community.
For some organizations that means hitting the talking circuit and being at a lot of the most innovative and highly networked events around the industry and whatever vertical you're in. A lot of DevRel folk in the open‑source community are here at All Things Open.
Writing articles and other kinds of content. Creating podcasts, like we're doing now. Those are some of the outputs that tend to be measured.
Others, it's about code contribution and being a shepherd of a particular community. Let's say you're a subject matter expert in Python and our project requires a Python SDK. We're looking to get more Python adopters. You, being the person that speaks to that and contributes to the code and helps curate that contribution, is more of the core facet.
I wish I could give you a solid single definition. I can tell you for sure you need to talk to somebody about what it is. You'll do some weird, but wonderful, combination of speaking and listening and coding and not coding [laughs] .
Gordon:  One of the things you said does talk to some of the background of people who might go into DevRel. You're suggesting that for some they might be doing quite a bit of coding, which obviously implies a certain interest in and some degree of technical background. Whereas there's other people at DevRel who really don't consider themselves technical.
Matt:  That's a good note. I tend to look at it as something where coding, that is the core part of your responsibility when I design a DevRel organization, which I've done a couple of times. It comes to finding that right mix of coding and talking.
For many organizations they just need somebody who can talk to somebody who is a developer. That has a lot more to do with your knowledge of the community, knowledge of the ecosystem, and less to do with how much time you spend pushing code to GitHub or to GitLab.
I appreciate that. There's no gate‑keeping here. Regardless of your background, you can be inside in DevRel. You may need to learn some of that software background to participate. It's really: Are you able to participate and communicate to the degree that aligns to whatever your business needs out of a developer relations organization?
Gordon:  You mentioned measurement in passing a minute or two back. You just gave a talk here about measurements and metrics.
I'm in an evangelist role myself. Fairly different from a developer relations role. I have struggled with that same issue of metrics and measurement. Part of it is that the stuff that is easy to measure is often the stuff that isn't very important; you hope it is a proxy for something that's important, but is really challenging.
Whereas a metric of how much do developers respect us as a company...you can do surveys and the like, but that's still kind of a hard thing to really suss out.
Matt:  Yeah, finding the soul between the numbers is always this thing. I keep trying to struggle with it because it's fun, and it's hard, but the way I approach it these days is I think of the different things we could measure, the tally marks and peanuts that we're counting.
That's raw data that we're going to feed into something, but when we're communicating our value, that's actually a business motion. We have to talk about what metric, which tends to be an aggregate metric, something that is providing more value than just, say, the number of talks I've given.
I think the number one thing that somebody in a DevRel‑ or evangelist‑type role as well, it's the stories you can tell after. Who have you influenced, what did they do with that information, what is something that happened that wouldn't have happened if you participated?
Telling that angle, which is not measurement. The core measurements, there's a couple that we can talk through that are really fascinating, but I think at the basis of it, there isn't a standardization. There's a need to know what you're being measured against, and whether that is how many people show up to your talks or how many people are contributing code to your open‑source project.
I've seen both, and they're both valid DevRel, they're just wildly different needs.
Gordon:  I think historically, there has been this tension or conundrum in, perhaps particularly open‑source ‑‑ though it's certainly not exclusively oriented towards open‑source ‑‑ towards looking at things like how many times something has been downloaded, for example.
Which has been super easy to measure, and probably indicates something. If the number is zero. That's kind of bad no matter how you slice it, but it also doesn't really tell you, for example, how much it's being used, how engaged the users are
Matt:  I really love this point, Gordon, because I don't think data has an opinion. We imply a lot of opinion from data.
Downloads, for example, you're like, "Is downloads good?" Probably yes, to some degree. Maybe it's bad if people have to keep re‑downloading the same thing in order to get it to run.
It might be a problem with your uptake for whatever project you're working on. I tend to think of downloads in some sort of time series. It's like downloads per day or downloads per week, downloads per individual, how many unique downloads can we have.
Now we're getting to data and parsing it in a way where we can tell a story behind it, because data on its own is just the raw bits. The stories can actually be really harmful if we don't use it in the right way.
A more common example, people talk about page views, because a lot of us create content. How many page views are you getting for what you're doing? Page views feels really vain, it's a vanity metric at its heart, but it can be a really good standard if other organizations you work with use page views in a way.
I can say when I write an article on opensource.com, I can get 10,000 page views to the right audience of developers, but we may have to spend $5,000 to get that syndicated to an expensive platform that we're paying for.
My free path is meeting that same measurement. Now I'm talking about business value. I'm adding value by writing here as opposed to money funneling there.
It's when we can find that comparison point that we go from a raw and maybe uncomfortable, maybe seemingly useless metric, to something that's like, "That data is transforming into a metric that will add value."
Gordon:  As you mentioned, time series, changes over time, can also be very valuable. Whatever you think of page views, for example, as a metric, if it is going up steadily month to month, quarter to quarter, year‑to‑year, that is probably a good thing.
Matt:  Yeah, exactly. It's fitting into that larger narrative of what's changing, why is it changing, can we find that if we push something, if we poke this that it goes up or down, so that we can test our causality with that change. That's fun too, but that's pretty advanced.
It really does come down to, can you measure the things that are worth measuring? Then can you find the metric that people are actually going to care about? A pitch, they don't pay me to do this, but Bitergia is the place to get your data in there for everything from Slack and Discourse to GitHub, GitLab.
It all aggregates it and starts to identify individuals and see their path through your community, so seeing the correlation of data is easier than ever with the tooling.
The storytelling is just as hard as it always been. We have to keep doubling down there and that's why I keep talking to people like yourself about it.
Gordon:  It does seem in general, we have the data points now and we know how to correlate them in things like that. As you say, you can still risk over applying certain types of vanity metrics, as you put it, GitHub stars and that kind of thing.
But we do at least have that data, so we at least have a baseline where we can be thinking about how to measure effectiveness and how to really direct people so they are more effective and take actions in that way.
Matt:  There's a wonderful phrase of, "Just be careful of what you measure because if you incentivize it, you will achieve it." Which means that even though these metrics, if these data points are a proxy for some point of value. GitHub Stars, my understanding for many is that it's a proxy for popularity and popularity's a proxy for monetization. That I can make some money on this if there's a lot of people that star it.
But if you start focusing just on stars, it's not going to necessarily correlate with the monetization. You still have to have the understanding of what's the business flow to make money, because open‑source is not a business model, as we're well aware.
So understanding like the flow all the way through from the raw data you're using to the outcome you're presuming, we all have a responsibility to inspect that and take the time to understand the impact.
Gordon:  Well, going back to downloads, for example. If you really focus in on downloads and you certainly saw that a number of years back in a lot of cases. If you make that your metric of success then the answer is, well, we advertise and let people know and encourage them to download and give them gift cards if they download and everything, and then our job is done.
Matt:  You nailed it. Now you're done, so exactly. There's a corollary to that. The bad of that is that you can miss the soul of it. You can miss that people want to be happy about what they're downloading, they're not downloading it because they're pissed off. There's a nuance there, of their emotional state as they do so that you can't really grab there. The question is, how do we pivot our metrics?
You start representing happiness as opposed to just raw downloads. The other thing is maybe you're right, maybe if downloads are a great metric, maybe you go to fewer conferences and save the money and give out some gift cards. That's a valid strategic move based on data informing it. That's why data can be very informative but it can't choose for you.
The data doesn't have an opinion on your strategy. You have to have that. There's a lot of work to be done in our space to inform and share common models that are working, because all models are wrong, but some of them are quite useful. It helps us communicate value in the same way as sales can talk about their sales qualified leads leading to closes. We need that in community work that leads to happiness as well.
Gordon:  There is the idea of the funnel, if you would, with developer relations as well. If everybody knows about your product, project, software, well, maybe building awareness isn't something you need to focus on. Maybe they are aware of it but they're also aware of how horribly hard it is to use. Maybe in that case you should be focusing on documentation, training seminars, that kind of thing.
Matt:  It's funny, because anyone who has done this for a bit, we all know the right things to do. The question is, "Can you justify it with your model?" Absolutely, I think, applying a sort of marketing funnel strategy to this, Mary Thengvall who wrote the book about DevRel as a business model is super brilliant. She's talking about DevRel Qualified Leads or Community Qualified Leads, same idea of having a single unit of measure of handing off individual contacts throughout the business.
I think it's a really cool metaphor that we might want to use strategically to be able to say, "Hey, this is who we bring in." Sometimes we hand them over to recruiting to get hired and sometimes they go to sales, sometimes they go to products.
That's the unit of measure so maybe that's part of the answer. I'm not totally sure right now but I do know it's going to be unique to your business .
Gordon:  Sometimes there's a discomfort with these kind of metrics because I think, for many of us, our first reaction is, "Oh, look, we're talking at a conference. We're writing a lot." Just trust us.
We're doing good things out there. The fact of the matter is if we don't all focus too much on the page views instead, so finding that, I think you called it the soul in between those really is challenging
Matt:  The soul between the data points is really hard to capture. If I could, I would completely drop all this data hunting stuff that I like to do even though it's kind of fun for me and just focus on the soul stuff like the things where somebody feels included and loved and cared for and that it's part of their identity to be part of the community.
But I've seen time and time again when you focus just on that, you end up losing funding. It's just a fact of business, and capitalism which we can't reject.
We have to accept where we're in in our system and build the system on top that will justify it, the models on top that will justify it, I'm with you, I want to find the sole in it. I think that we still need to get a strategy to quantify it so that we justify it ourselves.
Gordon:  Thank you, anything else you'd like to add?
Matt:  I really enjoyed talking to you. If anyone interested in how they can learn to write about their technology skills, maybe if you are an engineer and you've never done this before, I coach people as part of my job at opensource.com. Reach out, open@opensource.com. I'm happy to work through learning how to write your open‑source stories.
Gordon:  And even if you aren't a full‑time writer like I often seem to be, I would really encourage people to do this thing. It's a great platform for you to get better known. It's fun to do at least I find it fun to do. It's really a way to share, to let others know about your experience as always to get involved in new things.
Matt:  Definitely. We try to make it a very exciting community to be a part of so we got everything from cool swag to really great people we'll connect you with. Yeah, reach out.

No comments: