The four pillars of support in developer relations

Speaker 1: Thanks, everybody. Welcome to our talk, and thanks so much, Matt, and the other DevRelk on Earth organizers. We appreciate you. Let's jump right in.

Speaker 2: Yes. So raise your hand if you know who Misty Copeland is. I'm just kidding. I know you can't oh oh, so one person. Anything is possible when you have the right people there to support you is apt because not only is this Misty Coughlin, who is a famous ballerina, who means it metaphorically, but she also means it literally.

We're gonna stick with the metaphorical version. Mary?

Speaker 1: Yeah. So why are you here today at our talk specifically? Maybe you're here because you need support. Maybe you're here because you want to support others better. Maybe you're here because you wanna know more about developer relations, or maybe you're just here because you're our friends, which hi, and thank you.

But most likely, you're here because supporting anyone, whether you're supporting individuals or groups of people or anything, organizations, companies, projects, can be a little complicated and complex sometimes. And we're here to shed a little bit of light on what that means and how to do it. But first, before we jump into that, who are we and why are we here? Yes.

Speaker 2: So I'm a community manager with Packet, an Equinix company. I am also a technical collaborator with the open source project Tinkerbell as of just last week, which I'm super excited about. I've been working with communities for over twenty years, and Matthew took away my fun fact, which is that I've disappeared into a box stuff with swords and a pike. Very important. And, Mary?

Speaker 1: Yeah. So Matthew gave a great intro. Thank you so much. To add on to that, I am now the director of developer relations at a company called Camunda. We are an open source process automation company, so we can automate any process anywhere.

We work with a variety of companies all over the world, and I'm lucky to be leading and building a developer relations team there. And excited to talk to you more about how we're doing that here today.

Speaker 2: So that we're on the same page, we wanna define a couple of things. One is support, and the other is developer relations. And we mean support in the sense of to hold up or add strength to figuratively, serve as a foundation. And that last bit, especially with patients, is is key to being a a developer relations professional or to anyone who wants to be a part of a community.

Speaker 1: Absolutely. And the the the definition of developer relations that we're working with today is to build relationships with and enable technical communities, and it's that enablement part, the supporting part of enabling people that we're really focusing on today.

Speaker 2: So when we talk about support within the context, it's not referenced to those people that you call when you wanna fix your computer even though they are awesome and kick ass. We're actually talking about community support.

Speaker 1: Yeah. So what does community support mean? We're talking about the idea of, again, sustaining, encouraging, upholding something. And these four pillars that we're we'll be walking through today are how we support individuals, maintainers, projects, and communities. So we're taking this kind of five and a half foot, which is, you know, average height of people, to then 50 feet, which is, like, the average height of a house, a 100 feet, which is the average height of a company building, and then a thousand feet, the the kind of world view of it all.

So let's Exactly. Start with individuals, shall

Speaker 2: we? Yes. So when we talk about individuals, it's important to understand, that we're not necessarily talking about our maintainers. We wanted to focus in on maintainers as a different group within the community. We're talking about the individuals who are new, who are making contributions that are not necessarily technical, but are also technical.

Pretty much individuals are all the people. They may fit into another section within this group. They may also be maintainers. They may also be project leaders. They may also be, of course, they're gonna be part of the community, but it's important that, this is this can also be the consumer, the end user, the operator.

And these could be people who go and give talks at conferences who aren't necessarily contributing to the code at all, but just doing a demo. Those are all people that are part of the community. And it it includes people at companies, and it's it's kind of important to think of those individuals not just as employers of that company, but as individuals. And, and we've we find that the the individuals are like the Adams. They're the building blocks of the community.

It's the smallest unit of measurement. And even though I'm slightly higher than five five, I'm considered an individual. And Mary, being a little bit shorter than five five, is also an individual even though we may have other responsibilities within the context. There is a quote for individuals. It's all about building the relationships.

