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

Episode Date: February 2, 2023

About JeremyJeremy is the 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:CircleCI: https://circleci.com/DevOps Party Games: https://devopspartygames.com/Twitter: IamjerdogLinkedIn: https://www.linkedin.com/in/jeremymeiss/

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, 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 episode is sponsored in part by our friends at Logicworks. Getting to the cloud is challenging enough for many places,

especially maintaining security, resiliency, cost control, agility, etc., etc., etc. Things break, configurations drift, technology advances, and organizations, frankly, need to evolve. How can you get to the cloud faster and ensure you have the right team in place to maintain success over time? Day two matters. Work with a partner who gets it. Logicworks combines the cloud expertise and platform automation to customize solutions to meet your unique requirements. Get started by chatting with a cloud specialist today at snark.cloud slash logicworks. That's snark.cloud slash logicworks. And my thanks to them for sponsoring this ridiculous podcast. 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 getting that celestial kick in the ass. 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. You have been at CircleCI in their DevRel org,

heading their DevRel org, for approximately 20 years, but in real time, in non-tech company timeframes, three years. But it feels like 20. How's that been? It's been an interesting three years, I'll say that much, with the plague or the land. Yes, absolutely. No, it was definitely a time to join. I joined two weeks before the world went to shit, or shittier than it already was. And yeah, it's been a ride. Definitely see how everything's changed. But it's also been one that I couldn't be happier where I'm at and seeing the company grow. I've got to level with you. For the longest time, I kept encountering CircleCI in the same timeframes and contexts as I did TravisCI. They both have CI in the name, and I sort of got stuck on that. And telling one of the companies apart from the other was

super tricky at the time. Now it's way easier because Travis CI got acquired and then promptly imploded. Security issues that they tried to hide left and right. Everyone I knew there long since vanished. And at this point, it is borderline negligence from my point of view to wind up using them in production. So, oh yeah, CircleCI, that's the one that's not trash. I don't know that you necessarily want to put that on a billboard somewhere, but that's my mental shortcut for it. You know, I'm not going to disagree with that. I think, you know, it had its place.

I think there's probably only one or two companies nowadays actually propping it up as a business. And I think even they are actively trying to get out of it. So, yeah, not going to argue there. 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 circle CI 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 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 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've, we generally fit in that, that space of, you know, you can start, but now 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 rolling 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 in 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

Jenkins after, you know, Cisco, was it Cisco? No, it was a 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 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, then you have something to stand on. But you also have to have a product fit. You have to 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 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 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. 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 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. That's right. 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 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, like 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. Uh-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 that's a great spot for it, I think DevRel is an 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. This episode is sponsored in part by our friends at Strata. Are you struggling to keep up with the demands of managing and securing identity in your distributed enterprise IT environment? You're not alone, but you shouldn't let that hold you back. With Strata's Identity Orchestration Platform, you can secure all your apps on any cloud with any IDP, so your IT teams will never have to refactor for identity again. Imagine modernizing app identity in minutes instead of months,

deploying passwordless on any tricky old app, and achieving business resilience with always on identity all from one lightweight and flexible platform want to see it in action share your identity challenge with them on a discovery call and they'll hook you up with a complimentary pair of airpods pro don't miss out visit strata.io slash screamingcloud. 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 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 and 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 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 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

and 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? 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 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 we, 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, is 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 corners, 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've said that a few times. There's looking at it and making sure like, yeah, it would be great to go and get in front of 50,000 people this quarter or this year or 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 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, Maddie 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 deal for the 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, an opportunity to kind of 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 in the different, like 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 kind of a fun thing and 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. That's right. 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 being on, finally. I won't hold it against you anymore. Jeremy Meese, Director of DevRel at CircleCI. I'm Cloud Economist Corey Quinn. I won't hold it against you anymore. 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.