Creating the DevRel identity for your company

Speaker 1: Today, I'm gonna be talking about, crafting the DevRel identity, for your company. Woo hoo. What does that mean? I am speaking from firsthand experience here, and I will get into that shortly. So hi.

Speaker 1: I'm Ben. I am open source everywhere on the web. If you're looking for me somewhere, you can find me by looking that up, most likely. I have worked on a few projects. Most recent recently, I was working at Envision, and, have worked on open source projects like the OpenJS Foundation, Node.

Speaker 1: Js, t c 39, most most recently Unicode, w three c, some standards working groups and such. Howdy. Howdy. Howdy. And some of the sources from this talk or for this talk are derived from a lot of first hand experience, primarily at at Envision, trying to scale up a DevRel program there for a period of about two years.

Speaker 1: Some of the resources are from best documented documented best practices and then just countless conversations with wonderful people all across the spectrum, the developer spectrum. Some of the assumptions for this talk are that it is ground up. There's a lot of different contexts about size of company and business and what types of teams that you're working with. Some of the things I'm I'll talk about maybe well known if you're in a Deborah program already that's scaled up or you work at a large company. Some of these may be new, and I hope they are, and I hope it helps you.

Speaker 1: In the end, we're all in this together. So I hope this is either a rehash or helpful upfront. So let's imagine that you are the very first developer advocate at your company. You were hired to boot up the developer relations program. Well, what's your task?

Speaker 1: One of them is, to create a world class developer offering. Another one would be scale product gravity through the adoption of your APIs, most likely, across the developer spectrum. And build a community around it. That's my favorite. We put communities on things.

Speaker 1: Oh, and by doing all this, you will effectively bootstrap, maintain, and evolve your company's DevRel program. So how do you start making this task unambiguous? Because that's, you know, that's the the the classic thing about DevRel. Right? Is that all the the tasks are loosely defined and pretty ambiguous and sort of high level terms that you're faced with.

Speaker 1: So let's frame this in terms of quality of inputs and outputs. That's how I'm gonna proceed with the rest of the talk. So I'll talk about, the quality of your inputs and the quality of your outputs and how that results in delivering, strong opinions that build your program over time. So input number one, study your leadership's structure and communication dynamics. Your leadership is the gatekeeper I mean, the people in your leadership are the gatekeepers of your role's success.

Speaker 1: They hold in their hand your ability to continue what you do and make DevRel awesome at your company. So I'm going to talk about this in terms of three different sizes of companies to sort of hit the spectrum here. Let's say you work at Joe's AppShack, your small business, and you build them, you sell them, you make apps for people, they reap the reward, or the profits after you build them. So within this context, you might be just central, right in the middle of the conversation between everybody. And it's gonna be really easy for you to go directly to your product lead, if you need to voice, concerns, from the community and synthesize your metrics and your information into something that is directly actionable by the the developers on your team or the designers on your team.

Speaker 1: And it's a pretty small shop, so you're able to really have a ground up persona within your within your company. Well, let's say you don't work at Joe's Obshak. Let's say you work at Slick. It's a mid sized business, and they're really good at business communications. In this case, you're going to have multiple verticals that you're thinking about.

Speaker 1: And the verticals are represented by product organizations, so it may be I mean, by organizations, so it may be a product org, maybe marketing, maybe business development, or any of the above, sales. And you still have the autonomy to be able to to craft your metrics well and probably go set up a time to go directly with the leadership to be able to evolve your business and co collaborate. Well, let's say you work at MicroHard. It's a big enterprise business. If you don't subscribe to something that they offer, you probably will soon.

Speaker 1: So it's the the you're probably you're like, in a big business like this, you're not going to be starting from the ground up. There's already going to be a pretty matured organization that you're going to exist within. However, you might be, tasked with booting up a very strategic aspect of that, developer, advocacy program to handle, the growth of the community around a certain offering. Like, let's say, at MicroHard, you need to need to build up the community around their teams platform or whatnot. Yeah.

