DevRel Roundtable Castos https:// Listen to in-depth discussions of the DevRel topics that make a difference. Featuring DevRel leaders, practitioners, investors, consultants, and other experts from across the tech industry. In each episode, we dive deep into a subject that impacts how we plan and practice developer relations. From the team at DeveloperRelations.com. Thu, 11 Jul 2024 12:26:44 +0000 en-GB © 2022-2024 Hoopy Limited https://episodes.castos.com/61b7cc74b6a291-59102378/8137062f-aaa8-4218-b96e-294d30093488-roundtable-Show-Cover-CR.png DevRel Roundtable https:// Listen to in-depth discussions of the DevRel topics that make a difference. Featuring DevRel leaders, practitioners, investors, consultants, and other experts from across the tech industry. In each episode, we dive deep into a subject that impacts how we plan and practice developer relations. From the team at DeveloperRelations.com. DeveloperRelations.com episodic Listen to in-depth discussions of the DevRel topics that make a difference. Featuring DevRel leaders, practitioners, investors, consultants, and other experts from across the tech industry. In each episode, we dive deep into a subject that impacts how we plan and practice developer relations. From the team at DeveloperRelations.com. DeveloperRelations.com matthew@hoopy.io false https://feeds.castos.com/1431v yes <![CDATA[Developer newsletters and DevRel]]> Thu, 11 Jul 2024 12:26:44 +0000 DeveloperRelations.com https://permalink.castos.com/podcast/37381/episode/1783777 https://devrel-roundtable.castos.com/episodes/developer-newsletters-and-devrel full 11 2 false 00:54:04 <![CDATA[Mental health and developer relations]]> Wed, 14 Jun 2023 16:15:57 +0000 DeveloperRelations.com https://permalink.castos.com/podcast/37381/episode/1496664 https://devrel-roundtable.castos.com/episodes/mental-health-and-developer-relations Open Sourcing Mental Illness founder Ed Finkler, Rain Leander who has written openly about her own experience, David G Simmons who also has shared how ADD and depression have affected him, and Wesley Faulkner who has spoken previously on neurodiversity.  DevRel and community management are both jobs where we are exposed to the ups and downs of other people's lives. For some, there's a potentially exhausting amount of travel. And let's not forget that DevRel does seem to be a discipline where expectations between management and practitioners are often mismatched. All of this can lead to stress and, of course, burnout.  Huge thanks go to Common Room for sponsoring this episode!

Video episode

Watch the episode on YouTube. https://youtu.be/j6Kq7QP6HoI

Show notes

Hosts

Matthew Revell: Matthew runs developer relations consultancy Hoopy, as well as DeveloperRelations.com, and the DevRelCon event series. He works with companies to help them build and execute developer relations strategies. Matthew also creates content and research to help DevRel professionals become more effective. With his team at Hoopy, he works with clients around the world to advise them on developer relations, developer marketing, and developer community. Rebecca Marshburn: Rebecca is Head of Community at Common Room, connecting people doing things, and sharing stories about other people connecting people doing things across community platforms. She is also co-host of the Serverless Chats podcast.

Guests

Ed Finkler: Ed is the Executive Director and Founder of Open Sourcing Mental Illness (OMSI), as well as Senior Software Engineer at Ziff Davies Shopping, and mentor at ONOW. Rain Leander: Rain is a longstanding DevRel professional who has previously worked as at companies including Cockroach Labs and Red Hat.  David G. Simmons: David is Head of Developer Relations at Otterize and has a wealth of experience in Developer Relations, having worked in  senior roles at companies such as StarTree, Camunda, and QuestDB. Wesley Faulkner: Wesley's experience spans multiple facets of the technology industry. With over 20 years in product marketing, product management, strategic planning, and software/hardware implementation, he is currently Senior Community Manager for NAMER at AWS, and co-host of bot the Just Work and Community Pulse podcasts.

Links mentioned in the show

]]> full 2 2 false Open Sourcing Mental Illness founder Ed Finkler, Rain Leander who has written openly about her own experience, David G Simmons who also has shared how ADD and depression have affected him, and Wesley Faulkner who has spoken previously on neurodiversity.  DevRel and community management are both jobs where we are exposed to the ups and downs of other people's lives. For some, there's a potentially exhausting amount of travel. And let's not forget that DevRel does seem to be a discipline where expectations between management and practitioners are often mismatched. All of this can lead to stress and, of course, burnout.  Huge thanks go to Common Room for sponsoring this episode!

Video episode

Watch the episode on YouTube. https://youtu.be/j6Kq7QP6HoI

Show notes

Hosts

Matthew Revell: Matthew runs developer relations consultancy Hoopy, as well as DeveloperRelations.com, and the DevRelCon event series. He works with companies to help them build and execute developer relations strategies. Matthew also creates content and research to help DevRel professionals become more effective. With his team at Hoopy, he works with clients around the world to advise them on developer relations, developer marketing, and developer community. Rebecca Marshburn: Rebecca is Head of Community at Common Room, connecting people doing things, and sharing stories about other people connecting people doing things across community platforms. She is also co-host of the Serverless Chats podcast.

Guests

Ed Finkler: Ed is the Executive Director and Founder of Open Sourcing Mental Illness (OMSI), as well as Senior Software Engineer at Ziff Davies Shopping, and mentor at ONOW. Rain Leander: Rain is a longstanding DevRel professional who has previously worked as at companies including Cockroach Labs and Red Hat.  David G. Simmons: David is Head of Developer Relations at Otterize and has a wealth of experience in Developer Relations, having worked in  senior roles at companies such as StarTree, Camunda, and QuestDB. Wesley Faulkner: Wesley's experience spans multiple facets of the technology industry. With over 20 years in product marketing, product management, strategic planning, and software/hardware implementation, he is currently Senior Community Manager for NAMER at AWS, and co-host of bot the Just Work and Community Pulse podcasts.

Links mentioned in the show

Transcript

