Screaming in the Cloud - The Anatomy of Developer Advocacy with Matt Broberg

Episode Date: September 4, 2019

About Matt BrobergMatt loves working with technology communities to develop products and content that invite delightful engagement. He’s a serial podcaster, best known for the Geek Whisperers podcast, is on the board of the Influence Marketing Council, co-maintains the DevRel Collective, and often shares his thoughts on Twitter and GitHub @mbbroberg. He’s also a fan of tattoos and cats, though remains unsure of Schrödinger’s.Links Referenced: Twitter Username: MbbrobergLinkedIn URL: https://www.linkedin.com/in/mbbroberg/Personal site: Mbbroberg.funX-TeamCHAOSSEARCH

Hello and welcome to Screaming in the Cloud with your host, cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This week's episode of Screaming in the Cloud. first-class company environments. I've got to say, I'm pretty skeptical of remote work environments, so I got on the phone with these folks for about half an hour, and let me level with you. I've got to say, I believe in what they're doing, and their story is compelling. If I didn't believe that, I promise you I wouldn't say it. If you'd like to work for a company that

doesn't require you to live in San Francisco, take my advice and check out Xteam. They're hiring both developers and DevOps engineers. Check them out at the letter x-team.com slash cloud. That's x-team.com slash cloud to learn more. Thank you for sponsoring this ridiculous podcast. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Matt Broberg. Welcome to the show, Matt. Thank you so much, Corey. It's a pleasure to be with you. So your formal bio's a delight. Matt loves working with technology communities to develop products and content that invite delightful engagement is how it starts,

which is just, it feels like someone has workshopped that to no end. I mean, you can just do the kind of kissing motion while doing mwah, just tastes good when you say it. Exactly, but it continues. He's a serial podcaster, best known for the Geek Whisperers podcast, is on the board of the Influence Marketing Council, despite the fact that somehow no one really knows who you are. I may have ad-libbed that. That part's on the bio, yeah. Yeah, co-maintains the DevRel Collective, which I'm sure we'll get into, and often shares his thoughts on Twitter and GitHub.

Do you share your thoughts about Jithub on Twitter or vice versa? Oh, dear God. I think you're really just reminding me I'm due for a revision on this. Well, absolutely. There's no time preparing for something until right after the point you really needed to, which, why not? Game on. I might have you back someday. You currently work at IBM Hat as a technical advocate and editor for opensource.com.

In fact, I am employed at Red Hat, which is still Red Hat, and I do. I am one of the editors of opensource.com, which is a lovely site that you can contribute your ideas of what open source means or share tutorials about it. It's all under Creative Commons. And the code is based on anything that meets open source licensing. So it's really a great place to share and engage in the open source culture and to do so in a way that doesn't focus on code contribution, since we all know that's not the only way to contribute back to open source. Oh, yes. You read an article of mine, which I'll throw a link to in the show notes at some point, and have had the good sense never to

invite me back. Yeah, I mean, it doesn't come to memory, so I guess it wasn't on purpose. But yeah, maybe next time, Corey. Exactly. And no, you are at Red Hat, which is at the time of this recording, has just recently been acquired by IBM. So the hats are red, but the suits are IBM blue. Yeah, I mean, you're absolutely right. And it's a pretty exciting time to be there. I think I'm more impressed than ever that I was actually interviewing while IBM was in

the process of acquiring Red Hat. The news came through during the interview process, so it really caught my eye. And to everyone's kind of credit, it still went through completely smoothly. I just continued on with the interview process because the company was still exactly the company I'm working for now. So I feel really good about that. And I think it's a real credit. There's a lot of snark to be said about how companies change after acquisition, big and small. And this is the first time I haven't seen it completely freeze all hiring processes. It seems that everyone I've talked to there has continually nice things to say, which tells me that they're legally required to, which is fine. And that's not the point of having you on.

Instead, it's mostly to talk about what you've been up to lately. What have you been doing? What excites you? What interests you? You know what, Corey? I mean, the thing that's been on my mind is I just finished a stint getting a what we might call colloquially a DevRel developer relations organization off the ground in a technology company. And my last three jobs have all been in the DevRel Collective, which is this brilliant little brainchild of Dave Josephson, who wanted to get other people that were formerly developer evangelists

talking to each other on the side and getting each other some support, because it was so frequently teams have won in the early days. Well, we've definitely evolved far away from that timeline into it being in the mainstream and every organization almost to a degree of cargo culting pulling that term into their organization and i'm fascinated by this i see myself more as like a jane goodall character in devrel like curiously watching what's happening from the trees trying to blend in and i have some observations and i know you have some opinions, so I wanted to banter with you on that for a while. Oh, I generally have opinions on most things.

