DevOpsDays Minneapolis

Matty: [00:00:04] Welcome to Arrested DevOps, episode 16, DevOps Days Minneapolis. I am Matt Stratton, one of your usual co-hosts. And joining me today, since Trevor is not here, is our other co-host, Julian Dunn. So Julian, you want to introduce yourself?

Julian: Yeah, I’m Julian Dunn. I work at Chef with Matt Stratton. As an engineering lead. So thanks for having me co-host the program.

Matty: So what we wanted to do today was have some of the people who have attended or spoken at the conference so far join us and talk about their— this is really weird not looking into a camera in my computer— to talk— that’s okay, I’m gonna actually talk to people— to talk about their experiences either speaking or attending and just what it’s been like. For those of you who are joining us who don’t know anything about this event, so this is DevOps Days Minneapolis. It is the first ever DevOps Days conference in Minneapolis, and it’s the first one in the Midwest. So it’s super exciting. It’s also the first DevOps Days that I have actually been to, and it was my first Ignite that I’ve ever given, and it’s been a lot of firsts for me. So Julian, you wanna tell us a little bit about your experience with DevOps Days?

Mike Landy: [00:01:18] Sure.

Matty: In general and in specific.

Julian: This is probably about the 4th DevOps Days that I’ve been to, and it’s really quite interesting to see. There’s obviously commonalities across the different DevOps Days, and some of the talks are common, and there’s common themes that run through. But one of the really interesting things is kind of seeing local messages and local folks come out, and some of the open spaces go a little bit differently. For example, yesterday there was an open space about how to not be a pointy-haired boss, and somebody said, well, one of the reasons why perhaps feedback isn’t quite as direct in the Midwest, and especially in Minnesota, is because there’s this kind of Minnesota nice complex, right, where it’s considered impolite to give direct feedback to people. And so the challenges are a little bit different, and it’s interesting to see the regional differences and the regional challenges.

Matty: That’s super cool. So joining us to start, we’ve got our— so our first 2 guests are JP Morgenthal and Katherine Daniels. So do you guys want to— JP, introduce yourself quickly.

JP: Actually, ladies first, actually.

Matty: Oh, yeah.

Ryn: All right, I’m Katherine Daniels. I am an operations engineer, one-woman ops team, woo, at a company called GameChanger. We’re a platform that does scorekeeping and statistics for amateur sports. We’re based in New York.

William: [00:02:29] Cool.

JP: And I’m JP Morgenthal. I am the director of cloud computing and DevOps practice for Perficient.

Matty: So Kathryn, first, so you gave a talk today. It was called DevOps is Dead. So have you given that talk before? I know you’ve spoken at a bunch of conferences. Have you given that talk before?

Ryn: I gave a longer version of this talk at Berlin Buzzwords in Berlin at the end of May.

Matty: And I appreciated the kind of simplification of the Gartner hype cycle that you used to explain it, which was pretty good. Have you found that to be kind of an easy way for people to understand?

Ryn: It seems like it. I was actually introduced to the concept not that long ago, sometime this year, and it was easy for me to understand, so I figured other people might benefit from hearing hearing it explained that way as well.

Matty: And so what’s been— and then your experience with DevOps Days. You’ve been to them before, yes?

Ryn: Yeah, this is my 3rd DevOps Days. I’ve been to 2 in New York, including the one that was postponed because of the hurricane. I really liked this one. I told Bridget earlier it’s been the best DevOps Days event that I’ve been to so far. I really liked all of the talks. There was a lot more about culture instead of about tools. And it was really great to have so many open spaces so we can get these kind of conversations going.

Matty: [00:03:50] And JP, have you been to DevOps Days before?

JP: No, this was my first one as well, and highly impressed. The quality of the discussions are just far better than any cloud or DevOps conference that I’ve been to so far. And I think one of the things I was talking with someone on the way to lunch is different is that you go to a conference, like DevOps Summit or Cloud Expo, and you meet somebody, they’re not inclined, not knowing you personally, to open up and share with you, oh, my job sucks, I hate my boss, this is what’s broken, just because they don’t know who they’re talking to or where the information might go. Yet, you have an open space, and these same people will come in, and they deliver great input into the open space and share very quickly. And it just opens the opportunity to have such rich discussions about what’s happening and why things are happening that you can’t necessarily get at some other events.

Matty: So given that you haven’t been to a DevOpsDays before, based upon any expectations you might have had of attending, how was it different? What you expected? What really maybe threw you for a loop?

JP: [00:05:00] Well, they used to do the cloud ones, uh, with Dave Nielsen. So I, I got a feeling for the unconference stuff, uh, and in the past, and that those have been fun. Uh, again, I think it’s the level and quality of the, uh, the talks themselves that really differentiate the event. You know, typically it’s the pay-to-play scenario for a lot of conferences, whether it’s UBM or, uh, one of the other major event So SysCon, and there’s a necessary need, there’s a need for that, right? Here, I like the way that the vendors were given space, you know, 2 minutes to represent why they’re here and what their interests are, but the content was really well focused on things that matter on a day-to-day basis to people.

