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:
Post a Comment