Screaming in the Cloud - Doing DevRel on Easy Mode with Matty Stratton

Episode Date: April 12, 2022

About “Matty”Matt Stratton is a Staff Developer Advocate at Pulumi, founder and co-host of the popular Arrested DevOps podcast, and the global chair of the DevOpsDays set of conferences.Matt has over 20 years of experience in IT operations and is a sought-after speaker internationally, presenting at Agile, DevOps, and cloud engineering focused events worldwide. Demonstrating his keen insight into the changing landscape of technology, he recently changed his license plate from DEVOPS to KUBECTL.He lives in Chicago and has three awesome kids, whom he loves just a little bit more than he loves Diet Coke. Matt is the keeper of the Thought Leaderboard for the DevOps Party Games online game show and you can find him on Twitter at @mattstratton.Links ReferencedPulumi: https://www.pulumi.com/Arrested DevOps: https://www.arresteddevops.com/8bits.tv: https://8bits.tvTwitter: https://twitter.com/mattstrattonLinkedIn: https://www.linkedin.com/in/mattstratton/speaking.mattstratton.com: https://speaking.mattstratton.comtwitch.tv/Pulumi: https://twitch.tv/Pulumi8bit.tv: https://8bit.tvduckbillgroup.com: https://duckbillgroup.com

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 Vulture, spelled V-U-L-T-R, because they're all about helping save money, including on things like, you know, vowels.

So what they do is they are a cloud provider that provides surprisingly high performance cloud compute at a price that, well, sure, they claim it is better than AWS's pricing. And when they say that, they mean that it's less money. Sure, I don't dispute that. But what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to cost. They have a bunch of advanced networking features. They tell you in advance on a monthly basis what it's going to cost. They have a bunch of advanced networking features. They have 19 global locations and scale things elastically, not to be confused with openly, which is apparently elastic and open. They can mean the same thing sometimes. They have had over a million users. Deployments take less than 60 seconds across

12 pre-selected operating systems, or if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vulture Cloud Compute, they have plans for developers and businesses of all sizes, except maybe Amazon,

who stubbornly insists on having something of the scale on their own. Try Vulture today for free by visiting vulture.com slash screaming, and you'll receive $100 in credit. That's v-u-l-t-r dot com slash screaming. Couchbase Capella database as a service is flexible, full-featured, and fully managed with built-in access via key value, SQL, and full-text search. Flexible JSON documents align to your applications and workloads. Build faster with blazing fast in-memory performance and automated replication and scaling while reducing cost. Capella has the best price performance of any fully managed document database.

Visit couchbase.com slash screaming in the cloud to try Capella today for free and be up and running in three minutes with no credit card required. Couchbase Capella. Make your data sing. Welcome to Screaming in the Cloud. I'm Corey Quinn. Returning today for yet another round on the Screaming in the Cloud podcast is my dear friend, and hopefully yours as well, Maddy Stratton. Since the last time we spoke, you've changed jobs, Maddy. You're now a staff developer advocate at Pulumi.

I don't believe you were the last time you were on this show, but memory escapes me. You know, I was just wondering that myself, and I guess we'll have to go back to the archives. Yes, but that sounds like work, so we're going to roll with it anyway. Everyone who's listening, go do the homework for us and, like like just tweet and let us know what my job was last time. And yell at us if we get it wrong, of course. Yell at us if we get it right. In the interest of being, well, I guess a little on the judgy side, because why not? I tend to be good at that. I was hoping to be on the judgy side on this show. You have a very strange career trajectory in that of the companies you work for and how that winds up going back and forth.

When we first met, you were at Chef. And Chef, great company. And after that, it was PagerDuty. Great company. And then it was IBM Hat, which I, was it Red Hat? Was it IBM side? For me, it was IBM hat, which I, was it red hat? Was it IBM side? For me, it was red hat. So it went from Chef, which is great,

a company that was doing a lot of things for the container side of the world, became a thing and immutable infrastructure did sort of change Chef's business model. And then you went to pager duty, the wake you up in the middle of the night service named after some legacy technologies. And to be very direct in the popular consciousness.