Matthew: Well, hello and welcome to another DevRel Roundtable. My name is Matthew Revell, and I'm joined by my co-host Rebecca Marshburn. Hi, Rebecca. Rebecca: Hey, it's so good to see you, Matthew. As you said, I'm Rebecca Marshburn, and I'm the Head of Community at Common Room, and it's so nice to be here cause I've been away, I think, for the last two episodes, and now I'm back! And I'm really excited for this topic because, as you said in the green room, if you will, it's a weightier topic. It's a meatier topic, but it's also a really important and necessary topic. So thanks for having me back for this one. Matthew: Yeah, of course. It's great to have you back. So what is that weightier, meatier topic? Well, this is Mental Health Awareness Month, May 2023 at the time of recording. DevRel, community management are both roles, disciplines, where we are exposed to the ups and downs of other people's lives. But also there's travel, which can be exhausting. There are, in some companies mismatched expectations as well, where that introduces stress. And quite often DevRel people talk about burnout. At DevRelCon we've had a number of talks on burnout, and I think we probably will again at DevRelCon London in September.  But to actually address DevRel as a profession, community management as a profession, and how that impacts on our own mental health, how we can recognise the signs that something might not be right, is perhaps a topic we haven't covered in great detail previously. So why is developer relations, community management, particularly a discipline, a job where people do seem to suffer from burnouts? What are those things that you should be looking out for? And what can our teammates, our employers, our communities do to help?  Today we have some people who are really working hard on those questions, and to make people in tech generally more able to deal with mental health issues.  So, about 20 years ago as a student, I went through a period of depression and various things had got on top of me, and I went and sought help. And over a period of time, I was able to develop ways of coping with that. But even having been through that, I'm also someone who doesn't always recognise the signs that maybe not all is well, and perhaps I need to to work on that. So I'm looking forward to hearing some of the advice and things that people have to share today. Rebecca: Matthew, thank you for sharing that. I know all of us are probably searching for words a little bit more. And that's because I think even though we all believe that this is an extremely important topic to talk about, it's also a vulnerable and more personal topic to talk about. And I think when we're in those spaces, we want to hold space for each other, but we also need to hold space for ourselves, and it might be a little harder to find the words, and it might be a little harder to say the words correctly, right? I wouldn't say that there is a correct way to say it, but I think we have that voice in our heads that's like, ‘'oh, I'm usually, you know, smoother, or I can usually articulate my point more specifically’.  I think what's so important about this discussion and what we've all talked about is that we really want to hold space for each other to be the 'perfect imperfect' version of themselves. So thank you for sharing that, and thank you for taking the time to find the words that you needed.  That being said, someone who is also very well known for holding the space for others to talk about these types of topics, and bringing these types of topics to other people in the room, outside of the room, through technology, in the technology space, is Ed Finkler at OSMI. So, OSMI stands for Open Sourcing Mental Health. That's actually not the 'I', so I'm going to let Ed tell us what that means. But it is a non-profit dedicated to raising awareness, educating, and providing resources to support mental wellness in the tech and open source communities. OSMI began when Ed began the brave, often difficult process of speaking about his personal experiences as a web developer and open source advocate with mental health issues and concerns in public at tech conferences in 2013. He's super knowledgeable on the topic, both with personal experiences, and through research and developing a community and a non-profit around this space.  So really excited to have Ed here to help us understand a little bit more deeply the complexities of this, and how broad this conversation reaches, and how much broader it still needs to reach. So, welcome Ed. Thank you so much for being here. Ed: Well, thank you for having me. That was a very kind introduction. I am really glad to be here, and to just talk about what my experiences have been, and kind of what I've seen, particularly amongst developer relations and the hard road. A lot of you folks really walk on that. So yeah, I'm excited to be here. Matthew: The first question is, can we get the OSMI correct? What does the ‘I’ stand for? Ed: Oh, sorry. The name is Open Sourcing Mental Illness. We dabbled a little with some branding changes that I think we're kind of calling back on. So, as we restarted, some people were talking about Open Sourcing Mental Health, and we kind of looked at that, but we decided to go back and use that term 'illness' on purpose. So that was kind of a conscious decision I think we made in the last six months as we relaunch. Also as a lot of in-person conferences and events have really started spinning back up, and things are a lot more active now. So yeah, Open Sourcing Mental Illness is the name. Rebecca: Thank you for that correction. So as I briefly touched on, since 2013, you've expanded this research, and this discussion, and this dialogue, and through that there's also some more health stats and mental illness stats that you have. Maybe you could kind of set the context for us. While a lot of it is location or geography based, at least give us some sort of framework or foundation to work from in terms of how this affects people in the population. Looking at our colleague, or our teammate, or our neighbour, and perhaps knowing and understanding that people experiencing this are not alone. I think that numbers are quite helpful in understanding that context. Ed: I’d like to talk about my personal stuff a little bit first. I'll tell you a little bit about that. I now think I have a better understanding. I have ADHD of some variant. It's not very well described by the DSM or things like that, so that makes it difficult. Sorry, the DSM is sort of the book that the whole medical industry uses to say, 'this is what a disease is', and it's sort of like the official 'that's a disease'. And if it's not in the DSM, it gets really hard to pay for because they can't code it on insurance. Well, I have ADHD, which is not well described in the DSM, I can tell you that, and that does impact things because of that.  But also then along with that, I have generalised anxiety disorder. Now I've been diagnosed with those things. What do those things mean? It's different from diseases that we know about, viral and stuff like that. But it really just means this is the way my brain works, and it works kind of differently than other people's. As a consequence, that means that I have difficulty in some areas, doing normal life things, right? And the big thing for me I think my whole life has been emotional regulation, and feeling like I was just different from other people. It seemed like things affected me differently, and more intensely than other people. And I've really felt like that since I was a kid. That I think informs a lot of stuff and feeds into why you end up feeling that way as an adult, or feeling isolated, or alone, or apart as an adult. But what I found when I started doing research into it is that not only is it mental health, or mental health issues, or behavioural health issues. Really almost all of these things are based on how people behave. They can include substance disorders, things like that. Things that change your behaviour in some way, or make you unable to do things.  About every ten years, the World Health Organisation does a global survey on disease, and consistently the last two have found that the burden that these conditions put on populations worldwide is in fact extremely high. I think in the 2010 survey, I believe they said that that category of disease was the highest contributor to days lost to disease. I think it was measuring how it affects your life, and how it affects work and things like that. Okay.  So I think about that, but I think about that then in the context of speaking about it versus other significant medical conditions, health conditions, and how we deal with those in society, and how that impacts how we individually do things.  In that World Health Organisation survey 2010, it talked about the impact of behavioural health issues, and they found that the impact and burden of disability that a major depressive disorder puts on a person is very comparable to that of multiple sclerosis. And I'd be interested in hearing if anybody with multiple sclerosis was ever told: 'have you tried drinking more water?' Right? I don't think that we treat these things the same way, even though they are serious health conditions that have significant impacts on our ability to work and function in society. We're generally afraid to talk about it. And the numbers that we see in our annual surveys are that, generally, I think I could safely say, well over half, I think over three quarters of people still feel like it's likely or certain that something bad will happen to them if they reveal a mental health condition to say a supervisor, or somebody at work. Now compare that to physical stuff, like breaking your leg. Our numbers tell us people are not afraid to talk about things like that. And they are afraid to talk about things like this. So clearly there's a problem here. Here's how much it impacts us. Here's how we actually treat it. Most problems don't get solved by kind of ignoring them, or kind of sticking 'em in a bag and hoping they go away. So what do you do sort of organisationally and stuff like that? Basically, a lot of what we're trying to advocate for is that there's an extremely good economic argument, and also just a moral argument, for simply putting some basic time in for organisations to actively engage in mental wellness in their workplace. I believe that workplaces don't understand how significant an impact it has, how it improves retention, how it improves productivity, and saves them money down the road. I found that most people nowadays seem like they want to help and they'll say: 'Hey, I wanna figure out what to do'. And so that's changing a little bit. It used to be 23 years ago they said: 'Yeah, well we pay you, and we really don't care about the rest of it. That's your job'. So, that kind of ignores the reality that in the US, for almost every person, the workplace is the proxy to healthcare. And so not having a job means no healthcare. So yeah, and I think that's maybe a big thing. I think I just want to put in a context here. I'll give you one more thing. One of the things that I think, especially folks who are doing any kind of management, or if they're C level, or they're doing any kind of supervisory work, I do not think we have any kind of appreciation for how much control people in that position have over the happiness or emotional suffering that their employees experience. That's why I have to pay attention. That's why I have to learn these things. That's why I have to take courses, learn about this stuff. We can talk more about things like that, like mental health first aid, and stuff. But realistically, we're talking about numbers. I can tell you right now, pre-pandemic in the US it was estimated that about one in five, 20% of people, were dealing with a diagnosable behavioural health disorder at any given time. It was already one in five of the people you work with. If it's just the general population, some of the numbers in OSMI research suggest that rates of at least some of these things are significantly higher in the developer type, POT technology worker population. And so, even if you just talk about one in five, realistically, does anyone think of their workplace? People reply: 'Yes, I was aware of the 20% of people at a given time who are dealing with that'. You know, no, they absolutely weren't. They weren't because they were afraid to talk about it. And so, that being afraid to talk about it, that not being able to talk about it, that is what makes it so scary because we all feel like it's not safe to talk about. We really don't even know what to do. Even if we want to do the right things, we don't have the info, or we don't know where to do it.  Organisations have a responsibility. It makes huge economic sense that they actively engage in promoting the wellbeing of the people who work in the organisation. Rebecca: Ed, thank you so much. I think just that last bit that you left us with is such a grounding thought. The general population will just take that number, right? 20%. And you're like, okay, when you look around, let's say you're at a tiny startup, that's still two people out of those 10 and did you know? Or were you one of them? And then how do you either have conversations, lead conversations, open conversations, in a space where safety is paramount? So thank you for that grounding moment about what it means for the people around us or ourselves, statistically percentage wise. I do think that at the end of the show, and we'll also put it in the YouTube notes and stuff, we will link to things like mental health first aid, right? And then, Victoria Tran has a great post called Mental Health and Community Management. And it goes through some of the warning signs for us to like conscientiously evaluate. Are these warning signs happening in ourselves? Do we see them in others? Or how do we open conversations with others about these signs? So we'll definitely get to those and certainly link them in the notes as I think it's really important. But we're going to bring on some of our other panellists as well, to hear some of their stories. And someone that I'm really excited to introduce because I think they have been extremely influential in talking about safety and creating safe spaces, is Rain Leander. Rain Leander is an advocate, and has been a developer advocate and evangelist for well over a decade.  I really learned a lot about this from Rain because last year at All Things Open, I had the great honour of interviewing her on the qualities that comprise a thriving open source community, and what it takes to create an enduring open source community. And so much of that was not just tech specific, but human specific.  How do communities create safe inclusive spaces for people to think differently from one another? To be themselves with experiences and perspectives that are each unique? To make mistakes and corrections with one another? And to bring that diversity of perspectives and elevate it rather than try to flatten it, if you will. And so these are all points which I think will enrich the conversation today, and we're super happy to have you on, Rain. Rain: Thank you so much. I feel a little bit like an imposter these days because the whole reason I started doing this, which I'm sure maybe we can relate to, is because I was not well and I happened to have this wake up call. I was with Red Hat, and I was at Red Hat Summit, and they had just launched Open Source Stories. And one of the movies that I saw was the Open Patient. And it was about these two brain tumour patients who separately decided to put their records a hundred per cent online, and effectively saved their own lives. One built a community of support that she didn't have. And the other, another doctor saw his record and said: 'Oh, this is what you have, this is what you need'. And the doctors he had hadn't made that connection yet. And after that I started talking and was like: 'Oh, let's normalise this'. I'm everything you said. The DSM sucks. I was fortunate though. I lived in the Netherlands for 10 years and ended up getting that space to heal from a very intense trauma. I grew up neurodivergent, and with depression and generalised anxiety as well. But I had a specific trauma that broke me, and I would probably still be broken if I had stayed in the US.  In the Netherlands, they gave me two years to heal, a hundred per cent paid full. There's no bill from that, I got emergency services and outpatient. I can compare this with the US, where I was thrown into a hospital, only to become worse. Then I moved to the Netherlands, and they were like: 'We don't do inpatient for this. We would rather you be around family and support and come in every day.' And I was just like: ‘oh my God, this is black and white’. And I'm not saying the Netherlands has it right by any stretch of the imagination, but I'm very thankful that I have that space to heal.  And the reason I feel like an imposter is that I've been silent for two years, and I feel like this is due to the pandemic. The pandemic happened, and we all shifted. The pressure was so different and so intense, and I completely got out of the habit of talking about what was going on, and I stopped. Honestly, this is probably the first time in three years that I've publicly talked about being neurodivergent and recovering, and I take fluoxetine. It's Prozac. And I have a psychiatrist, I have a psychologist, I have a team, I have coping mechanisms.  Even over the past five weeks, I started to destabilise, because normally if you're looking for a new job, not to brag, but it takes days to find offers. And after two weeks, I was still not only not getting interviews, but definitely not getting offers. And so I wrote a whole book about looking for work in tech, and taking care of yourself while looking for work in tech. And that's what I needed to do, to be like: 'Okay, remember how to care for yourself'. Because even when you do have all that education, all that knowledge, and years of stability, it can be thrown off by something like a pandemic, or looking for work for longer. And sometimes you have to take a minute to really internalise, to reset and to care for yourself. So yeah, I'm a bit of an imposter, but I'm coming back to myself, and thank you for having me on. I'm just so thankful that you have created this space for this. It's a serious thing within DevRel. It's particularly intense. And I think because of the things that you mentioned, Matthew, about expectations, stress, travel, everything. Every time I go on a trip, or my partner goes on a trip, I'm like: 'Okay, this is how I'm taking care of myself'. And yeah, it's huge. I actually sent something off to DevRelCon London about how we take care of ourselves in DevRel, because our mental health is everything. Matthew: Thank you Rain. I'm going to bring in David G. Simmons. David, it was your suggestion that we cover this topic a few months back. Thank you for that. David, you're Head of Developer Advocacy at StarTree and you've had a long career in the world of IoT. But I think what's most relevant to this roundtable is that you've been very open recently about your own mental health, and your diagnosis with ADD. So, what does this topic mean to you? David: Well, first of all, thanks for having me on this. And for having Rain on as well. I'm thrilled to be in the same virtual room with all of you, actually. So it's interesting because my sort of struggle with mental health issues goes way back in time. I'm old enough that they didn't diagnose you with ADD when you were in school. They just said that you couldn't pay attention and you were a problem. Right? And all of my recurrent cards, like from elementary school on all said the same thing. And so, when around two years ago, I got finally diagnosed with ADD, everybody that's known me all that time said: 'Well, duh, you know, we all knew that'. And then I guess it was a year or so ago, I really ended up in yet another mental health crisis. And I'm lucky enough to have a good friend of mine who I've known for a very long time, who is also a psychologist who called me and said: 'Okay, what's going on? We need to get this straightened out. There's something going on with you, it's not right, and we need to figure out what's going on'. On my Twitter page, my pinned tweet is a thread about all of that and what I discovered in that process. It's easy for me to talk about technical things. It's harder for me to talk about personal things. And so I kind of went on both a personal and a technical thread there about what my mental health issues were, and how I discovered some solutions, and those sorts of things. I think it was shortly after that Rain and I got together and were talking about this. And we started this DevRel Diaries project, which is languishing and is not really doing much, but it's basically a place where anybody can go and anonymously contribute a mental health in DevRel story of their own.  So, I mean, there's a lot to this, especially in DevRel. And I don't know whether a lot of people gravitate towards DevRel because they have ADD, and it's like easy to have a career where you have to do lots of different things, or what leads to that. But I know that there seems to be a lot of that, or at least there's a lot more people in DevRel that are willing to talk about it, right? And willing to say: 'I've got ADD and I'm doing this about it'. One of the things that I think probably needs to be talked about more, and I see some of this discussion now, is substance abuse in DevRel, right? Conferences are organised around alcohol in a lot of ways. All the parties are, you know, at a bar, or drinks are served. I know, speaking for myself, I've been clean and sober for 37 years, and for people who are newly trying to get sober, those kinds of environments can be really hard, right? And if your life is going to conferences where all the activities are drinking, then it's really easy to sort of start going down that hole because it's encouraged, and it's kind of the basis of all the entertainment, right?  I have gotten sideways with a couple of conference organisers where I have said: 'Look, all you're providing is alcohol. You really need to think about people who don't drink, and provide something for them in a way that isn't like: 'Oh, you people go over there and drink water, kinda thing',' right?  To me, it's all really interconnected. I have ADD, I have depression, I have anxiety, I have PTSD, but I still do this. I still show up every day.  I think one of the things that contributes to some of the mental health issues in DevRel is also a lot of the uncertainty that we have in this field. Turnover is very high. Burnout is very high, right? There are a lot of mismatched expectations. And that goes on all the time. 'Mismatched expectations and we're letting you go', right? And now we get to start over again, right? I'm in the middle of that myself right now, and it's sort of a vicious cycle that repeats itself in DevRel.  You know, for the folks that I manage, I was very clear with them that I worry about mental health, I worry about burnout. In most of the places I've worked, we had unlimited PTO. And so I was telling people, I want you taking a minimum of 30 days of PTO a year, right? Which in the US is unheard of. You get two weeks of vacation. That's it. I'm like: ‘No, you need to take 30. That's a full six weeks, and I want you to take at least two of them consecutively on a regular basis because burnout is so high. We do so much that we are under such stress’. So, I'm really glad about this discussion because I think it needs to happen more. And part of the reason that I'm able to talk about this is other people that I have seen, mostly on Twitter and other places, willing to talk about their struggles with mental health, right? And me saying: 'Oh, well they're willing to do it. Maybe I can say a little bit, and then say a little bit more, and say a little bit more'.  I think it's important to have talks like this, and to have spaces like this where we can make it okay for people to talk about their mental health struggles, right? A year ago I thought I was fine, and it turns out I was anything but fine. I was really at the end of my tether. One of the things about mental health is like, you know, when you break your leg, you broke your leg. But when you're suffering from a mental health crisis, often you are the last person to know. Rebecca: Yeah. I think you have, David, such an exemplary and humbling way of talking about it. I don't know if you recall - because I think you've been able to practise talking about it and sharing it with others, maybe longer than I've been used to hearing about it, which I think hopefully that gap gets smaller where we're more used to both talking, and receiving and then dialoguing about it.  But actually it was at DevRelCon Prague last year where Victoria, head of the DevRelX community, and you and I were like: 'Oh, we all have six hours in Prague before we have to go separate ways'. And so we decided to take a long walk through the city together. And you shared some of your experiences with us, and both Victoria and I cried. I don't know if you know that I cried, I think privately. Victoria I think cried. It was very moving, and brave, and vulnerable of you to share that, and to share where you were. But I do remember saying to you: 'It's okay to cry'. And you said to me: ‘I know that’, in a kind way, you know? And I realised that I was trying to say that to you to reassure you. And really, it's like me as a receiver has to practise how to receive it and then to dialogue about it. I think that, anyway, I'm just very humbled by the way you share, and I think it's really amazing. So thank you. David: I remember being able to stand in a very crowded street in Prague, telling you both something, and crying at the same time. And I'd only just met you guys, but I think that's part of talking about mental health. If I'd broken my arm, I would've told you about breaking my arm, right? And this is the thing that for some reason we think of mental illnesses and these things as somehow different, and we can't talk about them. Right? And you should just be okay. I love what Ed asked, you know, if somebody with multiple sclerosis was ever told just to drink more water! The amount of horrible advice I've gotten on mental health issues that you would never give to somebody with any other illness. Yeah. Rebecca: Thank you for being here. We have one more guest to bring on to share their experience, and that is Wesley Faulkner. Wesley is a Developer Relations leader and current Senior Community Manager for North America at AWS. He's a co-host at the Just Work and Community Pulse podcasts. He's a founding member of Open Austin.  But one of my favourite things is something that is actually selfish of me, he's a gentleman I've been lucky enough to introduce on this show twice. And it was actually the first show that I'd introduced him, where I think it was either during the show or perhaps after, but we had talked about scoping out a show about mental health. And Wesley, you said: 'I would like to be on that episode. That's a really important topic to me that's really both personal, and affects people in your life, yourself, the way you approach work'. And so, really happy to have you back for this episode. Welcome. Wesley: Thank you. It's good to be here. I've enjoyed sitting in the green room, listening to the conversation. I almost felt like I was listening as part of the audience, and I almost forgot that I was going to be on. So it's great to join everyone here, and, you know, having the space to talk about this subject, that I feel personally, really, really invested in.  The saying goes: 'If you can speak it, you can survive it'. And so making sure that people have the permission and the outlet to be able to talk about this is, I think, one of the things that can help us actually get through some of the challenges that we all face. And I know that I've had my share, especially during the pandemic, where if it wasn't for being in the DevRel collective and being able to have the times where we could share when we were struggling through whatever it was that week, I don't know where I would be without feeling like I could be heard or understood. Mental health and mental illness is in some ways seen as a personal failing, as someone who is either not strong enough or doesn't know how to deal, and it doesn't take into account the systematic, external stressors that we all are a part of. It's just like when someone gets sick. Of course they could have worn a mask, they could have taken more vitamins, but you don't necessarily blame the person for catching a cold, because it's out there and it can hit you randomly. We can all go through it, and it should be seen that way, because that's exactly how it's experienced. Matthew: Thanks, Wesley. As this is a DevRel roundtable, I would love to just ask this question. Why do we seem to see burnout and associated mental health struggles quite prevalently within the DevRel profession? Wesley: I have some ideas. I definitely think it's more prevalent. I have a few reasons for that. One is that in order to be successful or to kind of survive in the DevRel space, you have to be able to be intuitive, and you have to be empathetic to the plight of developers and the community. And when you have that, in combination with being self deterministic in terms of the ways that you fulfil that charter, that mandate, you have to be really, really creative and think more about the system that you're operating in.  That being said, the powers that be - the employers, the people who determine your success - they may not be cut from the same cloth to the point where, from their subjective point of view, they are not able to measure that. And so there's a disconnect between delivering, executing, strategising, and the person evaluating that doesn't have the same base. And we are still fairly new as a profession in DevRel. We don't have any solid numbers for every kind of metric that needs to be tracked in order to measure the value of something. That's one. Two, there is a subtlety that that is required for DevRel, where you're establishing these relationships and this path of communication that feels so subtle that it's not detected, and thus it can be seen as not being effective, even though it is needed in order to gently kind of bring people in and bring people closer. I think a lot of business demands, say you met someone on Monday, you need to propose to them on Tuesday, and you need to get married on Wednesday.  It doesn't work that way. That understanding and that intuitive nature is something that we understand, but we're not being graded in the same way or with the same kind of rubric that we're executing, and that we feel is kind of the philosophy of DevRel.  And for me, I mentioned this, if you're part of a marginalised community, if you're a part of a group that can be undervalued, I know myself that it can be seen as though when you're working with management that your job is to ‘pet a cat’. The reason why I think that's an apt analogy is because if you've ever pet a cat and you do it for a long time, there'll be a point where the cat will let you know that it's done being pet, and the way they let you know is not necessarily subtle. That seems the same way with being under-represented in the tech structure. You're thinking you're doing everything right, you're doing great. You're given the love, and then there's a reaction, and that reaction causes some severe harm. And so everything subsequent to that is trying to detect the slightest sense that something's going to go wrong. So there's a huge cognitive load with being able to try to be super hyper-vigilant about the status of this thing that you think you're doing the right. You think you're doing the right thing, and you just want to be able to predict when the tables will be turned and things will go horribly wrong.  That mental kind of penalty or tax really diminishes the work that you need to be doing, this creative work, this sensitive work that's empathetic, pathetic work. And all of that is a giant formula for stress, and a formula for mental illness. I know I'm talking too much, so I will stop right there and just say, yeah, it happens. And I think all of this together from multiple sides causes the problem. David: Wesley, that was an absolutely perfect description of it for me right now. There's also the long tale of that, after the cat turns on you, right? There's the whole tale of trying to figure out what happened, how you can stop it from happening again. You know, was I really terrible? Or I'm right in the middle of that now, right? Yeah. My last review was fantastic, and then a month later it's like, nope, you're out. And there's that whole recovery, which we don't necessarily have time for, right? You've got to go find another job. We got to get back into it. You keep going.  Rain: Yeah, I don't know if it's actually more prevalent, or if we just talk more. I would love to see actual numbers of tech versus non-tech, and also DevRel versus the rest of tech kind of numbers. I don't even know if that exists. But I do appreciate that we talk about it, and I wish that it was normalised across all industries in the entire world, that people were comfortable talking about their broken legs and also their depression on Saturday night. I think that's my only thing.  I agree with Wesley. I think because we care as part of our job, we are passionate about communities. That does expose our heart and our psychology to 'attacking cats', to merge all of the analogies that have been happening across the entire show. I cannot tell you how much I love 'pet the cat' as an analogy. Wesley, thank you for that. Also it breaks my heart. Wesley: I also wanted to say the turnover thing is real. Rebecca, you introduced me as NAMER Senior Community Manager at AWS. Yesterday was my one year anniversary at AWS. And I've been doing DevRel for a while, like five years. This is the first time I've been in a job for a year. Rain: Oh, wow. Wesley: And it's one of those things that is new to me, even though I feel that I have great ideas, great execution, I do things that I think are right. And I think I've been recognised externally from several different outlets, but that means nothing to some people that can choose whether or not you're successful in their organisation. So that also illustrates how hard this industry is. David: Well, Rain and I have been commiserating, you know, for the last few weeks about our collective situations because they're very similar. The cats, they turned on us. Rain: Yeah, I also had a good review, and then two months later the cat attacked. I felt like I had a good space when I lived in the Netherlands and worked for Red Hat because of two things. One, I was in a country that treated all kinds of health very seriously. Two, I was at a company that valued developer relations very much. Three, I was in a department within the company that valued what I did and had a clear, 'this is the expectation. This is what you do for those expectations'. And so I was with Red Hat for many years as a developer advocate. The only reason I left was money. By the way, twins were expensive. And after that I had to make a little bit more money. But it kind of breaks my heart that AWS is a larger company. It can afford to give a little bit more time. That you also have found a place within AWS that values what you do, has that clear expectation, and then rewards you for those set expectations. And I would like to find that, again. It seems like a very low bar, but it isn't, and that's sad. Matthew: We have a, I don't want to overstate it, but kind of a crisis in DevRel management because it's grown so rapidly. We don't have many experienced DevRel leaders. And more importantly, we don't have organisations that know how to have DevRel exist successfully within that organisation. And, you know, maybe that's a contributing factor.  But Ed, in your words earlier you were saying that you feel that mental health issues are more prevalent in tech generally. And, you know, when I've spent a weekend digging soil or something like that, I feel a sense of satisfaction on a level that is nothing compared to anything I can do on my laptop. So is it just that we're trying to put ourselves into a box we don't fit into as humans? Ed: Well, I mean, there's some of that, and you can get into the idea of, and I certainly am pretty conscious of it, that I feel like my mind works one way and the rest of the world got different instructions. And all of their minds work that way, and the world's kind of made for them. And I have to figure out how to adapt to them, and I think that is part of it. At least in my experience. I think that... Could you repeat the question again? I got myself off down a rabbit hole. Sorry. Matthew: So, is it just that as human beings, we shouldn't be sitting at a laptop for eight hours a day, trying to do things remotely, and on computers, when we are built for physical exercise? Ed: Yeah, I mean, I think that is part of it, and I think that I would say I'm speculating entirely, but I suspect that somebody like me who has more problems with those kinds of things, I think I just notice it more and I'm more sensitive to it. But I think these kinds of things are common, and a lot of people, we just aren't aware of it. Rebecca: So what is one tactic that has helped you stay healthy within your community work and DevRel work? What is something a colleague and employer can do to help? So that'll be our closing question. We need a sense of guidance for all of us as we approach this topic with more vulnerability, and hopefully more openness in the future. Rain: As Ed started to say, you have to listen to your body. I realised that there are a lot of physical issues that you can have that are undetectable. There's fibromyalgia, there's physical illnesses and disorders there that doctors can do a quick test for, and ignore and can't find. But one of the things that I became very aware of is that when something is going on with my body, I go to the doctor and do the physical test. Is there a virus? Is there something physical? Or is this my body trying to tell me that something is wrong psychologically? And I realised that that's just being aware of yourself, and watching for that pain that Ed was talking about.  Then advocating for yourself, especially if you are in a country that doesn't want to listen, or you have something going on that's more difficult to detect. I would advocate all day long for my community, but when it comes to advocating for myself, I fail time and again. And I feel like that is one of the skills that we need to remember - we are part of the community as well, and therefore we need to advocate on behalf of ourselves.  As far as companies are concerned - I am not coming from very healthy places, but I think we've said this in several different ways - it is important to manage expectations, and make sure there are clear KPIs and that the goalpost doesn't move. And I realise that's difficult. Especially when a company is starting to maybe go under because of the economy, and you want to blame someone. It's easy to blame DevRel because we are the healthy fat, we are the extra bit within a company. You don't technically need DevRel to be successful, except that you kind of do. So as far as companies are concerned, don't just get a DevRel person because some venture capitalist says VC is a cheap marketing option, or an alternative sales option. Get a person, a developer advocate or a community manager because you have a community that you want managed or that you want. You have an advocate. You have a developer community that you want an advocate for. So Ed chatted in the background to us that having an externally focused option for validation seems like part of the job for DevRel. And that trains you to focus on making others happy. And it's very hard not to do that and to protect yourself. I agree. I think that we are really good at advocating for others. 'I got all these people, I take care of you. I've got it'. And then 'I'll take the bullets, and the cat will scratch me'. And because of the Netherlands, I've started thinking about myself as like, I'm not advocating for Rain Leander, I'm advocating for Rain Leander and I am going to do the best I can for this person. And that helps because there was some sort of block around being my own superhero. I agree. What about you, Wesley? Wesley: I guess a positive thing about this time is that there are discussions like this, but there are also some publications and other ways that people are wrapping up their own experiences. For me in my own journal, that was extremely helpful, not just to feel less alone and relate to other people's experience, but to build up my own vocabulary. And it turns out, if you don't have the right words to describe certain things, it's hard to even explain to yourself what's going on internally.  When you can't explain what's going on internally, that is also a barrier to telling someone externally about what you're going through, and to work through ways to see those other markers and other resources to learn more, to deepen your knowledge, to grow your vocabulary, and to kind of unwind and untangle that jumble in the head, and realise where you can start attributing where these things come from or what triggers.  So, having that vocabulary with the immense amount of resources from the Internet is something that wasn't available to me, I would say even five years ago. So, it's really great that these discussions happen, that people are stepping up and letting us as consumers decode what is happening to us. And I like that this is the trend, and it doesn't seem like it's slowing down. Rebecca: Thank you so much. What about you David? David: So most of what we do in DevRel is in some sense being of service to others, right? We help developers, we help our community. We find ways to be of service to other people. And I don't think we spend enough time finding ways to either let other people help us, or to sort of be of service to ourselves. And employers are, almost by definition, unable or unwilling to sort of be of service to their employees. It's the other way around, right? We're here to serve our employers and they are not here to serve us. And, we need to find ways to change that.  Matthew mentioned that there's not a long history of DevRel management. And one of the problems that I have seen occasionally is that good developer advocates get made into managers without consideration of whether they are good managers in addition to being a good developer advocate. And there's a difference, right?  In a large sense, being a good developer advocate is being of service to others, but it's also sort of trying to make yourself famous, right? And it's hard to do that and be a good manager for the people that report to you, because part of being a good manager is not making yourself famous, but making your people famous. Putting them before you and serving them. Not serving your manager, but serving the people that report to you. And there's precious little of that I think, anywhere. But certainly, many companies are not there to serve their employees. They're there to have their employees serve them. And, being someone whose life's work has always sort of been about being of service to others, it's really hard to see that. It's really hard in some sense to find ways to take care of myself because I'm trying to take care of, as Rain said, my community. ‘I got you, you know, I got you, I got you’. And on Saturday night, there's nobody that's got me, and that's where the mental health picture comes into it. So, I'm really glad that we are able to have these discussions, and I'm also really glad that we tend to talk about this stuff more than in other places. I know for me, having other people talk about it has made it more okay for me to talk about it. And I'm hoping that the more we talk about it, the more we make it okay for more people to talk about it, and not just in DevRel, that we can sort of infect tech in general with this willingness to talk about our defects and our struggles. It makes everybody more empathetic, right? There's that saying that, you never know what struggles somebody else is going through unless they talk about it. So it's important to make it a safe place for people to talk about it and not judge them for it. To say there won't be consequences for this, for talking about this. Then making sure that there aren't actually consequences is the hard part, right? Often we say that, and then people come out with it, and then it turns out there are consequences. So if you're going to say there won't be consequences for this, it's really important to make sure that there aren't. Ed: I'm kind of naturally externally focused and that kind of person anyway. When I was a kid, I used to come and do book reports on Bigfoot, and ask to do them in second grade and talk in front of the class about Bigfoot. So that was weird, right? I just do that naturally. I was talking to PJ Hagerty. He is like: ‘DevRel relations is what you have been doing all the time anyway’. Writing blogs and stuff. I just started doing that stuff cause I wanted to. So I'm really externally focused in that way. I think the big thing for me is that it was to the point where I didn't feel good about myself. Even though I told other people those things, it really wasn't something I did. I really had to work hard and talk about the stuff that I do struggle with. It's not voluntary, and the things I feel are not voluntary. So I didn't do anything to have this. It's my responsibility to take care of it. But for me, that was a fundamental thing.  Then the second thing, taking care of it is really saying to yourself: 'I have to put the resources first into me'. And if I compromise my foundation, which is myself, and the entirety of everything you experience is generated by this part of the brain, so it's all about that. And if that is not working, okay, it affects everything. Right? And so, anyway, the point is all that stuff, it's key.  We work on that foundation and you have to set those boundaries and say: 'No, I'm not gonna hang out after seven. I'm going back to the hotel room and sleeping, or I need to drink more water, or I need to do this'. Really, you have to say: 'Look, I'm the boss of me'. And it doesn't matter what you want, if it compromises my health. I don't care if you think it's a DevRel health problem or not. Health problems are health problems. They're all health problems. There is nothing that is physical or mental somehow about it. It's all interrelated, it's all just health problems. The thing is that we don't really know how to treat it well. So we're trying to learn how to do that.  I guess what we were talking about with employers, one of the things that I've run into is that most employers want to do the right things, but they don't know what to do. They really don't. And so I would say: 'I'm going to talk about my own programme'. OSMI specifically exists, and has created handbooks, and can provide direct consulting to tell you how to do this. And we give that stuff away for free. So we're there and we can help you with that stuff. Right now, on a basic level though, I think what it is saying is: 'I understand the major impact that I as an employer have on your happiness and wellbeing. So I need to treat it as a number one priority’. That's it. End of story. If it's not a number one priority, then why are you even there? Otherwise? The only reason an organisation exists, a for-profit organisation in the United States, the reason they exist is to make money. That's the only reason they exist. And legally everything pushes to that. Shareholders can even sue them if they don't make money, or enough money. So keep that in mind.  You're making a bargain with an organisation. You're signing a contract with an organisation that's purpose is to make money, no matter what they say. That's where it is. So you kind of have to be that person and say: 'No, my health matters this much, and I'm not going to compromise it for some job'. It is not that important. It's just not. David: I have been doing this at conferences. I actually did this in Prague at DevRelCon, where everybody's going out after the conference, and I have just said: 'You know, I'd love to, but I need to go ‘de-people’ for a while, right? I'm ‘peopled out’ for right now and I need to go not do that'. And I even posted in the DevRelCon chat on the DevRel collective that I wasn't going there. 'I'm going back to my hotel to ‘de-people’ for a while, and if anybody would like to go have a small dinner, let me know'. But that was all self-care. It was all selfish self-care of, you know, ‘I've been around people all day. I need some time to ‘de-people’ and be by myself for a minute. It's not that I don't want to be with you, I just need to be with smaller groups of people for a while’. Rain: But that's not selfish. You can't take care of other people if you're not taking care of yourself first. That's not selfish at all. David: It leads to burnout for me if I don't stop when I need to stop, and I just keep going, and then suddenly I'm over the line, way over the line, and I can't get back. Matthew: Well look, thank you everyone for your time. This has been a good discussion. I feel like we've only scratched the surface, but it feels like the beginning of a conversation rather than this being the end of it. So, thank you, each of you. We'll put lots of resources in the notes. I know that everyone here has shared things that we can put in there for people who are watching this or listening to this. Very briefly, if everyone could just share where people can find out more about you, that would be great. So Ed, OSMIhelp.org, is that where people can go? Ed: Yeah. OSMIhelp.org. Yeah. And that's where you can find out about us. Matthew: Thank you. Rain? Rain: I tend to be on most socials as Rain Leander. Matthew: David? David: I am almost always David GS. I am Davidgs.com. On Twitter, somebody stole David Gs. And I'm DavidGSIoT. But pretty much David GS will find me almost everywhere. Matthew: And Wesley? Wesley: You can find a lot of my stuff at wesleyfaulkner.com. I'm on Mastodon on the hachyderm server as Wesley83. Of course, I'm also on the podcast Community Pulse, and also just work with Kim Scott, so you can find me there. Matthew: Cool. And Rebecca, thank you so much for taking the time to be a part of this, and thank you to Common Room for sponsoring this episode. Thanks for sharing. Rebecca: It feels funny that you're calling me out to thank me. Really thank you to each of you, to our panellists, to this roundtable, this circle, and for bringing us all together, Matthew. This is really special. It's quite moving, so I don't really have much else to say other than thank you for the vulnerability, honesty, candour, and humour throughout it as well. So thanks for the education. Matthew: Thank you everyone. See you again.]]> 01:12:11 <![CDATA[How To Build Beautiful Friendships with Marketing and Sales]]> Fri, 05 May 2023 16:30:16 +0000 DeveloperRelations.com https://permalink.castos.com/podcast/37381/episode/1474530 https://devrel-roundtable.castos.com/episodes/how-to-build-beautiful-friendships-with-marketing-and-sales Common Room for sponsoring this episode!