Julian: Well, DevOps Days is obviously, it’s very practitioner-oriented, and that’s sort of what Kathryn was talking about as the one-person ops team. So, actually, back to your talk for a second. Can you kind of describe quickly, like, why do you say DevOps is dead?

Ryn: [00:06:02] Yeah. Basically, I was talking about how the term DevOps has been used and misused so many times that it’s become more of a buzzword, at least in some circles, like with recruiters especially, just throwing the word around. So, I kind of wanted to address that and get back to, I guess, like first principles. What was the movement originally trying to accomplish and where is it going to go in the next 5 years?

Julian: Right. Where do you think it is trying to go in the next 5 years?

JP: As she looks at Patrick Debois over there that you can’t see on camera.

Matty: Yeah.

Julian: What’s it like being a one-woman ops team?

Ryn: It’s tiring. Luckily, I work for a pretty great place where, like I was talking about in my talk, the developers are all on call. So I’m not the only person on call, though I have done that before and I’m not going to go back to that. But we’ve been kind of experimenting with how to organize the team as we grow. We’ve brought on, I think, 10 engineers in the past couple months. So it’s a process.

Julian: [00:07:02] Right. And part of what you talked about in your talk is making sure that the incentives are aligned for folks to ensure that they have good behavior. So can you talk a little bit about that, how you’ve kind of structured that within your company?

Ryn: Yeah. Like you just said, it’s aligning incentives. When we have the developers on call, they are all of a sudden, you know, the first line when something goes wrong. They have that visibility into it. So there’s more motivation for them to really care about, you know, the quality and the experience of using their own product.

Matty: I think Michael had a question for Kathryn. Oh, he’s moved on.

Bridget: Okay.

JP: You know, it’s really interesting. You know, one of the things that I struggle to reconcile with, and I’ve come to the point where I just create a delineation. So Katherine works for a small organization, and I think DevOps works very differently in that space than, say, a Fortune 2000 company that’s been around for, let’s say, more than 25, 30 years, where you’re now struggling. And we’ve seen it very interesting here for the people who are listening. One of the sponsors was Target. Target brought a lot of really great use cases and how for a very large IT organization, they’re trying to change the culture and bring and introduce DevOps as a way to really add quality, ensure, you know, remove fragility, speed time to market for their applications. And that’s great to see. But, you know, my experience is it’s very difficult to take a very large organization with embedded fiefdoms and political infighting and legacy systems and just try to introduce one of these concepts. CI tends to be probably the most easily adopted, but the concept of taking that and then adding that automation all the way to the end, and not only that, but the whole tie-in to continuous improvement, that’s the stuff that I see in the enterprise is very different. Where I think a small team has tremendous opportunity to make great headway and really leverage it, which from a business perspective is very interesting. Look at Kathryn’s organization. Revenue per employee is probably going to be very high in her organization because you have a one-man ops team, right? What does that say to a Fortune 2000 company who’s got 40,000 people in IT, right? And could, you know, what can they learn from this about revenue per employee and how much they’re spending on IT and what DevOps can bring for them.

Matty: [00:09:41] I think it’s interesting, and we’ve had this conversation on the show before, and actually this was something that came up with the conversation with Jez this week, which you guys can listen to at arresteddevops.com/15. He talks about it way better than I do, but one of the things was when we talked about how these things happen is he says, we talk about the idea of maneuver warfare. Which is this idea which goes back to basically almost back to Napoleon, and he says it way better than I do because he’s jazz, but that it’s— which is basically we focus on outcomes, which say you have the domain knowledge and you’re the boots that are on the ground doing the work. You know how to get from point A to point B. I don’t really care how you get there, but I need the result. And he said the irony is that we talk about command and control and we love this word in business, and command and control has not been in vogue in the military for hundreds of years. ’Cause it doesn’t work. And so I think when that talks about where you scale it to the enterprise, it’s a fundamental shift in how business gets done to move to this idea, but that’s how you keep from being disrupted, and I think that that’s what ends up happening is the enterprise can be slow-moving. The other thing that when we had on a show, when we had Damon on and he was talking about how The problem is there’s this perception, and it’s getting better because companies like Target and GE Capital are coming out and they’re talking about what they’re doing, but for years they didn’t talk about it. So all we heard about was Facebook and Netflix and startups, when the reality was the enterprise was doing some of this stuff, but nobody talked about it. So people who worked in the field were kind of like, oh yeah, I know, I was over at that place that rhymes with AP Jorgen Mace. And maybe they were doing some DevOps stuff, maybe they weren’t, but we can’t talk about it. And we even, in previous work I’ve done, we talk about having no-logo customers. It’s a customer that will not go on record saying they did this, but we’re all doing work and doing it. And then I think, so the first thing is companies are gonna sit there and they’re gonna say, how did this disruption, you’re gonna be disrupted, and the companies that are motivated to change are the ones who are gonna be disrupted, and if you’re not motivated to change to avoid the disruption, then you’re gonna be disrupted, and then who cares? Screw you, get out. So I think when people start seeing that competitive advantage, and then they wonder, why is Nordstrom working? Why were they not kicked out by Amazon? What are they doing? How can I be like them? Why is Target— why were they able to pivot? What did they do that was special? And I think that’s the challenge. And sure, it’s easy to say, oh, it’s way easier in a small company. It is and it’s not, right? But big companies are made up of small companies, and small companies are made up of people, right? We’re still all, you know, you can be, you know, again, GE, the biggest company in the world, and you’re still made up of all individuals, just as many people as Catherine’s company. Well, not as many, but each person is still one person, and I think that’s one of the challenges.