IBM views pagers as newfangled technology in some circles, in some areas. So it feels like you were traveling back in time a bit, again and again and again, on the federal side as well, which, for excellent reasons, is not usually the absolute bow wave of innovation, because you don't usually want your government doing that in some ways. And now you've leapfrogged into Pulumi, which is sort of the bleeding edge of the modern way we think about provisioning cloud infrastructure. It feels like it's a very interesting trajectory. Now, this is speaking as a complete outsider. I'm going to assume that's not how you view basically any characterization of any of those companies I have just named. How do you view it? You know, I don't know that I necessarily disagree with the

way that you've put everything, but there is some nuance and some interesting stuff when it comes to that. So I'm going to specifically talk about the Red Hat thing. Why did I leave PagerDuty? And one of the interesting things is I actually had an offer from Pulumi at the time that I took the job from Red Hat. So it actually took me a year to come and work at Pulumi. And the little bit of the short answer is Red Hat backed up a big truck of money. And we have what we all have a price. Yeah, the dulcet tones of a dump truck full of gold bricks emptying itself into your backyard is hard to say no to. The reason that I want to bring that up is that has nothing to do with specifically Red Hat, the company, versus other companies.

It was the role. It was a sales-oriented role. So if you don't know, sales gets paid a lot of money, and there's good reason. One of the reasons, again, if you don't work in sales, you don't necessarily know this, is the last day of the quarter, you will have your VP of sales talking. You'll be like, Corey, you are amazing. I love you. Look at this big deal you brought in. 24 hours later, what have you done for me lately? That didn't matter, right?

And I remember the CEO of PagerDuty, so Jen Tejada, at one of the sales kickoffs I was at, she said, you know, because salespeople, like you might know this, like the top sales reps in a company, they go on trips, they have all this stuff. And Jen said, you know, I've got engineers here that are like, well, I don't understand. It's like, how come the sales people get to go to Bermuda or do whatever? And she's like, would you like your paycheck to change every quarter based upon specifically what you did and have the stress of what have you done? All this stuff? No. OK, cool. Then you can, you know, there's a trade-off. So the point of that was— And as your paycheck gets smaller, you're getting closer and closer to losing your job because a salesperson needs to perform to keep it. It's very feast or famine.

It's a heck of a role, and I have nothing but respect for people who can do it. And people can do it well. And I do feel like a lot of people don't understand how sales works, especially in a larger organization. And I think it's really important. So one of the things that was interesting is we've all, I shouldn't say all, but many of us have worked in jobs that have some form of variable compensation, some kind of annual bonus. So let's say, for example, at X company I'm working at, they're like, Maddie, your bonus is equal to 10% of your paycheck. Well, the most it could be, generally speaking, it's like, let's say that your bonus would be, I'm just going to make up a number and say it's a $10,000 bonus. That's the most it could be. And that's if everything is amazing. Maybe I'll get a little more. Now,

your commission, what they call your on-target earnings in sales, they'll tell you a number and they'll say, OK, Corey, your on-target earnings are, say, $200,000. And you're like, oh, but whatever. The thing is, if you're only getting your on-target earnings, you probably are needing to look for another job. So you remember, we hear it differently. Those of us that have done bonuses in a non-sales way, we're like, but that's not a lot. You're like, no, but what they tell you your commission is, it's actually, it better end up being more or else you have trouble.

Anyway, point is. In some cases, it can be a significant multiple of that number as well for top performers. Absolutely. The upside is always interesting, and calculating out the nuances of the sales plan is always a challenge, speaking as a business owner. It is a very specific field that has a bunch of nuance to it. Something I learned very early on is that if you manage salespeople as if they were engineers or manage engineers as if they were salespeople, you are going to have an absolutely terrible time. I think one of the things that along those lines,

I've had conversations with people who work in different parts of technology, different parts of the business, who their long-term desire is to be a CEO. And I'm like, you really should go spend some time working in sales. Because most CEOs, again, this is blunt, but it's true. If you think about it, what is the area of the business that they pay the most attention to? And I don't mean they don't care about the other stuff, but who is the person on the executive team that the CEO is mostly joined at the hip with? And it's your chief revenue officer. It's your head of sales because you have to understand that. You have to understand pipeline. You have to understand pipeline. You have to understand a lot of things as a CEO.

But if you don't know how sales works, it doesn't mean know how to sell, but know the ideas behind it. I mean, you should know how to sell, but you know what I mean? Yeah, I think every CEO is selling. It is a sales job, whether that is selling the company to prospective employees, whether it is selling strategic partnerships, whether it's being brought in to help close strategic deals, etc. You're always selling in that role. That's a very good point. I should rephrase that where I wasn't saying you don't need to know. A CEO who has no idea how to sell is in the fundamentals of you put them in a meeting and they wind up saying the wrong thing and pooching the deal.