But to clarify, you would not consider yourself to be a developer advocate or developer evangelist or a dev reliper, as I insist on calling them? Not at the moment, no. I definitely am good at playing one on TV, as need be. I definitely think of it as a bit of a caricature you have to play sometimes. But, you know, in order to be in the DevRel space at a given time, you need to have a particular tribe to be talking to. I think that's an essential element of it. And your goal, my take on the overall goal is to inspire by example. That is fundamentally what a developer advocates role is to be. You know, Google has a definition as well from like 2015 that if I can pull that quote is developer relations role is to create a vibrant ecosystem of third-party developers by bringing

the interface between those developers and their platforms, product engineering, and design teams, which is kind of a fun idea of being the glue between these different experiences. And at the moment, I'm very happy to be just focused on writing articles and talking to people. So not at the moment, but I'm fascinated by it. I like to get into conversations about it on Twitter. And I think we're still at a place where it's just so ambiguously defined what that role is and what it looks like, depending on where you're getting hired, that you have to really peel back that onion and know what you're signing up for, or you have no idea what to expect from your job. I have mostly stayed out of those debates intentionally, largely because I know I'm going to irritate a number of people regardless of what I have to say and regardless of what

side of offense I come down on. So let me preface the rest of this conversation with a disclaimer, namely that I'm not sure who's on what side of what war is being fought over this, because honestly, I have other things I'm focusing on rather than outreach to developers. For my business, developers are generally a champion at best and not someone that I'm trying to sell anything to. So from my perspective, I don't need developer engagement. That said, let's start at the beginning. What is developer relations?

Well, so I gave you the textbook definition by... Yes, but now I want to hear it applied. Yeah, by Google's definition. And then I really do think that developer relations is a category of positions that is its main goal is to inspire by example for a given audience. The three disciplines I think that really are enveloped in this new strategy of DevRel are community, which isn't traditionally its own organization, but at sometimes community management is,

engineering, some function of engineering, and some function of marketing. If you smoosh those together and you sprinkle some unicorn dust, a rainbow pops out and then a developer advocate is born. Wonderful. And what is, I guess, functionally the role of one of these people?

Because I will start off by saying the external crappy view of a developer advocate or evangelist, we're not sure which they call themselves by because there's strong feelings about either side of that. And they're too busy quibbling among themselves, in my experience, to articulate a clear difference. I thought you weren't going to have an opinion on this, Corey. Oh, I said I was going to have an opinion. I just don't have a horse in the race. There's a difference. I see, I see. So I see the quibbling happen,

and talk to people about what they see the role being. But let's take the prototypical, poorly understood, crappy example, where you have someone who looks like a developer, except for the part where they cost way more. And their job description, more or less, is to fly around the world to exotic places where a conference is being held. And then they get on stage and they say something like, yes, I currently work at Twitter for Pets. Twitter for Pets is hiring. Let me know. And that's the last time in their talk that they mentioned the company because now their talk about how to choose the proper

standing desk for your home office is what they're focusing on. And it's not in any way relevant to what Twitter for Pets does. And then they flit off to the next conference and continue to go on effectively drinking parties with their friends. Now, this is probably not the complete encapsulation of the role, but to someone not steeped in it, it doesn't sound like it's that far from it. Yeah, that could be a pretty tough pill to swallow if you're in the profession right now and you hear that description. That is like the most annoying stereotype of what the work is, that you fly to exotic places, you get to hang out on a beach, and then you are paid to drink beers with your favorite people because they're also DevRel and they're in the same space. Forget annoying description. I'm pretty sure that was a verbatim job posting two years ago. I am not going to advocate or argue against that,

but I will say that, you know, if we want to talk about what it feels like in practice, I've done the job a few times now for a number of years. And one of my favorite things is talking to people in the DevRel collective and to people trying to break into DevRel. So what I found is that, you know, I just want to start by saying there's a wide variance in what the job is, depending on the size of the company, the subject matter the company cares about, and basically, like how well funded they are. So I think early startups to, you know, mature cloud vendors have wildly different expectations. But in its best form, there are a few key aspects of it that tend to come up over and over again. And it has to do with winning, you know, hearts and minds by having somebody who is, you know,

