Screaming in the Cloud - Summer Replay - The Evolution of DevRel with Jeremy Meiss

Episode Date: June 27, 2024

Developer relations have gone through quite an evolution over the years. In this reissued episode, Corey talks with Jeremy Meiss, former Director of DevRel and Community at CircleCI, about how DevRel has transitioned from a focus on conference appearances to a more strategic alignment with business objectives. Corey and Jeremy also discuss navigating career complexities during economic downturns, emphasizing the importance of maintaining relevance. They also touch on fostering open communication within organizations and the enduring value of personal interactions in professional communities.Show Highlights:(1:39) How CircleCI is using DevRel to helping clients go from developer’s laptops to production safely and sanely(6:23) What DevRel means to Jeremy and why it’s a problem that most people can’t define it(12:40) Why saying DevRel is part of product ignores much of what makes both roles unique(15:36) Combating burnout from being able to perform you’re role but not feeling connected to what the company actually does(21:30) How Jeremy sees DevRel evolvingAbout Jeremy:Jeremy is the former Director of DevRel & Community at CircleCI, formerly at Solace, Auth0, and XDA. He is active in the DevRel Community, and is a co-creator of DevOpsPartyGames.com. A lover of all things coffee, community, open source, and tech, he is also house-broken, and (generally) plays well with others.Links Referenced:LinkedIn: https://www.linkedin.com/in/jeremymeiss/ Twitter:  IAmJerdog - Jeremy’s @DevOpsAms https://twitter.com/iamjerdog?lang=enSponsor:Panoptica: https://www.panoptica.app/  

If you're not happy with the tool you're using, you're not gonna be as productive if you're not enjoying what you're doing. Welcome to Screaming in the Cloud, I'm Corey Quinn. I generally try to have people that I know in the ecosystem on this show from time to time, but somehow today's guest has never made it onto the show. And honestly, I have no excuse other than that. I guess I just like being contrary about it.

Jeremy Meese is the director of DevRel and community at CircleCI. Jeremy, thank you for finally getting on the show. Hey, you know what? I woke up months and months ago hoping I would be able to join and never have. So I appreciate you finally, you know, getting that celestial kick in the ass. This episode's been sponsored by our friends at Panoptica, part of Cisco. This is one of those real rarities where it's a security product

that you can get started with for free, but also scale to enterprise grade. Take a look. In fact, if you sign up started with for free, but also scale to enterprise grade. Take a look. In fact, if you sign up for an enterprise account, they'll even throw you one of the limited, heavily discounted AWS skill builder licenses they got, because believe it or not, unlike so many companies out there,

they do understand AWS. To learn more, please visit panoptica.app slash last week in AWS. To learn more, please visit panoptica.app slash lastweekinaws. That's panoptica.app slash lastweekinaws. I love the fact that this is what you lie awake at night worrying about, as all people should. So let's get into it. I have been on record previously as talking about CI, CD, continuous integration slash continuous deployment, or for those who have not gone tumbling down that rabbit hole, the idea that when you push a commit to a particular branch on Git, or for those who have not gotten to that

point, push the button, suddenly code winds up deploying to different environments, occasionally production, sometimes staging, sometimes development, sometimes by accident. And there are a bunch of options in that space. AWS has a bunch of services under their CodeStar suite, CodeBuild, CodeDeploy, CodePipeline. And that's basically there as a marketing exercise by CICD companies that are effective. Because after having attempted to set those things up with the native offerings, you go scrambling to something else, anything else. GitHub Actions has also been heavily in that space

because it's low friction to integrate. It's already there in GitHub and that's awesome in some ways, terrible in others. But CircleCI has persistently been something that I see in a lot of different environments, both the open source world as well as among my clients

where they are using you folks to go from developer laptops to production safely and sanely. Absolutely. Yeah. And I think that's, that's one thing for us is there's a niche of, you know, you can start if you're in the AWS or you're in the Google or you're in what any of those big ecosystems, you can certainly use what they have, but those are always like add-on things. They're always like an afterthought of, oh, we're going to go ahead and add this, or we're going to go add that. And so I think you adequately described it of, you know, once you start hitting scale, you're eventually going to start to want to use something. And I think that's where we generally fit in that space of, you know, you can start, but now you're going to eventually end up here and use best in class. I spent years at Auth0 and in the identity space, and it was the same kind of boat is that, you know, sure, you can start with hopefully not

