Creating the

DevRel Identity

for your company

Hi, I'm Ben (aka @obensource)!

Howdy


Howdy


Howdy

The sources for this talk

are derived from:

First-hand experience

Well documented
best practices

Countless conversations

with the wonderful people in this space, from:

Google

Microsoft

IBM

Amazon

Apple

Atlassian

Adobe

Slack
et al (not exhaustive).

Assumptions

This is a 'ground up' talk that tries to address a spectrum of business contexts and concerns.

Some of this may be well known or in practice for you if you already work in a mature DevRel program.

We're all in this together.

Imagine...

You're the very first Developer Advocate
at your company

Your task?

Create:

World Class

Developer Offerings

Scale:

Product Gravity

through the adoption of your APIs

"Build a community around it" 

Oh, and by doing all of that effectively
you'll...

🥾 Bootstrap
🛠 Maintain
📈 Evolve

Your company's DevRel Program ✅

So...

How do you start

making this task
unambiguous?

¯\_(ツ)_/¯

Let's frame this

in terms of quality

Inputs & Outputs

Study your leadership's

structure and
communication dynamics

(they are the gatekeepers of your role's success)

(Inputs)

Joe's App Shack

(small business)

"We build ‘em, you sell ‘em."

DevRel

Devs

Design

PM

Product
Lead

Devs

Sales

Marketing

Slick

(mid-sized business)

"The Slick way to do business communications"

Microhard

(enterprise business)

"If you don't subscribe already, you will soon."

Serve first, ask later.

Part of the

DevRel scope
is the
Developer Persona

(Inputs)

Has your

surface area been defined for you by your leadership?

No? Then you can define it before someone else does.

What's your position within the company's structure and power dynamic?

(Inputs)

What do they

think of you?

And how do you know?

You're working between the

tension of

two philosophies

in residence

(and continually validating the existence

of your team in relation to them)

One: Rising the Tide

(Most Important: Shared Value)

"A rising tide lifts all boats"

–Anonymous

Organizations who tend to care about this the most

• DevRel
• Misc Engineering Teams & IC Developers
• Open Source Programs Offices (OSPOs)

Two: Beating the competition with a monolithic product

(Most Important: Capital growth, and scaling sustainability)

Organizations who tend to care about this the most

• Investors
• Product Leadership
• Marketing
• Business Development

DevRel lives in

the 'eye of the storm'

Rectifying the alignment of

the rising tide and product sustainability

(Eg. Proving the business value of supporting standards, while delivering your part of the 2 year product roadmap)

Output Frameworks

(Outputs)

(Outputs)

"Create content first, help grow the community, and with that – refine the product."

– Seth Juarez, Cloud Advocate @ Microsoft

Continually

creating content

is a primary thing

This unifies your narrative publicly, and privately.

Take advantage of the uniqueness of your role

(Outputs)

Apply Radical Candor

(your agnostic position is a privileged one)

Set up regular

(or periodic)

check-ins with your stakeholders

Co-collaborate as much as possible.

Is what you're doing in-tune with what they care about?

Solidify your usefulness across the company

(Outputs)

Do things that

people care about

Align your OKRs & Roadmap with your org and across company verticals

OKRs and roadmaps are community bridges!

Also take Agency of

(Aka Co-Own)

Culture

Communication

Collaboration

Education

Identify & Relieve Product Thresholds

Advocate for community interests in developer marketing

(Authentic Narrative)

Internally educate your non-technical organizations on developer persona

best practices

Principals for

Solid Output

Regular content creation cadence

Contextualize your KPIs to how your leadership tracks progress

Define what your DevRel team's Qualified Leads are

up front

(For more: read "DevRel Qualified Leads" by Mary Thengvall)

(Outputs)

Use Friction Logging for output validation

(For more: read "An introduction to friction logging"

by Aja Hammerly)

(Outputs)

Prioritize

regular feedback from peers and colleagues

across teams & company organizations

(Outputs)

Output Measurements

Disclaimer:

Different output measurements mean different things to different people at different sized companies.

Check out The DevRel community's blog on DEV for an exhaustive list to spring from

(https://dev.to/tessamero/measuring-success-and-kpis-in-developer-relations-community-contributed-outline-1383)

Most of the time, it's the money that talks

Eg. 'How many subscriptions to your service were a direct result of the OKRs you set?'

(Outputs)

Regularly capture and synthesize

first-hand product feedback and use comparison language

(Outputs)

Define your

DX benchmarks

'How long did it take an average user to go from no exposure to our API to having something meaningful on their screen?'

(Outputs)

Categorize your KPIs by

stakeholder persona

(Outputs)

Other things worth measuring

(for your own growth)

The consistency of your narrative across your domain

(Eg. Am I saying the same thing in my Code as I am my Blogs and Tweets?)

Relational integrity with teams & orgs

(Eg. 'How often do we check in?')

Groundswell Support

('How many people said they agree with me on my position?')

(Outputs)

What are the results

of all of this?

Strong Opinions.

Created, fostered, delivered.

Created

Data

Shared Values

Bridge Building

Agency

(Outputs)

Fostered

Groundswell support

Effective Performance Measurements

A consistent, inspiring narrative

(Outputs)

Delivered

Great DX outputs that scale your company and community over time

(Outputs)

Thank you!

Twitter: @obensource

WWW: obensource.com

Mail: ben@obensource.com