JP: [00:12:40] The command and control issue is a big one. I wrote a blog for DevOps.com about how Services become the language of DevOps in large organizations because you have those silos, right? Michael talks about the goats and the silos, and everybody wants to either smash the silos, which creates this huge noise. It just adds your signal-to-noise ratio. It goes up significantly if you break down silos, but yet communication is needed across them. And that’s what That’s what traditionally we don’t have right now in large organizations is they don’t communicate well across the silos. And so if you can introduce that in a programmatic fashion, because you can’t count on it always going on in a personal fashion, then I think that you can really make some headway here.

Matty: So the godfather of DevOps Days, Patrick DeBois, has something to say. So Patrick, yeah, please come join.

Patrick: I just wanted to ask—

Julian: [00:13:40] is that on?

Matty: I don’t know if the mic’s on.

Patrick: Oh, there you go. If you say command and control doesn’t work, would you— are you willing to do command and control if you trust the command that controls you?

JP: I think part— well, if you look at the military, right, the option there is death. So you tend to do it for fear of death. So I guess if the carrot— the stick is big enough, you would. If you had choice and you have conviction, you might not.

Patrick: What if your manager has the view that you don’t have?

JP: I’m sorry, what if the—

Patrick: What if the manager has the view that you don’t have, and so you can judge, but he might be the one that knows the difference between life and death in your company?

JP: That’s right. And that tends to be why you follow those chains of command, is assuming that they have information to operate on. Of course, the people all below look up and go, what an idiot. I could do it so much better.

Matty: [00:14:42] But then I think that’s the exact crux of what Patrick just said, is the question was, would you follow the command if you trusted the command? Because I sit there and I said, oh, command and control doesn’t work, because obviously Jez said that, so it must be right. And then so the question was, right? So if you trust the command, then can it work? And then that’s the operative word. And then JP, you said, well, you say, oh, you’re a bunch of idiots, which is what we’re used to saying about management, right? How many times— I mean, used to being the, OK, well, I’ll do it because my boss said— it’s not common to have that trust. And the thing is, in a way— and I may paint myself in a corner on this thought, right? But it’s almost like the way that you gain that trust, or that you develop that trust in your leadership, is that they show the trust in you as well. So maneuver warfare definitely doesn’t mean that you go, hey, Patrick, just do whatever the frick you want. I don’t give a shit. I’m still going to coach. I’m still going to mentor. I’m still going to guide, and there may be times when I say, you know what? I might have information, and you know what? I really can’t share it with you, because sometimes that’s true, right? We can be as open as we want to be, but sometimes there’s regulatory reasons that I can’t tell you everything. But what I want to do is, number one, is say, but if I built up the right kind of trust, and I’ve been in organizations like this where I’ve had bosses that will say, actually I’ve had lots of bosses that say, you have to trust me. I’ve had very few where I actually did. But if I do trust you when that, what should be the rare occasion comes where I have to say, hey, you know what, Julian, it’s for your own good, just do this. If we have a culture of trust, you’re going to say, Okay, I don’t suspect ulterior motives of Matt, right? This time then maybe he does have this information, but the problem is it’s usually the stick, right? It’s usually the, well, I’m your— or you have the manager who’s kind of like, oh, well, see, I know things because I’ve talked to the board and because I’ve— the CEO has said things I just can’t tell you about and blah, blah, blah, and then you just go, well, so now you’re telling me there’s information that I don’t know and maybe I should know it and how do I know that they know what they’re doing? And I don’t necessarily trust you. So, I said trust like 35 times, and I think there’s a reason.

Ryn: [00:16:49] Yeah, I think a lot of it has to do with visibility and transparency, and that’s what I’ve noticed a lot moving from corporate America back in the early days of my career, moving towards startups. Though startups aren’t all the same. They’re not perfect, and some of them are not very transparent. And like you said, the ones where I have had the most trust in the people above me were the ones where they shared as much as they could, because obviously, Yeah, there’s sometimes stuff that you can’t share with everyone, but when you share what you can on a regular basis, it builds that.

Matty: I think transparency is the default, and you override it as needed and as rarely as possible. Michael, you have a question, thought?

Mike Landy: Yeah, so Mike Landy, and I work at Critical Mass, group technology director. And so as a group director, I do have, like, I have oscillated between high-trust cultures and kind of a command-and-control style. Because there are cases, as you described, where you just can’t divulge all of the details. But you can kind of do directional shepherding, where you want to have really strong individual contributors on your team, and for them to kind of, promise theory style, create a mesh network where they can each kind of go toward that goal. And that’s your directional tailoring. You’re trying to get them all to move in the same direction. But I think strong command and control can really fail when you have to collect so much information and kind of hold so much in headspace as the commander that you really don’t have all the perspective immediately available to make those right decisions. I think it can be really difficult if you’re trying to know everything, being omnipotent. I mean, no one is, right? So I, I think a really strong command and control just like out and out will fail because No one is omnipotent.

