Jessica West, who heads up developer relations for LaunchDarkly, lays out the importance to any developer relations programme of having the support and commitment of the company’s leadership.
Last updated
Was this helpful?
Three types of executives
They get it.
Middle ground.
No clue.
Implement Strategy
Program your initiatives
Creating measurements
Communication
The key is that you need to understand your value to the executive team.
Then you need to use that to measure against their priorities.
Defining executive buy-in
Looks different for a lot of places.
For the purpose of this talk, executive buy-in is an executive that understands your goals at a high level and advocates for you.
Not only defends you but advocates for you and says yes I understand what this person is doing, here’s the value they bring in, and I am behind it 100%.
Questions to ask executives
Overall value.
Success Factors
Teamwork
Communication
They get it.
They’re on your page.
They have a clear plan, there’s no question on budget or initiatives.
They’re all in.
Middle ground.
Understand developer relations.
They think it’s a cool thing, I’ve heard it and they’re “bought-in” and I do quotes and we’ll talk about that in a minute.
No clue.
They’re not quite sure what they need
“Dev rel” and they’re like “Yeah I don’t know. I don’t need to talk about that”.
How do you maintain buy-in and make sure there is no single point of failure?
Because yes they bought in but it doesn’t mean they’re always going to be bought in.
How can you maintain it?
Communication
Internal evangelism
Create a Roadbook for your future advocates so they know when they come in.
What does it mean to be an onboarding developer advocate at your specific company?
Ultimately you’re going to be fighting an uphill battle, and if your executive doesn’t have that buy-in, there’s not a lot of point for anything else. -- look for another job. ~ Speaker’s opinion.
Where a lot of developer relations departments and teams are right now.
The executive is there, they’ve heard of it.
How do we measure and execute? Not sure, kind of in-between space.
Ask more questions.
Make a clear path to align company values with yours.
Discussing what success factors look like for that department.
Communication, Teamwork, and ultimately, some strategy questions.
“Why do you think developer relations are important?
What value do you think it brings?
What are you looking to get out of dev rel?”
If the answer’s “I don’t know”. --- maybe it’s time for another job search.
If you have that question and they say they saw another company doing it and that’s the only reason they have, that’s a warning sign.
What does a successful dev rel person or team look like?
“How are you measuring success?”
And not just in developer relations but in the whole company.
How are they measuring success for Engineering? For Marketing? For Sales?
What does success look like to the board?
How is that divided amongst the whole company?
What does Marketing do, what do Sales do, what does BizDev, do you even have a BizDev?
Do you have a Customer Success team?
Do you have an Education team?
Changes in scale from companies from 0 to 50, 50 onwards and that could look different at one 50 person company to another, or even 1,000 person company.
How is the goal distributed?
And are stakeholders goals being represented around the team?
What goals are associated with them?
Are those goals then represented in your team?
How are they being found?
Communication
How do you currently communicate?
Are there newsletters that go internally? Externally? Is it all in a forum?
You can see how they communicate within departments and how you can communicate as a developer relations department.
How is communication handled between other departments?
Looks different for a lot of places.
For the purpose of this talk, executive buy-in is an executive that understands your goals at a high level and advocates for you.
Not only defends you but advocates for you and says yes I understand what this person is doing, here’s the value they bring in, and I am behind it 100%.
It is a tough place where people say “I believe in developer relations but I’m not quite sure how to measure and execute it”.
You might be going back and forth but you have a path and it may not always be clear.
Digging in and going back to those questions you have to ask the executive team.
Help start lining up your strategy and your goals.
Program your initiatives
Setting up programs for what you’re working on.
Creating measurements
What is it that you are measuring?
You need to set that measurement up. And with that reporting ideally. And then
Communication
Segmenting your developer relations teams or your developer relations initiatives into programs is really beneficial.
It May look like an ambassador program or a hackathon program,
Different types of events.
Education initiative.
Segment into programs and then you can have clear outcomes.
Developer Engagements
How many people were in your audience?
I’m giving a talk here so I can report back that x many people showed up and heard me speak.
Example - Goal as a company and we want to be in this forum, and we want to measure how many users are on there, and how many active users are there.
Communicate internally.
Because then nobody in your company knows what you did.
They think you’re doing work.
But you have to communicate that. And that may look different in a lot of different places.
Letting the company know what you’re working on is really key.
Important because they may not know and maybe they missed the email because we get a lot of them.
That’s really big and it won’t take much of your time.
Doing an internal wiki to showcase your work.
Have a homepage page that shows what we’re up to, here’s what we’re working on, and come talk to us about it.
Sitting in on other department meetings.
Coming into your partner department and going and asking what they’re up to.
Learning about what they are working on once a month or whatever that cadence looks like is really important.
Doing event recap internally and externally.
Do a quick recap on why you thought it was important for the developer community.
Team meetings
Having an open invitation for any department to come to join your teams.