They're not CEO for very long. It's not just knowing how to sell. It's understanding how a sales process works. That's sort of the thing. I'll take it one step further beyond that. And that is that I believe that every professional is working in sales and is selling something, but not everyone's aware of it. Well, I'm an engineer and I don't do any sort of sales work.

Well, I hear about that from folks who are, I have all these great ideas, but none of them ever get implemented. Well, you're not doing an effective job of selling the idea. I keep getting put up for promotion and not getting it, or I'm not doing well in job interviews, or I'm trying to get a raise and it just isn't working for me. And every job has elements of sales to it. I'd argue a lot of facets of modern life have sales elements to it. They do. And I think the reason that people get hung up, and I agree with you, I could not agree with you more.

I have a talk I used to give called the five love languages of DevOps, but it was really a talk about affecting organizational change and you have to be a salesperson, right? But I think we have this, and this is a much larger topic because it comes into how people always want to distance themselves from sales. We have this thing in our head that when we think of sales, we think of tricky people, shysters, right? Someone that's trying to like pull a fast one on us, like the used car salesperson thing. And I'm like, that's not most salespeople. Like salespeople want you to, because when we talk about learning how to sell, it's not learning how to trick somebody. It's actually learning about how to, I mean, here's the biggest

thing. You want to know, we talk about DevOps all the time and stuff like that. And empathy, you want to know one of the most important skills of a salesperson is freaking empathy, because you need to be able to understand what your prospect, and that's if you've, there's the book, The Challenger Sale, which like all business books can be summarized in a blog post, right? So you can just go read the blog post about The Challenger Sale. That'll tell you everything you need to know. But a good salesperson that's a challenger style salesperson knows the customer better than they know themselves and knows their problems they might have that they're not aware of. And it's not because they're smarter. They have a different perspective. So the same thing is true. So to Corey's point, we're always selling. And even whether it's figuratively like conceptually,

but I used to say when I was at Chef, I said the two best sales, most effective salespeople at Chef were Adam Jacob, the founder, and Nathan Harvey, the VP of community. Sales engineers are powerful because a customer will tell things to a sales engineer. They won't tell the rep because they think the rep is trying to take advantage of them, which isn't true. Most important conversations that happen are on the walk from the front desk to the conference room. How many conversations would I have with the SRE or whatever who was the one who came to get me from reception, and we're just walking to the conference room? I learned so much there than in any other discovery session. And there's no such thing as an easy sale either, and I think that gets overlooked a lot. Here at the Duck Bill Group, if you bring us in on a consulting engagement to fix your AWS bill, you will turn a profit on that engagement.

That has always been true. And we are quite literally selling money. It is effectively one of the easiest possible sales that you can make. It is incredibly easy to calculate out what the ROI looks like on any of these things, and it's great. And we still have a full-on enterprise sales force because that is what it takes to wind up getting deals done when you're selling business to business. These are not selling t-shirts to the masses. It is a nuanced field. And honestly, when I'm interviewing people, one of the easiest ways for me to discount someone as a potential hire is that they start talking smack about sales because it is clear, first,

they lack empathy. And secondly, they don't understand what sales does. One of the things that I think people who are not connected with it don't understand that, again, back to Corey's point about because selling is hard and selling internally is hard. So this is the thing. So you can have a champion inside your prospect who's like, I'm all about hiring Duckbill, but they have to convince other people. So what are salespeople really good at doing? They're really good at

helping you build your business case to be able to get your thing that you want. How to turn your champion into an effective advocate for the thing that's going to make their job easier because they're not the person that signs off on it. And they're not the expert. Like this used to happen when I was at Chef and I would have a customer who was like, okay, they go and buy a bunch of licenses and they're like, well, it didn't get deployed. And we're like, well, how can we help you? And they're like, well, no, it's just internal stuff. We got to convince people or whatever. And I was like, so what you need to do is what you're telling me. What you need to do is sell chef, right?