Matty: [00:18:35] Now here’s just a random thought that popped into my head with what you just said about taking that promise theory thing. And I’m just thinking about, do you think that the culture of your organization can drive the architecture of your software? And I’ll tell you what I mean.

JP: That was Conway’s Law, wasn’t it?

Ryn: Yeah.

Matty: Well, but in terms of— yeah. So taking that— but then it could go in both directions. So good point. So of course there’s no original thoughts. But I’m thinking about places I’ve been where There was lack of trust, and service-oriented architecture was never a consideration. Because if you don’t trust the other people, then you don’t trust other services. It’s not even so much that you don’t trust them, that you mistrust it. It doesn’t occur to you that such a thing could happen, that you could say, I only have to worry up to this contract.

Mike Landy: Hopefully you don’t implicitly trust forever all the services you consume in your architecture.

Matty: But if you have a contract, you trust that that contract— so it says that I have a contract to this service, so I don’t have to tested all the way through because the service is promising to me that it will at least try, right?

Mike Landy: [00:19:38] Yeah, there’s a heavy dose of truth in Conway’s Law.

Julian: Yeah, I wanted to ask some interesting questions about Conway’s Law. You know, Jeff Sosna talked about Conway’s Law, and, you know, coming away from his talk and describing what it was, I wasn’t totally sure whether or not the, the point was Conway’s Law is sort of a thing that just exists out there and we have to respect, like Moore’s Law, or whether or not it’s a thing to be blown up. Right, in terms of the organizational structures. You know, do we— you know, this is a pattern that we recognize through our sociological studies of how organizations work. Is it— do we— are we attempting to abide by the tenets of the law or just sort of accept that they’re there? Are we trying to explode it?

JP: We had an open space on that yesterday, actually. And it was really good. It was anti-Conway’s Law, meaning that can you actually shape your organization so it shapes your your output and your product in a particular way. But what we came out of that was, it’s an observation. Conway’s Law is an observation. This is gonna happen. It’s just human nature, right? Your product is gonna follow the communications of your organization. It just tends to flow that way. So the open space was, well, what about if we purposefully organize ourselves in a particular way, would that shape the output to what we want? And we, we did talk about some examples where that happened and it— the outcome was the desired outcome.

Matty: [00:21:02] Can—

Mike Landy: I totally agree, JP. I overheard someone asking if there was a semantic distinction between projects and a product, and I think the language that’s used, and it was a slide in Patrick’s talk, the language that’s used is also really important when you consider the implications of Conway’s Law, because you can easily change kind of the way a team feels about the work they’re doing if you refer to the work they’re doing as a part of a project— sorry, part of a product and contributing to that product instead of just like this project we got to get done by the end of the month.

JP: By the way, interesting to note, speaking about— and I know this is tangential, but we’re going to change topics in a second, I believe. Actually, show you how cool this community is. Michael, who was just speaking, myself, and Matt, we’re all organizers on the Chicago DevOps Days that’s coming up in October, and we’re here at the Minneapolis one. So really, really cool to have that community sharing that’s going on and the way we go to each other’s DevOps Days.

Matty: [00:22:03] So Andy has got a thought.

Andy Fleenor: So I’ll try to make it quick because I know you want to change topics. One of the things that just, I heard a lot, a lot this week about the trust and empathy and things like that, and when I was listening to the talks this morning, I haven’t fully processed some of these thoughts yet, but listening to Susna today when he was talking about promise theory and he brought up the idea that you really had to consistently reevaluate your level of trust based on the commitments that others in your organization are making to you and what that looks like, and then when you look at some of the things that Ian was discussing today around enabling people to feel comfortable failing, and making sure that if you’re building a process, it’s not just patching something stupid that you do, that it’s actually a valuable process. But when we talk about applying some of this culture and some of this logic at an enterprise level, I think, so I work at SPS Commerce, and we’re not quite there yet. We’ve got really good leadership that understands some of those subjective things that you need to be able to run with, but when you look at larger enterprises, I think what they run into sometimes is the idea that they understand you need to reevaluate trust, but they end up doing it in a way that’s very statistical and it’s not subjective because they need business numbers to demonstrate that. So as a result, you start incenting your teams to, like Ian was saying, make sure that graph looks okay. So it’s really, I think you have to have that level of subjective trust and assessment that you lose the ability to do that in an enterprise because they need to have those business graphs and those business objectives, and to Ian’s point, When you do that, what are you really incenting your team members to do? What, are you gonna come to work and do a good job, or do you wanna look like you’re doing a good job?