ruling your own, but eventually you're going to end up wanting to use something best in class that does everything that you want it to do and does it right. The thing that just completely blows my mind is how much for all of these companies, no matter who they are and how I talk to them, everyone talks about their CICD flow with almost a sense of embarrassment. And back in the days when I was running production environments, we used Jenkins as sort of the go-to answer for this. And that was always a giant screaming exception to the infrastructure as code approach, because you could configure it via the dashboard and the web interface, and it would write that out as XML files. So you wound

up with this bespoke thing lots of folks could interact with in different ways. And oh, by the way, it has access into development, staging, and production. Surely there will be no disasters that happen as a result of this. And that felt terrible. And now we've gotten into a place where most folks are not doing that anymore, at least with the folks that I talk to. But I'm still amazed by how few best practices around a lot of this stuff has really emerged. Every time I see a CICD pipeline, it feels like it is a reimplementation locally of solving a global problem. You're the director of DevRel and have been for a few years now. Why haven't you fixed

this yet? Primarily because I'm still stuck on the fact you mentioned pushing a button and getting to XML. That just kind of stuck me there and sent me back that I can't come up with a solution at this point. It's the way that you solve the gap, the schism, as it were, between JSON and YAML. Cool. We're going to use XML. Everyone's like, oh, God, not that. It's like, cool. Now you're going to settle your differences or I'm going to implement other things, too. That's right. Yeah. I mean, then we're going to go use some bespoke company's own way of doing IAC. No, I think there's an element here where, I mean, it goes back to still using best in class. I think Hudson, which eventually became's an element here where, I mean, it goes back to still using best-in-class. I think Hudson, which eventually became Jenkins after, you know, Cisco. Was it Cisco? No, it was

Sun. After Sun, you know, got their hands all over it. It was the thing. It's kind of, well, we're just going to spin this up and do it ourselves. But as the industry changes, we do more and more things on the cloud. And we do it primarily because we're relocating the things that we don't want to have to manage ourselves with all of the overhead and all of the other stuff. We're going to go spit it over to the cloud for that. And so I think there's been this shift in the industry that they still do, like you said, look at their pipelines with a little bit of embarrassment. I think, yeah, I chuckle when I think about that. But there is a piece where more and more people

are recognizing that there is a better way and that you can, you don't have to look at your pipelines as this thing you hate, and you can start to look at what better options there are than something you have to host yourself. What I'm wondering about now, though, because you've been fairly active in the space for a long time, which is a polite way of saying you have opinions, and you should hear the capital O in opinions when I say it that way. Let's fight about DevRel. What does DevRel mean to you,

or as I refer to it, DevRelipers. DevRelipers, yes. You know, not to take from the standard DevOps answer, but I think it depends. That's the standard lawyer answer to anything up to and including, is it legal for me to murder someone? And it's also the senior consultant answer to anything too, because it turns out the world is baked in nuance and doesn't lend itself to being resolved in 280 characters or less. That's what threads are for. Right. Trademark. That is ultimately the answer, I think, with DevRel. For me, it is depending on what your company is trying to do. You ultimately want to start with building relationships with your developers because they're the ones using your product. And if you can get them excited about what they're doing with your

product or get excited about your product with what they're doing, using your product. And if you can get them excited about what they're doing with your product or get excited about your product with what they're doing, then you have something to stand on. But you also have to have a product fit. You have to actually know what the hell your product is doing and is it going to integrate with whatever your developers want.

And so DevRel kind of stands in that gap that says, okay, here's what the community wants and advocates for the community. And then you have, that's going to advocate for the company back to the community. And hopefully at the end of the day, they all shake hands. But also I've been around enough to recognize that there's comes that point where you either a have to say, Hey, our product for that thing is probably not the best thing for what you're trying to do here. You should maybe start at this other point. And also understanding to take that even to the next step to finish up the answer,

like my biggest piece now is all the fights that we have constantly around DevRel in the space of what is it and what is it not. DevRel is marketing. DevRel is sales, DevRel is product. And each of those, if you're not doing those things as a member of the company, you're not doing your job. Everybody in the company is the product. Everybody in the company is sales. Everybody in the company is marketing. Not everyone in the company realizes this, but I agree wholeheartedly. Yes. And so that's where it's like, yes, DevRel is marketing. Yes, it is sales. And because if you're not out there spreading whatever the news is about your product and you're not actually showing people how to use it and answering and making things