Podcast video

Watch video on YouTube https://youtu.be/VNx7DrlUntQ

Show Notes

Sections

  • Figure out how to connect developer advocates to customers and prospects to help them be successful. The difference with Sales and Marketing perhaps is that DevRel looks to build longer term relationships and to solve developer problems, rather than making a product pitch (00:16:32)
  • Integrating the teams, making sure that people understand what their goals and responsibilities are, and being transparent around codependency is super helpful (00:28:00)
  • At each stage of the buyer journey, different roles add different types of value. (00:31:00)
  • DevRel can be helpful in the onboarding process because the department understands the developer specific needs (00:33:00)
  • Understanding what it is like to work in the other's role is key. Just doing the job together can help (00:50:00)
  • If you're starting out, have a clear understanding with leadership about where boundaries are (00:54:00)
  • Many things that come naturally to DevRel can directly support Sales (00:57:00)

Hosts

Matthew Revell: Matthew runs Developer Relations consultancy Hoopy, as well as DeveloperRelations.com, and the DevRelCon event series. He works with companies to help them build and execute Developer Relations strategies. Matthew also creates content and research to help DevRel professionals become more effective. With his team at Hoopy, he works with clients around the world to advise them on developer relations, developer marketing, and developer community. Josh Grose: San Francisco-based Josh is Head of Growth at Common Room, the intelligent community-led growth platform that helps deepen relationships, build better products, and drive impact. He is focused on outcomes. Usually involving ruthlessly prioritising the things that matter, a bit of creative problem solving, lots of learning, a healthy dose of collaboration, and plenty of doing.

Guests

Dana Oshiro: As General Partner at Heavybit Industries, Dana invests directly in pre-Seed and Seed stage startups, while managing the platform and marketing team. Over the past decade, Dana has helped 150+ B2B, developer and infrastructure company founders from companies like Netlify, LaunchDarkly, and Snyk scale their businesses. Laurent Doguin: Paris-based Laurent is Director of Developer Relations and Strategy at Couchbase, the company that delivers Capella, the cloud database platform for modern applications. Matty Stratton: Matty is Director of Developer Relations at data infrastructure company Aiven. He is passionate about helping organisations use great tools to focus on what makes them special and drive relevant cultural change. Tim Hughes: Tim is Head of Sales at Temporal Technologies, the company that develops and distributes th...]]> full 9 2 false Common Room for sponsoring this episode!

Podcast video

Watch video on YouTube https://youtu.be/VNx7DrlUntQ

Show Notes

Sections

  • Figure out how to connect developer advocates to customers and prospects to help them be successful. The difference with Sales and Marketing perhaps is that DevRel looks to build longer term relationships and to solve developer problems, rather than making a product pitch (00:16:32)
  • Integrating the teams, making sure that people understand what their goals and responsibilities are, and being transparent around codependency is super helpful (00:28:00)
  • At each stage of the buyer journey, different roles add different types of value. (00:31:00)
  • DevRel can be helpful in the onboarding process because the department understands the developer specific needs (00:33:00)
  • Understanding what it is like to work in the other's role is key. Just doing the job together can help (00:50:00)
  • If you're starting out, have a clear understanding with leadership about where boundaries are (00:54:00)
  • Many things that come naturally to DevRel can directly support Sales (00:57:00)

Hosts

Matthew Revell: Matthew runs Developer Relations consultancy Hoopy, as well as DeveloperRelations.com, and the DevRelCon event series. He works with companies to help them build and execute Developer Relations strategies. Matthew also creates content and research to help DevRel professionals become more effective. With his team at Hoopy, he works with clients around the world to advise them on developer relations, developer marketing, and developer community. Josh Grose: San Francisco-based Josh is Head of Growth at Common Room, the intelligent community-led growth platform that helps deepen relationships, build better products, and drive impact. He is focused on outcomes. Usually involving ruthlessly prioritising the things that matter, a bit of creative problem solving, lots of learning, a healthy dose of collaboration, and plenty of doing.

Guests

Dana Oshiro: As General Partner at Heavybit Industries, Dana invests directly in pre-Seed and Seed stage startups, while managing the platform and marketing team. Over the past decade, Dana has helped 150+ B2B, developer and infrastructure company founders from companies like Netlify, LaunchDarkly, and Snyk scale their businesses. Laurent Doguin: Paris-based Laurent is Director of Developer Relations and Strategy at Couchbase, the company that delivers Capella, the cloud database platform for modern applications. Matty Stratton: Matty is Director of Developer Relations at data infrastructure company Aiven. He is passionate about helping organisations use great tools to focus on what makes them special and drive relevant cultural change. Tim Hughes: Tim is Head of Sales at Temporal Technologies, the company that develops and distributes the world's leading open source durable execution system, making code fault tolerant, durable and simple.

Useful Links

Show sponsor: Common Room Matthew Revell: DeveloperRelations.com DevRelCon London 2023 Josh Grose: Twitter LinkedIn Dana Oshiro: Heavybit Twitter LinkedIn Laurent Doguin: Twitter LinkedIn Couchbase Matty Stratton: Twitter LinkedIn Mastodon Personal website Aiven Tim Hughes: LinkedIn Temporal

Transcript