Uh-huh. There is nobody on this planet better at selling chef than chef. So that's where that comes in. Because again, that's how everybody wins. So anyway, I went there because I was getting paid like a salesperson. Also, one thing I wanted to touch on, so you're right, usually public sector is not seen as the most cutting edge. One of the things that's interesting at Red Hat, especially on the sales side, and friends of mine who are working on the commercial side may disagree with this, but it's generally not been true. What they call NAPS, so the North America Public Sector, I used to say I was a NAPS specialist, which sounded awesome, because that was my title. I was a NAPS specialist. I specialized in NAPS. Your status in the internal messaging system should always be sleeping at that point. Why not? Sleeping, yeah. But it's sort of known that actually the kind of emergent tech group and

sales inside of the public sector, inside Red Hat, is very innovative compared to other ones. So a lot of stuff was created there. So it was, we were doing something around a transformation office that wasn't being done in the same way anywhere else. So it was very exciting. So I also, it was the opportunity to go and work with people like Andrew Clay Schaefer and John Willis and people that were, you know, it was all the people I was going to get to work with. So that got me excited to be there. And then COVID happened and I got news for you. Like my job was to have challenging conversations with people about how they should do work differently. It's pretty easy to tune somebody out on the Zoom. It's a lot easy to tune somebody out on the Zoom.

It's a lot harder to tune somebody out when they're challenging you in a room. So it was very hard to do this job during COVID. So our team really kind of disbanded towards the end of the year. I was really on the fence and to join in the first place. And the person who was referring me to come work on the team who wanted to convince me said, you know, what's holding you back? And I said, well, it's not. I said, I really like developer advocacy. I like DevRel. That's not this job. And he said, hey, come try this for a year. And if it turns out you didn't like it or it wasn't for you, then go back and do DevRel. And so that's sort of what happened. And I have seen, though, I am much happier in a smaller organization that's creating, you know, like,

I like to feel my impact. I think everybody should spend some time in a large org because if you're going to be working with other people, right, you know what I mean? Especially if you're a vendor, if you work on the vendor side, like I do and stuff. Corey, you and I have talked before about background in doing developer advocacy. And I always say that I do DevRel on easy mode because it's very easy for me to have empathy for my prospects and community because I did the job for 20 years. It's not impossible to be effective doing this job if you haven't literally done it. It's just that much harder. It's a heck of a lot harder. And there's a credibility question and the rest. Yeah. I do this on easy mode.

I can sit there and I can say, yes, I feel your pain. I literally did it for 20 years. And you're at a point, too, and let's be clear here, that you have a gravitas to you. I use you as my default example when I talk about the expression of dev rel, in that if you—like, back when you were at PagerDuty, which I guess dates the reference a bit, but it was, okay, if you sit down and say you're doing on-call wrong. Now, I've been around this industry at that point 15 years or so, and I'm pretty sure I'm not. But if you're going to say that, you have already got my attention in a constructive way, not in a, well, let me just tear this apart. It's no, no, I'm about to learn something by whatever it is you're about to say.

And it's very hard to have that level of credibility without having done the role. That's true, without doing it in that way. In the practitioner way, practicing the thing for which you are advocating. Like someone telling me that I'm doing on-call wrong, who has never themselves been in a role where they themselves were on-call,

is a little lacking in the authenticity department. It's not impossible, and it can be overcome. And you have to do it in a different way, right? And this goes back to another thing that I say a lot, my pithy Stratton quote is, DevRel contains multitudes, right? So this is one of the things that we ran into, like, when we're building out our advocacy team at PagerDuty. It was seeing sort of my boss, who's an amazing dude and everything like that. I love him. But, like, we don't scale horizontally.

Our team was made up of enough of different kinds of people that, like, the way that I was able to do it, because I had a certain experience, you couldn't expect that out of another one of my teammates. Because they actually had a different way of doing it that was just as effective, but in a different way because they have a different background, they have a different, so that's. And there's so many ways to do DevRel. Oh yeah, like I want to call it my own bias here,

where when I think about DevRel, I think about it through a lens of the way I approach things, of when I give conference talks, of how I present myself and the rest. And my approach would absolutely be aligned with what I just described of, so you're doing AWS billing wrong. And based upon who I am and what I do, I can make that claim with some credibility. If I were relatively new to the industry and giving a talk about AWS billing, I would not lead that way because it does not present nearly as well,