Matty: [00:23:42] You can get really good at making those numbers look right. It’s like Scott Adams, the Dilbert creator, Dilbert, like I have to tell anybody in this room who Scott Adams is, but maybe on the internet somewhere. But in one of his books, he had the, because people would write in with all the ridiculous things their companies do, and that’s why Scott makes as much money as he does, ’cause people do that for him, which is awesome. But anyway, the story was basically someone wrote in and said, hey, in our organization, They decided that to improve quality, they said we’re going to put a bounty for the testers for every bug that they find. They get a cash bounty. But then we’re also going to put a cash bounty for the developers for every bug that they fix. And then overnight, this black market of bugs comes up, of collusion between QA and dev. And then after they had to pay out like $6,000 in the first week, they’re like, no, no, no, this doesn’t work. So it’s like you said, you don’t want to game— the metric because people follow those incentives.

Andy Fleenor: I almost think it would be interesting to take, like, I can’t remember their names right now, but the Freakonomics guys and have them come in and actually look at the DevOps culture and environment and see how they can apply some of those economics to the human incentives we drive on.

Matty: [00:24:47] That would be awesome.

JP: You know, I don’t know, I’m not sure if, it’s been a while, but I was once at a talk and I think it was Kovi or one of those business self-help guys has a book called Business at the Speed of Trust. And in that book, they discuss a lot of these issues and how, you know, actually trust becomes such a key component to actually doing business at all levels. And it’s interesting that you’ve now brought it down a level, even into the IT group itself, and how we can execute on our projects and what we’re trying to get accomplished and how the trust we have for what we’re contributing to significantly shapes what we’ll deliver.

Julian: Cool.

Matty: So I do wanna shift gears a little bit. So first though, I wanna thank JP and Kathryn for joining us for this talk, which was awesome.

Julian: Thank you.

Bridget: Thank you, Aaron.

Matty: But I want to invite Bridget and Patrick to join us ’cause I wanna talk a little meta DevOps Days. For those people who either haven’t, kind of want to, because I would like to get an understanding of kind of the journey of what got us to— Bridget, I got one here. So yeah, I want to take a little bit of time, and this morning for people who were here, Michael Ducey gave us kind of a nice little story about like, hey, this was kind of the history of getting us to DevOps Days Minneapolis. But I’d like to hear both from Patrick, from you, and from Bridget. Like, what’s the story, right? How are we all sitting in this room together today? I know I told you I was going to ask you about the past or the future. That was what I promised Patrick yesterday.

Patrick: [00:26:27] No, actually, I told you not to ask me. But you shouldn’t actually ask me. You should ask Bridget.

Matty: Yes, that’s true. Bridget was looking the other way, and I didn’t think she was paying attention.

Bridget: It’s pretty much like Ducey said. I showed up at a meetup, and they said, Michael Ducey and some of the other folks at the meetup said, we’ve really been hoping to get a DevOps Days Minneapolis going. Would you like to be involved? Would you like to help make this happen? And I said, yes, I can do that. I can make this happen. And with our whole great team of awesome people, such things are actually possible. It’s kind of funny, I was giving Patrick a hard time. I think Ducey was laughing at me for it, because I was giving Patrick a hard time a couple of days ago, saying, you know, this is a franchise. We’re not gonna always do things your way. We’re gonna do things a little differently, but that’s okay. I mean, how many of these have you actually run personally from overseas?

Matty: Not command and control, right?

Patrick: I think about, I don’t know, 30?

Bridget: [00:27:32] So it’s not a terrible thing to have other people step in and do things, maybe a little differently, maybe not entirely differently. But I’m so grateful that you were able to make it to this one, because so many people, when I asked how many people in the auditorium were new to DevOpsDays yesterday, most people in the room had not been to one. And, you know, this time last year, I hadn’t been to any. And so it’s really exciting that It’s a community that we can all jump into and get engaged with right away.

Julian: One question I want to ask Patrick is, you know, the DevOpsDays— well, JP touched on a little bit about the individual practitioners, really about drawing out individual practitioners and the practices. And I think the format of DevOpsDays is quite unique with, you know, sort of a morning of invited talks or accepted talks from CFPs and then an afternoon of open spaces. How is it that you decided on that format? As being the way to run DevOps Days?

Patrick: Well, I was introduced to the format of Open Spaces before DevOps Days. I was running it within the Agile Open Space within Belgium, which I’ve done a few. So I knew the power of the format. But for where it was kind of easy for Agile on conference to do, because Agile was established, it wasn’t that easy to do it for DevOps, which is something new. Because randomly inviting people to a place where you don’t know what you’re going to talk about, because at the beginning we didn’t have a clue, that wasn’t really what was working out. So then it’s like, oh, we want to keep the open spaces, but maybe give talks in the morning to make it inspirational for discussions in the afternoon.

Bridget: [00:29:15] So that’s how it So I was thinking possibly when Andrew introduced you, he might have said something about Agile 2008. And I’m wondering if since you’re here with us now, you can tell us about how you and Andrew Clay Shafer were at the Agile 2008 conference and how your discussions from that maybe led to where we are today.

Patrick: Oh, okay. So a little bit of history lesson.

Bridget: Yeah.

Patrick: Well, it’s— I was experimenting because I was like fond of Agile. I was working with a great team of development, but I was the admin guy. You know, we had containers that time, Solaris.