Matthew: Hello and welcome to a DevRel Roundtable on a subject that I think most of us will have at least touched on at some point in our DevRel careers, and that is the relationship between Developer Relations, Sales, and Marketing. Now, we've got a great group of people to talk about this particular topic. Before we get into the full episode, I want to bring in my co-host Josh Grose, who is head of growth at Common Room. Hi, Josh. Josh: Hey, Matthew. Good to see you. Matthew: And you. So, thanks obviously go to Common Room for sponsoring DevRel Roundtable. I'd love to hear a bit about what you're doing at Common Room and why this particular topic is of interest to you. Josh: Yeah, definitely. I think what's most interesting about this for me is I had the realisation of the value of Developer Relations multiple times in my career, where I worked with our open source groups when I was at Dell EMC to help us to carry a story that not only could teach and provide value to our customers, but also connect some of our proprietary products back to overall outcomes for companies that had open source leanings.  Then most recently, I was at Splunk and we were working on Open Telemetry, a really large open source project for collecting metrics. And what I found there was we could carry the most influence when we were engaging directly with developers through knowledge transfer education. And so as I saw companies and individuals start to gravitate, it became clear that that was going to eventually lead to product activation, potentially even buying, and social amplification, all of those things. And so here at Common Room, what I focused on predominantly is working with organisations that are open source, open core, because of the natural fit of community developer relations and the relationship it has with overall business outcomes. Matthew: Great, thanks. Well, talking of business outcomes, let's bring in our guests to ask them how DevRel and the relationship between Sales and Marketing affects their business outcomes, as well as everything else about their work. So, I guess let's bring in Laurent Doguin. Laurent: Hello, my name is Laurent, and I'm Director of Operations at Couchbase. Josh: Hello Laurent. Do you want to give an introduction about yourself, as well as where Developer Relations falls under Couchbase, and what some of your goals or KPIs are for your organisation? Laurent: Yeah, absolutely. I am French. I live in Paris, in France. I'm the Director of Operations, so everything operations at Couchbase. It's a bit of a mixed report to marketing. We have a community team that reports to Marketing. We have a TA team that reports to engineering. Now, my team, DevRel, is really focused on outreach. My job is to give more work to the community team, basically. Increase our community funnel, increase the size of our communities, so that they get more stuff to do. So that's more outreach. Most of the metrics we do in my role is to increase other people's metrics, in the sense that we support the community team, and we support every other department in the company to become more developer friendly. So that goes with field marketing, that goes with community team, that goes with SDRs, making our SDRs more developer friendly, making them more able to close deals. We work with filtering. We enable field engineering to be more developer friendly, so deliver more developer friendly or developer focused content. So, we are sort of tracking all of the developer focused effort that these teams do.  We are still trying to figure out exactly what we're going to use right now. There has been rebooting very recently at Couchbase. I would love to set up a peer review process for that because my feeling is that if you always help everybody else, then your best metric is what they think of what you do. So I'd love to implement some peer review at Couchbase. This is still ongoing. And if not, then we'll go with the classic, 'let's measure input and let's see if we can tie all the input work that we do into some output', using some products like Common Room or others. Matthew: Great. Well, let's dive into some of the detail of that in the episode proper. I'm going to bring in Matty Stratton, who is Director of Developer Relations at Aiven. Hi Matt. Matty: Hey, Matthew. How's it going? Matthew: Yeah, very good, thanks. Good to have you on the roundtable. So, I'm going to ask you the same question that Josh asked Laurent. Where in Aiven does DevRel fall, and what are the core goals for your team? Matty: Yeah, so, our Developer Relations team sits in Marketing. We report to the same VP as our community team and our PLG team, which I think is really interesting, and I actually learned a lot about the synergy of that at DevRelCon in Prague. So that was really, really cool. We can talk about that some more. Where we focus and kind of think about our metrics and our goals, DevRel can encompass a lot. And so of course, on one hand it's all of it, right? But, our focus is primarily around awareness and enablement.  So we still have a fair number of metrics that we're working on that are more output than outcome, and we're working on it. We're a pretty content heavy team. So we're doing a lot around how we're driving long form, very technical enablement content to be able to help developers be successful with all the various open source projects that encompass what Aiven is. But we also do set metrics around, and measurements, at least at this point, around activations and service enablement. Creating new trials is interesting, but we also look at the developer journey, seeing people do things with that. And it's an important thing because a lot of times we set measurements and, we'll talk about this more later, but what I sometimes call my internal measurements or my measures, but not a goal, right?  So we can sit there and say, we want to understand this, but you've got to be careful because you'll start setting a goal that has to go up, up, up, up, up, up the ziggurrat all the time. And some measurements are okay if they dip and they go up because we want to see if we did something? So what we're trying to do with some of those is see the effect that we have. And then also, we got a lot of plans for measurement that directly connect to how we see our impact on Sales and Marketing, which I'm happy to talk about a little bit later. Matthew: Let's bring in Tim Hughes from Temporal. Josh: Tim, you're the Head of Sales at Temporal, and I feel like you are the ‘canary in the coal mine’ in terms of seeing a symbiotic relationship between Sales and DevRel. Where does DevRel fall within your org, and are there goals or KPIs that they have to support Sales and Marketing? Tim: So today, DevRel for us falls inside of product organisation on the open source side, which I think makes a lot of sense in terms of where we are as a company and a project. Temporal and its predecessor Cadence, is around seven years old or so now. Our core kind of goals or things we think about as a company right now is how do we grow the project, and how do we grow it as fast as we can with a high quality around it?  And from a Sales perspective, we really look to the community as the key place that we find the organisations who are ready to engage with us and start a sales process, or at least start up the process of understanding how our commercial offerings can help their journey of adopting Temporal to drive their mission critical workloads, certainly over time. And so the relationship there is pretty obvious and pretty tight. The sales organisation has direct correlation between our performance and the size of the community, but also the quality of the community. And by quality, I really mean how many people are adopting the projects, so finding it, learning about it, identifying where and how we can actually assist in developing software inside their organisations.  And then certainly as they go through that journey, understand where it makes sense to raise your hand and start engaging with Sales, and how we can help out. So for all of those things, I think it makes a lot of sense for DevRel today to sit inside the product org, where they can help have a bigger impact on how people find, use and adopt our open source project, which eventually leads to our paying customers. Matthew: And Dana Oshiro, you are General Partner at Heavybit Industries, which amongst other things is a fund that invests in developer tool companies. So for your portfolio companies, what role do you want DevRel to play? Dana: So first off, Heavybit invests directly in very early stage companies. So, it's pre C through to Series A, which is maybe something to note because as far as teams are concerned, there's not really a clear line between departments to be honest. I think DevRel plays a pretty generalist role. And in some cases that person has been everything from product marketing and helping take a product. Basically doing a lot of persona-based feature testing and discovery pre GA.  There's always the awareness and early usage kind of metrics. They're building social proof and finding user-generated case study type of content. And then of course, docs, developer experience design, onboarding, simple APIs. So it's a pretty generalist, sort of kitchen sink role. And in the same way that they're interacting with Marketing or Sales, it's usually one or two people, if Sales does exist, to be quite frank. Matthew: Great. Thank you. So I wondered, do the different strategic reasons or strategic goals that companies have for DevRel impact how they relate to Sales and Marketing? And I think for you, Laurent, it is particularly interesting because, am I right in saying that your team at Couchbase falls under Marketing, gets at least some of its funding from Sales, and yet what you're doing is Developer Relations? So you're kind of right in the middle of it all. Laurent: We've been going through hoops and loops with DevRel at Couchbase, a 10-year-old company. And, COVID happens. The A team couldn't move out too much. The A team was reassigned to the developer experience. They're building more developer integration, and now there's an issue that we don't have anyone that's community facing, outreach facing. And that feedback came from the field, from the assist, from Sales. And Sales realise they're selling a very technical product. Couchbase is a database company, sales cycles are pretty long. You need to be very thorough in the way you set up work. I was going to say it's not an easy SaaS, but that's kind of saying SaaS is hard as well. The solution engineer said we are meeting more and more developers, which is great because Marketing started targeting more developers. Couchbase was a long sale cycle, moving to a database as a service, more SaaS-like project, less critical, less high performance, less scalability use case, more data use case for everybody. If it's for everybody, you meet every developer. If you meet every developer, you need to make your speech more developer friendly and less 'this is how you scale a massive cluster and talk about metric and all that stuff'.  Developer experience becomes more important than performance and scalability. So solution engineers, solution architects realise that we have a different crowd. It's not about architects anymore. It's not about DBAs anymore. We have so many developers who are meeting every day in our sales activities, that we need to get better at that. This goes up into how Sales has been funding this function because they need us, they need to be more developer friendly. So the way it's built, we're building the team right now. We have four different sales regions. We're going to have one DevRel per region, basically at the start to support SEs. That's our main activity. It's hard to split between supporting Marketing and Sales. And we are sort of trying to figure out what's the best way - supporting SEs, building more content. It will be measured on that. Our scaling forces are assets right now, we are building the team.  We can not go all out with traditional DevRel activities. We have to scale through the team. So we have to make them better at talking to developers. And so that's mostly where it's originated from. It's also originated from 'well, we don't have a DA team anymore, so we need to go and rebuild community and endeavour'. I know that's the marketing part. We need to support the field marketing. So we need to do all the conferences, all the events, all the webinars and stuff like that. So, this is where it comes from.  Now, again, in terms of metrics, we're still figuring this out. I'm not going to say I'm against metrics. Metrics can be gamified, and that's sort of a problem to me. When you go to a conference and you set up a game, for instance, you try to get all those leads coming in to be nice with field marketing and say 'look, we have all those leads'.  You probably have some people that just give you their phone number or email just because they wanted to win that Lego set that you have on your booth. So having too much of a metric approach to me is an issue in the DevRel team. It suits other teams very well. I think my function right now is to help other people scale and see how to measure myself or help them scale. So it's just about my input and their feedback on what we do to help them to be better. And we can see that training SDRs, training SEs, we have better feedback and we have a better sales situation right now. Matthew: So for you, it really is about that integral relationship between Sales and Marketing. But Matty, you were talking about the importance of feeding back into the open source projects that Aiven relies on. And just to set the context, Aiven provides hosted instances of many open source projects for storing and working with data, for example. So, do you get involved with the sales and marketing team? Matty: Yeah, and we're kind of building that muscle right now. So for context, especially for people listening, I've been at Aiven since August. So what is that now? Eight months? Maybe a lifetime, maybe just a few minutes. Depends on the horizon that we're looking at. But kind of looking at how we can start to build to that. So how are we involved with Sales at this point? So I can tell you what we're starting to do, and then maybe the next part that we're getting in place.  One of the motions, and I will caveat this with, this motion only really works when you've got a pretty well defined and mature sales engineering organisation, because if you aren't careful and you try to do this, your DevRels become Sales Eng. There's nothing wrong with being a sales engineer, but it's a different role and a different skill and a different approach. What we try to do is figure out how we can have our developer advocates connect with customers and prospects to help them be successful, but not necessarily in a way to pitch the product or give specific training on the product or do something of that nature. So for example, we can have a customer that says: 'Hey, we're trying to solve this data governance problem'. So actually we don't wait for the customer to come to us. At the end of the day, what do SDRs and AUs want to do? They want a reason, an excuse to have a conversation with a customer, right? So one of the reasons can be: 'Hey, you know what? Laurent's going to be in region at this event. We know your office is there. We'd love to have him come in and talk to your team about data governance', right? Not talk about how to use Aiven, not talk about our product and our pitch and our demo, but this idea that's relevant to the decision makers and the practitioners that would be Aiven customers. And this has a couple of really effective things. One is, again, in past lives of doing this, how many times I'd walk out of a meeting and the rep would say to me: 'I've been trying to meet that CTO for six months, and now we have an excuse'. But it also shows some value to the customer or the prospect that says: 'Hey, when you have this relationship with us, you have access to these subject matter experts and to these things that are not just us coming in and demo-ing'. And then the point to how that connects with your Sales Eng, is the Sales Eng is the fast follow, right? To be able to say: 'Okay, cool. So all these ideas we just talked about, by the way, this is how you can do that with Aiven, if that's of interest to you'. You have that connection. And so we're building that muscle here at Aiven and figuring out how we do that. You have to also make sure you're really crisp with teaching your field how to do this with you. Otherwise, people just look and they take a guess. They're like: 'Oh, well, this is how I want to use a DA, I want to do this'. And we are putting together kind of our catalogue to say: 'Hey, these are the things we can do'. The other place is getting into the idea of a DQL or DevRel qualified lead, as Mary Thengvall talks about. We used to call them 'warm handoffs' and then nobody knew what that meant, so kind of rebranded as DQLs, because XQL means a thing. But even then I think a DQL doesn't look like an SQL or an MQL or whatever. To me it's a touchpoint, but it's not something that goes into a campaign.  So what we're building now and working towards is this idea that when we have a touch point with someone, and there's a DA, and then also with our community, we're going to get that into Salesforce under that and say: 'Hey, okay, I talked to Tina Smith, who's an SRE at JP Morgan Chase'. Cool. What never can happen there is a rep goes in and says: 'Oh, Tina's a contact, I'm going to reach out to Tina'. No. When you're looking at that opportunity, you go: 'Hey, Matty talked to somebody over there. Let me talk to Matty and find out more about what we understand of that case'. You have to be really crisp and protective of how your CRM and how all that stuff is set up.  There's a whole thing about developers not wanting to be marketed to - that's baloney. Developers don't like to be traditionally marketed to. And shoving them in a drip campaign is a sure way to p**s them off, right? So if we're going to capture those as DQLs, we put them in a way where if there's anything that looks like a campaign, it's something that provides value to them, but fundamentally it's just additional context. And then from a self-serving perspective, this is how we start to show influence, right? Because then we can start to say: 'Okay, this deal happened. I mean, were we influential?' Who knows? Connecting influence is still guesswork. Getting back to Laurent's point, we don't want to sit there because by doing it this way, I think it helps counter away from that sort of gamified metric. You don't set targets to say we should have X number of DQLs this month. That's just a thing we do as part of our operational thing, but we look at the outcome and then we want to be able to measure those outcomes.  But we have to be really careful that they don't look like goals. Because you talk about funnel, I mean, DevRel floats so high above the funnel, right? Attribution is so hard to do that you kind of have to look at it as an after effect. Just say: 'Hey, was this influential?' It's a lot harder to see a direct connection between 'I did this exact activity and it turned into this exact revenue'. Dana: Sorry, I'm not super familiar with DQL. Will you walk it back for me? Sorry. Matty: Yeah! So, okay. So just a little quick history lesson. And I believe in the Business Value of Developer Relations book they're still referred to as 'warm handoffs'. I think they got rebranded after the book. So there's this idea of saying, in community and DevRel, we have this idea of a 'warm handoff', which is some connection point of someone we have an interaction with that we hand off to somebody else in the organisation, whether it's to product, feedback, maybe it's marketing for a case study, maybe it's a sales lead, maybe it's recruiting.  So the problem is then, as an industry of the entire world, nobody knew what the heck the words 'warm handoff' meant, but we know what QL, qualified leads are. So we started calling them DQLs, DevRel Qualified Leads, which again is slippery and messy because they're not necessarily sales leads. So really what these are is they're recording contact points that happened, but it's not like a booth scan should never be a DQL. And this is actually the problem with, like Laurent said, the gamifying. I was at a place where we said we're going to have X number of DQLs a month. And you know what we would do? We set a booth scan at a community event like DevOps, says: 'That's a DQL'. Well no, it wasn't helpful, unless we put the context. These are our way of tracking a connection point of a person who's connected maybe to either to an opportunity or an account that we have so that we have that context. But it's not someone to outreach to, right? And I've definitely had that.  I mean, think about it as a much more operationalised way of what a rep does when they reach out to the DA and say: 'Hey, I see you're connected to Joe Smith at Panera Bread. Can you tell me about what they're doing there? Because I see you connected on LinkedIn'. How about if it's a little bit more? Because what the DQL says is: Hey, I met Joe Smith from Panera at DevOpsDays Pasadena, and we talked about this'. So now there's some information, but at no point is it an outreach contact, it's kind of that internal connection. Laurent: Sorry, if you go through a traditional SDR folder, we have a different state of qualification and we know that a 'warm handoff', you know, at the end of the federal, all the colleagues that we get from a conference will be stage one and that 'warm handoff' would be S three, four or, you know, deeper. Dana: It's not tied to revenue, but certainly within the concept of product qualified leads, there's definitely certain activities that are identified as moving more within a lead funnel, where I have seen teams pretty directly measured. Matty: I think that's why I really don't like calling them leads because a lead is a lead to the thing. It actually is kind of a diagonal entry point. It can be a diagonal, it can also be the first contact. Because we don't know, right? Like it can be like: 'Hey, I talked to Tina at JP Morgan Chase, they're not even an opportunity for us yet'. Okay, well then that ends up being created. Or it can be that they're an existing accountant. This just gives us some more information. So I think that's the problem with it being a QL. Leads imply sort of this very linear flow of a pipeline, right? And that's not really what this is. Dana: Multi-channel attribution has never been done very well. Matty: I just want to see that we touched that opportunity, right? Like even that is even sometimes enough. Although you're right, because the way it happens, I remember at PagerDuty for example, it would be the way that they did sort of the indirect attribution. But then this became a metric with our team. And it was funny because it would be like: 'I talked to so-and-so at KubeCon once and it turned out to be a $2 million deal. So we got a piece of it'. I mean, we didn't get paid, but, you know, it looked like we impacted that revenue and we're like, did we? Who knows? Josh: I think we're getting into attribution. We could have a whole session on that, especially as the number of digital channels is growing exponentially. I want to hear from Tim because what we're getting into is the tension between DevRel and Sales, and the sacredness of developer experience for developer-centric companies. Now, Tim, leading up sales at Temporal, we're a customer, we've had a great experience onboarding and adopting the technology as well. How do you balance this intention that you see Matty and Laurent putting into the experience for the developer into how you actually deliver, say, a sales led experience in community alongside DevRel at scale? Tim: It's always funny about how much tension seems to exist or people want to call it out. And the first thing I would say is it should be really transparent and people should be having conversations with those who lead these teams about what each team's incentivised around, and goaled on.  And if you can do that from the get-go, then you're going to pretty quickly identify like: 'Hey, there's a lot of friction between our two teams, just by the nature of how we're incentivising each team or what we're measuring them on'. So the first thing I would point out is like: 'Hey, well, what is this team responsible for? How are they going and metricing it? And then, what's the point of that thing?' So, at the end of the day, we all work for companies that eventually want to make money. And the DevRel responsibility is Developer Relations. If we're selling to developers, we want to grow their community. We want to make this an attractive place to be. But I don't think we need to lie to ourselves and pretend that the eventual outcome is to eventually have customers who spend money on the product. And what ideally I think every company wants to be built around and monetise their product on is people genuinely wanting to use the product. So they use the product because they get value out of it. We're lucky enough that we're pretty early in this whole journey, we're not multi hundreds or billions of dollars in revenue with all sorts of different fiefdoms, and it's hard to get people aligned. We're small so we can tackle this challenge pretty early right now. My broader point would be if we can get alignment around incentives and understand what each team is rowing towards, then it's much easier to create programs and handoffs, and to think about what each team is driving for, and how the different kinds of motions in this funnel actually can work together.  So like a small example would be meetups. I'm sure most folks have some type of meetup goal or they're regular running meetups. Well, meetups in isolation as a DevRel activity, I would say yields pretty poor results as opposed to if you have a full organisation function built up around it. So your marketing team are going to do quite a bit around the mechanics who are actually running these meetups and driving attendance to it. You might want to tap into the local sales community or the local sales team for helping to get a prospect or a customer to actually speak at that event. So: 'Hey, we're working with a customer in x, y, z City. We have an event coming up'. Reach out to that person, invite them to join the meetup as a speaker. They have an incentive to speak, because oftentimes it's like free recruiting, so on and so forth. And so now all of a sudden, DevRel and Sales are really working towards the same thing. 'Hey, we want people at this meetup to grow the community and the project. Well, Sales wants to be there to actually work with the different folks who are there from all sorts of different aspects. It's an easy free touchpoint for my customer. It's a free win with my customer if they get to speak at the event. Also, I get to talk to people and prospect into it'. So you can play this out on and on and on. And then even just think about the post-event process, right? So it's like: 'Okay, well what's the point of doing that meetup? Well, we all just talked about the reasons and the goals and incentives. Okay, so after Meetup, how are we all going to integrate our post meetup touch points to make sure that they make sense? Well, we had a bunch of prospects who threw that event, raised their hand and said they'd like to talk to Sales. Well, we probably shouldn't have those people be followed up by DevRel. We should just have them be followed up by Sales'.  I think my broader thing here is that integrating the teams, making sure that people understand what their goals and responsibilities are, and then being basically transparent around how we're all codependent on each other is super helpful. And I think the thing that largely gets missed is the main culprit of the friction between the various teams, and so I think it puts a lot of emphasis on your leadership to identify that, and work towards mitigating that or just addressing that friction if it's out there. Josh: When you think about scaling your sales team, you're bringing in sales members that maybe are more junior or haven't worked directly with a Dev Org, how do you prepare them? Tim: You can say a ton of things mechanically and tactically how you onboard and train people, but the number one thing for me is to make sure that everybody's - and I think this also, for what it's worth, is somewhat embedded in what your go-to-market and business model is like, how you monetise price and package - aligned around this idea that adding value at any given touchpoint along somebody's journey is our core shared goal and actually solves quite a few of the problems. So when you're talking about this idea of a DevRel 'warm handoff', and things of that nature, I think there's a few different ways that we've seen that that DevRel 'warm handoff' actually can be initiated by Sales. So a small example would be, we're observing our community. We can see somebody consistently asking questions around, I don't know, some type of e-commerce checkout process, you know, backend challenge they're having. Well, Sales maybe identifies it because they're paying attention to the community, looking for opportunities to sell into the community. But when we identify that person, we might say to ourselves: 'Hey, look, they're really pretty early in their journey. They're asking questions that our DevRel team would actually do a really good job around because they're going to go in and answer a tactical question, but really based off of like, say they've been in our community for two months. It's really pointing out that there's an opportunity here for DevRel to set in and probably expand the art of the possible, or do some like baseline education with that particular customer. So now you have this weird kind of back and forth where maybe a BDR identifies that this person needs some help. We ask the DevRel team to step in, given where they're at in their journey. DevRel team runs that meeting. Post that meeting, DevRel says: 'Hey look, these folks are not ready for a commercial product in any near term thing. But they've set them down on this pathway to be in a really good spot, in say six months from now. And now the sales organisation can set up flags, or reminders, or whatever it is to circle back with that. Or use tools to set alerts looking for behavioural characteristics, or traits, or things that then say: 'Hey, this person's six month journey we expected is actually happening in three months'. And there's some type of signal they're saying that then says, raise their hand again. So I think there's all sorts of different things you can do around the training and onboarding, but if you get everybody rallied around this idea that all of our jobs are to add value, and adding value eventually turns into money, then again these handoffs become pretty easy.  And then, I think it was Matt's point around this idea of attribution and leads not following the linear path. It's a great example. It's not a linear path. It starts with Sales, back to DevRel, then it's going through this funnel of adoption. 'We're looking for signals where you can actually short circuit this adoption funnel and dive in'. And when you dive in at that point it might be: 'Hey, we asked DevRel to come back in again' because really what they're asking for now is like: 'Can you do a lunch and learn where you can talk about our technology to a bunch of other teams who are now observing the success of this core team that originally adopted?' And you're all over the place. But again, add value, add value, add value, and eventually that value is going to turn into somebody raising their hand and looking for help that you can monetise. And they're going to be very happy to do that, if their experience has been one where 'when I engage with x, y, z company, I always walk away with something net positive. it's not a waste of my time, and it's not just a veiled pitch of their services'. Laurent: I think stop pitching is a good way to enable Sales. Sales engineers need to be more friendly. That was a huge part of our sales enablement. Lead with problem, not pitch.  Matty: I was just going to say too, with the onboarding, just kind of a thought - we're not doing it this way here at Aiven because we're in a different stage of this - but I've seen this work too. DevRel can sometimes be really helpful in the onboarding process because they understand the community and their problem.  And so like again, at PagerDuty, we provided some of the general training. Content that was then training the Sales team about 'this is what the DevOps community is like, this is what DevOps people are like', et cetera, et cetera. But what that does is that that almost from the beginning sets up this like, you have these subject matter experts over here that can coach and can connect. And to be frank, I think most of the problem is on the DevRel side and not on the Sales side. We need to get over ourselves a little bit. And I think honestly, most DevRels probably agree with what Tim said, and probably are in that place, but we have a lot of very loud people in social media who want to play the one true DevRel. 'We are not sullied by filthy capitalism. We fight for the user, we do all this stuff'. And the reality is, yeah, we all want to make some money. And, as I've said before, there's a sort of belief that when you're leading with Sales, you're, you're manipulating people. And I'm like: 'Hey, if the only way that someone would pay for your product is if you trick them, why are you working at that company?' Right? That seems like a different problem.  Like I said, I think what I've started to observe is that most 'chop wood, carry water' DevRel practitioners probably get this just fine, but we do have a big perception that's led by this idea. And the reality is, yeah, we all want to get the money there. We're just a little more indirect by it, right? I always said before, the best salesperson at Chef software when I was there was Nathan Harvey, the VP of community. Nobody saw Nathan coming, right? Because they're like, 'think about Sales Eng', right? By the way, I think that Sales Eng to DevRel pipeline is underrated and can be very powerful. But I used to say when I was a sales engineer, I'm like, customers will tell me stuff they would never tell an AE, because 'oh, well you're like the engineer guy'. I'm like: 'I'm still trying to sell this to you'. And then that goes a hundred fold for a DA, right? They're like: 'oh, you're the community person. You're a HugOps person. I'll tell you anything', right? And this is not tricking people by the way. I know this all sounds like it, but it's not. It's just a way of being able to have conversations in alternate ways.  Tim, I really like that back and forth handoff you were talking about. I myself have fallen victim to thinking in this one directional way, in this particular implementation. So yeah. Awesome reminder. Tim: Yeah. Totally. Yeah, I think the other thing too is like, especially for these 'bottoms up developer', kind of like 'PLG adoption type lead' motions... You mentioned JP Morgan. Selling into JP Morgan is a series of sales cycles that last a decade with tens of thousands of developers. And so you land inside one part of the organisation, well, that's like a huge opportunity and signal for DevRel to say: 'Actually, we probably should be allocating some type of resources to this mega firm who could potentially be a massive adopter of this technology. And now that we have a foothold, it's like: 'Okay, well DevRel actually can do quite a bit of work to help expand or evangelise the technology inside of that organisation'. It seems like a thing that everybody would be excited about. And you know, when I think about it, oftentimes we're preparing content. It's like: 'Well, how can we contextualise this content to the people we're talking to?' Contextualise something industry specific, or use cases, or whatever it is, the things that get them excited. Well, there's nothing more powerful in my opinion than being able to go into a customer, taking existing use cases, and using that is one of the ways that you evangelise and talk about the technology and the problems it solved to this broader audience. But that broader audience always has this core characteristic, which is: 'Hey, we're all working at the same company'.  So, again, that's like a non-linear path, right? It's like: 'Yeah, we touched them at the front end, then there was a deal, then we landed it, now they're running in production. Okay, now we're going to go back to that organisation because there's huge community that we haven't touched yet'. Matthew, remember this sort of came up a little bit in some of the conversation after my talk at DevRelCon, which is one type of DevRel we're talking about. So there's a lot of people that believe DevRel is about advocating for the developer into product, and all of this is deaf ears on that, I think, because they're like: 'This isn't what DevRel should be doing'. When you're more of a product-oriented advocate, where do those connections come from? As opposed to an awareness and an enablement oriented developer advocate? Which is kind of a different kind. Some people are all of them, but we've been focusing more I think on that latter one. Laurent: One thing for sure is that someone's paying for your salary and the goal of a company is to make money anyway. So whatever you do, you know that, in the end, you are for the sales motion, even if it's for the greater good, or however you want to call it. I'm tired of having people asking for a six figure salary and not wanting to understand that the goal of the company is to actually sell stuff to people, which I know sounds like a big shortcut, but that's what we do. Wherever you are, that's what company does. Josh: I think there are specific programs within product that benefit from that sales orientation. Like when you're thinking about defining your persona or your ideal customer profile by being engaged directly with community or individuals at events, and identifying use cases and so forth, it actually can accelerate your go-to-market strategy because you're kind of the tip of the spare in terms of seeing what developers are naturally doing with your product, or articulating the problem statement better, or anything like that. Those are pretty natural. Additionally, if you are more product oriented than one of the challenges, especially in larger companies. So if you're a developer advocate or DevRel with a large organisation, then building customer advisory boards is actually pretty challenging, because getting the right persona from the right type of company in a room with other like-minded individuals at the right time with your product teams is actually really hard to do. Usually it's recruited based on like, how much does this company spend, and who do we know in the company? And so you end up with this 'hodgepodge' of people representing different viewpoints that may or may not actually help accelerate your iteration and innovation process. And so I think all of those can be really helpful. Additionally, one thing that go-to-market relies on is case studies. And so when you launch a new product, you always want a couple of logos and stories of adoption going out with it. But typically, the go-to-market side and product marketing isn't necessarily equipped, and they keep going back to the same well to find these individuals, whereas developer advocates talk to someone new nearly every day. Dana: I've seen at the very, very early end of it, as far as DevRel and their interaction with the companies is concerned, even prior to knowing what your commercial product is going to be, if you are doing something that is category creation, the DevRel team has to do so much work in actually giving an identity to the persona in which you're trying to pursue.  So like, think about having to build an entirely new set of practices like the Jamstack folks, right? I think the folks at Netlify started working on Jamstack probably many years before their true commercial product was released. And part of that is that by figuring out this group of practitioners, who have obviously been forgotten as far as tooling is concerned, you can figure out their identity, figure out their motivations, talk to them and figure out all their problem set, and actually build into the solution that you need to with a very sharp set of features. I don't know how much patience people will currently have in this environment around that type of thing, but I think frankly, if you are a company that has created an entire category and an ecosystem which other players can jump into, that is the most amazing win of all. And I think even for community as well, for DevRel folks to look at it and be like: 'We have created a movement in which people are doing things in a more sane and better way'. What a dream to market that, what a dream to sell that, you know? Matty: Is that a little bit like when my career ladder at one place said to get to the principal level, it was 'Create something industry defining like blameless postmortems'. And I was like, really? That's my promotion case. Dana: You're like, yeah, like one person's going to just do that! Matty: Right? Yeah. But if you can, as an organisation... Matthew: There's a common problem that Marketing and DevRel teams face, which is that outsized achievements like that set the bar, and then everyone else has to kind of remind people that actually, you know, there's, there's a bit of luck involved, as well as foresight and talent, and all of that. But a lot of DevRel is a process that is just kind of ongoing, and after some time of hard grind, you see the results. And they might not be outsized. They might just be appropriately sized. Dana: My firm is all ex operators from Dev tool and infrastructure companies, right? And so I can only really speak from my own experience with an early stage firm, and a firm that specifically invests in early stage companies, and say that the things that we look for are indications that developers are excited or there is some ability to build community, right? Like, it is very hard to graft community onto a sales led organisation after the fact. The culture is pretty different.  There are these kind of very mercenary, very rigid, funnel focused activities, and there aren't a lot, there isn't a lot of room to do a little bit more discovery. And I think what usually ends up happening is we more often see companies that are still figuring out what the product is, and we'll bring in DevRel type people to help them discover that, help them understand their persona, help them understand the problem that they are trying to solve, or if the solution can be validated. In the late stage, it becomes a lot more revenue focused. Matty: I was going to say, and I wonder also if we're seeing this a little bit in downturn, we've had a lot of pretty latent examples. Also some indirect ones of, there's these things where we look at this organisation that is driving the state of the art forward, right? You know, I think about PagerDuty, we did this with ops guides, like PagerDuty's instant response framework, that has nothing to do with the product, but it is the gold standard of how to do instant response and everybody knows that. And so we built a lot of stuff around that. You talked about Netlify with the Jamstack stuff, and I'm going to come back to that in a second. But we're trying to do this with Aiven. We've got some stuff coming that's like: 'Hey, it's content that's not direct to that, but it's authority building. It's, you know, how do we drive the state of the art forward?' But then we look at stuff like DigitalOcean, which has happened to all their docs team, right? They had that. And so, it was like: 'Okay, we cut that'. Actually it was funny, the reason I bring up Netlify, and someone prove me wrong, but we were looking for some examples for some content we were doing, and I was like: 'Oh yeah, we're like, Netlify has all this great...'. You can't find it anymore. There was all this, strike me down for using this word, but all this thought leadership content around this stuff, and it disappears. And I think that's a late stage thing that happens too. You start to sit there, and like you said, you bring in CROs and stuff who sit down and say: 'Wait, why are we spending money on something that's not directly impacting funnel, that's not doing that?' And it gets hard because I think that's a very indirect kind of marketing and leading, but it's incredibly powerful. And so when we're in a case like now, in a downturn, it's like right now to survive we have to do things that require less imagination to show value. And it's a bummer because that's what separates you apart, besides being just like turnkey and, you know, transactional, and yes, we have this great product, but it's all the ideas behind it, and it's a great way early stage to grab on and get a name. And then I feel like we've got companies that did that. And then, like I said, then they get to later stage and it's like: 'Oh, but that doesn't matter anymore'. It costs a lot of money for something that doesn't look like it brings any revenue, right? Dana: Yeah. I mean, I guess it's less that it's late stage and more that it's like if your valuation is primarily on paper, and is not validated by the actual revenue behind the scenes right now, you are scared, right? And I think right now in particular, like this is a perfect storm, because tensions, like we talk about DevRel and Sales and Marketing getting along, like tensions are high. User and customer return is pretty high, due to company closures and budget cuts.  Teams haven't met, they've been remote working for years now, and you have no idea if you even know, you've met your salespeople or marketing people or whatever in person. And then companies who have raised too much money, or need to extend their runway because they don't want to fundraise in the next year or so, or they don't want to, or they can't IPO in the next year or so, have to do riffs and layoffs. And so departments are kind of blaming each other as far as missed targets are concerned. And this is where, I mean, Marketing teams and DevRel teams get gutted at times like this. And so I think it is very timely for us to talk about how to tie your metrics to something very solid. But also, the really big opportunities don't come from turning the crank and trying to double, double, triple, triple your revenue every single year. At a certain point there needs to be a more creative approach to all of this. And you can't continue to be like a market leader if you don't change. Matthew: I mean that kind of brings us onto something I wanted to talk about, which was friction between Sales and Marketing. We've talked about harmonising them and good relations, handoffs and so on, but it's not always the case that these teams get along. And I think one reason is there is some friction between Marketing and DevRel because sometimes it feels like they're going after the same bits of budget and the same results and so on. I'd love to hear how you've dealt with that friction in your organisations. Matty: Some of this is perceived and some of it isn't, right? Like perception is based in reality. There definitely are people who work in Sales that are not necessarily what come across as the most ethical maybe or whatever. There's also people like that in DevRel, just so we're clear, right? You know what I mean? But, I do have a story like that. It's a reframing exercise a lot, number one, right? And this is part of the reason why, and as Tim talked about this, about understanding the incentives, and there's a lot of people in DevRel that don't know what sales motion looks like, right?  We're supposed to be, what do people call developer advocates? Empathy engineers. We have zero empathy for the salespeople in our company as a unit, generally speaking. But if we understand where they come from, and what it's like to work in that role, sometimes it just helps by just doing the job together. Then, the people become people, and then sometimes you may become people and you're like: 'I don't actually like you'. And that's, that's the thing that happens too in life, right? So it is a little bit of reframing, a little bit of that understanding.  Here's one of the biggest ways to put it in context. I remember my team used to be invited to our Sales kickoff at one of the companies because it was a good way to talk to them. So we were sitting in all those, and of course they're having the big dinner, and it's like: 'Hey, this is everybody who won the trip to this exotic location' or whatever. And I remember our CEO said: 'We have all these other people'. And the company that said: 'Well, this isn't fair. Why do the sales reps get to go to Greece and get to do all this?' And she said: 'Do you want your job to be continually reevaluated every three months about whether or not you were even reasonable at what you do, and live or die every day? Cool. Then you can go on an exotic trip.' You know?  And that's the thing to understand. Like, there's a thing, we don't get it as much in non-sale roles, that you could have the biggest quarter the company's ever seen. You could sign the biggest deal that was ever done, and on the last day of the quarter, everyone applauds you. The next day your Sales VP goes: 'What do you got for me now?' 'Don't care. Don't care. What's that? What's in your pipeline? Where's it going?'  And when we understand that, we understand the people's motivations and what they're trying to accomplish. And we also one of the things for us to learn is don't bother salespeople at the end of the quarter. Like that's not the time to ask for a favour from an SA, right? That's a beautiful thing for us. Even when you're connected to Sales as a DA, you're not closing any deals, right? We don't have the panicky end of quarter. We're earlier.  So I think one of the things is that just working on stuff together eventually breeds empathy, right? Just by doing it. I said a lot of times we just haven't even met people in person and worked on stuff. So I do think this sort of 'ride along the customer' stuff helps a ton, because now we're people, right? We're not just slack messages, we're not just requests. We're also humans. Laurent: I think it depends on what you're selling because if upsell for you is super important, as DevRel, doing lunch and learn, doing lots of activities, and an existing customer is bringing tremendous value, you are really helping them, making sure that they can upsell more. So it's not just before, it's also after.  Now about sales, I guess it depends also on where you are because a sale on the zero to 10 million will be completely different than a sale from 10 to a hundred, or a hundred to 200, because AR becomes more important than just getting logos. So it completely changes the way Sales works as well. And I know because I was at Couchbase in 2014, where we were on the zero to 10 phase, or zero to a hundred, and now I'm in the higher phase, and it drastically changes the way they operate. And if AR becomes more important, and if churn becomes a much more important metric as well, then that has a very big impact on how we keep and how we grow our existing customer base. Matthew: We've had a really interesting conversation. I think though, to start to wrap things up a little bit, do you have any closing bits of advice from all your experience, each of you, on what DevRel people perhaps at the start of their career should be looking out for when trying to make the most of those relationships across the organisation? Laurent: Get to know them. Just talk to DevRel. That's what Mary said. Yeah. Like make them a human being, not just a function. Get to know what other people do in the company. Some tech will stay in their tech bubble for years and never understand what Marketing does, or what Sales does, or what the go-to-market motion is. And if you are DevRel, that's a problem. You should understand most of the other roles, especially go-to-market motion. DevRel is practice. It doesn't have to stop with people hired as DevRel. It could be anyone. Part of my role is to actually talk to Sales and make them more DevRel-ish, in a sense. And I think that's what you should do. You should talk to other people. Matty: I think especially if you're starting out. So the advice is different for a DevRel leader, because I'm going to pin some of this on your DevRel leader, but if you're starting out, make sure that you have a crisp understanding with your leadership about where those boundaries are. On the other side of this, it is really, really hard for people in this role to say no to people because you fundamentally don't want to do this job unless you're someone that wants to help people. If you don't have a specific way that these engagements happen, you're going to end up just sort of doing whatever is asked of you. And so it's easier to say yes, actually the more senior and authoritative you are in the organisation. So be enabled to say no, be enabled to escalate, but ask questions, right? And again, remember, no is temporary, yes is forever. It's true in open source maintenance. And it's true in this thing too because once you say you're going to do a thing, now you're doing the thing, and you're probably going to have to do it a lot. But 'no' can be 'let's find out a little bit more about it'. So, let your boss be the bad guy. Matthew: And Dana, for the early stage developer tool companies that you are working with, is there a playbook that you have that you think would be kind of generally applicable to other firms? Or is that really specific to Heavybit? What advice do you give to those companies when they first start to look at how to engage with developers? Which I guess is at the very beginning for your portfolio. Dana: I think generally early stage companies pursue DevRel programs because there's some developer led product in the broader commercial effort. That being said, if you really just hope to outsource that to some poor DevRel that you hire, versus actually caring about the community, it isn't going to work.  It is so much work to listen that closely to your users, especially when you actually get to a point where you get into the thousands and hundreds of thousands. So I would say if you're going to do community, be all in, and if not, then figure out what your other go-to market is going to be. But I don't think it's for everyone. I think it is extremely efficient from a marketing and commercial effort perspective, but I don't think that it is meant to be for every team or product, frankly. There's a lot of deep tech products that are for enterprises or for large enterprises. Tracing for example isn't necessarily something that ICDevs will care about, right? So you sort of have to figure out your flavour of it. Matthew: And Josh, what are you folks at Common Room seeing that you would point to as the best practice in terms of this integration between all the different touch points along the customer journey, I guess, the buyer journey? Josh: Yeah, I think it's understanding that a lot of the things that would come naturally to DevRel, whether it's a workshop, a lunch and learn, an event, they can directly support Sales. And so don't think that just because you're doing something that isn't necessarily funded or asked for by Sales, doesn't mean it can't be associated with their outcomes. And so having an open mind in terms of what you naturally would do in terms of creating awareness, striving, adoption, et cetera, plays a role. And then creating an input metric around that.  So if we want to do workshops or this or that, hold yourself accountable, do that and then see what happens. The lagging indicators that you might see in terms of adoption by people that attended those will show up. I think DevRel is this belief that if we do the right things for developers to become aware, adopt our products, engage, if they feel heard, if we can accelerate their journey so that they can deliver real outcomes for their companies, then it will be a net positive for us too. And so, realising that most of what you're doing will connect to Sales in some way, let's just try and be thoughtful around what we prioritise, and then hold ourselves accountable to do it, and then you'll get a lot of support. Matthew: Well, one thing I would say is that as a DevRel person, you probably need to be quite vocal about what you've done as well, especially if you've done a favour for another team, and look at ways of repurposing that so it goes more directly towards your own goals. So if you do a lunch and learn, how can you turn that into a Twitch stream or some other reproducible reusable bit of content? Okay. Well thank you very much everyone for taking part in this discussion. I'd like to invite each of you to share where people can find you on the Internet. So Matt, let's go first with you. Where can people find you? Matty: You can find me on Twitter @MattStratton, or on Mastodon at MattStratton@hachyderm.io And I'm also on LinkedIn @MattStratton. You can find me pretty much as Matt Stratton everywhere. MattStratton.com. Matthew: Great, thanks. And Dana, where can people find out more about you and Heavybit? Dana: So you could check out heavybit.com. You can honestly email me directly @danaheavybit.com, which is very easy. I am Dana Oshiro on LinkedIn, Twitter, basically everything. Matthew: Great. Thanks. And Tim, how about you? Tim: Yeah, best place to find me is just tim@temporal.io, or on LinkedIn. You can just find Timothy Hughes at Temporal. Matthew: And Laurent? Laurent: You can find me with L Doguin, which is spelt L D O G U I N on anything social. And if I'm not there, then that means I don't have an account there. Twitter is probably the best way to get to me. Matthew: Great, thanks. Well, Josh, it's been great spending this time with you. I'll leave the final word to you then. Where can people find more about you? Josh: I'm on Twitter @sudotechie, LinkedIn, of course, Josh Grose, and then jg@commonroom.io. Matthew: Great, thank you very much. Well take a look at DeveloperRelations.com, and I'll say thank you very much, and goodbye. If you enjoyed this DevRel Roundtable, check out the other episodes in our Roundtable series here      ]]> 01:01:27 <![CDATA[Looking ahead to conference season]]> Fri, 24 Mar 2023 06:55:57 +0000 DeveloperRelations.com https://permalink.castos.com/podcast/37381/episode/1443315 https://devrel-roundtable.castos.com/episodes/looking-ahead-to-conference-season Common Room for sponsoring this episode! Watch the YouTube video. https://youtu.be/wmhQAGiWVXo