first off, a member of the given tribe that they're trying to influence. So you, Corey, if you ever were to dare, could easily be a great dev advocate for a cloud vendor if you wanted to try. Would you ever try that? I have the sneaking suspicion that I would be entirely too honest. Let's also not escape the fact that I am a terrible employee for everything that my personality suggests I would be. Fair enough, fair enough. Okay, so avoiding, if we just focus on that aspect, you would be good to go.

But there are other aspects, right? There is the angle of what is the value that company is expecting to get out of this business investment of a developer advocate or a developer relations professional. So in that way, it really depends on whatever executive coughed up the hundreds of thousands of dollars to millions of dollars of investing into this project. And to give some concrete examples, like if you look at the top three cloud vendors of Google, Amazon, and Microsoft, you see really deep lineups of developer advocates. trying to provide a better experience for their particular cloud by in whatever way they think makes sense to them. So you recently had Jess Frizzell on the show. I think Jess is one of those like secret superpowered dev advocate types who like fundamentally is an engineer at heart, but she can't help but go fix things for actual people in real ways. So it's not just about what's been put on the backlog on Jira.

It's like, what are people pissed about? How can I go find the person that can fix that and, you know, hold their head towards the tweet that says how bad it is until they actually fix it. Like that is like one of the superpower the superpower elements of a dev rel. And we're calling those individuals a dev rel as a singular now. That's the terminology and nomenclature we've settled on?

No, I'm terribly sorry, and I would love to provide an alternative. So developer relations would be an umbrella term. I wasn't criticizing. I think every term I've heard about this has been awful. But I'm just willing to figure out what the appropriate term is. I'm not one of them. I use the term that they tell me to use. So I don't want to put my wood behind the fire of DevRel. It's a terrible term. But developer relations is the umbrella organization, if you will, if we're going to think about this from a business standpoint. And then within a developer relations

organization, if you're creating that, you tend to have developer advocates, which are your, you know, general purpose unicorns, as we're talking about right now. You might also have developer experience engineers in that organization that focus more on, you know, SDKs and library support. And then in the larger organizations, they have an entire staff of sort of product and program management teams that help support the initiatives that the DevRel organization is uniquely responsible for. So my understanding over at Microsoft is that there's a DevRel organization that has program managers that support their own band of certain events and activities and sponsorships of podcasts and things that differentiate from the core brand of

marketing that that company is doing that are more focused on giving back to the community at large and less about immediate conversion for the sake of marketing goals, which marketing's goal is to convert people into sales opportunities. And yet, as you mentioned earlier, they put millions of dollars behind a DevRel program at these companies and they want to see some value in return for that. Otherwise, you may as well send people you like on faraway trips to expensive places. But the question then immediately emerges, how do you measure that value that you're getting from it?

This is my happy place. This is the thing no one has still cracked the code on, and it's absolutely amazing that it's so consistently problematic. We're talking about organizations, so org charts will always have those steady pillars in organizations of marketing, sales, engineering. And the only other essential one is finance because you got to make some money

and know what to do with it. But being so new and not being so one-to-one aligned with KPIs like these four organizations are means the dev rel organization will always look a little alien when we start talking about return on investment. The ROI of a developer relations program has to be aligned with some sort of strategic strategy, or else it just looks like the sort of general purpose, like we just make things better for the company type statements, which don't tend to lend well in like a boardroom scenario. But, you know, to double down on that for a second.

Because that always in the rock, paper, scissors game falls to, I make things less expensive for the company. So there has to be a value clearly articulated. Yeah, exactly. So I really, I kind of keep going back to business theory in this. And I'm like, you're either a cost center or a profit center. And DevRel, unless communicated in a way that it is providing some sort of coherent value based on the other organizations we're used to, it's going to eventually be a cost center and eventually cut because they can be wildly expensive due to the activities. But why are people investing in them in droves still? And it's that their organizations that currently exist are fundamentally broken at communicating with the target audience. The idea of most organizations, both their marketing and engineering teams having a coherent conversation with an end user are just busted. Like you have engineers that will produce whatever their backlog tells them to, not because they want to or it's been validated, but because that's what they have to do.

And then you have marketing organizations that are very good at times at talking to the C-suite or talking to the person they perceive to be the moneymaker, but we're living in the wake of developers being the new kingmakers. And that whole idea... Nice Red Monk reference. Thank you, thank you. And not being able to talk to developers is seen as a huge liability.

So we're left in this little bit of a primordial ooze of what do you do in this state where we don't have the right resources and the right organizations? This week's episode is sponsored by Chaos Search. If you've ever tried managing Elasticsearch yourself, you know that it's of the devil. You have to manage a series of instances. You have to potentially deal with a managed service.