And within the context of developer relations, you might say with developers, but it's also about, as I said, the the users, the operators, the managers even of individuals as well. Connecting them with each other as well as you is very important. Amplifying their voices instead of your own so that your voice is scalable. Individuals within a community are so important in so many ways for conference talks, highlights in newsletter, blog posts, etcetera, etcetera, etcetera. As I said, there might be there are four ways that we've listed about how we support these individuals.

And, you may notice if we were doing this with a live audience, we would be like, what do you think is missing? Because at first glance, these four points about content, about contributor guidelines, communication, and weekly meetings seem like very solid ways to support individuals. But quick as a wink, someone raised their hand at DevRelCon Czech Republic and was like, you're forgetting mentorship. And that's right. We are.

Except we're not forgetting it. It'll be mentioned later, I promise. But I wanted to call it out that mentorship is so valuable, especially between individuals, for bringing new people in, for being able to not be the sole point of failure for any collection of code or documentation or speaking or whatnot. You want several individuals within your community to have groups of responsibilities. And this is how we get to from these four content contributor guidelines, communication, weekly meetings, then we move up not up, over.

We specialize our individuals and reach towards our maintainers for the second column. That's the word I could not think of. Mary, go ahead.

Speaker 1: Sure. So I'm the maintainer. Sorry. Say. You can jump right in where I can.

We're good.

Speaker 2: Nice. Alright. Individuals maintainers Brief. Brief. Okay.

So one of the reasons why I specifically was so enthusiastic about speaking about maintainers is is that I am particularly passionate about making sure that this group of people doesn't burn out. As someone who's been a maintainer of of projects and seen several maintainers of projects, this this delicate there's a certain delicate pressure and balance that needs to be maintained between being one of, hopefully, not the only sole point of of responsibility, but, that pressure of always being responsible for this group of code or project. Excuse me. So how do we support the maintainers? Sorry.

One so, hopefully, you have more than one maintainer that is tasked with ensuring the source code, including patches and releases. They are consistent and viable for use in the broader project. We are particularly interested in supporting this group separately from the maintainers in a certain sense because they're kind of the backbone for getting stuff done. They're doing hard work that is often ignored, that can sometimes be, taken for granted. And how how would we support this group?

Why should you care? Because because they're responsible for getting this stuff done, and they're overlooked. And to me, a maintainer has a a statistically higher chance of burnout than an individual might. Not all maintainers, not all individuals, but there's definitely a higher chance for burnout. And so there needs to be a certain level of sensitivity.

By the way, there's this, there's this conference that used to exist, and, hopefully, it comes back after COVID called, maintainerati. And it's specifically about the pain points and working through things that happen within a maintainer community that you might not experience if you've never actually been a maintainer. Highly recommend checking it out for resources. And, really, it comes down to communication. The I already touched about touched on burnout prevention, but those weekly meetings, those communications, they're so vital to support a maintainer both ways.

The maintainer needs to be able to ask for the help that they need, but we also need to reach out and be like, hey. Is there anything what can I do for you? Rather than saying, is there anything you need? This opens up the question by saying, what can I do for you? It it tells them you are actively ready to help.

And that may be implementing a mentorship program so that they can mentor someone so that other people can be responsible for that maintainer's maintainer's group and that pressure.

Speaker 1: And with that, now I will turn it over to Mary for projects. Absolutely. As you can tell, there's a lot of overlap between these four pillars, which is part of the reason why we have a hard time keeping it straight. Because it's like, well, but that goes with this one and it goes here too. And I think there's a lot of that overlap because when we look at, you know, what projects are we supporting, it can be open source, it can be enterprise, it can be product teams, the teams that are actually building those projects.

And so there's a lot of overlap between the groups, and there's also a lot of overlap as far as the responsibilities that we have to support those groups. So this is kind of our broad overview of products or projects that you're supporting as a part of your role. But, again, why do we support them? How do we support them? And why should you care?

There's a quote on this next slide that says the impact we have expands beyond the end users of our products. And the important thing to remember with this particular pillar is this idea that when we're engaging with the community, the community isn't just the end users of our products. It's also our coworkers. It's also, the maintainers. It's also the enterprise people who might not be developers, but who are using the end product or or paying customers, right, or the people who are making the decisions about whether or not to pay for our products.