Show notes

Sections

  1. Budgets are getting cut. How does that impact DevRel events strategy? (1:36)
  2. Event attendance is lower that in previous years. (9:15)
  3. Are events the right strategy? (10:11)
  4. Is it best to mix online and in-person events across the year? (15:15)
  5. Showing value (17:21)
  6. Keeping content relevant (23:33)
  7. Self-care at events (38:23)
  8. “Remember why you're there and still get your work done.” (43:33)

Hosts

Kevin Lewis: Based in Berlin, Kevin is Developer Relations Lead at Directus. He is also the founder of the You Got This!, a learning hub focused on core skills needed for a happy and healthy work life. An experienced developer and educator with a history of creating engaging technical content in a range of formats, he helps developers to be successful in understanding complex concepts and applying them to projects, regardless of their professional experience. Matthew Revell: Matthew runs the developer relations consultancy Hoopy, as well as DeveloperRelations.com, and the DevRelCon event series. He works with companies to help them build and execute developer relations strategies. Matthew also creates content and research to help DevRel professionals become more effective. With his team at Hoopy, he works with clients around the world to advise them on developer relations, developer marketing, and developer community.

Guests

Floor Drees: Floor is Staff Community Program Manager at Aiven and Microsoft MVP for Developer Technologies. Based in the Netherlands, Floor has worked on global-scale projects and events such as KubeCon + CloudNativeCon, and managed several projects around inclusive communication strategies and accessibility. She is a serial tech event organiser and also holds many meetups. Floor has helped external communities adopt and enforce a Code of Conduct, and recruit a diverse line-up, and has also supported communities going online.  Mark Hazell: Mark is the organiser of the annual Devoxx UK developer community conference, and co founder of Voxxed. Voxxed is a knowledge sharing platform with the same DNA as the Devoxx conferences and a productive relation with Parleys.com. Focusing on Java, JVM methodology, cloud, future, mobile, and everything in between.  Erin Mikail Staples: Erin is a senior developer community advocate at Label Studio and also a technical adjunct professor at NYU. and stand-up comedian.

Useful links

Show sponsor: Common Room! Matthew Revell: DeveloperRelations.com DevRelCon London 2023 Kevin Lewis: Kevin's website Directus You Got...]]> full 8 2 false Common Room for sponsoring this episode! Watch the YouTube video. https://youtu.be/wmhQAGiWVXo

Show notes

Sections

  1. Budgets are getting cut. How does that impact DevRel events strategy? (1:36)
  2. Event attendance is lower that in previous years. (9:15)
  3. Are events the right strategy? (10:11)
  4. Is it best to mix online and in-person events across the year? (15:15)
  5. Showing value (17:21)
  6. Keeping content relevant (23:33)
  7. Self-care at events (38:23)
  8. “Remember why you're there and still get your work done.” (43:33)

Hosts

Kevin Lewis: Based in Berlin, Kevin is Developer Relations Lead at Directus. He is also the founder of the You Got This!, a learning hub focused on core skills needed for a happy and healthy work life. An experienced developer and educator with a history of creating engaging technical content in a range of formats, he helps developers to be successful in understanding complex concepts and applying them to projects, regardless of their professional experience. Matthew Revell: Matthew runs the developer relations consultancy Hoopy, as well as DeveloperRelations.com, and the DevRelCon event series. He works with companies to help them build and execute developer relations strategies. Matthew also creates content and research to help DevRel professionals become more effective. With his team at Hoopy, he works with clients around the world to advise them on developer relations, developer marketing, and developer community.

Guests

Floor Drees: Floor is Staff Community Program Manager at Aiven and Microsoft MVP for Developer Technologies. Based in the Netherlands, Floor has worked on global-scale projects and events such as KubeCon + CloudNativeCon, and managed several projects around inclusive communication strategies and accessibility. She is a serial tech event organiser and also holds many meetups. Floor has helped external communities adopt and enforce a Code of Conduct, and recruit a diverse line-up, and has also supported communities going online.  Mark Hazell: Mark is the organiser of the annual Devoxx UK developer community conference, and co founder of Voxxed. Voxxed is a knowledge sharing platform with the same DNA as the Devoxx conferences and a productive relation with Parleys.com. Focusing on Java, JVM methodology, cloud, future, mobile, and everything in between.  Erin Mikail Staples: Erin is a senior developer community advocate at Label Studio and also a technical adjunct professor at NYU. and stand-up comedian.

Useful links

Show sponsor: Common Room! Matthew Revell: DeveloperRelations.com DevRelCon London 2023 Kevin Lewis: Kevin's website Directus You Got This Mark Hazell: Devoxx Links Voxxed Days Erin Mikail Staples: Erin's Website Erin on YouTube Label Studio Label Studio Integrations DevRel(ish) Floor Drees: Floor on Mastodon Floor onLinkedIn DevOps Days Events

Transcript

