Subscribe
Share
Share
Embed
For the last five years, Matt Broberg has worn many different developer advocate hats. These days, his developer hat looks a bit … red ... as he’s an advocate, writer, and editor for opensource.com at Red Hat. Join Corey and Matt as they discuss IBM’s recent acquisition of Red Hat, open source culture and how to contribute without submitting code, the rise of developer relations and whether the term “DevRel” will stick, what developer relations actually is, what its future looks like, and more.
Screaming in the Cloud with Corey Quinn features conversations with domain experts in the world of Cloud Computing. Topics discussed include AWS, GCP, Azure, Oracle Cloud, and the "why" behind how businesses are coming to think about the Cloud.
Transcript
Speaker 1: 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 Cory refuses to apologize. This is Screaming in the Cloud.
Corey: This week’s episode of Screaming in the Cloud is sponsored by X-Team. X-Team is a 100% remote company that helps other remote companies scale their development teams. You can live anywhere you like and enjoy a life of freedom while working on first-class company environments. I gotta 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 gotta 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 would like to work for a company that doesn’t require that you live in San Francisco, take my advice and check out X-Team. They’re hiring both developers and devops engineers. Check them out at the letter x dash Team dot com slash cloud. That’s x-team.com/cloud to learn more. Thank you for sponsoring this ridiculous podcast.
Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Matt Broberg. Welcome to the show, Matt.
Matt: Thank you so much, Corey. It's a pleasure to be with you.
Corey: 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 workshoped that to no end.
Matt: I mean, you can just do the kind of kissing motion while doing ... Just tastes good when you say it.
Corey: Exactly. But it continues. He's a serial podcaster, best known for The Geek Whisperer's 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 added that.
Matt: That part's on the bio, yeah.
Corey: Yeah. Co-maintains the DevRel Collective, which I'm sure we'll get into, and often shares his thoughts on Twitter and GitHub.
Corey: Do you share your thoughts about GitHub on Twitter or vice versa?
Matt: Oh, dear God. I think you're really just reminding me I'm due for a revision on this.
Corey: Well, absolutely. There's no time like preparing for something until right after the point you really need to do, which why not? Game on. I might have you back some day.
You currently work at IBM Hat as a technical advocate and editor for Opensource.com
Matt: 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 the open source licensing. So, it's really great place to share and engage in the open source culture and to do so in a way that doesn't focus on code contributions since we all know that's not the only way to contribute back to open source.
Corey: 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-
Matt: I did.
Corey: ... the good sense never to invite me back.
Matt: Well, yeah. I mean, it doesn't come to memory, so I guess it wasn't on purpose, but yeah, maybe next time, Corey.
Corey: Exactly. And no, you are at Red Hat, which at the time of this recording, has just recently been acquired by IBM. So, the hats are red, but the suits are IBM blue.
Matt: 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 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 stark 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.
Corey: It seems that everyone I've talked to there has continually nice things to say, which tells me that their legally required to. Which is fine, and that's not the point of having you on.
Matt: No, sir.
Corey: 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?
Matt: You know what, Cory, 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. My last three jobs have all been focused on DevRel. And on the side I've been really fortunate to participate in the DevRel Collective, which is this brilliant little brainchild of Dave Josephsen who wanted to get other people that were firmly developer evangelists, talking to each other on the side and getting each other some support because it was so frequently teams of one 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, 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 awhile.
Corey: 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 DevReloper as I insist on calling them?
Matt: Not at the moment. No, I definitely am good at playing one on TV as need be. I definitely think of it as like a bit of a caricature you have to play sometimes, but 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 advocate's role is to be.
Google has a definition as well from 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. 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.
Corey: 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?
Matt: Well, so I gave you the textbook definition by-
Corey: Yes, but now I want to hear it applied.
Matt: 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.
Corey: 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. So, cool.
Matt: I thought you weren't going to have an opinion on this, Corey.
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.
Matt: Ah, I see. I see.
Corey: 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 mention the company because now they're talk about how to choose the proper standing desk for your home office is what they're focusing on and that'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 and capsulation of the role, but to someone not steeped in it, it doesn't sound like it's that far from it.
Matt: Yeah. That can be a pretty tough pill to swallow if you're in the profession right now and you hear that description. That is 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 are also DevRel and they're in the same space.
Corey: Forget annoying description. I'm pretty sure that was a verbatim job posting two years ago.
Matt: I am not going to advocate or argue against that, but I will say that 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 ... 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 how well funded they are.
I think early startups to 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 hearts and minds by having somebody who is, 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?
Corey: 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.
Matt: Fair enough. Fair enough. Okay. So, 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 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, if you look at the top three cloud vendors of Google, Amazon and Microsoft, you see really deep lineups of developer advocates and each of them are focused on some form of public speaking, some form of listening to users in a very strategic way and then trying to provide a better experience for their particular cloud by in whatever way they think makes sense to them.
You recently had Jess Rozelle on the show. I think Jess is one of those secret superpowered dev advocate types who 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 what are people piss about? How can I go find the person that can fix that and hold their head towards the tweet that says how bad it is until they actually fix it? That is one of the superpower kind of elements of a DevRel
Corey: And we're calling those individuals a DevRel as a singular now? That's the terminology and nomenclature we've settled on?
Matt: No, I'm terribly sorry and I would love to provide an alternative. So, Developer Relations would be ...
Corey: Oh, 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.
Matt: 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 thinking 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 general purpose unicorns as we're talking about right now. You might also have developer experience engineers in that organization that focus more on SEKs 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 goals is to convert people into sales opportunities.
Corey: 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 far away trips to expensive places. But the question then immediately emerges, how do you measure that value that you're getting from it?
Matt: 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 that ... 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 DevRel 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, we just make things better for the company type statements, which don't tend to land well in a boardroom scenario. But to double down on that for a second-
Corey: Right. 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.
Matt: Yeah, exactly. So, 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 in droves still? It's that the 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. 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 money maker, but we're living in the wake of developers being the new king makers and that whole idea-
Corey: Nice reference.
Matt: 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 in the right organizations?
Corey: This week’s episode is sponsored by CHAOSSEARCH. If you’ve ever tried managing Elasticsearch yourself, you know that it is of the Devil. You have to manage a series of instances, you have to potentially deal with a managed service. What if all that went away? CHAOSSEARCH 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, 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 CHAOSSEARCHING they cannot find the caps lock key to turn it off. My thanks to CHAOSSEARCH for sponsoring this ridiculous podcast.
Corey: 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. 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 impact, but it never works that way. I mean, there's 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 16th impression winds up getting all the credit and everything else was just a waste of money, but it's not how it works.
Matt: 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 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.
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 engaged 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 first push to their API, they sign up for a new account. So, it's an easy ROI conversation.
When it gets quite tricky is when we focus on where our hearts are here in the 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 talk to that dev advocate.
So, there are things that are easy quantitatively to measure, but that doesn't make them qualitatively correct. Finding the line between what's easy to measure it and what's useful to measure is something that we're still way off on as a principal. If I could tell you the one thing that has to be measured across all organizations, I absolutely would, but I have 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.
Corey: 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 org at 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 is its own skillset and making sure that you wind up asking the right questions in the right way is incredibly complex. I mean, 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.
So, 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 farfetched.
Matt: Yeah. I mean, you're scratching on that itch again of just, we're asking too much from a single new idea. I do want to give a shout-out, not that he will 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 he 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 has an additive value in this current state of affairs in the current time that we're in, in the current market we're in.
Corey: Absolutely. And one thing I want to address is why-
Matt: It's kind of open for you to argue with me. I'm not going to lie.
Corey: I don't know. I don't know if I agree with you or not. I think that it's a nuanced issue and 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 and 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, and 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.
Matt: Ooh, 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 their latest version of a webpage or new place where you can add your email to get a cookie.
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 life cycle of the product.
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 has those tough conversations when they need to.
It's part of the job for sure, to put your yourself out there and 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 and that's resulted in both.
Corey: Absolutely. And 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. He's been doing this for 20 years, so if he 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 Matty's 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 and 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 as 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 were relatively new to the industry. Is that something you're seeing or is that a selection bias on my part?
Matt: 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 DevRel, 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 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. That's what I see a lot of startups hiring for in the DevRel space. While larger 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.
Corey: So, if we take a look across the ecosystem around people who have successfully transitioned into becoming developer advocates or whatever ridiculous term we want to use for them. I still go with DevReloper and I will die on that hill. What is it that, I guess, that separates them out from someone who continues down an engineering path or goes in a different business direction?
Matt: It's a fantastic point to mention that DevReloper ... Why DevReloper? Wait, can we have a quick aside? Of all the things, not DevRelian, not Developer Avocado or something like that?
Corey: Because when I say DevReloper, 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.
Matt: 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 DevReloper 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 a product marketer, there's a wide breadth of expertise that they can bring to any organization if they do a stint in DevRel.
Corey: Sounds completely reasonable. Matt, 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?
Matt: I'm always happy to banter on Twitter at M.B Broberg or you can hit me up at mbbroberg.fun to reach out.
Corey: I'm sorry, did you say dot fun?
Matt: Absolutely.
Corey: Do you ever get ... Well, it's just 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.
Matt: 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 to be [crosstalk 00:35:20].
Corey: At some point I start to feel bad for you. Are you enjoying this? That's kind of sad. Not to kink shame, but my God.
Matt: 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.
Corey: Matt Broberg at Red Had/IBM Hat, depending upon who you ask. I'm Corey Quinn. This is Screaming in the Cloud.
Speaker 1: 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.
Speaker 4: This has been a HumblePod production. Stay humble.