and it's going to call into question a whole bunch of skepticism. I would instead approach it as, here are some interesting facets about AWS billing that you may or may not be aware of. There are different ways to approach it. Let's also be clear that it's not just conference talks. It can be blog posts. It can be documentation. It can be writing sample code. It can be Twitter. It could be TikTok, of all things. There are so many ways to communicate with an audience, and your audience is wherever you happen to find them.

Ideally, not in line at a Starbucks, harassing the poor person in front of you just trying to order their coffee. But, you know, as long as it's all consensual, talk to people who are interested in this stuff wherever they happen to be. I think that's a really important statement you said there towards the end, which is you meet people where they are, whether that's where you want them to be or not. And this comes up, it's interesting because one of the things, I'm a big believer in repurposing of content,

and that's just partially because of effectiveness. But it's like, hey, if I give a talk, I should make that a blog post. I should make it a video. I should do a code example. And it's not so much because then I can hit all my OKRs with my boss. I mean, that's part of it, right? But not everybody likes the same kind of content. You know, there are people who really like videos and there are people who are like, I don't want to learn from a video at all. And there's two ways you can approach that. One is you can say you're wrong. Videos are better. You should watch all my videos and take a guess about how well that's going to work with them getting your information or say, I'll meet you where you are.

And I learned this even well before doing DevRel when I just thought about internal communication at an organization I was at when I was at Apartments.com. And I was like, how do we get information? And you can't just say like, well, we have this email we send to everybody. Well, everybody doesn't read email, right? So it could be maybe some people like RSS feeds. They want to capture it there. And the example I always gave is the most effective way that I ever saw that information was communicated inside our organization was signs in the restroom. Oh, yeah. That's a well-renowned way of doing it. I think that Google pioneered this for a while.

They had all these things up about interesting things going on inside the company, about the way some systems work. I was at a Google office and using the restroom, and I was standing there, and right in front of me was a whole good practice on cross-site scripting vulnerabilities. I guarantee they probably sent that email to everybody. It's probably been in meetings, and the people who saw it were as they saw it in the restroom. Now, of course, I'm sure they probably sell ads on those sheets, but okay.

Yeah, you know, a little bit. When I was at Apartments.com, the floor that I worked on, the main restroom I used was a shared restroom with another office, which meant corporate never put anything up in there. And there was actually a fair amount of stuff that I didn't know about because I ignored it everywhere else and would have known. Anyway, so the point is, back if you do work in person, which who is doing that anymore and why bother your most effective way to communicate. So if you can figure out how to do DevRel in the like in signs in a restroom at a conference, ooh, conferences should sell sponsorship of restroom signs.

The jokes write themselves and almost certainly violate the code of conduct of at least four different things, but it works. It works. We'll take those to Twitter. You've been around the industry for a while. You are one of the co-hosts of the Arrested DevOps podcast. You've been instrumental in organizing a number of DevOps days, or DevsOps days. However you want to mispluralize that is fine by me.

Roll with it. We argue more about the capitalization than the pluralization. Very fair. I want to talk to you a little bit about how the DevOps movement slash community slash role has evolved. For a long time now, it's been great. So where are the DevOps people sitting? And when you hear the shouted response of, it's not a job, it's a culture, good work, you found them. Now you can go talk to them and all. What has changed over the past few years in the world of DevOps?

So I am fond of saying you can't buy DevOps, but I can sell it to you. Oh, absolutely. You're an exemplary DevOps salesman. Yeah, so what happened? When we think back across the decade plus, you know, back since 2009, one of the things I think that's interesting is when we look at things like DevSecOps or the other port mantus that are being created, it's a little bit like that meme, right, with the astronaut. Wait, you mean it's been DevSecOps all along? You know, it's, yes, always has. That's the thing. Like, for those of you who don't know, Andrew Clay Schaefer is best known as coining the term.

And I love Andrew, but wow, is it the worst name in the world for what we're talking about. Because it makes us all think that it's only about development and operations. And it's always been about cross-functional across all of those things. And if it helps us to give it a different name... It's replacing dysfunction with cross-function. Yes. There we go. That's DevOps right there. That's the best definition of DevOps I've heard. That's how one coins a phrase, in case you wondered. So we still use the term comms to say what it's about. It's about culture, automation, lean measurement, and sharing.