Kevin: Hello everyone, and welcome to the DevRel Roundtable. My name is Kevin Lewis. I run developer relations at Directus, and today my co-conspirator is... Matthew: Hello. Yeah, I'm Matthew Revell and I do things to do with DevRel at Hoopy, and I'm really pleased to have you joining me today, Kevin, because it's I think the first time we've co-hosted something like this together. Kevin: And quite possibly the last! Matthew: Let's see how it goes. Yeah! So the topic today is, I mean, it's March, right? And in a normal year before the pandemic, March is 'oh, we're about to start doing conferences' for a few months before the summer dies down. And then, back into the Fall/Autumn, it's conferences again. And I thought it'd be good to speak to people who run conferences, such as yourself, and people who do participation in conferences on behalf of DevRel teams, again, such as yourself, and see if people have tips and that kind of thing. So, how can we make the most out of conference season for DevRel people? I think that's my aim here. But also what's different now, and I don't want to go into the pandemic too much, because I feel like we've already talked a lot about it. Kevin: Yeah, we're, we're in a very interesting time. There is a pandemic, which is still ongoing, but we are kind of seeing the other side of that now. Events are returning in person. The macro economic climate means a lot of teams are losing a bunch of budget or needing to be very, very pointed about how they spend it. And so on all sides of this equation, running events, applying to events, attending, sponsoring events, there's a bunch more scrutiny and consideration that needs to go into it. Matthew: And thank you very much to Common Room for sponsoring this episode. You can go to common room.io if you want to learn more about their platform for helping you to understand and measure your community. Kevin: We've got some excellent guests today. Shall we introduce them? Matthew: Floor Drees, how are you? Floor: Hi, I'm good. Yeah, and I love the comment about events coming up because I already had five events just this year, so I'm already fully in conference season. So yeah, my name is Floor. I'm the staff community program manager. I just recently changed from Staff Developer Advocate, so that's why I have some trouble with pronouncing the new title. I've been doing DevRel at various companies and I'm one of the organisers, or one of the core organisers, of DevOps days. I organise the DevOps days, Amsterdam and conferences. among many other things, but that's the one I'm going to mention. Matthew: We also have Mark Hazell. Mark, you run conferences, you've founded conferences. So tell us a bit about yourself, Mark. Mark: My name's Mark Hazell. I run Devoxx in the UK and also am co-founder of Voxxed Days conference series. Matthew: And we also have Erin Mikail Staples joining us all the way from New York. Erin: I'm Erin. I'm currently a senior developer community advocate at Label Studio, so, really exciting these days, especially with a lot of the recent innovations in machine learning and AI. Outside of that, I am a technical adjunct professor at NYU, teaching tech skills to non-technical folks and a comedian. So, I actually do host an open mic series called 'Laugh, Dammit!!!' in New York City, and I run the podcast 'DevRel(ish)' with Brian Rinaldi. So if you're interested in more DevRel-ishy things, come hang out with us. Matthew: Kevin and I touched on this in the introduction. Things are unusual right now. So how does the conference season look in 2023? And I want to ask you, Mark, if you don't mind first, because you've got your big event in London coming up in May. So from your perspective, how are things in 2023 as a conference organiser? Mark: It's a tough question. I think we need to look at it from two perspectives. One pre-pandemic and one post. From a post pandemic perspective, I feel like we're coming right the way back to where we were beforehand. Certainly looking at Devoxx UK, we're expecting levels of attendance to be back to pre- pandemic. But it's taken time and it's been really hard to get back to that space. I know in Europe it feels like we're beyond the real challenges that we had, whereas I know many of our colleagues in the US are still really struggling to get in-person audiences back to those levels. So certainly from my perspective, I feel really positive. I think the big difference now is whilst we are looking at attendee levels being back to where they were, we've got this crisis financially happening. As an organiser that makes things like sponsorship pretty difficult. What we're seeing is, I think it's a good opportunity for a lot of younger, smaller companies to come through and fill some of the space that some of the bigger companies previously were signing up to and filling up beforehand. That's certainly a trend that we are seeing. A lot of companies coming in, they're young, they're vibrant, they're really energetic, they're taking the kind of lower levels of sponsorship and they're trying to be really quite creative about what they're going to go out there and talk to people about. Whereas some of those household names that you'd expect to have been there are fighting with budgets. I guess if they're laying a load of folks off, they can't necessarily turn around and go 'okay, well look, we're also spending a load of money on this'. It's not good optics. So it's an interesting time of year, but like Floor, I'm three months into my conferences already and multiple events in. So it's nice to be talking about coming up to conference season, but it's already well underway for many people. Kevin: Do you mind if I follow up with a question? As a fellow event organiser, I have experienced exactly the same - attendance numbers ticking back up to where they were, cash is drying up also. Are you finding yourself as an event organiser, needing to adapt to the fact that funds are becoming a little more difficult to come across? Are you being a bit more savvy? Or are you still running things as expected and are those smaller companies actually filling your coffers to the point where they need to be in order to deliver the exact same event you were before? Mark: Well, I think if you work in community driven events and you are trying to keep your price point low for attendees, and yet you're still trying to deliver as much value to an attendee audience, you've got to be sitting there worrying about rising costs. Thankfully, I've got a great relationship with the venue that we work with in the UK. I'll talk purely from a Devoxx UK perspective for a minute. They're brilliant. We sat down, we hashed out this year's cost base really early. And so am I worried too much? For 2024, I'm really worried, but for 2023, not so much, just because we've got most of the cost base sorted really early with our suppliers. But we are seeing the cost of everything go up. And then we've got some interesting challenges that come along as well. And it'll be interesting to talk to some of you folks who are doing DevRel jobs to understand how you are being impacted. Certainly we're seeing some DevRel advocates that aren't able to get out there to speaker conferences because their budget's been completely cut. And that's got to make it really hard for you folks to get out there and do the basis of your job. Thankfully, we've got a really robust event that people want to come to every year. Even then, I feel kind of bad when you see some DevRel advocates saying: ‘Well, look, company's not paying for me, but I'm just going to pick the tab up myself this year’. So throwing that back to you, what are you finding as DevRel folks? Erin: We actually did have a very serious conversation about our planning this year when it comes to events and went back and forth about which events make sense for us. And so, for context, Label Studio is an open source data labeling platform. And a couple of things that are interesting about this space is that our user base is very broad. We have enterprise users, we have open source users, and we have a very large academic audience. And so those are three very different audiences some days, in very different industries. So finding an event that fits one group is kind of hard. Budgets are tighter than ever, so it's making sure that we're mindful of that. But also, we did have part of our conference schedule tracked. We're a two person community team. One's on the west coast and one's on the east coast of the United States. So it's kind of like 'if it's on the west coast, you're going, if it's on the east coast, you're going', and then if it's a speaking gig, whoever got the speaking gig is going. I will be travelling to Berlin for PIE Data Berlin later on. Some of the events that we did attend already this year, it was like: 'how do we measure if it was worth our time?' We're finding that the attendance has even been lower than years past. The meetups involve work too. As someone who's organised events, you don't want to blame the organisers, but how do we get people to contribute good value and good energy to it and is this the best strategy still? Asking the question, are events the right strategy? When we do attend an event, how much work is the satellite lifting of the events? We're going to PI Data and then Python this year and planning to do meetups around that, but do I really need a plan to do a meetup at the event, which means budget, time and energy. Or is it more valuable to just do a meetup that we know our audience is already going to attend outside of that conference? Kevin: Everything's time and money, though. It's not just sponsorship. A load of events have fixed costs, whether I'm going to a small meetup in a nearby city, or you are travelling far away. There's time implications. Your time has a cost attributed to it. Whether you're speaking or sponsoring, there is going to be travel and expenses to some degree, unless it's extremely local. And these all need to be factored in too, because they stack really quick. Sponsoring an event is sponsoring and then all the other costs almost are fixed regardless of your engagement type. Floor, did you have anything to add? Floor: Yeah, so I think from an event organiser's perspective, when we look at our CFP and, for most of the events, we'll go through some sort of anonymous round first and then look at the short list that you come up with. And then whenever you see a developer advocate title, you sort of assume that their company will pay for their travel if you're doing a community event and it's sort of on the topic for their business. But now we're noticing, and I'm not just speaking for DevOps space, but also for other events, that when you start confirming some of those speakers, they need to pull out anyway because they don't have their travel budget or they need to be more diligent with what events they can actually commit to. I also think that maybe it's a little bit like a downturn disguised as we're also being really diligent about sustainability. So we're trying to find some events that are more local and see if we can do train travel. Of course, that takes a little bit more time, so that's something that needs to be factored in. So from a DevRel team perspective, we're looking more at JAR packing, making sure that if you're going to an event anyway then maybe there can also be a customer meeting and a meetup. There could also be like all these other things, prioritising of course that you go to the full event anyway. In that case, I'm totally onboard. Whenever we can make it a bit more sustainable than we have been, because we have been travelling all the time everywhere, I think that's a good thing. So it's not terrible that we need to refocus a little bit. It's unfortunate that when we can't participate in events anymore that we would've otherwise because there are all of these restrictions. Mark: So if you can't participate in events the way that you were, how are you replacing that? Because I'm a big advocate of events, otherwise I wouldn't do what I do. I think if the pandemic taught us anything, it's that we all massively missed events, not just because they're great fun, but that human contact is one of the best ways to to reach your goals. It's not just about your internal goals, but how do you get that kind of validation and feedback from folks if you are not having the conversations face-to-face? Because I just find that people don't speak the same in online channels. Floor: Yeah. So maybe not replace, but do a bit of both and participate in the events that are hybrid or online and do a good job at that and not just turn on a live stream and have a little live chat that is not monitored at all, which happens way too often still, unfortunately. I actually did a whole study around how DevOps days chapters or cities' teams responded to the pandemic globally, and whether or not they hosted online events or hybrid events, and if they continue to do sort of a hybrid model, when they could go back in person. Obviously the answer is it depends, because cities and teams respond differently and value different things. Some found that they actually got a bigger audience now in person too because people were able to find out about these events and they would've otherwise not attended or maybe wanted to have that first experience with a DevOps days event, or like there's all kinds of reasons why people would go to an online event and couldn't make it to an in-person event. So, I don't know. I think, for yourself as a DevRel professional, having a schedule of both in-person events and some online events, is sort of where it's at. Erin: Floor, bouncing off your idea, I think that's a really great point to mention. We really thought about our ecosystem. One of the benefits is that we're a tool that can integrate with a lot of different partners. We're all in it together. We're all doing the thing. When we succeed, our friends succeed. We're kind of taking that mindset with everything moving forward. So we launched an integrations directory as kind of a base early on in this year with the intention to continue to expand on it and create. This is a way to continue to connect. So whether that's through tutorials, live streams, meetups, but it allows us kind of this connective tissue for us to integrate with any other tool that people might be using in our ecosystem, which expands us and gives us pretty concrete ways to collaborate with groups of people, whether in-person or not. But it allows us to focus the conversation around a specific workflow, a way of doing, much like you'd be doing at a conference, but gives us that same talk and provides actionable execution-type result. Kevin: There is also a slightly more cynical way of looking at this perhaps, which is that you spend all this money to go to an event, all of the combined cost - sponsorship, t and e swag, anything else, time, anything else that's attributed to it. And ultimately it's a cost per head exercise. Not only is it a cost per head exercise, it's a cost per head exercise versus the ability to generate revenue off of those conversations that you have. It's always a relatively small number of people for the cost versus other forms of perhaps more traditional marketing exercises. I think one of the big challenges we have as developer relations practitioners is perhaps in the past where money was more free flowing, a little less attention was paid to the oversight as to the money spent versus the clear line to the revenue, perhaps now it's a lot more clear. For that same money you can do a lot more traditional marketing that has very easily measured results. So what you may do instead of events is more traditional marketing exercises. There's that human touch which isn't quite the same, but you can still do human touch activities without the swag, without the t and e, the travel and expense costs, and sponsorships generally being a bit lower. So maybe I'm the cynic here, but that's also worth consideration. Matthew: I'd want to drill down though into that point you touched on. I think there is a qualitative difference - and I'm not making a value judgement, I just think it's different. The kind of contact that you have with someone at an event compared to whether they saw your ad in a newsletter that they follow. I'm not saying you're suggesting there isn't, but does anybody in this group have a formula that they use to judge whether an activity is worth the cost? Floor: Actually, maybe. We do have a database of all of the events that we went to in previous years, and so we'll look at those because we do a little feedback form which will be upgraded to an event, like an actual trip report, sometime soon, I hope. The form doesn't really capture everything. You should fill it in right after an event, but most of the stuff actually only materialises after a couple of days, weeks, months. So then you would need to go back to the Freeport form, and that doesn't really work. But we definitely do look at the events that we've been at when we're looking at what events we want to consider for next year. So there's a lot of content on the form so that you can say: 'Oh, well these are the questions that were asked, these were the kind of conversations and these were some of the outcomes'. For instance, at a recent event I had a conversation with someone who was sponsoring KubeCon. We didn't necessarily have a budget to go to it, but they have invited us to speak at their little booth thing. And then certainly somehow it makes sense to go there, especially when you're based in the countries as I am, which is fantastic. So there needs to be a lot of storytelling. It's not necessarily like: 'Oh, this many people showed up for my talk'. For all of these forms, you also need to count heads that are in the room really quickly before you start your talk. But I mean those impact stories that explain why it was useful for you to go to the event. But yeah, I do find myself needing to explain why we should go to an event, whereas before it was much easier. My paper got accepted or my talk got accepted, so obviously I'm going. Mark: This kind of brings us down to the whole qualitative versus quantitative argument, and that's something that's been a hundred per cent difficult to quantify within developer relations, since the term developer relations was created. And Floor, what you said about having to go back and fill forms in three months later, realistically, do you do that? Do you track that pipeline through and how long do you keep tracking it for? Ultimately you're going to see results from an event and you're going to look at them. We're too focused on numbers I think as an industry anyway, but the whole marketing industry's been focused on numbers forever. You have to segment the activities out. And so a replacement like for like is really difficult to qualify here because I think that I'm a big advocate of small events. Devoxx UK, we're a mid-size event, we're like 1200. We go out to Devoxx Belgium and it's like three and a half thousand. But the V Day series, when one of those starts up it might be 300 people. As it grows and gets bigger, it might grow up to 5, 7, 800 people. And you see a real difference as you go through. And I personally love going to all different types of events, but some of the best experiences I have are when I'm at a 3, 400 person event. I can relate to those people and they can relate to me much better, and I'm more likely to see positive results out of it. I'm more likely to grab a crowd of people at the end of a talk and be able to talk to them. Erin: One thing that I've learned, especially over the last year or two, has been the prioritisation of events just can't be an event anymore. And it's same as the content article can't just be an article. The article has to be the article and how are you promoting the article and who's reading the article? And then, how do you share the article and then, what collaborations come on top of the article? Or when you do an event, it's who are you meeting at the event? Okay, how are you planning what collaborations came because of that event? And I've shown that that has been part of my event reporting process more and more recently. Even with events like this, I'll be like: 'Okay, here's what I did, here's the things that I'm doing, here's the people that I'm meeting, here's the discussions that this facilitated, which eventually led to this', and showing that pipeline, almost in a weird little convoluted roadmap way. Even though it's not a number or data set, it does make sense and helps highlight the importance of even those smaller interactions. Mark: I think as an organiser, we're trying to cover both sides of this this year. So we've got 1200 coming to the event, that's pretty big. We've split into six rooms through the course of three days. So that's amazing, but I'm always kind of conscious of two things. One, that doesn't do the small group proposition that we are really looking for. And secondly, and this is allied with that, is we open a call for papers six months prior to the event. It closes like four and a half months prior to the event. So much changes so quickly that how do you keep your content relevant? Although it's relevant, there's still new shiny coming along or there's new thinking coming along and we've chosen our content four months beforehand. So this year we're playing with having an non-conference on site as well. Matthew: I think everyone here either does or has organised conferences so we can all chip in, but as a conference organiser, what do you look for from contributions, from submissions from DevRel people? Because Floor mentioned earlier that submissions from DevRel people come with certain caveats. I've seen plenty of people put on Twitter: 'Ah, if there's a developer advocate giving a talk, I'm out of there. I'm not listening to that'. So what advice would you give to developer relations people who are submitting talks? Mark: So firstly, I think that the attendee who looks at a talk title and a speaker and says: 'Oh my God, that's a DevRel advocate I'm out of here' is very shortsighted. That's the first thing I would say. We got 930 proposals this year in our CFP. That's a lot and there's some that are really great and there are some that are not so good. What are we looking for? I think from developer advocates what we're really looking for is honesty, that you don't want a product pitch to come across. Well, actually if there's a product pitch, it's pretty easy to sniff out in a talk submission and it's pretty easy therefore to just press the 'respectfully decline' button. But yeah, real honesty and to think: 'Okay, when I'm putting a talk submission together, I want people to come at it from the perspective that these are the problems that users have brought to me and these are the solutions therefore that people need to understand'. That's probably my number one request - be solutions focused, don't be product focused. And if you can bring real world examples - I know it's not always possible because of confidentiality with clients etc - but any real world examples, that stuff is gold when it comes to developers sitting in the audience saying: 'This is what I want to listen to'. So, a big healthy dose of honesty and ultimately make sure that you're talking about the right thing to the right audience. Oh, and don't copy paste, because different conferences have different audiences. Matthew: That's why we stopped using a paper submissions platform for DevRelCon because it was just too easy for people to go click, click and then they submit their conference talk to ten different conferences in ten minutes without really having to worry about whether it was appropriate or not. Floor: Yeah, literally why for DevOps days we've switched to pre-talks because it's not possible to just shoot to a lot of different conferences because we got that all the time. I love submissions like 'how to do typescript for a DevOps days conference'. Like, but why though? Erin: I'm going to approach this from two different lenses - one submitting for a conference, and then one having reviewed submissions. So from both lenses here, first off, I think the biggest thing that is a pet peeve as someone who has been very fortunate in the last year or so to have been asked more and more to join and speak, which is great. I think if you're a conference organiser, really think about what is this bringing to me? And how is this person contributing to my audience, and is there actually interest here? Also take the diversity card. I was reached out to this month for the sole fact that I was a female. They didn't look at my website history, job history at all. They were like: 'What do you wanna talk about? We just were really excited because you seem to have a presence and you are a woman'. And I was like: 'Okay, cool. I'm not interested. Like I'm out'. You can do 30 seconds of homework to determine if this is a good fit or not. I've started to be a little more diligent in that homework as a speaker there. And I think if you're organising, think about diversity. How are you keeping your panels diverse? How are you thinking about including things? How are you doing things like including pronouns or preferred languages? DevRelCon, you guys had the Latin America version this year, which is really exciting to see and I'm starting to really see a lot more diversity in that, which is super exciting. The other thing as an organiser is, again, don't copy paste talks. On top of that also it's really frustrating when you get someone and they don't appear interested in your event and you've worked really hard and they've made a big deal about your event, but then they don't really come across as interested. It's a two-way street. We're all in this industry together, whether you're an organiser or participant, and it takes 30 seconds to retweet something or to share it on LinkedIn. Just do it. As someone who's pitching, I think the biggest thing is, we always get a lot of pressure as DevRel advocates or community folks to be very brand or product oriented. I'll be transparent. There's no way my boss would let me to go to a conference and be like: 'Erin, let's go talk about your comedy career for ten minutes at a developer conference'. But, how can I think about how it's related to my day job or tied in? Be yourself and be authentic. And then my last kind of personal one is disclose your bias. Everybody has bias, disclose it. That may include who's writing the cheque, who paid for you to be there, who else you're paid for if you do freelance work on the side. If you have prior affiliations with any company brand or organisation mentioned in your talk, shout it out, disclose that. And that's just good ethical practices. I have that both on my website and I try to just close it in my talks. 'I know I'm here today paid for by this, but this is also possible within other tools'. Kevin: If I may, as an event organiser, one of the things that I really want to see is that the talk is highly relevant to the audience I am gathering. You really need to know who the audience is. In the same way that as developer advocates attending, speaking out and sponsoring events, we have a really high degree of scrutiny at the moment as to how money is being spent and whether we should participate, exactly the same is happening to people attending. Whether that's because they have limited time, deciding which events they're able to spend their budget on to go to events. If you are trying to deliver a talk and it isn't going to be highly relevant to that audience, I'm not going to to do it because it devalues the overall event in the eyes of the attendee, then I get less attendees. So just the same way we have that scrutiny as people delivering talks at events, sponsoring them, attending them, spending any amount of resource on them, we have to do the same as people submitting talks as well. I think copying and pasting talks is fine, as long as it's the right audience for those talks. I think that was alluded to, but just to be more explicit there. As long as it's relevant to the audience, it doesn't matter. If anything, that is a very efficient way to spend your time. If you write a talk highly specialised for the audience that is relevant to your org and then you go and seek out specifically that audience. The mixed audience thing is challenging I think in this age of DevRel, because ultimately it might be fine, as Mark said earlier, to have a smaller audience, but it has to be a smaller audience of a buying persona. Otherwise it's just a smaller audience of people who don't drive revenue and don't help you justify your job. Mark: I don't know about you folks, but I see a lot of talks that are given for kind of six to eight months by a person. Then they'll go: 'Right, okay, that talk's done. I'll go back to the drawing board and write the next one'. If that talk doesn't change over those six to eight months, then actually as an organiser, because most events are recorded and there's such availability on YouTube for free now, then I want to know that it's going to be a bit different six months after the last time I saw it. Matthew: As a sponsor, and I guess we've all done booth duty here, as someone who's there in this sort of liminal space of you're on sale for the company, but you're also trying to retain your own authenticity and credibility. For people who are coming into this for the first time, because there's lots of people who come into developer relations and this might be their first in-person conference season, where a marketing or a sales colleague says: 'Hey, can you do booth duty?' What are the ways that people can retain some sense that they are doing the right thing, but as a developer relations person and to the community, while also representing their brand? Erin: I have a lot of strong thoughts on this one. First off, just again, disclose your bias, be honest about it, but also don't be afraid to say what you think is cool. And I think so many, in this world of tech hypy trends, leave our personality at the door sometimes because we're scared to admit that we don't like something or don't know something or that something is not interesting, but that's super cool. Since when did we have this attitude that we're too cool for things? I want you people to be into things. Share that excitement. Share your own excitement for what you do. It doesn't have to be the rehearsed sales pitch. I don't think any salesperson actually first off has ever given me a sales pitch because they know I won't follow it. I'm probably a little stubborn like that. But at that point, you can be yourself and you can share why you're excited about something, but you can also be authentic in the other things that you're excited about. Floor: Yeah, I also love your comment before about celebrating conferences and the work that they do, because organisers do a lot of work. Don't just sort of show up for either your talk or your booth duty and do this schpiel, but actually be excited about things and be courageous about being excited about things. I think that's spot on. That way you can definitely be authentic if your authentic self is an excited person. So, for me, that's totally goes. When I do booth duty, I mostly try and ask people a lot of questions because I'm absolutely curious why they're at an event, what they're looking forward to, what they're hoping to get from the event. Maybe if they stop by our booth, if they already know the company, just ask a lot of questions. I want to get feedback from people. I want to figure out where we are in our sort of awareness journey. Also I'm just authentically interested in what brings people to an event. Kevin: I just want to riff off of what Floor just said. Ultimately, our job is to drive revenue, might be now, might be later. You need to understand who the person coming to you is and what their motivation for coming to you is before you even start. It's really easy to just go with the schpiel. I got the 22nd version, I reel it off every single time. But if I know why you are here, I understand whether that's appropriate, whether I should change it up and talk to you differently because you are coming with a different set of experiences or expectations. Or if you're just not interested, that's cool, I can still spend time with you as a fellow developer talking about whatever it is you find interesting, or I find interesting, or what we collectively find interesting. But then I know that you are not going to meet the ultimate goal of why I'm at the event. And that's cool. There is also the need in getting the most out of events to weigh all of these conversations correctly. You have a big group of people in front of you, you're not sure who you are going to spend ten minutes with as opposed to two minutes with. Understand what they're there for. However crude it may sound, you need to invest more time into those conversations and relationships that turn into some kind of impact for the business, for us to all have our jobs in 6, 12, 18 months time. Mark: I think use your time wisely as well. I mean, if you're on booth duty, realistically you're talking about maybe breakfast, some kind of welcome period, two coffee breaks and a lunch. So that's about two and a half hours of your day at a conference. The rest of the time, the exhibition area is probably really quiet. Slip away, go to a talk - this is my personal thing anyway - slip away, go to a talk that I'm actually interested in and have a conversation with the people sitting next to you about that talk and the content that's going on there. If it relates back to what you do on a day-to-day basis and your company and you can carry that conversation on back at the booth, then encourage them to come by and see, but softly, softly. That's actually much more valuable as a conversation than sitting on the booth during dead periods where there's nothing going on and everybody else is in a conference session. Erin: I was just going to reiterate, take care of yourself. I know that the post-conference plague is real. I am neurodiverse. I find myself getting very overstimulated if I don't have an hour or two at the end of the day by myself for an hour. I use a lunch break to be by myself, no colleagues, no coworkers. No, get away from me and let me sit in my own circle in my quiet space. I'm actually not as extroverted as people think. So you have to take care of yourself and that comes first because you won't make it through the conference or the days after without it. Mark: That's such brilliant advice. I applaud you for saying it. It's such brilliant advice and everybody should do so whether they're doing this from a DevRel perspective, an organiser perspective or just an attendee. Look after yourself and take time for you. I quite often do this even whilst running a conference. I'll take the little walkie talkie so that I'm in contact, but actually I'm laying down doing a 20 minute yoga session in my hotel room next door. The beauty of modern communications is that I can hear what's going on and if I really need to be contacted, I can be. Floor: Ideally you'll have some people to share the booth duty with, which should be good. Sometimes you'll have booth duty and then also one of your colleagues is speaking, and so you can do a thing where the person who is a speaker can maybe say that they can do prolonged Q and A at the booth, so you'll have a little bit of time to do other stuff while they take the booth. So hopefully, it's something that you can share because otherwise it's a long time to stand up straight, which is also not great. Yeah, a lot of time to be very social and that's actual work. Mark: If you are just getting into DevRel for the first time, or maybe you've been in it for ages and you haven't done this, please come and talk to the organiser. If you are at an event that I'm running, I want you to come and say hello. I want you to come and tell us what you think, but also I want you to immerse yourself in the experience and give full feedback as well, because that's the only way that organisers get to understand how they can improve. But also it's great relationship building, and who knows what we're all going to be in the future. I know as somebody who runs around sometimes looking like a bit of a headless chicken at an event, I don't always stop to talk to everybody that I would like to talk to, but if they approach me, I'll just drop everything and make sure that I've got time. Floor: I think we're creating events together - the organisers, the speakers, the attendees and so. Figure out if you're going to an event anyway and you're speaking there, make sure that you attend talks, especially when those talks are on a similar subject as your talk, so you're not doing a lot of repeating. Make sure that you can reference other talks that are on a similar topic and sort of uplift your fellow speakers that way. Figure out if you can do anything to volunteer at the event. Maybe they need a room host, because otherwise they'll have organisers do the MCing and not all of the organisers actually really enjoy doing that, so maybe that's something you can do. Uplift your fellow speakers by tweeting or whatever we do nowadays about their talks, that's a good way. I try to fully immerse myself in whatever conference I go to because I know I would appreciate it if my speakers did that. If there is a photo booth, I will definitely go to the photo booth and take people with me. If there's a raffle, I will participate in a raffle. Whatever you organise, I will just participate in it, because I know that I would appreciate it if it were the other way around. Matthew: Cool. Well, I think we need a second edition where we get into some of the practicalities, particularly for newer people to DevRel. I remember standing in a conference booth in Zurich with all of my stuff stuck in customs and post-it notes behind me trying to recreate the booth that I should have had. There are lots of lessons that people who've done it before all know now and we just don't really have a guidebook on how to go and be at a conference as a sponsor for the first time. Any closing thoughts? Mark: Be good. Have fun. Enjoy the conference season. Floor: Wow. Hydrate. Erin: Don't be a stranger. Like we're all living in this world together. And guess what, if you think that you're being awkward or weird, we all probably feel like we're awkward and weird, or maybe that's just me and I'm reflecting on it. That's part of it. And you're not alone in feeling awkward and weird no matter where you're at in your journey. Kevin: I will continue to beat the drum of remember why you're there and still get your work done. Still prove your value in your events. There are going to be some that don't meet the value that you require, but you need a decent average in order to continue to have an event program in your DevRel team. That doesn't mean that's all you do. You are not a robot designed just to meet your goal. And remember that we have techniques and ways of achieving goals, which are still authentic to us and authentic to our discipline. But you have a goal and you must meet the goal, otherwise you will not get to do events for very long. Matthew: Well, thank you everyone. Where can we find each of you? Mark, where can people find DevOps UK? Mark: At Devoxxuk on Twitter, on LinkedIn, on Facebook. Just go to the website devoxx.co.uk and the coordinates are there. D E V O X X Matthew: Erin? Erin: Yeah, you can find me personally - Erin Mikail across all the platforms. Or at erinmikailstaples.com, all the stuff on YouTube @erin.tube or check out what I'm up to at Label Studio at labelstud.io, or our latest integrations library by labelstudio/integrations or come hang out with us at DevRel(ish) on YouTube. Kevin: Floor? Floor: I guess mostly on Mastodon these days as Floor D, or Floor Drees on other platforms. I'm the only person with that name, so it should be easy to find me. Then for DevOps days, it's DevOpsdays.org/events. There are so many events planned for this year, so please find one that is close to your physical location and join one of those events because they're really unique in their format. Matthew: And Kevin? Kevin: You can find me personally at lws.io, which links out to all of my social links. You can find more about Directus at directus.io, or my own event series about core skills at yougotthis.io. And Matthew? Matthew: Well, thank you for asking. I'd like to direct you to developerrelations.com where we have all sorts of content for people in DevRel and DevRelCon London is taking place September 7th and 8th at Code Node. CFP is open. I would like to say that if you are looking for other DevRel people to collaborate with, it's a really good place to be. But yeah, thank you everyone for taking part and see you on the Internet, and hopefully in real life at some point as well.]]> 00:46:15 <![CDATA[Data driven community management]]> Mon, 27 Feb 2023 20:18:10 +0000 DeveloperRelations.com https://permalink.castos.com/podcast/37381/episode/1425891 https://devrel-roundtable.castos.com/episodes/data-drive-community-management Watch the video on YouTube.

Transcript

Transcript coming soon]]> full 7 2 false Watch the video on YouTube.

Transcript

Transcript coming soon]]> 01:04:55 <![CDATA[Getting your first job in DevRel]]> Tue, 21 Feb 2023 15:01:06 +0000 DeveloperRelations.com https://permalink.castos.com/podcast/37381/episode/1419242 https://devrel-roundtable.castos.com/episodes/getting-your-first-job-in-devrel Common Room for sponsoring this episode! Watch the video on YouTube. https://youtu.be/uVU6V1VqOB4

Transcript

Coming soon.]]> full 16 2 false Common Room for sponsoring this episode! Watch the video on YouTube. https://youtu.be/uVU6V1VqOB4

Transcript

Coming soon.]]> 01:08:26 <![CDATA[Re-engaging communities after a break]]> Mon, 13 Feb 2023 10:35:52 +0000 DeveloperRelations.com https://permalink.castos.com/podcast/37381/episode/1410537 https://devrel-roundtable.castos.com/episodes/re-enaging-communities-after-a-break See the video on YouTube. https://youtu.be/_W7DFqHfPew

Transcript

Transcript coming soon.]]> full 5 2 false See the video on YouTube. https://youtu.be/_W7DFqHfPew

Transcript