easier for people, you're not going to have a job. And too often, these companies that, or too often, I think a lot of DevRel teams find themselves in places where they're the first that get dropped when the company goes through things, because sometimes it is just the fact that the company has not figured out what they really want.

But also sometimes it's the team hasn't really figured out how to position themselves inside the business. One of the biggest, I'll call it challenges that I see in the DevRel space comes down to defining what it is first and foremost. I think that it is collectively a mistake for an awful lot of practitioners of developer relations to wind up saying first and foremost that we're not marketing. Well, what is it that you believe that marketing is? In fact, I'll take it a step beyond that. I think that marketing is inherently the only place in most companies where we know that doing these things leads to good results, but it's very difficult to attribute or define that value.

So how do we make sure that we're not first off on the chopping block? That has been marketing's entire existence. It's, you know, that doing a whole bunch of things in marketing will go well for you. But as the old chestnut says, half your marketing budget is wasted and you'll go broke figuring out which half it is. Yeah. And whenever you have to make cuts, generally, they always come to the marketing teams. Because, hey, they're the ones spending millions of dollars a quarter on ads or whatever it is. And so, yeah, marketing has in many ways figured this out. They're also the team that spends the most money in a company. So I don't really know where to go with that.

That isn't completely off the rails, but it is the reality. Like that's where things happen. And they are the most in touch with what the direction of the company is going to ultimately be received as and how it's going to be spoken about. And DevRel has great opportunities there.

I find that when people are particularly militant about not liking sales or marketing or any other business function out there, one of the ways to get through them is to ask, great, in your own words, describe to me what you believe that department does. What is that? And people will talk about marketing in a bunch of tropes or sales on a bunch of tropes where it is the worst examples of that. It's terrific. Great. Do you want me to wind up describing what you do as an engineer in many cases in the most toxic stereotype of Uber in 2015 style engineer I can come up with? I think in most cases, if we're having a conversation and I haven't ended it by now, you would be horrified by that descriptor. Yeah. And not every salesperson is the skeezy used car salesman trying to trick you into something awful. Actual selling comes down to

how do we wind up taking your pain away? One of my lines is I'm a consultant. You have problems and money. I will take both. Yeah, that's right. If you don't have a painful problem, I have nothing to sell you. And all I'm doing is wasting my breath trying. Yeah, exactly. And that's where I'll say two ways. The difference between good marketing teams are is understanding that pain point of the people that they're trying to sell to. And that's also a difference between good good and bad. Even DevRel teams is understanding what are the challenges that your users are having that you're trying to express to you're trying to fix, figure that out. Because if you can't figure that out, then

you or your marketing team are probably soon to be on the block and they're going to bring someone else in. I'm going to fight you a little bit, I suspect, in that a line I've heard is that, oh, DevRel is part of product because we are the voice of the community back into the development cycle of what product is building. And the reason that I question that is I think that it glosses over an awful lot of what makes product competent as a department and not just a function done by other people. It's, oh, you're part of the product, or great. How much formal training have you had as part of your job in conducting user research and interviews with users and the rest? And the answer invariably rounds to zero. And okay, in other words, you're just giving feedback in a drive-by fashion that's not structured in any way, and your product people are polite enough not to call you out on it.

And that's when the fighting and slapping begins. Yeah, I don't think we're going to disagree too much there. I think one of the challenges, though, is for the very reason you just mentioned that the product teams tend to hear, your product sucks, and we've heard all the people telling us that. Like, people in the community say that.

They hear that so much, and they've been so conditioned to it that it just rolls off their back. Like, okay, whatever. So for DevRel teams, even if you're in product, which we can come back to that, regardless of where you're at, bringing any type of feedback you bring should have a person, a name associated with it, with like, Corey at Duckbill Group hates this product. Oh, remember, my name is tied to feedback.

It never goes well for me, but that will teach me eventually, ideally to keep my mouth shut. Yeah. Well, how's that working for you? I'll let you know if it ever happens. Good. But once you start making the feedback like an actual person, it changes the conversation because now it's like, oh, it's not this nebulous like thing I can not listen to. It's now, oh, it's actually a person at a specific company. So