And so the scope that we have, the impact that we have goes beyond just the scope of here's our technical audience that is working on these particular pieces and moving forward in these particular ways. And so keeping in mind that this impact that we have expands beyond those those end users specifically is an important piece here. So how do we specifically support these project? Again, being quick and and early with communication, communicating the feedback internally, helping to fix quick bugs if we have the technical skills to do so, and then this being the hub of the wheel. And this idea is that, as a wheel spins, it's got that centerpiece that's necessary.

Right? And it connects the community. It connects other pieces of the departments within your company. It connects individuals within the community. And so as developer relations professionals, being that hub of the wheel really allows us to not only keep a pulse on what's happening, but also be supporting everyone, our company, our coworkers, our contributors, our maintainers, everyone across the board.

So this one pillar really overlaps with all of the others in a unique way. And that brings me to our last pillar today, which is this super broad understanding of community, and this goes along with a lot of what I was just saying. There's so much that goes into this broad definition. And the definition that I have here is from my book. It's a group of people who not only share common principles, but also develop and share practices that help individuals in the group thrive.

And this is the main reason why when you're talking about community and who your community is, it's far more than just our end users. It's far more than just the people coding or the technical audience or people like that because this group of people who share these common principles, they might be solving similar problems or solving, looking for solutions that they haven't yet found the the solution for. It could be that they are developing and sharing best practices. Right? And I I don't think you can have one without the other.

I think they need to both be dealing with the same problems or sharing the same same common principles, but also sharing those practices. And that's really what makes that community sticky, as we say. It keeps people coming back. We've got a quote here from Helen Keller. Alone, we can do so little.

Together, we can do so much. And this is really what keeps us going. Right? It's it's the idea of by ourselves without sharing this information together. It's difficult to really do something more beyond our company, beyond our department.

But if we can join together and form a community of people who are caring about these same issues and trying to solve these same problems, then we're able to build a place where together we can do far more than we can do on our own. So how do we support these overarching communities? There's a couple of things here. The first that we have listed on the screen is a code of conduct, and this really plays into the overall onboarding process of, you know, how do people get started? How should they join your community?

What are the expectations that you have for them as they join your community? What should they keep in mind? Are there certain days of the week where you accept certain submissions and other days where you don't? Do you take a couple weeks to process applications or to do all of the admin type of stuff around your forum or things like that? Documentation can include getting started guides, use cases, screen captures, tutorials, all different types of things.

If you're interested in kind of a deep dive into more documentation, there's a fantastic talk, at Picon a few years ago by Daniela Preseda. If you look up for four types of documentation or I think it's, the the things no one tells you no one tells you about documentation, he walks through the four different types of docs, tutorials, how to guides, discussions, and reference. Mentorship, which Rain mentioned earlier, and they were talking through you know, that's for individuals as well as contributors as well as maintainers. This is really all encompassing of everybody, including your coworkers. Right?

Mentoring people to know how do I respond to people on the forum? How do I know what to say or what not to say? And then also diving into metrics. And this is, of course, a huge, huge topic for developer relations professionals and teams as a whole. And this is really how do we create a sustainable program the business believes in and understands.

Because at the end of the day, if we can't figure out a way to prove that we are providing value for the community as well as the company, then it's not a sustainable program. It's probably not going to continue in the long run unless we can prove that value somewhere down the road. And so that metrics piece is really integral to supporting our community as a whole because if we don't have that proof, if we haven't made the program sustainable and made made it so that our stakeholders at the company understand why we are there and why we're doing what we're doing, then there's a good chance that it unfortunately won't continue, and we won't be there for the community and for our coworkers and the contributors and the maintainers across the board.

Speaker 2: Yeah.

Speaker 1: So we have kind of a a summary here. Rain, do you wanna walk us through just those high level bullet points?