Transcript coming soon.]]> 00:58:29 <![CDATA[DevRel New Year's Resolutions]]> Wed, 18 Jan 2023 09:14:44 +0000 DeveloperRelations.com https://permalink.castos.com/podcast/37381/episode/1380671 https://devrel-roundtable.castos.com/episodes/devrel-new-years-resolutions Common Room for sponsoring this episode. Watch the video on YouTube. https://youtu.be/D5EPslzL0vE]]> full 4 1 false Common Room for sponsoring this episode. Watch the video on YouTube. https://youtu.be/D5EPslzL0vE]]> 01:04:15 <![CDATA[What we learned from the pandemic]]> Wed, 09 Nov 2022 09:44:53 +0000 DeveloperRelations.com https://permalink.castos.com/podcast/37381/episode/1314990 https://devrel-roundtable.castos.com/episodes/what-we-learned-from-the-pandemic-1 Almost three years on from the first known Covid-19 case, the pandemic's impact on the world as a whole is a story of individual tragedy combined with global change. For DevRel, the pandemic forced both a tactical and strategic rethink. In this roundtable, co-organised with the Berlin DevRel meetup, we look at the response to and learnings from the change brought about by Covid-19. Watch the video or catch the audio podcast using the player above as host Carla Teixeira (Miro) brings together a panel of:
  • Jonan Scheffler (Parity Technologies)
  • Celine Buchholz (Camunda)
  • Richard Süselbeck (Vonage)
  • Alessandro Palmieri (Google).
https://youtu.be/nFDOH5UG0WM  ]]> full 3 1 false Almost three years on from the first known Covid-19 case, the pandemic's impact on the world as a whole is a story of individual tragedy combined with global change. For DevRel, the pandemic forced both a tactical and strategic rethink. In this roundtable, co-organised with the Berlin DevRel meetup, we look at the response to and learnings from the change brought about by Covid-19. Watch the video or catch the audio podcast using the player above as host Carla Teixeira (Miro) brings together a panel of:
  • Jonan Scheffler (Parity Technologies)
  • Celine Buchholz (Camunda)
  • Richard Süselbeck (Vonage)
  • Alessandro Palmieri (Google).
https://youtu.be/nFDOH5UG0WM  ]]> 01:03:00 <![CDATA[DevRel tips for Hacktoberfest]]> Fri, 30 Sep 2022 10:27:06 +0000 DeveloperRelations.com https://permalink.castos.com/podcast/37381/episode/1285157 https://devrel-roundtable.castos.com/episodes/devrel-tips-for-hacktoberfest With Hacktoberfest just around the corner, DevRel teams across the world are preparing for an intense month of creativity, fun, and hard work. In this roundtable, Digital Ocean's Hacktoberfest organiser Phoebe Quincy joins hosts Matthew Revell and Suze Shardlow to share her advice for the 2022 edition and how this year's focus is on encouraging no code and low code contributions. Appwrite's Haimantika Mitra and Aiven's Floor Drees discuss their approach to Hacktoberfest, including lessons learned, while GoDaddy's Courtney Robertson talks about bringing the Wordpress project into Hacktoberfest for the first time.   https://youtu.be/sAjrcKufge0]]> full 2 1 false With Hacktoberfest just around the corner, DevRel teams across the world are preparing for an intense month of creativity, fun, and hard work. In this roundtable, Digital Ocean's Hacktoberfest organiser Phoebe Quincy joins hosts Matthew Revell and Suze Shardlow to share her advice for the 2022 edition and how this year's focus is on encouraging no code and low code contributions. Appwrite's Haimantika Mitra and Aiven's Floor Drees discuss their approach to Hacktoberfest, including lessons learned, while GoDaddy's Courtney Robertson talks about bringing the Wordpress project into Hacktoberfest for the first time.   https://youtu.be/sAjrcKufge0]]> 00:55:07 <![CDATA[DevRel in a Downturn]]> Thu, 28 Jul 2022 15:10:26 +0000 DeveloperRelations.com https://devrel-roundtable.castos.com/podcasts/37381/episodes/devrel-in-downturn https://devrel-roundtable.castos.com/episodes/devrel-in-downturn Developer relations is often one of the first functions to go when a company needs to make savings. If we're heading into a recession, what does that mean for DevRel more generally? In this roundtable, Jono Bacon, Jocelyn Goldfein, and Sam Ramji discuss how DevRel teams and individuals can prepare both their programs and themselves for a downturn. https://youtu.be/qQ1m8KjXB-M

Transcript

Matthew: Okay, welcome and hello to this round table about developer relations in a downturn. My name is Matthew Revell and I work for Hoopy. Bryan: Hello, I'm Bryan Robinson. I work at Orbit. Matthew: Bryan, do you want to share a little bit about Orbit who are kindly sponsoring today's round table? Bryan: Sure. So first and foremost, this is like a really super important topic, especially in current economic climate. So we're incredibly happy to be able to, to help make it happen. A couple things I do wanna mention first orbit is a community growth platform. So we do things to help DevRels and community managers build up their community, strengthen their community, but we also really like to create value and like talk best practices. So I wanted to mention a few resources and content that we have available that I think speak to this topic a little bit. So first we've got a print magazine -- print's not dead -- called Gravity. And our first issue was around metrics, analytics. You can find out about that at orbit.love/gravity. And then we ran a conference a couple months back and there were three talks I think, that speak to this. So you can find out more at orbit.love/nexus. But the talks are "Data led community programs" with Jeremy Meis, from CircleCI, "Scaling and thriving community" with Peggy Rayzis from Apollo. And then I gave a workshop on demonstrating community value in DevRel value our Orbit model, our open source model. So overall we just wanted to make sure this panel could definitely happen in the best way it could, but those are some additional resources you might wanna check out. Matthew: Right. Thank you. So as you say, this isn't really a discussion, I guess, any of us wants to be having, but it is a discussion that I feel needs to happen. We've seen multiple layoffs recently in tech many of which affect developer relations or developer community developer experience teams. And so the question comes, how do we prepare ourselves for choppier economic times, even if it's not coming now, it will come at some point. So we probably need to think about how we as individual DevRel people, I guess, insulate our careers somewhat, or prepare ourselves for potential change in our careers, but also within the DevRel programs that we're involved in. How do we make sure that they are contributing what they need to, to the company in order that we give our companies the best chance of survival, but also to make sure that DevRel programs stay around. Bryan: Yeah. Even in the best of times, DevRel is one of those things that we're always kind of scrapping and, and being scrappy to try to prove value in. In the worst of times, that's super important. Matthew: For sure. Yeah. so we joined today by three guests who I think will have some really great insights. So let's introduce our, our guests. We have Jono bacon is joining us. Hello, Jono, how are you? Jono: Good. It's good to be here. How are you guys doing? Matthew: Good. We've also got Jocelyn Goldfein who is joining us. Hello, welcome Jocelyn. Jocelyn: Hi everybody. Matthew: Thanks for joining us and Sam Ramji as well. Hello, Sam, how are you doing? Sam: I'm doing great. Good to see you all this morning. Matthew: Let's go to our first question then. It seems like a recession is coming, but I guess the quest...]]> full 1 1 false Developer relations is often one of the first functions to go when a company needs to make savings. If we're heading into a recession, what does that mean for DevRel more generally? In this roundtable, Jono Bacon, Jocelyn Goldfein, and Sam Ramji discuss how DevRel teams and individuals can prepare both their programs and themselves for a downturn. https://youtu.be/qQ1m8KjXB-M

Transcript

