Summer Replay – The Evolution of DevRel with Jeremy Meiss

• (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 evolving

• LinkedIn: https://www.linkedin.com/in/jeremymeiss/ 
• Twitter:  IAmJerdog - Jeremy’s @DevOpsAms https://twitter.com/iamjerdog?lang=en

Transcript

Jeremy: If you're not happy with the tool you're using, You're not going to be as productive if you're not enjoying what you're doing.

Corey Quinn: 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.

Jeremy: 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.

Corey Quinn: This episode has 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 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.

That's panoptica. app slash last week in AWS. 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 a different environment. 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.

Jeremy: 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 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 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 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, you know, 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.

Corey Quinn: 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 re implementation 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?

Jeremy: 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.

Corey Quinn: 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.

Jeremy: 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 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, there's been this shift in the industry that they still do, like you said, look at their pipelines with, you know, 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.

Corey Quinn: 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, DevRelopers.

Jeremy: DevRel, of course. Yes. You know, not to take from the standard DevOps answer, but I think it depends.

Corey Quinn: 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.

Jeremy: 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, to recognize that there's comes that point where you either a have to say, Hey, our product for that thing is, 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 Everybody in the company is sales.

Everybody in the company is marketing.

Corey Quinn: Not everyone in the company realizes this, but I agree wholeheartedly.

Jeremy: Yes, and so that's that's where it's like, yes, DevRel is marketing. Yes, it is sales. Because if you're not out there spreading whatever the news is about your product and you're not actually, you know, 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, 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.

Corey Quinn: 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 chomping 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.

Jeremy: Yeah, and whenever you have to make cuts, generally, they always come, you know, always come to the marketing teams.

Because, hey, they're the ones spending, you know, millions of dollars a quarter on, you know, Ads or, you know, whatever it is. And, and so, yeah, marketing has in many ways figured this out. They're also the team that, 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.

Corey Quinn: 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 in 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, 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.

Jeremy: That's right. Yeah, that's right.

Corey Quinn: If you don't have a painful problem, I have nothing to sell you. And all I'm doing is wasting my breath trying.

Jeremy: 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 it's also a difference between like, good and bad, even DevRel teams, is understanding what are those 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.

Corey Quinn: 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. 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 and 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.

Jeremy: 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 it, 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

Corey Quinn: 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.

Jeremy: Yeah, well how's that working for you?

Corey Quinn: I'll let you know if it ever happens.

Jeremy: 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 one of the challenges that in working with product that you have to overcome. When DevRel in product, while I don't think 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, 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. in a big surface area to have some impact.

Corey Quinn: 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 a mess by 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, it just feels like there's a disconnect element happening.

Jeremy: 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, you know, 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, we don't kind of feel like a ship that's without a sail and just floating wherever things go.

Corey Quinn: 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.

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 being 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.

Jeremy: 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. Then 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.

Corey Quinn: 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 dot dot. And that is very rarely how executives make decisions, except apparently if they're Elon Musk.

Jeremy: Right, well, the muskrat can, you know, sink any company he wants to 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 makes, 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, too. It's like laying it out there and, and just, you know, getting people alongside with you.

Corey Quinn: 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?

Jeremy: 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. 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, this year, 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, 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, you know, 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 would be easy Some people are gonna have to stretch that muscle and others are gonna be in a real tough pickle

Corey Quinn: 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?

Jeremy: 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 should, 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, uh, what is it? So probably like eight, nine months. Primarily because it's harder and harder to do so.

As everybody, we're now, you know, 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 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, you know, A different level of interaction with the crowd, the same thing as doing it in person.

So it was just kind of a fun thing and an opportunity maybe to continue to do it in person.

Corey Quinn: 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.

Jeremy: They say make love to the camera, but it doesn't work anyways.

Corey Quinn: 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?

Jeremy: Well, uh, for the foreseeable future, or at least what we can guess, uh, you can find me on the Twitters at IamJaredog.

You can find me there or you can find me at, you know, LinkedIn at JeremyMeesLinkedIn and, you know, come probably come into your local, uh, DevOpsDays or other conference as well.

Corey Quinn: Of course, and we will of course put links to that in the show notes.

Jeremy: Excellent.

Corey Quinn: Thank you so much for being so generous with your time.

It is always appreciated and I do love talking with you.

Jeremy: And I appreciate it, Corey. It was great being on, finally. I won't hold it against you anymore.

Corey Quinn: 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 5 star review on your podcast platform of choice.

Whereas if you've hated this podcast, please leave a 5 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 CICD. 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.