What if all of that went away? Chaos Search does that. It winds up taking the data that lives in your S3 buckets and indexing that and providing an Elasticsearch compatible API. You don't have to manage infrastructure, you don't have to play stupid slap-and-tickle games with various licensing arrangements, and fundamentally, you wind up dealing with a better user experience for roughly 80% less than you'll spend on managing actual Elasticsearch. ChaosSearch is one of those rare companies where I don't just advertise for them, I actively recommend them to my clients because fundamentally,

they're hitting it out of the park. To learn more, look at ChaosSearch.io. ChaosSearch is, of course, all in capital letters because despite chaos searching, they cannot find the caps lock key to turn it off. My thanks to Chaos Search for sponsoring this ridiculous podcast. From my perspective, and I'm curious to see what your thoughts are on this, I view DevRel as an extension of marketing. Now, I know somewhere listening to this, someone just sat bolt upright and started swearing and possibly almost caused an accident if they're commuting. But I don't mean that in any way as an insult.

I consider myself more than a little bit of a marketer. And because the way I see it is that it aligns so clearly with the larger picture of marketing. When people have a, I guess, angry opinion toward marketing, from my perspective, it's the crappy implementation of marketing. Easy example for that is we're on a podcast. As people have heard at the beginning of this episode, it's sponsored by a company. Huzzah. Now, people are generally not going to be pulling over to the side of the road, causing a second accident on some of these freeways around here, and pulling up long URLs

and punching in discount codes necessarily. But there is value as far as brand awareness goes to affiliating a brand with something like this that people at least ostensibly like. And measuring the ROI on something like that becomes super challenging. So companies instead try and game the system. Well, if you make them use this code for some discount, then we'll be able to loop back around and track the exact number of impacts. But it never works that way. I mean, there's this problem of effective frequency. If you see a brand 15 times and the 16th, you see the sign, you decide to buy it. Well, that's that 16th thing. That 16th impression winds up getting all the credit and everything else was just a waste of money, but it's not how it works. 100% correct. I'm with you all the way, Corey, that

we're now really getting into the guts and really the deeper level than most people want to about like, what is marketing about? If you can tell you're being marketed to, it's because it's bad marketing. If you start from that premise, you can think about how developer relations could be a bandaid over the current status quo of marketing in most tech organizations. It's, we need developers talking to developers about things developers care about, and keeping them engaged, excited, and contributing back to something larger than themselves. So you see this a lot in open source communities because it's easy to see that the more I engage with contributors and maintainers,

the more they contribute back and thus the better the code gets. In sort of API-driven companies, you see that DevRel, when they do a tutorial at a conference that gets people their, you know, their first push to their API, they sign up for a new account. So it's an easy ROI conversation. a cloudy space or the sort of products that are more regular releases of things that people go and run on premises themselves. You have to have a bit of a leap of faith that when I get somebody you trust to talk in front of you, you are going to be more likely to use this software or hardware or whatever it may be than you were before you talked to that dev advocate. So there is something like there are things that are easy quantitatively to measure, but that doesn't make them qualitatively correct. And finding the line between what's easy to measure and what's useful to measure is something that we're still way off on as a principle.

And if I could tell you the one thing that has to be measured across all organizations, I absolutely would. But I've found that there are so many variances in how people define their DevRel program's goals that you have to align the KPI, the outcome that we're pushing towards with the business initiative,

or you're just trying to whitewash this idea in a way that doesn't work. Absolutely. And I think that if you view marketing through the lens of crappy marketing, such as people who are statistics or metric-driven around it all comes down to the clicks and getting in front of people in obnoxious ways,

then yeah, I wouldn't want to be associated with that either. But as you say, that's crappy marketing. That's not what marketing should be about. Another direction I've heard people take DevRel in is that it becomes the voice of the customer or the developer back in to inform the product and make it better over time. And if you ever want to see someone struggling to keep a straight face, I would urge you to use that exact phrasing to someone who runs a product or get a company. And then pour six to eight drinks into them and then let them loose and see what they have to say. Because fundamentally, user interviews are an integral part of product teams.

Conducting those as its own skill set and making sure that you wind up asking the right questions in the right way is incredibly complex. I hire someone specifically to do testimonial work with my existing customers just because I don't have that background to be able to ask the probing leading questions to get the story that I'm looking to get from a consulting engagement. From that perspective, a bunch of people with some form of engineering background who are now giving talks, writing blog posts, et cetera, the idea that they can walk out and into a random conference room, have a conversation for 20 minutes with someone that they like,