that's one of the challenges that in working with product that you have to overcome. When I think about DevRel in product, while I don't think that's a great spot for it, I think DevRel is a extension of product. That's part of where the big developer experience craze comes from and why it is a valuable place for DevRel to be able to have input into is because you tend to be the closest to the people actually using the product. So you have a lot of opportunities and a big surface area to have some impact. Few things are better for your career and your company

than achieving more expertise in the cloud. Security improves, compensation goes up, employee retention skyrockets. Panoptica, a cloud security platform from Cisco, has created an academy of free courses just for you. Head on over to academy.panoptica.app to get started. I think that that is a deceptively nuanced statement. One of the things I learned from an earlier episode I had with Dr. Christina Maslach

is contributors to occupational burnout, so much of it really distills down, using, I guess my crappy layman's terms, to a lack of, I guess what I would call relevance, or a lack, a feeling like you are not significant to what the company is actually doing in any meaningful way. And I will confess to having had a number of those challenges in my career when I was working in production environments. Because, yeah, I kept the servers up and the applications up. But if you really think about it, one of the benefits of working in the system space or the production engineer space or DevOps or platform engineering, or don't even start with me these days, is that what you do conveys

almost seamlessly from company to company. The same reason that I can do what I do conveys almost seamlessly from company to company. The same reason that I can do what I do now. I don't care what your company does necessarily. I just know that the AWS bill is a bounded problem space and I can reason about it almost regardless of what you do. And if I'm keeping the site up, well, okay, it doesn't matter if we're streaming movies or selling widgets or doing anything just so long as I don't find that it contradicts my own values. And that's great. But it also is isolating because you feel like you're not really relevant to the direction of what the company actually does. It's, okay, so what does

this company do? We make rubber bands. Well, I'm not really a rubber band connoisseur, but I could make sure that the website stays up. It just feels like there's a disconnect element happening. That is real. It is very real. And one of the ways that I try to kind of combat that, and I help my team kind of really try and keep this in mind, is we try to meet as much as possible with the people that are actually doing the direction, whether

it be for product marketing or whether it's in product managers or it's even in engineering, is have some regular conversations with what we do as a company. How are we going to fit with that in what we do and what we say and all of our objectives and making sure that everything we do ties to something that helps other teams and that fits within the business and where it's going so that we grow our understanding of what the company is trying to do so that we don't kind of feel like a ship that's without a sail and just floating wherever things go. On some level, I am curious as to what you're seeing as we navigate this.

I don't know if it's a recession. I don't know if it's a recession. I don't know if it's a correction. I'm not sure what to call it. But my gut tells me that a lot of things that were aimed at, let's call it developer quality of life, they were something of a necessity in the unprecedented bull market that we've seen for the last decade at some point, because most companies cannot afford to compete with the giant tech company compensation packages. So you have to instead talk about quality of life and what work-life balance looks like. And here's why all of the tools and processes here won't drive you to madness.

And now it feels like, oh, we don't actually have to invest in a lot of those things just because, oh yeah, like the benefits here are you're still going to be employed next week. So how about that? And I don't think that that's a particularly healthy way to interact with people. It's certainly not how I do, but it does seem that worrying about keeping developers absolutely thrilled with every aspect of their jobs has taken something of a backseat during the downturn. I don't know. I feel like developer satisfaction is still an important piece,

even though, you know, we have a changing market. And as you described, if you're not happy with the tool you're using, you're not going to be as productive than using the tool or using, you know, whether it's an actual developer productivity tool, or it's even just the fact that you might need two monitors. You're not going to be as productive if you're not enjoying what you're doing. So there is a piece of it I think that companies are recognizing that there are some tools that do ultimately benefit. And there's some things that they can say, we're not going to invest in that area right now. We're good with where we're at.

On some level, being able to say, no, we're not going to invest in that right now is the right decision. It is challenging in some cases to wind up talking to some team members in some orgs who do not have the context that is required to understand why that decision is being made. Because without context, it looks like, no, I'm just canceling Christmas for you personally this year. Sorry, doesn't it suck to be you, dot, dot. And that is very rarely how executives make decisions, except apparently if they're Elon Musk. Right, well, the Muskrat can, you know, sink any company he wants.

Play with it. And that's one thing I've really been happy with where I'm at now, is you have a leadership team that says, hey, here's where things are and here's what it looks like and here's how we're all contributing to where we're going and here's the decisions we're going to make and here's how, like, they're very open with what's going on. And it's not a surprise to anybody that the economic time means that we maybe can't go to 65 events next year. Like, that's just reality.

