Emily: [00:00:00] New York does finance, San Francisco does tech, DC does war, and you pick up some things when you live there.
Matty: It’s time for Arrested DevOps, the podcast where we help you achieve understanding, develop good practices, and operate your team and organization for maximum DevOps awesomeness. I’m Matt Stratton, and joining me today is Bridget Kromhout.
Bridget: Today, we’re recording live at DevOps Days Madison, and we’re talking about effective change in an organization where you’re trying to drive the change and maybe, spoiler alert, you don’t make every single decision ever. What? That happens. Terrible. The show notes for this episode can be found at arresteddevops.com/devopsdays-madison.
Matty: So, but before we get started, a word from our sponsors.
Bridget: This episode is sponsored by VictorOps. Built for modern incident management, VictorOps provides a unified platform for real-time alerting, collaboration, and documentation. Driven by your IT and DevOps system data, VictorOps helps you to respond to incidents more effectively so you can minimize downtime and make being on call suck less. Visit arresteddevops.com/victorops to schedule a demo or start your trial. Mention you heard about VictorOps on Arrested DevOps, and you’ll be eligible for some sweet discounts too. GoCD is the on-premise, open-source continuous delivery server created by ThoughtWorks. With GoCD’s comprehensive pipeline modeling, you can model complex workflows for multiple teams with ease. And GoCD’s value stream map lets you track a change from commit to deploy at a glance. GoCD’s real power is in the visibility it provides over your end-to-end workflow. So you get complete control of and visibility into your deployments across multiple teams. Say goodbye to deployment panic and hello to consistent, predictable deliveries. To learn more about GoCD, visit gocd.org/arrested to download. It’s completely free to use. Commercial support and enterprise add-ons, including disaster recovery, are available.
Matty: [00:02:15] This episode is brought to you by Datadog, a monitoring tool that helps bridge the gap between operations and dev teams. Datadog brings together system metrics, changes, alerts, and events from over 120 common infrastructure tools such as Chef, Docker, and AWS so that dev and ops teams share their key data and alerts in a single place and collaborate on issues in real time. Datadog is available for a free 14-day trial at arresteddevops.com/datadog. So we’ve got an awesome panel joining us. Our panels are always awesome, but these are especially awesome because they’re here. So that’s what I’m going to say. So we’d like to get started with a couple quick introductions. Just, if you tell us a little bit about yourself, what brought you to DevOpsDays Madison, and what got you into the DevOps world, and we’ll take it from there.
Josh: I’m Josh Zimmerman. I work for the University of Wisconsin Libraries, and I’m here at DevOpsDays Madison because a couple of years ago, I was speaking at DevOpsDays Minneapolis, and Bridget sat me down with one of our— the other people that are on the panel that will introduce themselves in a bit and said, hey, by the end of the year, you’re going to run a conference in your city. And we said, uh, what? And then we started to meet up and a year later we’re now— or we started the conference and this is now our second year. So that’s why I’m here.
Emily: [00:03:33] That’s awesome. I’m Emily Freeman. I’m a developer advocate for Kickbox. We do email verification. And I’m here, I’m speaking tomorrow, the Scaling Sparta talk. I’m coming back. I am like so excited because this was actually the first American conference I ever spoke at. And to, like, first also to be invited back. So, it’s very special to me, Madison.
Bridget: Wow, that’s really exciting.
Emily: Yeah, it is.
Matty: Love it.
Bridget: Okay.
Christian: I’m Christian Herro, and I’m the other, the aforementioned organizer that Bridget strong-armed into running DevOps Days here in Madison. And I’ve known Bridget and Joe practically forever at this point.
Bridget: Is this the part where we admit that you’re Joe’s college roommate? And so that’s how I strong-armed you into running this. So what I wanted to talk with these panelists specifically about, ’cause we kind of have a range of their employers and we didn’t touch on your actual roles and your employers too much, but I wanna get more into that because you all are in a position where you’ve either worked at places large and small, or you’ve seen inside organizations large and small And I would love to just start with one kind of wide-open question. Hey, say things inside your organization are not exactly as you believe they should be. How do you get started with making some kind of change happen?
Josh: [00:04:59] For starters, one of the things that a lot of— that I definitely experienced early on when I was starting to try to make change happen, and I definitely see from other people that come up and talk to me, is a lot of people, when they go out, like, when you first realize that something is not entirely right or that you want to change something because it’s maybe not modern or whatever, a lot of people are kind of upset or frustrated about it by the time that they are trying to actually make change. And one of the things that’s been really eye-opening in being a part of the DevOps community is that it turns out when you talk to people that are going out to a wide variety of organizations that what you see at conferences, what you see most people talking about in blogs, that’s like their prototypes. That’s like, they’re not quite always there yet, or maybe they just got there. And so, like, when you’re seeing some of these things, like, most, like, many organizations that have IT orgs aren’t doing full CI yet. Most places aren’t doing CD yet. If somebody’s running Kubernetes and it’s in production, it might be like 2 apps, not their full array of applications. And so, the first thing before you even get started trying to make change happen is to not be upset that you’re not there yet, because most people aren’t.
Emily: [00:06:23] I think you also have to embody that change. Whatever you want that to be, you have to serve as an example of that. And it can be very small. Kind of owning that and creating your own sort of MVP for what you want to see change, and then beginning to advocate for it. If you don’t believe in it, nothing else is going to change no matter what organization you work for.
Christian: All right. I mean, some of my background is that I started at Target way back in the day before DevOps was even a glimmer in Patrick Dubois and Andrew Clay Shafer’s eyes. Things have changed so much in the last 20 years. You know, it used to be that you just felt bad and you couldn’t get anything done because you didn’t realize that you were empowered to make change in your own organization. As I’ve moved to smaller and smaller and smaller organizations, it’s become easier to make change, but that’s also a function of my career. So I guess where I’m going with this is that No matter how large an organization you are in, you should realize that you are empowered to make change. It’s just getting to that realization is the hard part.
Matty: [00:07:38] I think a big part too, and especially as technologists, we look at the change and we immediately jump to solutioneering. And we think about the change that we want to make is to implement continuous delivery or start using Jenkins or k8s, all the things. And at the end of the day, the company could absolutely give a shit. So what you need to do is take a step back and say, what is the business outcome that I’m trying to change? And the reality is, if you cannot define that, then you will absolutely never make the change that you want to make. But if you can, then it’s simply a matter of figuring out the folks that have to hear the story because you’re telling it in that story. And we had an open space earlier when we were talking about DevOps transformation in an organization. As in the different parts of an organization that have to change besides tech. And that was kind of the piece of that. We talked a little bit about you want to make a change. Sorry, not sorry, you’d have to understand how to write a business case. And you know what, a business case is not a 20-page PowerPoint deck. It can be 1 or 2 sentences that say, hey, doing this thing helps us make more money, right? And then people get that, you know, especially the people who have the purse strings or have— so if you cannot articulate the change you want to make in an outcome that’s business-related, go back, we’ll wait, come back when you can do that, and you’ll get a lot further.
Bridget: [00:09:00] And I think that’s— Matt is so right. That’s so huge because many of us, we go to tech conferences because we want to learn about exciting tech. And we work in tech because we like typing things into computers and having them do our bidding. And the part where we have to talk to other humans is a necessary yet evil side effect, right? I think the thing that is the hardest to realize is that the business, as Matt puts it, does not care if you are orchestrating your containers in the most au courant, exciting way possible. It’s very unlikely that your employer at, like, the highest levels cares exactly how you orchestrate them. They probably don’t even care if you have containers. They probably care a lot if your customers can get things done. Or if your stakeholders, you may not be a profit-motivated organization, but I bet you a lot of people care if your stakeholders are able to achieve results. So if you can tie the exciting resume-driven development stuff you want to do to those important stakeholder results, that’s how you get to work on all of the fun things you want to do.
Emily: [00:10:03] I think that also brings up a good point in that you have to choose like one thing. Who’s the Bill Clinton advisor, the rage occasion?
Matty: Oh, James Carville.
Emily: Yes. So his whole thing— Clinton had all these economic ideas, I’m very excited, and he said, no, if you say 3 things, you say nothing. You have to choose one thing and then focus on that. And that’s what they did, and he won the presidency. And so, yeah, I think you have to choose that one thing and then fight for that. Because if you sort of overwhelm people, then at some point you’re just becoming a squeaky wheel.
Josh: Or at a minimum, you at least need to be able to break up your large thing into small bite-sized things. Like, if you want to get to immutable infrastructure, or something like that. Well, chances are you’re gonna need a CI pipeline, and maybe you start there and you say, now that we have this, we can also start on this other project, because you’re beginning to see pain points in another place, like maybe having a bunch of CI workers, you know, you now need service discovery or something like that. And so, as you can start, you can figure out ways to build on— you don’t have to start with your large idea. You don’t have to start by saying, let’s do immutable. You can say, hey, why don’t we do this because this is the business case for this one small bit, and you can start working people towards that by helping them figure out where their pain points are. Because chances are if you’re working from a macro level, you can at least figure out which people need to buy into which parts, and so it helps to break it up.
Christian: [00:11:33] I was going to say, or maybe like being not too CI yet and you’re just doing other things, but Yeah, that’s actually been— so again, in my ancient career, um, you know, I was doing waterfall for the entire time up until my most recent position, and, uh, I’m actually still learning how to break up work into small parts. And that is difficult, but it is incredibly powerful. I mean, I hope that most people listening to this podcast know that, but, uh, it’s definitely something to check out if you have not done a lot of Agile-style work. That’s where it’s at.
Matty: I think that that is a very challenging skill, and one of the best ways to be able to develop it is to take it into your personal way of doing stuff, which is something I discovered by accident because I discovered I needed to do that to actually get any work done because I’m— I have ADHD, and the only way to do stuff is to have a lot of rigor around small tasks and small batch sizes. And I kind of made this correlation not too long ago and said, hey, boy, this sounds a lot like Agile and DevOps and everything. And what would I tell a customer if their company was run the way that my brain is? You know, and turns out it works really well. But if you have to develop that skill, and you may not have that ability to do it right away immediately in work, you actually— this, all this stuff you kind of apply to personal life. And we were talking in an earlier open space about an Ignite that was, hey, DevOps dating or whatever. And so that’s, by the way, the trick we learned in that open space is if you want to come up with a talk title, just DevOps plus thing and there you go.
Bridget: [00:13:18] DevOps Thanksgiving dinner. Iterate with your family.
Matty: Fun, great choice.
Josh: Totally.
Matty: But take these practices. I mean, now we’re kind of going off topic, but you want to be able to kind of experiment. Again, talking about experimentation. Experiment with your own workflow before you try to figure out how to make it happen. And it still goes back, just want to say, like, I cannot stress enough how much the outcome-based things be because we are so driven. This happens quite a bit with customers of mine where I’ll sit down and I’ll say, you know, I’m talking to, you know, IT director or SVP or whatever. I’m like, okay, so what’s your, you know, business outcome? Why did you buy Chef? Or what’s your outcome to do with Chef? And they’re like, well, my outcome is to install the Chef client on 10,000 nodes. I’m like, that’s not your business outcome. That’s my business outcome. But yours is not just to install that. But we do get very wound up into implementation. And we need to be able to communicate the business value. And again, it goes back to, if you cannot articulate— and Bridget, I know you said not everybody’s profit-driven, but whatever it might be. But I’m just going to use the model of—
Bridget: [00:14:23] Mission.
Matty: Whatever, just maybe easier to just say this way, right? Is to say— sorry, I didn’t mean to say whatever, but I did a little bit. If you can’t tell me how your company makes money or achieves their mission, then you have some homework to do, right? And then come back when you know how to do that. And then you can say, this is how doing this— and by the way, saving us money is not exactly there, right? You need to figure out how you tie that to value. So there you go, tie it to value.
Josh: Well, going off of some of that though, there’s, you know, at a university you wind up with this weird thing where there’s about 2,000 different missions depending on which person you talk to. But that’s actually a really strong way to— those missions end up so much more personal to the people that have them, which means that if you can tie what you’re trying to accomplish to their specific mission, that they will champion it far more further than even some of the business cases at an actual— at a company where you’re trying to make profit because At the end of the day, like, you know, that’s that person’s livelihood. That’s like what they’re trying to do with their life. And so it’s super personal. And if you can tie that in, it’s wonderful.
Bridget: [00:15:32] Yeah. And I think that there’s also that interesting disconnect if, like you said, you’re reaching out to tie things into other people’s missions. I’m interested in what Emily thinks because like me and Matt, she works at a vendor. When you’re trying to get to the why, with an organization that maybe you’ve parachuted in and you’re talking to them. Can you talk a little bit about that? Because you might— sometimes I feel like from the outside you can see people’s why a little more than they can articulate it.
Emily: Absolutely, absolutely. But I think part of that is just listening, you know, and actually talking to people and hearing, you know, observing what goes on and hearing their stories. And sometimes what people say they want or need is not actually what they want or need. And so paying attention to those like little seeds And kind of stringing it all together, I think, helps. But yeah, you absolutely have to put yourself in their shoes. And I think you’re always going to make a mistake when you’re trying to advocate for change, and it’s like, well, you’re doing it wrong. You know, that’s a terrible idea. Like, you’re not going to get anywhere with that. You kind of have to appeal to people and turn them into an evangelist for whatever you’re trying to get them on board with.
Matty: [00:16:35] That’s— couldn’t have said it better. Like, combining what Josh was saying, what Emily said, which is— this is going to sound a little manipulative, but it’s like when people think it’s their idea, they’re super into it. But the non-manipulative part of that is that it came from a place of trust and desire, right? You weren’t like, I’m going to trick you into it. I’m going to help you understand why you actually do care about this. You just didn’t know how to put it into words before. And I think Emily nailed it, which is sometimes you don’t see the forest for the trees when you’re in the middle of it. And I’ve seen that so much. I have organizations I work with just similar who’ve been going through a transformation. And I’ve been working with them for years, right? And I sit and I talk to them and they’re like, man, it just sucks. It’s like we have got nothing done. And I’m like, dude, you are so much better than you were 2 years ago, but you don’t know that because you’re in the middle of it. Like, I’m sitting here on the outside. So it’s the act of listening. Like Emily said, just listening. You know, we’re as vendors and stuff, if we’re doing it right, we’re really good rubber duck debuggers. We just sit there and just let you talk.
Christian: [00:17:38] Right?
Matty: And you’ll get there, right? Tell me what— and the problem is sometimes people will say like, oh, I’m going to go to you and say, hey Bridget, what sucks? Where’s your pain? I don’t ask those questions because, you know, you’re going to tell me what you think it is. I’m going to— because again, I think you’re saying like sometimes what you think your biggest problem is is not what it is. But if I let you walk through it, you might actually discover it.
Bridget: Yeah, absolutely. And I’m also kind of— I’m going to pick on Christian again for a minute and say, because he’s hiding, I’m interested in, uh, if you can talk a little bit to— because you’ve worked in organizations of varying sizes— how people start affecting change depending on the size of their organization. Like, what techniques have you had work, or have you seen not work, in organizations ranging from ginormous to minuscule?
Christian: So, I mean, so as we all know, believe, it goes back to trust and how we work with other people, like how we connect with them. And in my experience in larger organizations, it is really difficult to get outside of that, outside of that small trusted group and expand the trust. And that part of my career is a while back, and I don’t have any great solutions for it at the moment. I suspect that Josh has better ideas than I do. But moving into medium-sized organizations, I was at a managed service provider where we were parachuting into various companies and, you know, building trust with people that you’re going there to help out. Just trying to establish that quickly. Connecting on a personal level is incredibly important and something that I— took me a long time to learn because I am very slow to pick up on things like that.
Matty: [00:19:35] I just had a thought. I may— this is one of those where Matt may paint himself into a corner because I didn’t think the analogy all the way through. But when we think on a personal level, if you’re in a relationship and there’s a problem with trust, trust takes time to build. Hopefully we all kind of know that. And if we don’t, by the way, spoiler alert, trust takes time to build.
Christian: Turns out.
Matty: Yes, turns out. Now, the way that happens is it starts with the party. So let’s say Bridget doesn’t trust me. It doesn’t start— Bridget doesn’t start trusting me because she discovers that I’m always telling the truth to her. It starts by her seeing a change in my behavior in general. She’s seeing that I’m doing more proactive things. That I’m working on the things that cause whatever problem of trust or just working towards it. That’s where it starts to make it so that my colleague or friend or significant other or whatever can start to trust me. And then eventually they do start to trust me and they’re able to see that things are— because it’s like proving a negative, right, when it comes to trust. So I think it’s a similar thing. You— it’s unfair, just like it would be unfair, like, again, there’s a— and I’m not saying there was a breach of trust between 2 different groups, but there is in a way because there’s a We’re used to that, right? So we’re saying we’re going to try to build trust. It’s unfair, just as it’s unfair for me to go to someone I have a relationship with and say, there was a breach of trust, please just start trusting me. It’s hard for me to go to my colleagues in this other team and say, you should just start trusting me now. So it’s, it’s the onus is a little bit on me to start being proactive in behaviors, and that will actually have an effect, right? And whether that’s in how more I’m sharing things. I’m being, you know, I’m actually— this analogy is working super well now that I realize it. Another talk idea.
Christian: [00:21:21] So, oh, I was gonna say what you were just talking about sparked some memories from so long ago. But, you know, when you’re in a large organization and you have a problem, somebody else also has a problem, and you go to them and say, hey, We have this thing that we need to work on together. We get it fixed. A, we are in much better shape than we were yesterday. And then B, you have started to build trust with them. And that’s one of the things that has worked best for me. I mean, again, you know, don’t, don’t go around causing problems just to do that.
Matty: But sometimes— I don’t think you have to cause them. They’ll probably come to you. I mean, but I think that’s a really good idea. That’s just saying, how do you bring a partner together? And then that person will say you’re someone that we now have trust and a relationship.
Christian: Yeah.
Matty: And but here’s the thing, trust is really hard to earn. Well, there’s that. Trust is very hard to earn and very easy to lose. So you can do all this stuff that Christian’s talking about, and all it takes is accidentally— I’m gonna say accidentally because I don’t think we ever do this on purpose— accidentally throwing that coworker under the bus or pointing the finger, and it’s all over. So it sucks.
Josh: [00:22:37] It’s hard. It’s also important, as you mentioned, that trust is not about the words that we say, because especially when you talk about something like DevOps culture or a lot of the components of it, anybody hears about blameless postmortems and you can— or post-incident reviews.
Bridget: No one died.
Matty: The Jason Hand drinking game. Everybody does a shot once it’s postmortem.
Josh: But, you know, you can talk about the ideas behind it and everybody will say, yeah, we totally agree with that. But that doesn’t mean that they have embodied it, that they can put that into effect. And that’s with so many of these things in DevOps. Like, you talk about collaboration, which most people don’t understand that there’s a difference between cooperation and collaboration. And so, especially when you’re working in a larger org, like, what you see a lot of times is the cooperation. Well, we will work towards the same goal, but we’ll work in our different silos. We’ll both try to achieve this thing. But that doesn’t really work. And everybody in those situations will say they are collaborating, but they’re not. By the definition of the 2 words, they are not actually collaborating, which requires you to work together, which actually— you do the thing together. You don’t just sit and say, I’m going to take this piece, you’re going to take this piece, and we’re going to meet up in the middle. That doesn’t usually work. So, people don’t necessarily— just because they think they believe something or they do actually believe it doesn’t mean they’re actually practicing those things.
Matty: [00:24:06] You have to have the visceral experience. I’m mentioning this mostly because I want to remember to put it in the show notes. There was an episode of Food Fight Show a couple of years ago and they had some folks from GitHub. I don’t remember exactly who it was. It was probably—
Christian: I don’t know who it was.
Matty: Anyway, I’ll put a link in the show notes. But the conversation came up about blameless postmortems. And the guest said, you know, when I joined GitHub and they said, hey, we do this blamelessness thing. I was like, yeah, yeah, sure, sure, sure. And then I broke production. And I was like, I got called into my office. I’m like, shit, super fired. And they’re like, so, what up? What happened? And I was like, what? And he’s like, I told you, blameless. I was like, for real? You know, he’s like, I didn’t really believe it until it happened. And I think with things like that, To Josh’s point, you have to— it has to be experiential, right? It’s all a bunch of talk till you experience it. And then once you do, then you’re committed. You’re not—
Emily: I think the one exception to that I would say is that you can convey trust through words by being vulnerable and like actually showing, like sharing your mistakes and telling stories about your own experience. And I think that that opens up a lot of, you know, good things for relationships in general.
Bridget: [00:25:20] Yeah, I think that’s a really key way to build your team, build your community, both inside your org, across your teams. Just allowing people to collaborate and cooperate and grow is huge. And I kind of, I want to focus for a minute on Emily’s talk topic. I know some of the folks in the audience here are going to hear your talk tomorrow, so we don’t need too many spoilers. But in broad strokes, if you want to talk to us about what is the general focus of your topic, because I think it’s relevant here.
Emily: Yeah. So, basically, I started thinking about scaling an organization, and I worked in very large organizations in my previous career in, like, PR and writing. Spoiler alert, development is my second career. And so, now I work mostly in startups, and I started thinking, like, Okay, what is the difference between a startup and a current Google? How did they advance and what kind of lessons did they learn along the way? And I’m sure it was absolutely a shit show there a couple times throughout the path. So I started thinking about the military. I’m from DC, so I have a ton, like half my friends are either military or spooks. Yeah, it’s true. New York does finance, San Francisco does tech, DC does war. And you pick up some things when you live there. And so I started thinking about different historical military organizations, and I thought that Sparta, the Mongols, and the Romans are pretty good analogs, I think, for a startup, a mid-sized company, and then your sort of enormous organization. Yeah, so it’s kind of fun.
Christian: [00:26:56] That is awesome.
Emily: Thank you.
Matty: So good.
Emily: I hope I live up to the hype.
Matty: Y’all are in for a treat.
Emily: Thank you.
Bridget: That is— I’m really excited to see that talk. I’m excited to live tweet that talk tomorrow. So I also am interested just because I feel like some of A lot of our audience members do go on to run their own DevOpsDays events. Spoiler alert, you too can run a DevOpsDays.
Matty: We haven’t yet hit 100 in a year, so yeah, make some more. We can super scale. Let’s see how many weeks there are in a year. I guess we already know, there’s 52.
Bridget: Matt’s done some amazing work with the website that I think makes it a lot easier for people to onboard on the tech side.
Matty: Spoiler alert, that’s the easiest part of running a DevOps Days, by the way, is updating the website.
Bridget: Nice. But I wanna hear a little bit more from our organizers, especially how you see the outreach to the community, the selection of talks, how you’re curating this experience for your local community, because that’s one of the great things about having an event that’s so decentralized is Every community that runs one of these, it’s a little bit different, and they have their own mandate of how they want to shape their local tech scene. So I want to hear a little bit about shaping a local community and the way you set conference and meetup up to do that.
Josh: [00:28:18] Yeah, so the first thing is before you even want to organize a conference, you should try a meetup. Meetups are an interesting beast because, like, I strongly believe that nobody should be required to do professional development after work unless they want to. However, it’s a very good thing for your professional career to actually make it out to meetups, to be talking to people, meeting people that do tech in your community. And so you walk this very fine line trying to chill out this thing that you’re really working hard on and hopefully has some really good content, but you can’t really expect anybody, including your colleagues, to go because it is making a commitment after work and people are parents, people have other hobbies like And they should not be engaged in tech 24/7 unless they want to. That being said, you also start realizing that every tech community is different. And so one of the things that we encounter with Madison is that there’s a lot of really great tech folks here that are working pretty much in isolation, or especially this is what we encountered at the beginning. And so part of it has been us slowly over time reaching out to like 1 or 2 people at these orgs and you get them to bring a friend or 2 and it just kind of slowly snowballs. And so at this point we’re one of the consistently larger meetups in town, which isn’t super big by any standards, but it’s been really eye-opening and kind of—
Emily: [00:29:56] yeah.
Christian: Yeah, I was going to say that. We are continuing, we are always continuing to work on outreach to additional communities, but specifically for DevOps Days Madison, we encouraged a lot of local people to submit talks, offered assistance if they needed it, and then, you know, opened the doors to try and get some other good talks from other areas. And made sure that we were curating the talks responsibly?
Josh: Yeah, the curation part is, it’s going to be different for every city because every city has its own needs, especially cities in which DevOps is coming to, like, you know, we’re about a decade into DevOps as a term now. And so when we’re coming into this term relatively late, there’s a lot of connotation of DevOps as just Operations 2.0. And so, one of the big things is really trying to cut through that, and especially not just with the ops folk, because a lot of people who are traditional sysadmins, they hear all of the kumbaya we preach, and they’re like, oh my gosh, this can happen? And people get really on board with it pretty quickly. But at the same time, you need to convince developers, QA folk, business side people, like security, like project management, anybody at those organizations that this could be applicable to them. And so especially on the local level, that’s a lot of the outreach that you really have to be doing because if you don’t get those folks in your community involved, they’re not going to and you’re going to have a bunch of sysadmins who sit around and try to commiserate about, you know, well, this developer did blah. It’s not really useful for anybody.
Christian: [00:31:53] And something else I wanted to talk about, just Madison being located in— not stuck, but located in between Chicago and Minneapolis. You know, we intentionally try to be hyperlocal with our talks, with both the meetup but also with the conference, just because if somebody wants a really big conference, you can go to Minneapolis, you can go to Chicago. They’re not They’re not that far, trust me. And it’s a great experience. Like, my first DevOps Days was Minneapolis, and it’s amazing, but it’s a completely different experience than something smaller. And, you know, we are never going to be the same size as Minneapolis or Chicago. We don’t want to be because it’s a different experience, and we hope that our— hope that people who attend appreciate it for that.
Matty: I think that’s it. Every, like you said, every city is different and every DevOpsDays event is different because of the personality of their community and also the personality of the organizers as well, you know, and the event they want to do, which is hopefully influenced by the needs of the community. I’d like to think that it is in the case of Houston.
Bridget: [00:33:07] We hope.
Matty: But, you know, there’s certain things, you know, it’s like, to your point, I vastly appreciate going to Minneapolis and the size that Minneapolis is and Chicago is never going to be at that size. That’s an intentionality on our part because, to be quite honest, I think that, you know, Bridget is the only organizer who can pull that off. I know we can’t and make it feel right.
Bridget: The numbers he’s talking about is we’re at maybe 850 and you’re at like 400, 500.
Matty: Right, but 850 felt like 400 when I was there. It would feel like 2,000 if we tried to do it, you know, because we’re— that’s just not where our skill set is. So we build a different kind of a program and do a different kind of a thing. But like when you talk about curating the talks and the content, you know, we’ve always in Chicago tried to have a lot of intentionality around— it’s not always very apparent, but there usually is a story of some kind. And it’s not always something I’m really well able to articulate, but a lot of it has to do with what needs to be heard in our opinion in the local community that year. And it was kind of funny, like Bridget was mouthing to me, security. Before, and I was just— my running joke is, if you remember that 2014 DevOps Days was the year of empathy talks, 2016 or 2017 DevOps Days is the year of security talks. You know, I gave one too, it’s fine. But it’s— there’s the themes, and it’s not because everyone’s like kind of, you know, copying from everybody. It’s because this is what we’re interested in. So it’s important to know, what I’m connecting to is that when you’re curating your content, it’s what is applicable to your community And again, what they’re talking about in Silicon Valley is different than what they’re talking about here in the Midwest. We in the Midwest, all 3 cities we’re talking about, we’re all salt-of-the-earth, wait-and-see towns, right? Starts on the West Coast, then the East Coast does it, then the Midwest goes, okay, now we’re ready.
Bridget: [00:34:57] Well, we’re just not going to YOLO everything out into production on day one. We’ll let California do it.
Matty: It’s totally fine, right? So it’s good, but then we’re measured. But that being said, We do need, you know, there is value in saying, let’s, to me, I just sort of, and I think this is the, you’ve built your program similarly too, is it’s important there’s voices, quote unquote, nationally, if you will, for lack of a better term, that folks in Chicago need to hear because they’re thoughts that we don’t have in my town, right? But they also need to hear, but if it’s all companies in New York and San Fran and whatever, then no one’s, they’re like, well, that’s fine for them. So they need to hear, What if local— so in my mind, transformation stories should be 100% local. Concepts can come from wherever someone has a smart idea, right? But yeah, again, who cares about a transformation story in a different metro that has a different feel, right?
Bridget: It’s like Andrew Clay Shafer always likes to say, it’s like so much attack is tribalism in fashion. Everybody wants to know, well, that’s great, but does it work for somebody in my vertical? And, like, in my geo? If it does, then we’ll talk. Now, I want— I know we’re getting low on time, but I do want, before we get some closing thoughts from everyone, I wanna hear what Emily thinks from the point of view of, you don’t run a DevOpsDays, you’ve spoken at DevOpsDays, several of them.
Josh: [00:36:18] Yes.
Bridget: And other conferences too.
Matty: Which one is the best?
Bridget: No, we don’t wanna hear that. At least I don’t.
Emily: There’s too many organizers in this room.
Bridget: But what I do wanna hear, Because you’ve also done in your developer advocacy role, someday I will learn to say that word.
Emily: I struggle with it too. Don’t worry about it.
Josh: DevRel.
Bridget: Yeah, in your DevRel role, can you talk a little bit about the kind of reach and scope and focus and direction of the conferences that you’re out going to, that you’re seeing? Like, how would you say that the DevOpsDays conferences are the same or different from other events?
Emily: Oh, DevOps Days are my favorite by a league. And the reason, and, like, you know, I never really worked in operations. I was a developer, and I just somehow fell into this, and I love it. But the setup, I think, is so accessible, you know, and that’s everything from the talks that are given to the price of the ticket, you know, like, not everyone can go to DockerCon. No hate to them, but it’s just a different audience. And so, I love that people can come, they can stay locally. Usually the people that show up are from that area. They may know people or employers or whatever. And so I like that focus. And then the open spaces is really what I think distinguishes it from the other conferences where you have the ability to actually curate your own experience, which is extremely unique. But looping back to what you were saying, just going around the country, I kind of thought that tech would be the same everywhere. And it’s not. I gave a talk in New York, and I should have known this, but they were, like, all finance people. I was like, oh, you all work for Bloomberg. Okay. And then, you know, you go to, like, Connecticut, and it’s like, even the DevOps days, it’s going to be Fortune 500 companies because that’s what’s there. Whereas Denver is a lot more focused on startups. And so, it’s just interesting, really eye-opening to see what works for these different verticals depending on where they are. And, yeah, just talk with people. That’s my favorite thing, just getting to chat with people.
Matty: [00:38:20] So I think we probably need to wrap it because I’m pretty sure people need to come back in this room for closing ceremony. So maybe we’ll just hit one parting thought going back to our initial theme of being able to make change, to be basically— what would be your one piece of advice to affect some kind of change in your organization when maybe you’re not the big boss?
Bridget: Person? All right, and I, and I think you should answer that first, Brett, and then we’ll just go around.
Matty: All right, there we go. Uh, my, my first bit of advice, my one bit of advice is understand what your business is about and figure out one change to make and tie it to— but a change in outcome.
Christian: Outcome.
Josh: I’ve got 3 relatively short things.
Emily: Sorry, um, did you hear my quote from earlier?
Josh: I know, but So first is that you have to start local. You’re not going to affect change on a massive scale, which segues into the next, is that change happens slowly. You’re not going to see something tomorrow. You’re not going to see something next week. It might be months. It might be a year. It might be longer, depending on what kind of org you’re in, which leads to the third, which is that you need to make sure you don’t burn yourself out while you’re affecting change. Happens way too often in our community. And if you are a change agent at any sort of organization, especially one of any size, you run the risk of that, and you have to be careful. If you’re burning out while trying to affect change, you need to leave or stop.
Emily: [00:39:54] Sort of piggybacking off of that, I like to think of change like water. It’s slow, and sometimes it’s, you know, painstaking, but it slowly carves that sort of pattern over the rock, and that’s going to be the long-lasting change. When something changes very suddenly, it may last for a minute, but it’s not going to be that sort of evergreen change that you’re looking for.
Christian: So I guess no matter the size of your organization, whether or not you feel it right now or not, you are absolutely empowered to make a change. It might start with trust, just creating trust with one other person. It might start with creating trust with the director or the CEO or whoever. Just get out there and start talking to somebody and start affecting change. Then you too can start out as an AIX admin and end up 100% on the cloud.
Matty: I would like to point out that both between Christian’s comments here and then a talk earlier, there was this comment like AIX is prehistoric and nobody uses it, and I would like to introduce you to almost all of my customers.
Bridget: [00:41:02] And I think I would agree with everything I’ve heard here, but I’d also point out, if you’re sitting there listening to this wondering who is going to change things and who is going to make things better, make things better, spoiler alert, it’s you. So like, you should feel like you can and you should make things better around you. And if people do not want to let you change your organization. As, you know, I think Nathan Harvey liked to put it, you can always change your organization. Everyone’s hiring. So, like, it is you. You are empowered. If you need permission, Arrested DevOps gives it to you.
Matty: We’ll write a note to your boss. So, this was awesome. So, thank you for our live studio audience. Live in terms of that you are alive, not that we broadcast this live. You can head over to arresteddevops.com/devopsdaysmadison for the episode show notes. Our website also has where you can subscribe to our newsletter, check out our Patreon, all the Arrested DevOps stuff you could ever want. If you’re here and you want a sticker, I have a couple of them. My pocket still. If you go to arresteddevops.com/itunes and leave us a review in the iTunes Store, that actually helps people find the podcast. I’m not shilling for reviews, mostly not shilling for reviews.
Bridget: [00:42:34] Thank you so much to Christian, Emily, and Joshua for joining us.
Emily: Thank you.
Bridget: Thanks. I’m Bridget at Bridget Kromhout.
Matty: I’m Matt at Matt Stratton.
Bridget: We’re Arrested DevOps, and remember, there’s always DevOps in the banana stand. Today’s podcast at DevOps Days Madison was brought to you in part by a fortuitous loan of a Tascam recorder. Peter Sengstock brought us this recorder. Peter, can you introduce yourself and tell us a little bit about your organization?
Peter: Sure thing. I’m the computer media specialist for the Department of Communication Arts at the University of Wisconsin-Madison. One of our researchers is currently working on a rather large project to archive all the podcasts and make analytics available to media researchers. The project is called Podcaster, P-O-D-C-A-S-T-R-E dot org. And I know we’re looking for anyone who wants to have their podcasts archived for media historians to analyze in the future. So if you have any interest in that, please contact us.
Bridget: [00:43:51] Thank you so much, Peter. I think Matt also really appreciates us getting a chance to do an impromptu recording here. Matt, do you want to talk a little bit about how we might be able to work with Podcaster in the future?
Matty: That sounds great. I mean, we’ll definitely put a link in the show notes so it’s easy for people to get to. They don’t have to remember later to do that. So make sure you head over to the show notes to find the link for that. I for one am absolutely fascinated to check this project out and share it with other people in the podcasting community that I know about and definitely amplify that and see what there is to do about that. So, and we’re happy to mention it again and again and again on the show. So listeners, look forward to hearing more about Podcaster.