and come back with meaningful product feedback that carries statistical weight to product seems a little far-fetched. Yeah. I mean, you're scratching on that itch again, right? We're asking too much from a single new idea. I do want to give a shout out, not that he'll necessarily listen, but maybe he listens. But Kelsey Hightower, I think, is a wonderful example of what this looks like in practice, where DevRel is adding value in a unique way, as opposed to trying to replace what product management would do. His work with empathy sessions, this idea of gathering users into a room using his star power and expertise in the community space to grow people and then to aggregate them into a place

gives him an opportunity to get people using a new tutorial that you put together, but then product team members can join that exact same space and get to know the same people and have that one-to-one relationship or one-to-few relationship that DevRel is just better at. Because to date, many, many product organizations do not actually talk to their end customers. Because to date, many product organizations struggle to get that same level of relationship with people because they're not engaged on Twitter like a developer advocate would be.

And they don't show up to the conferences regularly enough to be just invited into a room of people. So there is a value add, but we have to start talking about this as additive and less as being a replacement for other organizations. We still need marketing. We still need engineers who are writing code and pushing bug fixes. And we still need product management that's doing what product management does uniquely. But we're also saying that that's not enough anymore. And in the current state of affairs, we need an organization like Developer Relations to provide that social tissue, that connectivity with our target audience, and then to lead by example by participating in the ways that we want other people to participate.

So I'm fully with you that there's expertise in each of these nuances to each of these roles, but DevRel is an additive value in this current state of affairs and the current time that we're in in the current market we're in. Absolutely. One thing I want to address is why— I was kind of hoping you'd argue with me. I'm not going to lie. I don't know.

I don't know if I agree with you or not. I think that it's a nuanced issue. Again, I'm trying to be very clear on this. I'm not trying to call anyone in particular out on anything. Some of the most inspirational people I've ever had the privilege of speaking with are developer relations professionals. I'm a big fan of the work, and I definitely think it's needed. My concern has been largely around the way that it's talked about in some circles.

I'm not necessarily trying to get hate mail, but I'm also not trying to paper over a lot of, shall we say, unfortunate behavior that I'm seeing in this space. For example, a lot of companies are effectively trying to significantly beef up their developer relations function, where they have a tremendous roster of people who are known and respected throughout the entire

industry. And the problem that you see is great. So these people are using their personal credibility to convince me to try something I otherwise wouldn't try. Well, absolutely. I like these people. If you tell me something's good, I'm going to believe it. And then it turns out it's crap. And 12 months goes by and hey, try it again. It's not crap anymore. I'm not going to trust you the next time that you say this. So I fear that people are in some cases burning personal credibility because they feel they either need to or they actually need to based upon what their employer is measuring them based upon. That's some tough love right there.

But I can't disagree with the premise that when being in a developer relations environment, when that is your role, part of what you're doing is you're putting your credibility out there as a source of value for the company you're working for. That's part of the idea of the top of funnel marketing draw that you provide that other people in marketing can't provide with, you know, their latest version of a web page or, you know, new place where you can add your email to get a cookie. So you're totally right that people are putting themselves out there and i think being on the other side of that more than a few times i think the hope is that you aren't too blind to the fact that it has flaws as well and you can honestly advocate for the right way to use something and the wrong way to use something and when it is good and when it isn't good and you can request

the kind of feedback that's appropriate to the lifecycle of the product. So like sometimes I've had to push back and be like, I know you want me to get people to go buy this, but I think I actually need to tell people that it's in beta and here's an open source release they should download. So you're talking business strategy at that point and talking about maturity of the audience and whether they're willing to accept something where it's at, even though it's not where you want it to be yet. And having that heart to heart with people that are well above your pay grade, but a good dev advocate, you know, has those tough conversations when they need to. So that's, it's part of the job for sure to, to put yourself out there. Ideally, you can stay honest in your job.

I have a core value that I don't want to be at a place I need to lie. I would rather quit or get fired before I'm lying for somebody. That's resulted in both. Absolutely. I think there's also a strange spectrum that we're seeing in the DevRel space. Easy example of this would be, the canonical example I always like to go back to is Matty Stratton at PagerDuty. Sure. He's been doing this for 20 years.