Matty: All is good, all is new.

Patrick: But, you know, this kind of flexibility of doing things, I got like excited they were doing, but like I was— I didn’t have that same kind of practices or I didn’t look. I was then moving a data center for a government. So I worked 15 years in government. So if you thought there was no inspiration for government to develop, so you’re wrong. And I know how hard it is and how rewarding it is if something works, but on the side. So the moving of a data center, that kind of made me like, how am I tackling that? So it was less about the technology, but more on the process. Like, how do we organize these things? And eventually I moved in with a team that was running like the change in the data center. And we started experimenting with Scrum.

William: [00:30:52] And it didn’t work.

Patrick: It was too slow. The iterations in the day-to-day didn’t work. So we kind of learned, ah, Kanban was around. Let’s do an experiment with this. And I wrote a paper on it in 2008, IEEE, to get accepted for the Agile Toronto Conference. Where I talked about it. I think there were 15 people in the room. They were like, what’s he talking about? But at the same conference, there was Andrew Schaefer, which I didn’t know upfront, but he had put up a bird of a feather saying Agile Infrastructure. So I was triggered, like, hey, there’s one person in this whole conference I want to talk to. And I go there at the time that it was foreseen, and he wasn’t there. So he thought nobody was interested in those ideas. So that’s actually the history. And so we kind of got connected on Twitter. He was already involved with Velocity. I saw the talk from John Allspaw, and on Twitter I said, well, we need something, a conference, or at least be able to talk to it. And then somebody tweeted, why don’t you run your own conference? And I did. So that’s the story.

Bridget: [00:32:07] So that’s how we got here. And that’s why we had Andrew Clay Shafer introducing Patrick Debois yesterday— or earlier today. It’s all a blur.

Matty: So from an organizing perspective, Bridget, and again, I have my ulterior motive being going through this myself. But when you— and Ducey showed us your very excited email being like, sure, great, this sounds awesome. So was there any point after the sure, great, this sounds awesome when you went, oh, well, maybe this was really big, or has it, you know, was it just as hard as you thought it would be, or just as easy, or what, how did your perceptions shift?

Bridget: Well, I maybe have a different perspective than some first-time DevOpsDays organizers in that this isn’t my first rodeo. I have been involved with local science fiction conventions and other fandom conventions in concom capacities in the past for years. So I am aware of a lot of the stuff that goes into it from that side. Also, my partner Joe, who is making this livestream happen right now with his partner Ed back in the booth. You can’t see them. Maybe you’ve seen Joe in the livestream a few times, but they’ve been doing great work to make this happen. And he’s actually been in meetings and event technology for 16 years. So I actually see a lot of meetings and events from that side. So I knew what I was getting into. I may not have realized exactly how great it would be doing it with the folks from the local meetup who I had only a passing acquaintance with some of them. Because really, I mean, like Patrick said, when you want to put a DevOps stage together, you just— it’s not a cliquish thing. This is not an in-group thing. This is anyone who wants to show up, just like the law of open space. Anyone who wants to show up are the right people. So we had a whole group of people get together who some of whom I didn’t really know well at all. We’ve gotten to know each other and it’s really been fantastic.

Julian: [00:33:54] How did you find your co-organizers?

Bridget: This is seriously, it was whoever showed up at the local meetup and said that they were willing to work. And some people had more time beforehand, some people had more time during, but everybody brought something unique, something different, something very useful and helpful to make it possible.

Matty: So that actually brings up a question which I’ll throw to both of you because you both have background in other events. So that was like a thought where you said, okay, hey, I’ve done this before. But you haven’t done this before. So I’m interested, what’s different from an organizing or planning perspective of DevOpsDays versus other conferences or events that you might have been involved in?

Bridget: The logistics piece for me, and I bet Patrick has a lot more on this topic, but the logistics piece for me that was actually the hardest to juggle was actually trying to keep everything on time, getting the trains to run on time, more or less, for the purposes of the livestream. ’Cause we only slipped about 10, 15 minutes right at lunchtime today, And there were people on Twitter asking if the livestream was down, because you know what? It’s not just the people who are in the room today or have been at the conference. There’s a whole national/worldwide audience of people who are actually watching this conference in real time, and they wanna know what’s going on if the livestream’s down. Fortunately, our livestream, other than we were just late to turn it on because we were running late from lunch, has been rock solid. Thanks again, Joe and Ed. Really, usually you’re only thinking about the people in the building and maybe about anything that’ll be published later for the conferences I’ve done before. So it was the trying to keep everything synchronized and running for people who aren’t physically here but are still with us on Twitter and in spirit.

Patrick: [00:35:33] Yeah, I think that actually shows also your capacity as a leader. You might— I know you don’t see it like that, but you know, when people say that to me, I cringe the same way. So that’s probably why we connect. But I want to give you like 2 examples on how worried she is about these things. I was at the hotel and you get a cookie at the hotel and there are speakers that are gluten-free or vegan, vegan actually, yeah, and she made sure they had something else.

Bridget: I went to the food co-op and got a vegan chocolate chip cookie because if the DoubleTree gives you a chocolate chip cookie but you but the chocolate chip cookie is not accessible to you, you’re not having a good experience.