But at the end of the day, we still have to go and do a job and help grow the company. So how can we do that more efficiently, which means that it leaves it better to try and figure that out than to be so nebulous with like, yep, nope, you can't go do that. That's where true leadership comes to, too. It's like laying it out there and just getting people alongside with you. How do you see DevRel evolving? Because I think we had a giant evolution over the past few years because suddenly the old vision of DevRel,

at least in some quarters, which I admit I fell a little too deeply into, was I'm going to go to all of the conferences and give all of the talks, even though most of them are not related to the core of what I do. And maybe that's a viable strategy. Maybe it's not. I think it depends on what your business does. And I don't disagree with the assertion that going and doing something in public can have excellent downstream effects, even if the connection is not obvious. But suddenly we weren't able to do that. And people were forced to almost reinvent how a lot of that works. Now that the world is, for better or worse, starting to open up again, how do you see it

evolving? Are we going right back to a different DevOps days in a different city every week? I think it's a lot more strategic now. I think generally, there is less mountains of money that you can pull from to go and do whatever the hell you want. You have to be more strategic. I said that a few times. Like there's looking at it and making sure like, yeah, it would be great to go and, you know, get in front of 50,000 people this quarter or this year or whatever, whatever you want to do. But is that really going to move the bottom line for us? Is that really going to help the business line for us? Is that really going to help the

business or is that just helping your Delta miles? What is really the best bang for the buck? So I think DevRel as it evolves in the next few years has to come to a good recognition moment of we need to be a little bit more prescriptive in how we do things within our company and not so willy-nilly return to what we generally used to get away with. That means you're going to see a lot more people have to be held to account within their companies of, is what you're doing actually match up to our business goal here? How does that fit in having to explain more of that? And that's, I think for some people will be easy. Some people are going to have to stretch that muscle and others are going to be in a real tough pickle.

One last topic I want to get into with you is DevOpsPartyGames.com, an online, more or less, DevOps quote-unquote personality assortment of folks who wind up playing online games. I was invited once and promptly never invited back ever again. So first, was it something I said, obviously? And two, what is that and how is that still going in this post-pandemic-ish era? I like how you answered your own question first. That way I don't have to answer it. The second one, the way it came about was just, you know, Maddy and I had started missing that interaction that we would tend to have in person. And so one of the ways we started realizing is we play these, you know, Jackbox games,

and why can't we just do this with DevOps tech prompts? So that's kind of how it kicked off. We started playing around and doing it for fun. And then it was like, we could do this as a big, big deal for foreseeable future. Where is that now? Is we actually have not done one online for, what is it? So probably like eight, nine months, primarily because it's harder and harder to do so. As everybody, we're now doing a little bit more travel and it's hard to do those, as you know, doing podcasts, it takes a lot of work. It's not an easy kind of thing. And so we've kind of put that on pause.

But we actually did our first in-person DevOps Party Games at DevOps Day Chicago recently. And that was a big hit, I think, and an opportunity to take what we were doing virtually, and the fun and excitement that we generally would have, relatively half drunk, to actually doing it actually in person at an event. And just as giving talks in person was a different level of interaction with the crowd,

the same thing is doing it in person. So it was just a fun thing and an opportunity maybe to continue to do it in person. I think we all got a hell of a lot better very quickly at speaking to cameras instead of audiences and the rest. It also forced us to be more focused because the camera gives you nothing in a way that the audience absolutely does. They say make love to the camera, but it doesn't work anyways. I really want to thank you for spending as much time as you have talking to me. If people want to learn more about who you are and what you're up to, where should they go? Well, for the foreseeable future, or at least what we can guess, you can find me on the Twitters at IamJerDog. You can

find me there, or you can find me at LinkedIn, Jeremy Meese LinkedIn, and probably come into your local DevOps Days or other conference as well. Of course. And we will, of course, put links to that in the show notes. Excellent. Thank you so much for being so generous with your time. It is always appreciated. And I do love talking with you. And I appreciate it, Corey. It was great to be on, finally. I won't hold it against you anymore. Jeremy Meese, Director of DevRel at CircleCI. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry, irritated comment talking about how CICD is

nonsense and the correct way to deploy to production is via the tried and true method of copying and pasting. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.