That's held up for a reason. For something that was scrawled on a napkin in 2010, there's a reason we still talk that way. It sounds like we talk about culture more than anything else, and it's not because it's more important. It's because it's the one that we have to scream from the rooftops. You don't have to convince engineers to play with automation tools. They're going to do it. That's fine, right? So they're all equal. Now that said, what's changed is we have definitely found DevOps to feel a lot more about that it's about automation.

It's about the technology. We've veered away from the people to your statement about like, oh, it's a culture, not a type. Well, it's all of these things. This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of Hello World demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking, databases, observability, management, and security.

And let me be clear here it's actually free there's no surprise billing until you intentionally and proactively upgrade your account this means you can provision a virtual machine instance or spin up an autonomous database that manages itself all while gaining the networking load balancing and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build. With Always Free, you can do things like run small-scale applications or do proof-of-concept testing without spending a dime. You know that I always like to put asterisk next to the word free. This is actually free, no asterisk. Start now. Visit snark.cloud slash oci-free. That's snark.cloud slash oci-free.

One thing I do want to call out, because the whole point of having you on the show, of course, is to embarrass you with proof positive of the example that you are, in fact, a good person at heart, despite, you know, your dubious friendship with people like me, is we both used to be adamant about the idea of DevOps is not a role, not a job title. And we both stopped, but for different reasons. The reason that I stopped was that I took a job as the director of DevOps at a company because I was trying to solve about five or six different things that were important for me to negotiate for, and job title did not make the cut of impactful changes. You had a far less self-serving reason for no longer picking that

particular fight. What was it? I do want to call out one of my favorite jokes, which is not supposed to be gatekeeping, but it's making fun of Corey, so it's okay. Nathan Harvey said years ago, and it was actually, I think, intended as a shot at our friend Pete Cheslock, who also has had the title of Director of DevOps, which said, the only DevOps tool is a person that calls themselves director of DevOps. Oh, absolutely. It's super lucrative. I was really insulted about it and cried all the way to the bank. Uh-huh. Now, I'll tell you, there's two reasons that I've changed my tune on. You know, I used to say it's not a tool, title, or team. I still will agree that it's not a tool. The title and team and the reason for that is twofold, and neither of which are self-serving other than I don't want people to think I'm a jerk. The first

reason that deviated me from a little bit was, again, to go back to your friend and mine, Pete Cheslock. He gave a talk. I don't remember where it was, but he made the point where he said, you look at it, the title DevOps engineer is a 30 to 35% pay bump. So it's like, I don't care what you call yourself, go get paid. So that's that. So first of all, I was like, cool. J. Paul Reed did a whole talk pay thing that shined a light on that. Absolutely. The one that I think is more empathetic and probably is maybe a little more important or equally, so Ian Coldwater has pointed out before, and this really resonated with me, is that when we get on Twitter and are like, oh my God,

DevOps Engineer is not a real title, blah, blah, blah. The people that hear that are the people who have that title. They did not give themselves that title. It's very exclusionary. All that will happen out of that is it doesn't- I'm going to go quit my job and not be able to make rent this month. Why? Because Twitter said that my job title was bad. Of all the reasons to quit a job, I promise you job title is not one of them, unless it is something horrifying, as in into the territory of discriminating or belittling. There are always exceptions to every rule, but by and large, that's a ridiculous job title is not the reason to quit a job, says the self-proclaimed chief

cloud economist. So totally, yeah. I mean, you know what? It's very similar. There's a meme about like every time people want to make fun of political figures or something, and they'll make fun of them being overweight or any kind of thing. And it's like the meme is like the only people who hear that are your friends that have a similar condition, not the actual person you're making fun of. So all you're doing there is hurting people who. So that's a similar thing. Now, I will say, and I think you and I might disagree about this a little bit, so that'll be fine. I hope so.

When I hear, and actually the title doesn't do this for me. It's actually very specifically a DevOps team. When people say we have a DevOps team, this is not a perfect analogy when I say it's a code smell. I call it an organizational smell. And what I mean by that, it's not as bad as a code smell. What it does is it makes me ask more questions. If it's relevant to me to ask questions, it might be none of my damn business. If you tweet that I'm on the DevOps team, I'm not going to come into your mentions and start questioning your existence. Oh, please, I have way better personal attacks than that.

Oh, yeah. But if I'm working with you and we're working on that or we're having a conversation and it comes up that you have a team called DevOps team, I'm going to ask questions because that could be okay or it could be, I want to use the word dangerous lightly. It's not, but like counter effective. And the reason for that is if it's, if the DevOps team is the one who does all your automation and you haven't really enabled other squads and all you've done is move a silo around,