So if he sits down at a chair, sits down in a chair at a stage and spins it around, straddles it backwards, because for some reason in my mental image, that's always how he would do this. And he would say, I have seen some stuff. Let me tell you about it. You're doing paging wrong. Now, I don't necessarily believe that I am. I've been doing this for not quite as long, but not a short period of time either. But if Matt is going to get on stage and he's going to say something that provocative, he's got something to follow it up and he has my attention. When you have someone who's relatively new to the industry on the other end of that spectrum,

then maybe one to three years of development experience, I'm a lot less likely to believe that necessarily because I've been through the cycle enough times to see tomorrow's amazing shiny technology turn into yesterday's garbage. And that leads to a certain cynicism at some point. Oh, you've got a new way to do, I don't know, logging or paging or whatever it may be.

I'm cynical. I'll hear you out, but I'm not going to suspend my disbelief. And what's strange to me is that the more I talk to people in this space, the more it seems like there's almost a bimodal distribution of people who've been either doing this for well over a decade or people who are relatively new to the industry. Is that something you're seeing or is that a selection bias on my part? That's an interesting observation. I want to explore that with you. I see it more as related to organizational size and expectations for the role that on the younger startup space, people are like, oh, everyone's saying dev advocate and dev route.

We should probably hire that too. And these individuals join an organization. It's unclear who their leadership is. They're probably rolling up into marketing or into engineering and then actually rolling up into marketing. And then they're asked to do everything from blog posts every week, write as many talks and get them accepted around the world at first class events, and then also maintain the documentation, maybe a few dozen GitHub, GitLab repositories, and then, you know, just do some more on the side, because that's not enough. And they kind of have the trial by fire version of what it means to be in an organization. They didn't want to go into engineering directly because maybe their coding isn't quite to that level. And they like to

socialize. So they wanted to be more on the social side of things. And that's what I see a lot of startups hiring for in the DevRel space. While like large organizations are really looking for subject matter experts with deep expertise that are talking about a specific topic in depth. And that is more of the fundamental thing. So I see more as an organizational struggle and maybe a budgeting struggle, if we're going to get honest about this, that it's easier to hire people earlier in their career in smaller organizations because it more aligns with a startup budget as opposed to larger ones. If we take a look across the ecosystem around people who have successfully transitioned into becoming developer advocates,

whatever ridiculous term you want to use for them, I still go with developer and I will die on that hill. What is it that separates them out from someone who continues down an engineering path or goes in a different business direction? It's a fantastic point to mention that DevReliper. Why DevReliper? Can we have a quick aside of all the things,

not DevRelian, not Developer Avocado or something like that? Because when I say dev reliper, people first think they misheard it, and then it finally sinks in, and they just stare at me with this disappointed look on their face, and it reminds me of growing up. That's fantastic.

Okay, so what does it look like from here? Okay, I think developer relations in practice is it's engineering that empathizes with its users. It means spending more time on documentation and discussions with end users than most people get the opportunity to do in their day. It's also mostly good marketing. It's the kind so good you actually give a damn when people say the words in front of you that sound like the words in the right order and not like word salad. And it's also community leadership. It's people that are uniting those that care about a given technology in a given space and providing empathy and leadership to do so. So what I love about it

is that anyone who is really good at any of those skills has every right to be in the developer relations space and to lead as a dev reloper. And whether that is a forever position or whether they decide, you know what, I want to do this more on the product management side, or I want to work back into engineering and lead developer experience efforts, or they want to be a technical marketer or product marketer, there's a wide breadth of expertise that they can bring to any organization if they do a stint in DevRel. Sounds completely reasonable. Thank you so much for taking the time to speak with me. If people want to hear more of your sage advice, where can they find you? I'm always happy to banter on Twitter at mbbroberg, or you can hit me up at mbbroberg.fun to reach out.

I'm sorry, did you say.fun? Absolutely. You ever get such a perfect setup pitch to make fun of someone and your mind goes completely blank and all you can do is point and do a ha ha? Yeah, I was really hoping, but I think I've set you up so much for my willingness for you to make fun of me that it's almost kind of surprising to you. And you seem at some point I start to feel bad for you. It's like, are you enjoying this? That's kind of sad.

Not to kink shame, but my God. No, this is lovely. No, Corey, I can't thank you enough. It's a pleasure to be here. And I'm happy to talk to anyone about this stuff or anything else related to my absurd profile. Matt Broberg at Red Hat slash IBM Hat, depending upon who you ask. I'm Corey Quinn. This is Screaming in the Cloud.

This has been this week's episode of Screaming in the Cloud. You can also find more Corey at Screaminginthecloud.com or wherever Fine Snark is sold. This has been a HumblePod production. Stay humble.