Matthew: Okay, welcome and hello to this round table about developer relations in a downturn. My name is Matthew Revell and I work for Hoopy. Bryan: Hello, I'm Bryan Robinson. I work at Orbit. Matthew: Bryan, do you want to share a little bit about Orbit who are kindly sponsoring today's round table? Bryan: Sure. So first and foremost, this is like a really super important topic, especially in current economic climate. So we're incredibly happy to be able to, to help make it happen. A couple things I do wanna mention first orbit is a community growth platform. So we do things to help DevRels and community managers build up their community, strengthen their community, but we also really like to create value and like talk best practices. So I wanted to mention a few resources and content that we have available that I think speak to this topic a little bit. So first we've got a print magazine -- print's not dead -- called Gravity. And our first issue was around metrics, analytics. You can find out about that at orbit.love/gravity. And then we ran a conference a couple months back and there were three talks I think, that speak to this. So you can find out more at orbit.love/nexus. But the talks are "Data led community programs" with Jeremy Meis, from CircleCI, "Scaling and thriving community" with Peggy Rayzis from Apollo. And then I gave a workshop on demonstrating community value in DevRel value our Orbit model, our open source model. So overall we just wanted to make sure this panel could definitely happen in the best way it could, but those are some additional resources you might wanna check out. Matthew: Right. Thank you. So as you say, this isn't really a discussion, I guess, any of us wants to be having, but it is a discussion that I feel needs to happen. We've seen multiple layoffs recently in tech many of which affect developer relations or developer community developer experience teams. And so the question comes, how do we prepare ourselves for choppier economic times, even if it's not coming now, it will come at some point. So we probably need to think about how we as individual DevRel people, I guess, insulate our careers somewhat, or prepare ourselves for potential change in our careers, but also within the DevRel programs that we're involved in. How do we make sure that they are contributing what they need to, to the company in order that we give our companies the best chance of survival, but also to make sure that DevRel programs stay around. Bryan: Yeah. Even in the best of times, DevRel is one of those things that we're always kind of scrapping and, and being scrappy to try to prove value in. In the worst of times, that's super important. Matthew: For sure. Yeah. so we joined today by three guests who I think will have some really great insights. So let's introduce our, our guests. We have Jono bacon is joining us. Hello, Jono, how are you? Jono: Good. It's good to be here. How are you guys doing? Matthew: Good. We've also got Jocelyn Goldfein who is joining us. Hello, welcome Jocelyn. Jocelyn: Hi everybody. Matthew: Thanks for joining us and Sam Ramji as well. Hello, Sam, how are you doing? Sam: I'm doing great. Good to see you all this morning. Matthew: Let's go to our first question then. It seems like a recession is coming, but I guess the question we should open with is, is one coming or is it already here? And Jocelyn, as you work in an investment capacity, I suppose you have a good overview of what's happening in the market. Jocelyn: I am certainly happy to share one person's perspective. You know, I think we haven't met the kind of official, you know economic indicators for a recession; two quarters in a row declining growth that hasn't happened yet. I think everybody sitting around the table in investment circles and CFOs are fully expecting that to happen in sometime in the next four to six quarters. And there are people projecting it to be short, there are people projecting it to be long. It's Anybody's guess, but it's there's enough indicators that it's a smart time to brace yourself and be thinking ahead. What I will say has already happened is that boards and CEOs and CFOs are all making those preparations. So they're all thinking about if they're a sort of venture backed private company, the ones I sit on the boards of, they're all thinking about how do we extend runway? Jocelyn: How do we make our cash last, as long as possible? How do we add cash to the business right now, if we can, and sort of watching their plan like a hawk, but I'm already seeing companies, revise plans downward sort of have lower expectations of the revenue they're gonna drive in the next quarter. If you're a public company. I mean, we've seen the public companies are already taking actions, freezing hiring, starting layoffs, and those are all in the same spirit of what private companies are doing. And in these moments cash is king, not to be too sobering, but that's the reason we're having the round table today. Prepare for the worst. And then you can only exceed your expectations. Matthew: Sam, as chief strategy officer at DataStax, what are you doing to accommodate this new reality? Sam: Well, we've fortunately just raised $115 million in, a round led by Goldman Sachs. We had an up round despite the decline in macroeconomic conditions. And I think that has everything to do with the fact that companies no longer have an option but to digitize their way out of a recession. So you have to look at what is the strategy of the customers you're serving. So we've gotten very focused on making sure that we're not part of cost saving measures. You know, that's always a place where you're already in a conversation where you're gonna get squeezed for more and more discounts and possibly out of the deal because a huge cloud provider could come along and say, you know, what, if you just use our version of this software, you know, we'll cut 5% off of your bill. Now they're paying a hundred million dollars a year to GCP or Azure or AWS. Sam: And so 5% savings, all of a sudden looks like $5 million. Well, that's more than we charge them per year. So you don't wanna be on the cost saving side. You really have to be on the growth side. You have to be focusing on where's the line of business working to make sure that their company not just sticks around, but thrives in the downturn. And I think that's all about making sure that you're focusing on innovation internally. We're being really smart about the money we have. We're increasing efficiency. We're asking, what can we do differently? What do we need to stop doing? It's very easy for us to get used to growth as a constant. Money is free. We'll just spend and worry about the accounting later. But the wonderful thing about a downturn is it gets you that sobering opportunity, the word that you mentioned before "sobering", okay, what have we been doing over the last couple years? What have we become numb to that we shouldn't be doing? And where can we just wake up and stop? So I think efficiency is key and understanding that we should always be optimistic about technology as being the way that companies are gonna power themselves out of the downturn, cuz we're still in a digitization phase of the economy. Bryan: So you mentioned growth versus efficiency. Would you also kinda see that as explosive growth versus sustainable growth? Or is that a different concept? Sam: I think we have to continue to look for explosive growth. If you look at the companies that continue to echo today, many of them came out of the 2008, 2009 downturn. So we can have kind of a shrinkage mindset and worry about, oh my gosh, the sky's falling. What's gonna happen next. We're gonna have to manage things professionally the way that we manage them anyway. But if you can have that new vision, if you can say, you know, what surprised us about the breakout growth that we saw, maybe at small scale with the particular class of customers that we didn't expect, how are they using our software? Can we be nimble? And can we go after them hard? Can we create new campaigns? Can we go and ask those questions and get more people to use our software in that way? Sam: There were a lot of surprises in '08, '09 and we still use the technology of the companies that that built themselves during that time period. So I think explosively has to be the mandate. Jocelyn will point out, of course, that the rule of 40 is important. So it really depends on whether you're a public company or a startup. Where are you in your fundraising cycle? And are you targeting an IPO? Like if you were targeting an IPO based on your explosive growth in 2022, I think most people would caution you that maybe this is not the year to go out. If you're a public company, though, consumption is king, so you're looking for sustained growth and you know that that's gonna come from DevRel, not to beg the question that our whole conversation's about today, Matthew: For those that don't know, can we look at what the rule of 40 is? Sam: Sure. So the rule of 40 is a way to think about the appropriate valuation of a company. It used to be in recent times we saw Snowflake and HashiCorp go public at valuation multiples of about 52 times revenue, which is pretty eye popping, right? We're talking like 80 billion valuation for Snowflake. That's based on just amazing runaway growth, right? The top line growth was over 140%, I think for Snowflake when they had that valuation rule of 40 then has a much more sober perspective. And it says basically the profitability of your company measured in a percentage plus the growth of your company measured in a percentage should add up to 40 or more. And if you're over 40, then we think you probably have your stuff together and you know how to manage the company. And you can kind of go up with the upturns and you can weather the downturns. So it's a way that we start to say growth at any costs might not be so favorable. Now let's take a look at growth balanced with profitability. Matthew: Thanks. And Jono your work brings you into contact with many different companies and developer communities and developer relations programs. Are you seeing any differences? Jono: I'd say yes. Yes and no. I mean, the, the elements that Jocelyn and Sam were just talking about around, you know executives are preparing for the worst is definitely happening. Seeing freezing hires happening everywhere. What I'm not seeing right now is any significant reduction of DevRel teams and staffing. I think many companies see the value in this work and the importance of this work. You know, if you're gonna go through a recession, you can't just stop engaging with your audience. It just doesn't work that way. So I think people realize this, however, what I do think is happening, and I think this is actually a good thing is there is an increasing level of scrutiny around the impact of every role in a business. And and I think that's important for DevRel as well as anything else. Jono: The challenge I think with DevRel is that I think sometimes either there hasn't been a culture of scrutiny in some companies, in some cases. And then in other cases, there are also DevRel folks who struggle with being able to show to an executive team the value of the work that they're bringing. You know, they may be bringing an enormous value, but they can't necessarily translate it. And I don't mean that in a demeaning or a condescending manner, it's just, it's something that I see quite regularly with my clients. And I think bridging that gap is gonna be really critical, but I'm not seeing any really significant changes there. I'm also seeing like a ton of my clients which is just one slice of the market of course, continuing to hire these roles. Where I've seen most significant freezing when it comes to hiring is actually primarily in engineering. Bryan: So I think that's a, that's a really good segue overall. So some things I heard: executives are making adjustments. We are looking towards cost savings measures across the board and there's more scrutiny around business metrics. So it sounds like some combination of those might explain why there might be, I'd say, maybe fear in the DevRel community around is DevRel going to be one of the first things cut and how do we prevent DevRel from being one of the first things that's cut? Jono: Yeah. You know I kind of take a fairly blunt view on this, which I appreciate there's many holes in this view, which is if you're bringing outstanding value to a business, you're unlikely to lose your job. Now there are gonna be cases where companies make bad bets. I mean, this has happened with Shopify recently, right? The CEO came out and said, "I made some bad bets on e-commerce", and they've had 10% layoffs. So sometimes good people who are doing really good work do get laid off, of course. But I think when you are focused on ecosystem development, which is always gonna be critical to a business and you're doing great work and you're able to translate that work into value that your stakeholders can understand, then I think you're probably gonna be okay. But I've seen like some of this fear in the DevRel community where there are really good people doing really good work and they don't feel like their work is well understood or well quantified. We talk about this all the time in DevRel, right? But there needs to be more and more clarity around that ROI component of it, which is never all encompassing, but it's gotta be enough where we can relieve that fear. Jocelyn: I'd love to jump in and amplify what you just said, which I do a hundred percent think is all about the value. And it's particularly, it's what Sam said about sort of driving impact, driving measurable growth. And if you are a growth driver right now, then you are too precious to lose. And in fact those are the roles that are still being hired, even in the context of a larger, hiring freeze. I think that the big difference, it's always true that we need to quantify growth, that we need to show ROI that that's been a long term kind of trend in DevRel. How do we go from something that feels like a nice to have to something where we can quantify the value we're creating. But I think one difference between the last recession 10 years ago, and now is that historically DevRel was a long term investment. Jocelyn: It was a healthy ecosystem. It was a happy, you know, it was partnership. It was things that would drive revenue somewhere down the line. But second order effects. What's happened in the last five years with the rise of open core business models with the rise of product led growth, self-service is that for products that are largely bought or influenced by a developer community, which is not every product, not every DevRel role, but a big chunk of them today, DevRel is actually a growth driver. DevRel is actually what's driving revenue. And so I think I think there's, it's almost gonna be a haves and have nots world. If a company sits there and looks at DevRel and says, "This is a long term investment", and, "Hey, maybe right now I gotta tighten my belt and long term investments are not a luxury or luxury I can't afford at this moment". Jocelyn: Then they may have to scale back their DevRel efforts. But if they look at DevRel as something that drives revenue in the short term, or drives customer retention and customer expansion in the short term, then DevRel is precious and they're gonna keep investing into it. I mean, it's that black and white. And so I think a good thing to take inventory of right now is both, "Am I sitting in a company whose business model is driven by DevRel? If so, I'm in a strong position. If I'm not, maybe I need to think about looking at some of these companies where it is who are still hiring because they need it". But I do think that there's this kind of mushy middle, where as Jono says, it's all about being able to articulate the value and drive a connection between what you're doing and how many leads I generated for the Salesforce. Maybe it's not product led, maybe it's direct sales, but maybe the qualified leads that really convert are the ones that came through the developer community. So being able to quantify your impact, not on strategic initiatives, but on revenue in the next three quarters is a guarantee of job security. Jono: You know, just real quick, one of the things that Kirk, so there was a comment in the chat that Kirk says, "Qualifying the value of DevRel and showing metrics is such a difficult thing", which I agree with. But I think one of the challenges that a lot of DevRel people face here is trying to come up with the one true means of demonstrating value of the work they're doing. And in my mind, it doesn't exist and it never will exist that the metrics will be somewhat dependent on what value is considered by the company that you're working for. And, you know, to your point, Jocelyn, there are standard metrics like revenue, right? If you can demonstrate a link to revenue, then clearly that's gonna be a powerful metric, but different companies are at different phases, right? Jono: In terms of brand growth and, and you know user or registration growth and things like that. So in my mind, the key to solving that problem, that Kirk's highlighting there is really crisply understanding what are the top three things that the company that you work for cares about? And the hard thing is, is that the things that they may care about, may be the things that you don't care about. Right? Cause I think a lot of DevRel people are motivated and inspired by people and relationships and all those things, which are super important. But I think when we can identify those things for your specific company, even if it may be very different to other companies. Then I think it makes it easier to be able to define that for people moving forward. Sam: Yeah. I think connection versus isolation is absolutely crucial. And I think this mushy middle that has been articulated is so excellent because often we find that DevRel can show up as a bit like an art colony, right? Don't ask me about the value of the art. It's amazing. We do fantastic things and there are all these wonderful experiences. That's kind of an isolated way to communicate about what you do and only other practitioners can, can grok it, even grok is a good word to describe it, right? Like whereas connectedness is actually our accountability as DevRel professionals to be very curious about how the business operates and think about how good we are at evangelizing the value of what our company does to our community. What if we could flip that around and use those same skills to evangelize the value of what our community does for our company. Sam: So we need to get over the fear of communicating with the supreme executive vice president chancellor, right? Whatever, all those things that we worry about hierarchically and just go, "Hmm. I think you could really create a connection between what we do right now and what happens to the business next quarter". It's not the same as revenue this quarter, but it is a leading indicator and that will make you more capable of making good predictions about where your business is going. So just some curiosity about that interface rather than being isolated, right. Choosing to be connected. Bryan: So we heard a couple things about like DevRel as a growth driver, right. And definitely there are probably the majority of DevRel programs that kind of fit that bill, but also like that feels like a DevRel team that falls under maybe a marketing org, but there's also kind of the second side of DevRel that falls under maybe a product org. And I wonder, I think the marketing org is easier to prove that that growth it's, you you'd probably know your metrics because you're, you know, reporting to VP of growth, VP of marketing, whatever that might be. What's the kinda flip of the switch on that. And how could maybe DevRel teams that report up through a product org have a similar thing, even if it is a product led growth company, Sam: I refer to Jocelyn because she has a number of investments in this area, and frankly, if you were a DevRel and your job's getting cut, you should send Jocelyn a note because most of her companies are hiring DevRel. Jocelyn: We actually are. I do sit on the board of a lot of companies that are trying hard to hire DevRel people right now and consider it one of the toughest jobs to hire for. So if you're excited to go initiate a new community, I do wanna put in a word for startups here. In times when macroeconomic conditions are shaky, people often feel like, oh, the safe thing is to go work for a big company. And and maybe now is not the time in my life to take the risk of joining a startup. But if you think about an early stage startup, one that has raised recently has 18 to 24 months of runway and you know, and a pretty decent chance of raising again, like you, you can assess the quality of the startup and decide if they have a decent chance of raising again, if they have four years of runway, like that's forever, that's longer than your average job. Jocelyn: So like that's as safe as a big company. And, and I would argue that in current circumstances, the companies that have been first to freeze hiring and do layoffs are the big ones, not the small ones, because they're, this is starting in the public markets. And so I actually think that like right now startups may be safer and especially a startup where it's a DevRel led growth model and you're kind of the core of growth and of getting off the ground for a company. So anyway thank you Sam, for giving me a chance to get on my soapbox and say, if you're feeling risk averse, now's the time to embrace the startup. But in terms of the metrics, when you're sitting in the product organization, now's the original question. It's gotta be the product metrics and look, some companies are incredibly metric oriented. Jocelyn: I worked for four years at Facebook and this company had product instrumented to the to a T. If you sat in the photos team, you knew exactly what metrics you were trying to move this quarter. We're trying to make not just the absolute number of photos go up, but we're trying to make participation rate go up. So the percentage of our users that upload at least one photo and we're looking at, so we're looking at photo uploads, we're looking at engagement photos. And so the more a product is oriented organization is oriented towards metrics in that way, actually the easier it is for DevRel to just kind of fall in line and be able to actually measure and instrument the impact. The more kind of it's loosey goosey and qualitative and like you know, like the art colony, like the artists aren't wrong, like the customer delight is real and it has an unquantifiable impact, like the impact's not false, but to the extent that that impact exists, eventually somewhere you can measure it. You can measure, are people coming, are they spending more time? Jocelyn: Are they adopting more? Are they downloading more? Are they using, are they consuming the API, the SDK more? And like those metrics are so called and dried, but it was actually beautiful API design. It was great developer ergonomics that, that made those download rates go up that made those consumption rates go up. But at the end of the day, if you are having value to people, if you're creating an impact, then you can find a way to measure it. And I think that for DevRel people who are sort of allergic to thinking about the business and revenue and like, oh, that's what sales guys and suits do. Like, I'm a creative, I'm creative and I'm a creator. And I'm serving my community and relationships. I think the thing that for me got me over the hump was, was this was thinking about what I really care about is creating value for my customers, for my community. I really care about that impact and a business model revenue, all of that. Like, that's nothing more than keeping score of whether I created value for people. Jocelyn: And so the way my company makes money almost always falls in line with the way I create value for people. And so if I can kind of lean back and think about it as like, you know, "How can I be sure that I really am delighting my users? How can I be sure that I really am making a difference to my community?" And think about metrics like starting from first principles, starting from what would make you feel good that you were doing that your job had impact almost always, you can divide and conquer the problem. If you make that your starting point, you can work step by step back to a way that it touches your business model. Otherwise your company's business model is fairly flawed. If you cannot draw a connection step by step, you know, one step at a time from delighting your community and creating value for people to them wanting to pay you money, then maybe that's not a company that has a future that, you know, that needs to exist. Jono: You know, one thing that what you were just saying, I just learned that kind of where my mind goes here is I, I agree with you, you know, that kind of revenue number, it's, it's a way of measuring one type of impact, right? And value on an audience. And you know, in the in the revenue world, companies talk about lifetime value, like, what is the amount of money somebody is gonna spend with you over the course of their life, with you as a customer?And where my head is kind of going a little bit is, you know, everybody talks about growth in DevRel and it always makes me kind of feel little awkward because growth is often at the front end of the funnel, which is getting new people in. And I know we're not talking about that exclusively here, which is one measurement of growth. Jono: And I think a lot of executives will look at how many more people came in this month. Which I think is one thing that's important to look at. But to me, the real impact of DevRel is in maintaining and building authentic relationships between a company and its developers and its users. And I wonder whether one approach to this is to think of lifetime value within the context of DevRel. And to me, lifetime value within the context of DevRel is the number of touch points across an extended period of time. Like if you've got a developer who shows up and they're brand new, so they contribute to your top of funnel growth metric. That's great. But if that developer then over the course of two years, goes to 10 of your technical workshops, reads 600 pages of your documentation, contributes four different ideas that get actioned inside of your community. Jono: To me, that is an undeniable example of the impact of DevRel because that journey would've not happened without that person weaving and nurturing that person through that maze of options that are available to them in a world of a billion, different distractions, one of which is Stranger Things, which everybody should go and watch. So I wonder whether we need to kind of get into that modality of we track the front of the top of funnel growth piece, but then how we instrument that to your point, Jocelyn, around how Facebook is an example, we're instrumenting product metrics, where we instrument that lifetime value that that developers are experiencing as they go through it. Sam: It tells you a lot about the organization, whether the DevRel is organized under the chief product officer or under the chief marketing officer. Ideally it should be a collaborative function. You're gonna have a bit each way. Right? when I worked at Microsoft in the 2000s, we didn't call it DevRel we called developer evangelism, and it was very much you know, part of the marketing organization and part of the sales organization, and many of the folks who were leaders there and practitioners have ended up in places like Azure technical sales, but the product teams did want to hear from us every quarter or so to be able to improve their product. So I think being able to keep the connection between product and marketing is one of the key values of DevRel. I loved both what Jocelyn and Jono said. Sam: I think when you look at the metrics, you, you have to remember that we left behind the idea of revenue as the only metric that matters to a business in 1980, right? That's roughly when the practice of the balance scorecard was created. I was nine years old then, I'm 50 now, right? So if you're running your business on revenue, you're probably not a place to, you know, you really not a place that's gonna innovate or grow. So if you think about the balance scorecard, you think about earned growth. If you think about product led growth, there's a new way of thinking about satisfaction and how it affects revenue. And I'd encourage every DevRel person to go and take a look at this article came out in the last year or so in Harvard business review, it's called NPS 3.0 NPS. A lot of people say like, I hate NPS. Sam: It can be gamed. They know, they're sorry. It was 20 years ago. NPS 2.0, came out in late 2000 but 3.0, combines these ideas that Jocelyn and Jono offered around how do we think about improving the product through telemetry? How do we understand lifetime value? How do we relate customer acquisition cost? And that incremental improvement of the product that comes in from the DevRel stream does it decrease churn, because I'll tell you the killer for LTV is churn. And if DevReL is connected with dropping churn in a product organization, and it's also connected with increaseign conversion, because your content's better, your docs are better your out there connecting with users and your're doing developer support. I really think ideally the DevRel person is poly. They're curious about everything a user may need, no job is too small, right? They work in dev support. They also do keynotes, right? So that's, that's how we create kind of this magical function that makes me so excited about DevRel every day. Matthew: One of the issues that marketing people talk about is that attribution is one of the hardest problems they face. So while DevRel people can know what impacts they believe they've had, how can you separate out the impact of DevRel versus all the other parts of the organization working together? Sam: I think Jono is the person that I would lean to, to offer a framework. Actually when we decided -- I'm part of the new management team at Datastax -- we came on board about maybe two and three quarters years ago and a little bit in when we decided we needed to really professionalize the organization, we had about 450 employees at the time. We're like, you know, what, if we're gonna be great at DevRel we need to hire Jono so I would lean on his framework because we use it day internally and I could give you a precis but it wouldn't be as good as the horse's mouth. Jono: I appreciate that, Sam, very kind of you. I think there's a couple of things that spring to mind for me here. There's kind of like strategic methods and there's tactical methods. One of the things, if we start with the tactics just briefly, one of the things that surprises me about a lot of DevRel folks, as well as marketing folks that I've worked with clients is that is that they're not tracking the source of their traffic. And there's a whole separate question around how much you should track people online, but every single link that you put out there to any piece of content and DevRel folks, you know, generate so much content, typically you should be tracking where that traffic is coming from. And you can do that with UTM codes really easily. Jono: You can track it in Google Analytics. And that's a great source of if you see that 30% of your traffic came from initiatives that were run by the DevRel team, then that's a really simple, quick fix that you can apply. But I think that's a bandaid and that can be helpful. To me, there's two other thoughts here. One is I think attribution's important, but at the end of the day, we have to play together as a team, right? And I think if, if it turns into a game of, well, who's responsible for this and who's responsible for this too much, then to me, it's as flawed as asking people to track their hours is that we're tracking the wrong metric. What we should be tracking is, if we are able to source someone on the internet, a developer to bring them in, give them a great experience and to keep them around for, you know, two or 3, 4, 5, 6 years then the product team and the marketing team and the IT and infrastructure team all played a role in that journey happening. To me, what's important when it comes to attribution is figuring out who's responsible for which pieces of that puzzle and how effective were those pieces. Jono: So to me, I'd rather, instead of tracking, you know, who's responsible for that developer kind of coming in more when we ran that technical workshop, was it effective and that's where we can use a lot of the traditional digital marketing metrics like, you know, how many people showed up to your workshop, what was the conversion rate of your landing page and things like that. I think if you've got a DevRel person, they run, let's say a technical workshop and they build a funnel for that. And all the components of those funnel of that funnel are optimized. Then you know that that DevRel person is basically is working as effectively as they can, but they can get people through the door. But if you've got a product that sucks, you're not gonna get a great developer experience. And that's where I think we need to kind of align everybody that we are all part of the same team. Jono: And I think sometimes this means, and this can be terrifying for DevRel folks, especially, you know, as Sam was saying earlier on, if people are a little nervous about talking to executives, I think part of the job in my mind is really setting expectations and, and aligning executives with what are the right? What are the, what are the right things to track? Just because someone's an executive doesn't necessarily mean they have all the answers. And in many cases, they're looking to their DevRel team for guidance and input. I found this with the vast majority of exec execs that I've worked with is, and this is not just talking to me. This is talking to the DevRel folks is they want to learn from the DevRel folks. It's not a one way relationship. So I think saying, you know, just purely track and attribution is one piece of it, but we should really be making sure that we're identifying who's responsible for the initiatives and then optimizing the initiatives and that we're all part of the same team. Bryan: I have a question and it goes back a little bit, but I think it speaks to this attribution side of things. So Jocelyn, you mentioned at Facebook everything was like super well oiled in terms of the tracking. And you've got a portfolio of startups now, most of whom are probably not a well oiled machine yet. Right. So how can the DevRel folks who are watching right now help influence how we can better tracking internal to the product because marketing folks, they've got a decent set of attribution, like UTM codes and all that. But like how do we take that funnel that we had for the technical workshop and then trace that through to a spike in product usage around the feature we covered inside of that for, for both maybe a well oiled machine and a non and a rusty new machine, which is antithetical, I suppose. Jocelyn: Well, I think it really varies depending on the company and its stage and its business model, but really like what is important to the company. And it, it does mean that that DevRel people have to get comfortable with that kind of cross-functional communication with hugging their counterparts in marketing and in product and even in finance, right. And figuring out what matters at a seed stage startup with its first DevRel person that's just trying to create a community program. Like you don't need to have telemetry on every single thing, what you need are three design partners. And you know, what if those design partners appeared in Slack and were engaged in Slack then, like chances are we give DevRel credit for it. Like attribution's not super important when it's that small. Jocelyn: So clearly when you're a little bit larger and the name of the game is about repeatability scale and growth, that's where it's really important to have a great relationship with the product team you work with. And the good news is it's awesome for product managers and engineers to have this kind of instrumentation too, because they can measure if their product is successful, if their product is working for customers and users. If they can measure what are the key moments? Is it logins? Is it is it API calls? And and I think that you'd be, you'd be flying blind to try to scale product growth or the growth of an SDK, whatever your business model is, without the basics of, "Are people using my stuff and is it working for them? How is it solving their problem?" Jocelyn: And so what that is will vary by product by product, but that's a conversation between between PM and DevRel, I think. I almost wonder how much we're living in the past here too, because, and maybe I'm living too much in the future but I feel like any tech company that got its start in the last five or eight years is growth forward, has adopted this playbook of... It's you know, 20 years ago we treated customer support as a cost center. We knew we had to solve customer problems or they would stop paying us, but we wanted to spend as little on it as possible because there was no upside, there was only avoiding downside. Jocelyn: And then we realized, "Oh, wait, now that we're in a subscription business model, if customers are really happy, they'll use our product more, they'll buy more of it." And so actually this is a growth driver, this generates revenue. So we made the transition from customer support cost center, make it run cheap, do as much with as little as you can, to customer success. Invest into it because this drives growth. Like, I feel like that's the mentality of execs today and that's the mentality of product companies today is to measure, but to, but to believe you know, to believe that investing in the community is gonna invest in expansion. We're measuring business metrics now, like net revenue retention. And if someone trained up 10 years ago and has been like, "Oh, that's icky business stuff, don't need to pay attention to that." Jocelyn: Like, you've actually missed a pretty tectonic shift in how your function is valued and measured. So I guess I feel differently. I sit in so many board meetings where we talk about the importance of growing community, where we talk about you know, engagements in Discord or GitHub stars as sort of measures that we're measuring for their own sake that we want to see grow, because we all believe that there's a connection between that and driving leads to our sales team or driving credit card swipes on the website down the line. Or if you're Facebook and it's ad driven revenue, like if our product is great, then people will spend more time and we'll make more money that way. So I almost think that that growth mentality has become so ubiquitous now in Silicon Valley startups, I'm kind of like if you work for a company that doesn't have that mentality, man, find a better job. Find a better set of execs who get it. Also, do be open to going and talking to those people and hugging them. I think there's been a real sea change. I think everybody knows native content is the best way to drive authentic interactions with community members or people who may pay you money. Someday. I think that this is the new common wisdom. Jono: You know, Jocelyn, one of the things I love about what you just said there is about the hugging it out because I think some DevRel folks see themselves as sitting in their lane. Right. But, and there's a lot of debate in the DevRel world around reporting into marketing or reporting into engineering or reporting into product. And to me, the most inspiring and incredible DevRel folks that I've ever seen have just got this ability to just slither all over the business and just engage with people and draw connections and get everybody excited about a common mission. And those people are super powerful. And I think the DevRel people that have struggled at times have become a little tribal in nature where they say, "Well, hang on, we're in the engineering team. And those marketing people are making us do these things, or those sales people are making us do things." And, and to your point, I think that's a perspective of the past. You won't last long with that mentality. Jocelyn: And you're neglecting your superpower. You're an evangelist, you're a community builder. Exactly. Like use that mindset to build community with your teammates to coworkers. Yeah. And to evangelize what you do to, you know, I mean, that's your superpower. And when you define other business, other job functions as your rivals or as some other silo, you're actually just like leaving your superpower on the floor and like, you know, leaving your magic sword and armor at home and like just going and being a muggle, like why would you? Sam: I'll point out something surprising, which is that the DevRel folks who are afraid of executives or of other functions, those functions are afraid of them. So think about this, you have a technical product, right? And then you have people who come into the company and they don't have a technical background. And it's easy for us to forget the level of intimidation that non-technical people feel in startups and in technical product companies. So if we can start to change our heart and again, to follow Jocelyn's hug your executives, hug the other functions. It's really important to enable them to decrease their fear, right? Because whatever we fear, we're gonna keep it ar arm's length. And we might take actions that don't make sense. Teams might get cut. People might get fired because the conversation never happened. I do have a, a couple things to say that I think are maybe just very practical and metrics oriented because I don't, I don't believe that it's not measurable. Sam: I also agree that we shouldn't do hard attribution. I had the privilege of working at Google for a few years and our Chief Financial Officer, Ruth Porat who I think is really one of the very best in the business. She was constantly asked about attribution and if we were gonna run Google as P and Ls, and she said, "No, every year we get asked the question every year, we take a look at it". And she said, "I think what makes Google magical is that we believe that lots of smart people working hard together can create great experiences for customers. And that makes us a great company. Once we start doing attribution, now we've created this whole new game. That sucks up a lot of our time of counting things. And did you count the thing or did I get the thing?" Sam: And now we fight about that or else, do we lie to each other? And we say, well, we'll both count both things. And now we've created this new ungrounded economy where everything gets doubled and eventually gets tripled. So attribution as a term, it's a, it's a mistake. Don't, don't follow that path. But measurement, measurement's king. Simple question. Do you have a technical product? Okay. If you do guess what technical products don't sell themselves. They also don't use themselves. Where do they happen? Marketing brings people to the show. DevRel creates the show. The people who arrive there are a cohort. You can offer them a tracking code. You can figure out how many people came in and use the free trial. You can put that in the cookie. You can make sure that you understand who these people are as they come through your site without violating their privacy. Sam: You can look at that cohort and do conversion. So everything that we've learned about PLG or product led growth, if you go to the SaaStr conference, just take that and maybe replace the P with the D like developer led growth, or maybe it's developer centric, product led growth. We need better terms here. Then you can say like, what's happening with our doc views with people with those cookies. What about support tickets? What about Slack members? If you have a Slack community? So these things are super trackable and I'll reflect one last piece of wisdom that Mary Thengvall offered when, when Jono and I got a chance to talk with her a few months ago, she said, what about DevRel qualified leads? We can create clear language as both Jono and Jocelyn were mentioning, there's sort of top of funnel, which ends up flowing down in the marketing system to be an MQL or a marketing qualified lead. Eventually it gets handed off to some salesperson. They make an inbound call. It's called a S0, right? It's a sales opportunity stage zero. And then they progress. Sam: This is what sort of modern sales and marketing understand. It's highly programmatic and conversion rates are generally around 2%. If you're doing really, really great, right? You've got all these people at the front, and then you eventually bring 'em in, but DevRel qualified leads may be lower in total volume, but they're much higher in conversion, stickiness, and much lower in churn. So you're really talking about two very different things. Do you want the gold, or do you want the gold ore. You gotta crunch a lot of gold ore to get down to the gold, but DevRel may be just bringing gold. So cohorts, tracking codes, free trial conversion, doc views, support tickets, Slack members, and DevRel qualified leads, I think are very clean ways to fit into a modern technical product business for DevRel. Matthew: I'd like to ask you in closing, we've spoken a lot about the organizational level and how people can contribute to their team's success within a company. But if someone watching this has found themselves no longer employed, how can they put their best foot foot forward to go and get that next DevRel role in maybe a more constrained economy? Jono: I've got a really practical thing that they can do. So I actually built a training course for how people can get their dream community job. If people want to email me, I'll give them free access to it. Like these are difficult times and it walks people step by step through how to identify companies you want to work for. How to put together a great resume, how to go to an interview and actually do it well. You know how to learn more about the company before you actually share your skills and experience. It's a very, very practical way of going through it. And given that we're in difficult times, if people want to email me jono@jonobacon.com I'm happy to give people free access to it. Matthew: That's wonderful. Thanks Jono. Jocelyn, what are you advising your founders to look for in DevRel people? Jocelyn: Well, we're frequently hiring the first DevRel person. And so what we're looking for is someone who's a little bit of a Jack of All Trades and doesn't have to be the master of one of them, but someone who can get us set up, someone who can kind of cover the bases and say, and come up with our strategy. You know, we need a place to talk to our community. Is that Discord? Is that Slack? Let's get it going. We need a way to interact and solve problems and we need a way to measure success. Maybe we need to adopt Orbit. But also this person is gonna end up being the perso doing the writing. So so I think like the ability to write clearly and authentically in a good developer voice is one of the most important things. Jocelyn: The ability to run workshops and really bond and form real meaningful relationships with the party at the other end. So I would say it's that breadth. It's being able to do a little bit of everything that is most important when you're hiring the first one. And if someone had joined another tech company, when the community team was small, and then when the community was small and saw it grow and saw a sort of variety of things that did and didn't work, that would be catnip to me. Because I would love someone who has seen the future a little bit. And then, you know, if I got to keep piling on things that would be just bonus points and add appeal to me, someone who's got a spirit of experimentation. What worked at some other company is not necessarily gonna work at my company. Jocelyn: Every product is different, which means every community is different. And so someone who's just like prepared to try a bunch of things in a scrappy way and sort of walk away from the things that didn't work, don't fall in love with your babies. But try more. If you know it's not working, don't get in the dumps, just like, okay, that test didn't work. We're gonna try the next one. We're gonna try the next one. We're gonna find the thing that does work. So, you know, I think that kind of resiliency and hustle attitude, but grounded and authentically caring about people and product. Can I have it all? Matthew: Sam, any advice from your side? Sam: Yeah. So, you know, 21 years ago I was cut from my company in a recession, right? 2001, we had the dot com bust and we thought that was the worst it was gonna get. But then right after that, of course was September 11th 2001. So that was, that was a tough time, but it enabled me to retool. So I would invite people who are about to lose their job, right. Or who got surprised with it to kind of take, take the most of the package. It's gonna be shocking. It hurts. I get it. I've been there, but to be able to do some written reflection and reimagine the work you've done, how might you explain this in a zero stress environment, just you and your computer. You're just writing out a document. How might I explain what I've done in the last two years to a chief marketing officer? Sam: How might I describe it to a chief financial officer? You can talk to some people who you might have met in finance or marketing, right? How do you start to just get a little bit more on the business. That reset, that re-imagination of what you've done now that you're not under the stress of having to deliver constantly does give you an opportunity to learn something about yourself, tell a slightly different story. At the same time, don't disappear. Right? Many of us in the industry suffer from from depression, from anxiety. I'm certainly one of them and the cure is not retreating and licking your wounds. It is to connect with the beautiful things about the DevRel communities, not just that it's poly, not just that it's artistic, but that it is connected and caring. So I've seen the prior recession with COVID two years ago. Sam: I saw a lot of people coming out on Twitter and saying, I just lost my job. I feel terrible. And you just see there's this swarm of like 10 or 20 or a hundred people going, oh, I'm so sorry. Hey, call me, do you wanna just chat? Oh my gosh, I'm hiring. And the way that social media can work at its best, I think is often showcased in how we, how we support each other in the DevRel community. So reimagine, reflect, reset, and then stay connected. Get out there. Just tell people what's going on. May be too scary to ask for help. You could just say life sucks for me right now and I think you'll be amazed at what comes back. Matthew: Wonderful. Jocelyn, Jono, Sam. Thank you so much for your time and your wisdom over the past fifty minutes. Bryan, thanks for co-hosting with me. Bryan: Thank you.]]> 00:52:01