Speaker 2: Yes. Of everything. So when we say support, we we mean sustain, encourage, uphold. If you're gonna screenshot any any kind of screen from this, this is the screenshot to, to grab. This is about, make sure you have a mentorship program for your individuals.

It is not only healthy for your individuals, but also the maintainers, the project itself, and the community. For the maintainers, please, please, please set up a burnout prevention. It may be informal, but I highly recommend that at least two people, not just one, but two people, are reaching out to maintainers, to specifically see what how you can help them, how you can help them be scalable and have balance within their work life. Within the projects, having the hub within a company to bring feedback that comes in through the projects to go to recruitment, to the product, to, actual engineering, being that central person, but not being the only one who is that central person, but a group of at least two, having a hub within a wheel for a project will, will help that project grow. And then within the community, always make sure you're using metrics, especially especially Mary's, DevRel qualified leads.

There are now two, community focused, CRMs that I know of off the top of my head, but, please be using metrics. Please document things. Please don't we we know that you are valuable, but we're also DevRel professionals. We want you to be able to prove on black and white documentation that you're valuable to your company and to your community. So on the next slide is our resources, and we even have the specific website about documentation, divvio.com/blog/documentation.

These up at the top, these are all these four at the top, they're all websites that will help you particularly with open source communities, but this is definitely something that can be expand to proprietary companies to nontechnical companies. It's it's really good guides for different type of communities. And then the bottom four, the reason I'm actually reading this slide instead of Mary is because she's she's written that last book, the business value of developer relations. But we highly recommend the art of community. There are two books with the same title, which is why we kept the author in those.

There's one by Jono Bacon, and there's one by Charles Fogel. And then forge your future with open source, that is by, I just v embrasure. I just completely blanked on her actual name, but v embrasure on Twitter. Wow. And then the business value of developer relations.

I have these books in my background, which are which includes actually three of those. But the reason the business value of developer relations isn't in my background is because it's on my desk because I use it all the time. Highly recommend it. Do you wanna add anything to this, Mary?

Speaker 1: No. I think we're good. But as far as you know, there are a number of resources beyond this. We kind of just started with these. Also, a lot of these are you know, here's here's a lot of information on one place for you to find it.

Opensource.com is a great example of that. There are so many fantastic articles and resources there. And I think the only other thing I would add is if you're if you have specific questions, we have a couple minutes for questions, of course. But, also, feel free to reach out on Twitter. Feel free to find us online.

I don't think either one of us is difficult to find. But, yeah, we are always happy to help. We are always happy to be a resource to you or to your team in any way that we can. So

Speaker 2: Definitely. Yes. Thank you.

Speaker 1: Thank you so much for joining us today.

Speaker 2: Hey. Thank you, you can go ahead, Matthew. Thank you. I was gonna say that you could give us questions to, I think, the YouTube channel, Twitch, and Slack.

Speaker 3: Yeah. Absolutely. And there's a little bit of delay between what we're doing right now and it getting to YouTube and Twitch. So I'll I'll I'll jump in with a question first. In developer relations and community, generally, we seem to be oh, that you have it.

Available on Amazon and elsewhere. We do seem to be the the people within a company whose primary focus is is people. And I'm trying to think, is is that unique? And and is that why a lot of these questions around how we take care of what we do actually feel quite novel.

Speaker 1: Yeah. So I think one of the ways that I look at it is, you know, everyone at the company, almost everyone at the company, interacts with your end users in some way. Right? Like, the only people who really don't is your HR department, but we are the one department that really the community is our sole focus. People are our sole focus.

We aren't split between the end users and money with the sales team or end users, and how do we get more leads, or how do we produce better content? Like, end users are our goal, and we are producing trying to produce better content for them, trying to help serve them in different ways. But the end goal with developer relations is people 100% of the time. So I think trying to wrap our head around, well, how do you put metrics around people and relationships is part of the reason why it's so novel because you can't really categorize things into, like, well, but I bought you coffee, and we had lunch at this conference. And we've built our relationship over the last five years through, you know, $200 worth of travel and whatever it is.