Patrick: So by this detail, you can tell how passionate, like, how she is about making this awesome for everybody. And she’s done it to me, she does it to everybody else to make them feel at home. And it is really interesting when you were talking about the, you know, the cultural thing of Minneapolis, that it’s hard to say, you know, in the open. This is so Belgian. So again, I do connect. So thank you for that, Bridget.

Matty: [00:36:50] So in the audience, people in the audience, who has never been to a DevOps Days before that would like to talk about what their experience has been at the DevOps Days? If you step at the mic, Craig, do you want to? I know I didn’t say I was going to call anybody, but I’m going to call on you.

Patrick: Everybody raised their hand, but then they didn’t want to come up.

William: Yes.

Matty: So is there anyone who has, this is your first DevOps Day? Yeah.

JP: Okay.

Andy Fleenor: And you don’t mind, again, I’ll just go really quick to get it started. So this is actually my first one and I was on the organizing committee too. So I leaned on Bridget a ton to, you know, just help guide me and direct me. But I think one of the things that got me real excited yesterday was just the quality of the conversations. They were great, and then to hear Jeff, who I know has been at a lot of these sessions yesterday, made that same exact comment that he was really excited about the quality of the conversations for this being the first event, and the folks here, everything from culture and how you apply it, how you implement it, to the tool sets and how people have them implemented. It was just a really good wide variety of conversations, and the depth of them was really good too. It was really fun.

Matty: [00:37:59] Anyone else?

Julian: Oh, yeah.

William: Yeah, for me, it was like, so what’s this unicorn thing?

JP: The goat?

William: Like, could you explain? So we went out for coffee. I took— I was like, okay, like, imagine you’ve never been here before. What’s that goat thing about? Because it’s obviously part of the communal experience to get all that sorted.

Ryn: Yeah?

William: So that was part of that. Does have a really strong sense of community. And it’s something in general in an American lifestyle— I don’t know in Belgium what it’s like, but we have like a deteriorating sense of community in most of our experiences. So even our work experiences sort of in general have this deteriorating sense of community. We kind of live more separately from each other than together with our neighbors, that kind of a thing. So I think a lot of us, this is what you’re really looking for, is people to belong to. And that share your values and share your challenges and so forth. So that’s kind of the energizing part of it. So it’s been good from that standpoint. So yeah.

Matty: [00:39:00] Thanks, William.

Andy Fleenor: I’m Andy Fleenor. This is my first DevOps Days, my first Ignite talk, my first time giving a public speaking thing at all. So a lot of firsts. Jump in the deep end, man. Yeah, a lot of firsts. And you know what? It’s been a pretty amazing experience. This conference is just awesome. Like everything about it is just fantastic and learned a lot of stuff and all of the conversations have been pretty— How was— how’d you feel about— because today was my first Ignite ever and like I know people who know me or the fact that I mean I talk to the whole internet all the time, but I was scared out of my mind. Yeah, the adrenaline gets pumping. I mean, I was third, so I like had some time to just stand up there and like think about it while they were going.

JP: So it was—

Patrick: If it’s any consolation, I’ve seen well-known speakers triple at their Ignite, so you actually picked the hardest format first. So I’m just expecting a submission next year from you. Thank you.

Matty: I think one of the things that’s awesome, and I know we kind of like— it’s really intimidating to submit a talk or say you want to do a thing, and there’s a couple reasons for that. One is because we think that you have to have something new that’s under the sun, right? Like, I have to teach something that’s It’s never been thought of before. Well, that’s not necessarily true, because first of all, even if it’s a topic that someone else has talked about, you’ve never talked about it before, right? So that’s new. And that was even kind of the genesis. But the thing is, to me, this feels like a room full of people that want you to win, right? I’ve given talks at lots of other places, and there are times when you’re sitting there, and you’ll sit there, and you’ll be like, boop, all laptops open, and no one’s really paying attention, or whatever. Totally, because people are here because they want to be here, right? I don’t think anyone’s here because their boss said, damn, you better go to that damn DevOps Days thing or whatever. All of us probably had to ask really nicely to be able to come to DevOps Days. So we want to be here. We want to hear what people have to say. And it’s just a really great energy. And I think this is a great conference for speaking for the first time because you’ve got a room full of people who are totally on your side. And then with the idea of giving a talk of something that’s already been done, That was totally the thing with my Ignite, was like, it started as a joke, as also Doocy’s goat talk I think started as a joke, right? All good talks start as a joke, that’s my new theory, cuz mine did. But then I went to go put it together, and I was kinda like, or no, well, first it just started as an idea, and I’m like, hey, wouldn’t it be great to have this idea thing? And Cheslock goes, oh, somebody already did that. And I’m like, thanks, great. But then he immediately replied and said, but you could do it a little different. And I said, great, good idea. So that being said, I think if you haven’t given a talk, I think you should totally submit a paper for the next thing you can do, and that might be Chicago, it might be Boston— well, Boston’s closed now, but it might be next Minneapolis, might be anything, but I think it’s a— to me, I think it’s a great and rewarding experience.