Speaker 1: You you're going to have to work really hard to to gain the trust. You're going to have to serve first and then act or ask later. It's it's really important to think not go in guns blazing, but think about it in terms of how do I serve and how do I gain the trust of the people to trust me for the task that I was given. So that might be your case. And if that is your case, I the rest of this may be more common knowledge to you, but hopefully you get something out of it.

Speaker 1: So next, I'm gonna talk about inputs. So part of the DevRel scope is the developer, persona. So you have your own persona when you're building up the DevRel program that you can bring into the conversation that is not familiar, necessarily across the other that you were actually responsible to it's not familiar across the different parallels of the organization that you work within. And you might be you might be talking about how to evolve the mastery of your company or your company's mastery within the domain of standards as a long term plan as long alongside the goals that are two years out for the the current roadmap. But it's really important to recognize this upfront as as an input, you know, that the community is your input, and then you're able to synthesize the community's concerns to your company as well as advocate for the concerns of your company with within their community.

Speaker 1: So has your surface area been defined by your leadership? Probably not. They're hiring you to do this to do this well. So it's up to you. And you should define this before someone else does it for you.

Speaker 1: What's your position within the this is another important input. What's your position within the company's structure and and power dynamic? So yeah. I I kinda touched on this already a little bit, so I'm gonna move along here for time. But I think what's most important is what do they think of you and and how do you know?

Speaker 1: How how do you know? How do you how do you track what they think of you? Are you do they even know about you? Are you, are you just a number on a page? Or do you have a relationship that you're building with leadership and across across organizations within your company?

Speaker 1: I think something that's really important to recognize upfront if you are trying to advocate for changes within your company that build a developer relations program over time is that you're you're gonna be working between the tension of two philosophies that are in residence at your company. And I this is pretty true across most every company I've ever encountered. You're gonna be continually validating your existence the existence of your team in light of these two philosophies. And the first one is rising the tide. There's a lot of people that believe in shared value and pursuing pursuing the ends or the end goal around what it what is the shared value of what you're doing.

Speaker 1: Is it evolving your tools over time? Is it, you know, is it making tools such that your company is the master of them and other people rise up around you to be able to use them and profit from them as well? There's a lot of people that believe in this. The organizations who tend to care about this the most are typically DevRel, engineering teams, IC developers, and definitely if there's an open source program office programs office, they're gonna care about about thinking things this thinking about things this way within the company. The second philosophy is beating out the competition with a monolithic product.

Speaker 1: And this is most important to people who are most solely focused on not solely, but most focused on capital growth and scaling sustainability for the business. The organizations within the company that tend to care about this the most are the investors, the product leadership, the marketing, business development. And DevRel definitely lives in the eye of the storm between these. As far as in my experience of building a program over a couple years at a fairly large company. I had to consistently rectify the alignment of the rising tide, how does this benefit everyone in the ecosystem, and product sustainability.

Speaker 1: How are we actually delivering outputs that matter? And that's why I keep coming back to the proving the business value of things like supporting standards that reinforce the short term goals with the long term solid goals that put your company in a position of leadership. So let's move on to output frameworks and outputs in general. This was a great quote that Seth Juarez from Microsoft, he's a cloud advocate there, recently told me. He said, create content first as a developer advocate.

Speaker 1: Create content first, help grow the community, and with that, refine the product. Continually creating comment content is a primary thing for any developer advocate or advocate program. You're if you're not creating content, you're not telling a narrative, you're not tying things together. It unifies the narrative publicly and privately. And then take advantage of the uniqueness of your role.

Speaker 1: You know, being a DevRel is like playing the instrument in a band that nobody really plays, And so they look to you to do it well. And you get to leverage that with the relationships that you build. Apply radical candor. There's a I I would say there's a one to one relationship with the application of transparency and radical candor with each activity in the communication across your organization. And you're in a privileged position.

Speaker 1: You get to, be agnostic about, you know, developer opinions about, you know, APIs and developer tooling and this sort of thing and be able to communicate that across the company on behalf of on on behalf of both the development community and the company that you work for. It's like being a diplomat. Another good good way to do this is to set up regular or periodic check ins with your stakeholders. Co collaborate as much as possible. You don't wanna be in the dark.