So it's difficult because how do you how do you put a metric on a relationship you're building?

Speaker 2: Yeah. Exactly. And I feel like there are there are other roles within a company like the customer experience person or the UX person who is not necessarily within DevRel, but they're totally in DevRel. You know what I mean? Like like, it's one of those things where you don't officially your title of product manager may not actually be within the DevRel group, but you are thinking about the end user and getting feedback from the end user, and that's DevRel.

It's it's kind of like it's kind of I forget where I saw it, but, like, I saw a talk that was like, everyone is actually in DevRel. They just don't know it. So they but it's to different degrees. And and I think the like Mary said, the focus she's up here, by the way, and you're over here. The focus on on developers, the focus on relationship is what makes us new and unique, and the fact that the actual titles exist is new and unique.

Speaker 3: So I have a follow-up question then Mhmm. Which is basically indulge me because it's something I've been thinking about a lot for a while. So it's perhaps just a selfish question. Drawing on what you just said, the idea that, hey. We're all in DevRel, really.

I I've kinda come to think that maybe the ultimate goal of developer relations is to destroy itself because we should set a template for a company that means that a dedicated DevRel team is no longer necessary. Am I just being a bit fanciful?

Speaker 2: No. No. Okay. So, like, maybe maybe destroy itself is a little bit, you know

Speaker 3: Yeah.

Speaker 2: Aggressive. But in the perfect world, people would balance their money, goals with the people goals. That doesn't exist. Like, the perfect world doesn't exist. And I think I think if, yes, if the perfect world existed and everyone was keeping that in mind, but but the reality is that DevRel is the one that fills that that loop of people looking other directions where we look all those directions too, but we're also definitely looking at our relationships.

Speaker 1: Yeah. Plus plus 100 to all of that. I think the only thing that I would add is that maybe instead of destroying DevRel, make it possible to scale DevRel beyond your individual team. And I think that's one of the things that's incredibly important for people to keep track of or keep in mind as they're struggling with getting more headcount. Right?

Like, maybe we don't need additional headcount. Maybe we just need to work with our internal developers to coach them on writing content or work with them to speak at conferences or work with them to, you know, work with our product managers on how do you solicit better, more descriptive feedback. And so I think we can scale ourselves beyond, you know, our small teams or typically small teams. But I think, Rain, like you said, having having that pure focus of only focused on the community is the thing that sets us apart, and I I don't know if it's possible to have that dual focus of people plus money or relationships plus have to get this product out the door today. Yeah.

I don't know.

Speaker 3: Yeah. I mean, I tend to rely on hyperbole when I speak, so I don't mean we should destroy DevRel. But what I do think is that developer we should see developer relations teams as enablers and examples for the rest of the company. So we can set a tone. We can set a a framework for for for putting developers, but also community generally as a first class citizen, for want of a better phrase, within the company's strategy.

Speaker 1: Yes. 100%. Absolutely.

Speaker 3: Gonna check Slack quickly. We don't have any questions from Slack right now, unfortunately. I guess it is still fairly early on the left part of America. So yeah. So is there anything else you'd like to add?

I know you told us where to find you, but if you want to, you know, summarize where people can find you on the Internet or anything like that.

Speaker 1: Sure. You can find me on Twitter, Mary underscore Grace, or my website is marygrace.community.

Speaker 2: Aw. You oh, that's awesome. So on Twitter, I'm at rainleander, l e a n d e r, rain just like the weather. And my website is, wait. Let me I almost said it in Dutch, because I'm so used to saying it in Dutch.

It's rain.nl, but just look me up on Twitter.

Speaker 3: It's For all of

Speaker 2: better that way.

Speaker 3: Thank you so much for for for being a part of the event today and for sharing your talk. It's been been really great to have you with us even if it is at a distance. But at least we say some jet fuel, so that's that's good.

Speaker 1: Absolutely. Thanks for including us. We appreciate it.

Speaker 2: Absolutely. Thank you, Matthew. Thank you, Amy. Thank you, everybody.