doesn't make you a bad person, but that's not the most effective way you could be. So it makes me start to ask questions, right? But sometimes DevOps teams are people who lead in the organization. They are empowerment teams. Maybe they run Dojo. Maybe they are subject matter experts that help. As long as there are good bridges still being built, it's not bad, right? So it just, again, it raises questions. It's not inherently wrong. I am sure that Pulumi, where I work, actually many of the tools I've worked with have been called DevOps tools. I will still tell you there's no tool

that gives you DevOps, right? But when other people, like Vides, buyers refer to you as the DevOps tool company, well, you can be right or you can make a sale in some cases. You have to meet people where they are, and this is a part of that. I say that in full sincerity, same story with the idea of, of culture. I hear this question all the time. How do we wind up making all of our engineers aware of AWS billing issues? And to a point you should have understanding that when you turn something on, it runs forever, bigger things cost more than smaller things, but the knowledge fits on an index card. You shouldn't have every engineer wanting to or needing to become deep experts in this space. Having a centralized team that specializes in that at a sufficient level of org size and maturity makes an awful lot of sense, and they can float around.

But yeah, having the AWS Bill team, in some cases, is the right answer. In others, it's the complete wrong answer, and it really does depend. I think the way that we solve this problem authoritatively is a way that neither you nor I can argue with, because the only source for authoritative DevOps answers is from the source itself. And that is, of course, Emily Freeman, whose treatise on the subject, DevOps for Dummies, despite the weird title, is absolutely a fantastic work that gives insight into all of this. And are you prepared to tell her she's wrong? Because I'm certainly not. Well, there are plenty of people who will, as we know.

Yes, and we call them shitheads, if we're being perfectly honest with you. Yeah. The internet, what a place. No, Emily is an absolute treasure in the space, and I'm continuing to watch her meteoric rise with nothing other than pure admiration. It is just spectacular to see her succeed. I could not agree more. This is something I struggle with a little bit. I don't think Emily would mind me saying it this way. This is the thing where you don't want to sound condescending, but I always love when I look at people and it's not it's going to come off a little bit about like I knew them when. And it's not like I was a Corey Quinn fan before he went pop.

But I love to see when it would remember where we all came from. And it's true of myself and it's true of other people. But that's one of my favorite things is I love to see my friends succeed. Corey, I love to see what you've done. Like, I think back to when we knew each other, not saying you weren't successful, but it's funny, this is where it's supposed to sound a little kind of silly to be like, oh, I'm so proud of you, but I am. And I'm impressed. It's great to see. And Emily's another example. Like, I remember when I first met Emily and not like I was any big deal either, but it's like everybody

comes from somewhere, right? Jackie Grindrod, who just recently left Hashi, I remember when she started to get into DevRel and I was talking to her because she's like, I may be thinking I want to do this thing. And you look and you see these people and it's not supposed to be like, oh, I remember when you were like the cute little baby DevRel. It's not like that. It's like, it's just impressive to see and not even impressive. It's you like that. It's like, it's just impressive to see, and not even impressive, it's you like to see people who do good work and have a good heart and want to help people grow and be successful.

And I'll tell you something here. We're going to get real for a second. You can be jealous of them. It's okay. And I'm going to be honest. There are times that Emily and Corey are both good friends of mine. And there are times that I'm like,

wow, I'm a little jealous of you. Sometimes I'm a lot jealous of you. Sometimes I'm not at all. So I'm telling everybody it's okay to be jealous. I agree with the sentiment, but I changed the word to envious because envy is the one of those like, I want that too. Whereas jealousy is a lot more of a shade of, I want to have it and I don't want them to. And I don't believe that's the direction you're heading in. No, thank you. No, that's, you're exactly right. Envy is the better one. Yeah, because it's never... I only recently learned the distinction there by getting it very wrong and saying things I didn't intend to imply, which is why I bring it up. Again, let my mistake be something others can learn from. Sometimes the best purpose I can serve as industry is as a

counter example. I was going to say, you know, just for everybody, I remember at the beginning, you know, Corey said, maybe we'll learn something. I'm like, I guess that's what we learned. Yeah. It's the difference between envy and jealousy. I mean, the rest of it got us, you know, it took us half an hour to get there, but, you know. No, no. And I appreciate your friendship throughout the years. Like, you are one of those people that has been something of a guiding star where it's sometimes I get it right, sometimes I get it