Speaker 1: Continue checking to see if what you're doing is in tune with what they care about. Another output framework here is to so this is this should be fairly obvious, but solidify your usefulness across the company. That's what essentially what you're trying to do. And do things that care people really care about. A way a good way to do this is to align your OKRs, which are objectives and key results.

Speaker 1: Essentially, a a road map contract, if you will. So if if you can align your OKRs and your road map with your without within your org and across company verticals, it's like being a community bridge across your company. And also being able to think about what the community cares about and framing that in the terms of your OKRs are really important too. Also take to take agency of, culture, communication, collaboration, and education within your company, and, and co own it, as a program. So, a good output that is really beneficial for product is to identify and relieve product thresholds.

Speaker 1: So if you have if you have, you know, thousands of users waiting for one feature from one company so that they can adopt your API. Recognizing that and communicating that and advocating for that is definitely going to solidify your position within the company and be very help you be become, you know, more and more valuable. Advocating for community interests in developer marketing to retain an authentic narrative is a good output. Intern internally educating your technical organizations on developer persona best practices. Just taking agency of the fact that you are someone with knowledge across, you know, in a domain that other people need to be able to do their job well.

Speaker 1: Educating sales on how to best to to best communicate with developers about tools that they may want to use at which time in their in their development cycle, you know, for example, is a is a good way to think about this. But being able to be that that voice of the developer to the rest of the companies is is a good way to make key outputs that help the company grow too. So principles for solid output, have a regular content creation cadence, contextualize your KPIs, your key progress indicators to how your leadership tracks progress. So you don't wanna just make your KPIs only relevant to your team or your your org, but you wanna think about it across how the company is tracking KPIs. Define what your DevRel team's qualified leads are up front.

Speaker 1: This is a really common becoming a common term within our the DevRel community. You wanna read more about it, check out DevRel qualified leads by Mary Thingbull. It's a really key way to think about producing value over time. It's DevRel. Use friction logging for your own output validation.

Speaker 1: You don't just have to use friction logging, which is another great tool in the the developer grab bag. Usually used to, you know, validate things like the usefulness of blogs or documentation or things like that to validate the points of friction or to notate the the points of friction and then alleviate them over and over and over. Do this for everything you do. It's a great great way to think about your your outputs in general. Prioritize regular feedback from peers and colleagues across teams and company organizations.

Speaker 1: And finally, I'm going to briefly touch on output measurements. So there are different output measurements that mean different things to different people across different sized companies. If you want to, see a more of an exhaustive list, there's a community generated exhaustive list, on the DevRel, on this dev two blog that Tessa Merrill published. There's a link to it down there. Please check that out.

Speaker 1: It's really great. Most of the time, I'll say it's the money that talks. So when you're when you're looking at your KPIs and your outputs, you can think of things in terms of, like, how many subscriptions to the service that your company is offering were a direct result of the OKRs that you set, and how do you track every point of output all the way back from what you put out to how many subscriptions happened? Okay. And then regularly capture and synthesize percent product feedback and use comparison language to other companies.

Speaker 1: People love that. 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? What was the time frame? What's what's a meaningful time frame for us?

Speaker 1: Categorize your KPIs by stakeholder persona. So think about which KPIs are meaningful to which person in the company. And if you want to look I'm running out of time. So if you wanna look at some of the other outputs I suggest, please check out my my slide deck. But I will say that ground wall support ground swell support is is vital.

Speaker 1: Instead of going for the jugular and advocating for something, gathering everyone around you and tracking how many people say that they might agree with you on a position to be able to then, build your opinion. And the results are strong opinions. You've created them. You've fostered them. You've delivered them.

Speaker 1: You've created data, shared values, bridge building, and agency. You foster ground swell support, effective performance measurements, a consistent inspiring narrative, and you've delivered great DX outputs that scale your company and community over time. Thank you.