Julian: [00:41:54] The other thing is there’s always new practitioners to the field, right? And if you’re a new practitioner, having personal experiences from the speakers that even if it’s ground that’s been trod before, their personal experiences, like Catherine’s talk was great because it’s a personal experience, right?

Matty: Yeah.

Julian: And they’re, you know, people’s personal journeys, and that definitely resonates with people and really gets them in that mindset, right? Because they can connect with the speaker personally as a human as to what that journey was like.

Patrick: I think a little secret, I write my presentations not because people listen at it, but it makes me like put my thoughts together. And like, once that is accomplished, you know, it— the bonus is if people want to listen, but the actual bonus is that you’ve sorted your ideas for yourself.

Matty: You’re doing it for you. So Craig. Yeah, so, um, this is my first, uh, DevOps conference. Um, I left my, um, Mac development background a long time ago. I’ve been in the Microsoft world, so I was kind of shrinking down in my chair when everyone was talking about Windows and everything. But, um, I’ve been to a lot of MMS tech ed I actually gave up going to WPC this week to come and be with all of you. So it’s been a great experience. The Microsoft culture is very tight. And I met a lot of great people over the past 2 days. So I’m very happy to be here and look forward to seeing you all hopefully in Chicago.

William: [00:43:11] So thank you.

Bridget: Thank you. Actually, that brings to mind some— something I was thinking about earlier. Sasha talked about in her opening keynote about inclusiveness, and I got some good feedback earlier actually from somebody who, we had a little bit of a blameless postmortem at lunch, just premortem, I don’t know, in the middle of the conference. I got some good feedback about how there are, of course, like in any culture, there are in-jokes about goats or unicorns or whatever, and it’s easy to look at that and think, I don’t know what they’re talking about with goats and unicorns, is this for me? And I gotta tell you, like I said, October last year is the first DevOps Days I ever went to, and then I ran one this summer, less than a year later. So it’s not a closed community, it is an open community. Sometimes people might forget that you don’t know what these horses and unicorns and goats and what are all these animals. And you know, actually, I gotta tell you, the team that called themselves the Sparkly DevOps, Sparkly Post-DevOps Princesses, Yeah, the post-DevOps Sparkly Princesses, I think, got the worst possible score on the recognizing the O’Reilly animals trivia. And the local team full of individuals who probably didn’t even consider themselves to be of the DevOps are the ones who walked away with all the prizes. So it’s really not a closed system.

Matty: [00:44:36] So I think that— oh, well, I was going to wrap up, so you should talk. ’Cause when I say my thing, then we’re done, so.

William: As sort of like a new person in the situation, experiencing it new, there seems to be a lot of concern about identity. And so the feeling is, at one weird level, it felt like Occupy to me a little bit. You know what I’m saying? Because there was a sense there that they rejected the idea that other people were defining their identity. But I’m not sure they articulated it clearly themselves. So, people— the resistance to have the identity co-opted, I think, is really important. But the responsibility then is to actually affirm an identity so that it’s not at the whim of an external party to define that. So, regardless of whether recruiters ever get it or not, I mean, there’s going to be people that really are not even part of the practitioner group, right, that are going to try to impose some kind of easy— they don’t think very deeply. So, they’re not gonna really get that. So, one of the things I’ve been doing, I’ve got a mind map tool on my iPad and I’ve been trying to mind map what I think the identity is. And it seems like it might be a worthwhile activity to characterize it. Rather than leave the definition to someone else, how do you define it? And it could be as simple as, we’re the people who are here to today. It’s just this group of people. But I think there’s something more important behind that. There’s a more important binding between that.

Julian: [00:46:12] I think that’s a great talk idea, William. You should submit that as a CFP.

Matty: And there was an open space. So Shannon from Chicago just told me right before this, she said, oh, I had this idea for an open space and I was going to submit it, but then I kind of got scared at the last minute. And then she told me what it was and I was like, oh my God, why didn’t you submit it? Because that would have been awesome. And I’ll tell you what it was because I think that people should do this open space, and then I’ll tell you why I think it’s awesome. You may disagree, but it was, she’s like, so what do you want marketing to say about DevOps? Because we sit here and we say, ah, marketing is fucking it up and blah, blah, blah, da, da, da, da, da. And she sits there and goes, well then what are we supposed to say? And I love it because it’s like, stop complaining and help us do it right.

Patrick: So a typical characteristic of a technology worker is that he defines success on external factors. We’re like this in supportive, so we always depend on something. So we might want to think like you say, can we define success for ourselves and not like have it by somebody else’s action define that we have our success? So yeah. Yeah, thank you for that.

Matty: [00:47:25] Awesome. So I think we are going to wrap up because we’ve got more open spaces to go and open space. So I want to thank everyone who joined us for this episode. So JP Morgenthal, Kathryn Daniels, Bridget Kromhout, and Patrick Debois, and my amazing stunt Trevor, Julian Dunn. So, and everybody who this is your first DevOps Days or it’s your 50th DevOps Days, enjoy the rest of the conference and thank you so much for participating.

Julian: Thank you. Thank you.