wrong. And you've always been someone who has been very willing to share which side of that divide you think I'm on with anything that I've done. And for lack of a better term, you knew me before I basically bought ink by the barrel. And back when I was just the conference speaker that would follow one of your ridiculous talks, like, oh, God, those are some big shoes to fill. I better learn how to give a conference talk. So most of what I've become is your fault. But I just want to thank you for your guidance over the years on these things. Can we tell the real story about how I claim ownership of the Duckbill Group?

By all means, take it away. Oh, okay. So I honestly still think that I should have a part ownership in the Duckbill group, because for those of you who don't know, Corey mentioned that I had worked at PagerDuty, and actually that job came down between the two of us, and Corey didn't get it, and then went and started his own company and became famous and amazing. So really it's because of me is what I'm trying to get at. To be fair, they made the right hire. Which one of us do you think makes the better employee? Let's be very clear. And yeah, I am thrilled to deal you in an ownership of the Duck Bill Group because the way we're structured, you cannot have ownership without also assuming liability. So yeah, I would love to dump legal responsibility for my shenanigans on someone else. Come on in. Yeah.

There's always a cutting edge to everything else. But no, you're right. I always wonder what would have happened if that decision had gone differently. And I'm very glad it played out the way that it did. You were the right hire for the company in a way that I never would have been. But I would have given it a good try for a while before they begrudgingly had to fire me or I sensed the ax was coming and left on my own. That is the nature of me as an employee. You have a very different perspective because you're good at things that I'm terrible at. And vice versa.

It was interesting. You just talked about like, how would things go different? So I yesterday just recorded, I don't know when it's going to come out. I was on a podcast called 8 Bits. So it's 8bits.tv. And it's really a show about people's journey through tech. And what was interesting that came out of that conversation was, first of all, how much of my, how I got to where I am is

because of spite, which you're going to have to go back and listen to the episode to hear the whole story of all the spite. But we did talk about like those junction points that happen that seem innocuous. And it's like, I made this one choice that wasn't even necessarily a choice. And you follow all the forking logic that gets you to, Corey, you and I are sitting here on a podcast right now. How many decisions that weren't even decisions? There's the alternate universe where this doesn't happen, where this doesn't exist, right? It's weird how this stuff always, years before I met either one of you, you videotaped my wife's law school musical and burned it to CD. We found that out when you were

here over dinner one night. That was my favorite thing. It was surreal. Yeah, we were I was at dinner with Corey and his wife, and we got into a conversation about that she had gone to law school in Chicago. And I was like, oh, funny thing. Like I produced the video of the law school and she's like, wait, when was that? And I couldn't remember how to like dig back into like an old blog post and was that and then yeah, and Bethany like She walks into the room and comes back with a DVD that you burned your handwriting on it. Yeah, pretty much. Yeah. The world is small. Be nice to everybody. It never hurts. I want to thank you for taking time out of your day to basically tell stories. Once again,

it's always good to talk to you. If people want to learn more about who you are, what you're up to, where's the best place they can find you? So really the best place is Twitter. You know, so I'm at Matt Stratton on Twitter. If you're not a Twittery person, that's okay. LinkedIn is not great for, I don't always remember to post stuff there. If you want to know about upcoming, you know, so if you go to speaking.mattstratton.com, that has all my previous talks, my upcoming talks and things as hopefully we'll have more and more of that. And yeah, and every week I stream on twitch.tv slash Pulumi on Thursdays. And it's not webinars. It's not slick demos. It's just me screwing around and sometimes having fun people on and sometimes just proving how little I know about coding. So yeah, good times. Thank you for

having me on again, Corey. It's always fun. Of course. Links to all that go in the show notes. And as always, it's a pleasure. Also, I will say, Corey, I'll give you the link to that 8Bits TV if you want to put that in the show notes if people want to go and find that because I think it's similar connected to what we talked about. Good. I look forward to listening to it myself. Matty Stratton, staff developer advocate at Pulumi. 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 hated this podcast, please leave a five-star

review on your podcast platform of choice, along with a long, angry comment detailing that DevOps is in fact a role, and here's what it means, and then go ahead and describe a sysadmin. 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.

This has been a humble pod production stay humble