We Are Always Learning with Patrick Debois

Patrick: [00:00:00] In all due respect, I call bullshit.

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.

Jeff: And I’m Jeff Smith.

Matty: Welcome to podcast hosting, Jeff.

Jeff: Oh, thank you, Matt. It’s so good to be in the virtual building or whatever you guys want to call it here. Um, but I’m really excited to be joining the team and, uh, really excited for today’s episode where we’re, uh, gonna have sit down and have a chat with, uh, Patrick Debois. Before we get into it though, what’s, what’s new with you, Patrick?

Patrick: New with me? I know there’s not never anything new with me.

Jeff: So yeah, right, everything is always just, you know, mellow, nothing changes, right?

Patrick: I’m just a happy father, so yeah.

Jeff: [00:01:01] Well, so you do have a bit of a new role. Um, I think it was, uh, as early as January of this year, right?

Patrick: Yeah, it was a surprise to me as well.

Jeff: Hopefully a good surprise, right?

Patrick: Yeah, you know, I, I, I was thinking of doing it a little bit like more quiet and taking some time off And then all of a sudden, I find myself having a new job.

Jeff: Why don’t you tell us a little bit about what you’re doing now?

Patrick: I have this fancy title that everybody will hate me for. I am the Director of DevOps Relations. In a nutshell, I’ve joined the DevRel group. I’ve done many different roles in the past, and DevRel is new to me. That is again like a new perspective to be in, in an organization. I think my job would be a little bit more on like broadening in the company that I joined, like Snyk, to talk about security more in general, you know, not just from the dev perspective, but from an ops, from a DevOps perspective. And so far it’s been really great, so.

Jeff: [00:02:17] That’s awesome. DevOps, DevRel, you know, like, are you qualified for this? Do you think?

Patrick: Well, I don’t know. Maybe if I get my certification, I will.

Jeff: Right, right.

Matty: So I think it’s interesting when you kind of made the joke about saying, you know, because you have DevOps in the title, although I think it’s okay because you have relations after it. And also I’m someone with that, like, so I’m a DevOps advocate, you know, and I push for that. So I think you and I have similar thoughts about like what the DevRel part is with that advocacy, right? It’s a little less about the product and more about the hearts and minds and change in thought and approach. So what are you thinking about approaching that?

Patrick: Yeah, it’s funny that you mentioned like hard. Like when I put my title on LinkedIn, I made like Dev Hard Ops, but it doesn’t seem to pick up. Like nobody’s copying that when I speak at conferences. Maybe it’s a Unicode problem, I don’t know. But you know, it’s just, yeah, like you say, it’s I find it important to put the word relations in there because that makes it less about the technology and more about people collaborating and the cultural side of it.

Jeff: [00:03:33] So I’ve got a question that I’ve been dying to ask for I don’t know how long. So you’re very well known in the DevOps space. You’re one of the fathers of DevOps. But 10, 15 years ago, you weren’t a tech household name, right? You were doing some systems work, engineering work that we’re all familiar with. With, and then you had this brilliant idea. And I’ve always wanted to ask you, like, what gave you the balls to think you could change an entire industry?

Patrick: For one, I didn’t have the idea, and I don’t have the balls. So yeah, you know, it just happened. It just happened, right? So I never take credit of thinking of, you know, this is something I come up with, this is something, you know, I did to change the world. I’m not that type of person. So, you know, people keep asking me that question, but what I can say is that I do think I’ve put a lot of effort into it, like, you know, promoting the ideas and standing behind the ideas, but they were not my ideas. It’s kind of, you know, when you do research, you find a lot of different little nuggets and then you put the pieces together. Does that mean you kind of invented it? No, it’s just like you kind of saw a little pattern, and then by amplifying that and talking to other people, it seemed that it stuck. Interesting side thing, I think it was kind of started with doing the first DevOpsDays. Probably if it would have been me, I was just talking to John Willis who was at the same one, if it would have been me, it would have stayed from by just organizing the one conference. But it was because people were so excited and they want to take it further, you know, that it got its own life and it got taken to the US, Australia, and so on. So I think I usually say it’s like I was at the right time, you know, just happened to be there, like amplifying the zeitgeist, as the Germans would say. Of ideas that were ripe to be discussed in the world.

Matty: [00:05:50] I think, yeah, I’m just curious too. We just had the 10th anniversary of DevOpsDays in Ghent, and one of the things that I thought was really interesting to observe was, so we had, for listeners, the day before the event, we had what we called a Day Zero. DevOpsDays organizers from all over the world came together to learn from each other. I think we saw that there were more people at that Day Zero than were at that very first DevOps Days. So, Patrick, when you’re looking at the growth, and like you said, there were people running with that, and I completely understand what you’re saying. You didn’t invent this thing, and maybe it wasn’t kind of your vision of it, but you’ve definitely been at ground zero and seen and know what it felt like when you were at that first event and getting those people together. Then when you look at it now, at what it’s become, you know, kind of what does that feel like?

Patrick: Yeah, it’s, you know, Belgians are known for their surrealism, and that’s how it feels, right? It’s like watching this from afar and then seeing it grow to so many events. And also, you know, having multiple people have an angle on it, discussing things. I find that fascinating. For something that you need to know about me, what makes me tick is learning, right? And then from that perspective, it’s been amazing that over the years new perspectives came in, new voices, and now for example, at the 10th anniversary, people from Brazil, I don’t know how many events they started this year, this has exploded. And a couple of years ago it was in China, And it just keeps going. And when I looked at the first day, I think the most rewarding part was that people wanted to do this and they were so enthusiastic about it. And the sharing was just enormous of people helping each other, whether it was like people helping people on a budget to fly into Belgium or just logistics or anything, this kind of cooperation between a bunch of random individuals, not necessarily being paid, on their free time, and just like being on a cause. It sometimes does feel a little bit like a religion. Like, you know, Matt, I rant sometimes on Twitter where I’m in a dark mood, like, hey, this is the echo chamber. Let’s escape this. But yeah, it’s hard. It doesn’t take away all the good ideas we have, but because I’m somebody who’s about learning, obviously I wanna hear new things and new ideas and just keep expanding that.

Jeff: [00:08:47] And would you say that desire for learning is sort of what drove— because you could have these conversations in a much smaller circle, right? But you obviously had this drive to sort of make it a little bit bigger, maybe not as big as it became today, but you wanted to grow it. Was it the love of learning that wanted you to sort of expand and have these big conversations where, you know, a lot of people are just happy if they can get dev and ops in the same room to chat about the next release?

Patrick: Well, I don’t think I had the drive to make it something big. So I just took, you know, the opportunities that presented itself. So a little backstory, like in organizing the first events was just like, Hey, wouldn’t it be cool that I can travel to country X? And then I just found some random people on Twitter, getting them excited and then going there. It wasn’t because I wanted to take over the world or organize like a million events ever. For me, again, that was the opportunity. I go somewhere, I get new ideas, and, you know, It might sound selfish, but in a way, that’s what makes me do a lot of this stuff.

Matty: [00:10:01] So what would you say— so as this has expanded and you’ve had a lot of great opportunities with this global community, um, what are— what would you say is like a couple of the most really interesting things that you’ve, you’ve learned through the fact that now we have this global set of people that are, are having these conversations? So like, what have you learned that’s really stuck with you?

Patrick: I think one particular thing I found during the discussions is about the tool relationship and the human relationship. And I’m not talking about tooling, but this whole friction point about, you know, they go hand in hand, but we tend not to want to believe that they go hand in hand. And I found the concept of the irony of automation for example, an interesting one. Another thing obviously I learned is like promise theory. I would never have been exposed to that if it weren’t for Mark Burgess. Things like designing things came up, and then the whole thing about safety and resilience. Yeah, there’s so many people that inspired me along the way. With new ideas. And, you know, up until today, like every day, whenever I give a talk and there’s like people sending me some feedback or some link, I’m like, every day I’m surprised, oh, I didn’t know that, I didn’t know that. So yeah.

Jeff: [00:11:35] You know, it’s funny when you mentioned safety because, you know, that is sort of like the new hot thing that people are talking about, safety in systems. And what do you think has been driving sort of this push towards this new conversation? You know, it’s really resonant on Twitter, right? But when you get into a lot of organizations, it’s not, those conversations aren’t really happening, right? We’re still talking about trying to get them to do blameless postmortems and things like that. What do you think has sort of pushed that to the forefront in the online DevOps community? And what do you think is preventing it from breaking through organizations that don’t spend all day on Twitter?

Patrick: Well, if I would speak for maybe a smaller community saying the DevOps days, I think it’s the fact that people are willing to listen on those kind of human side of things. And there are companies definitely listening on that perspective because either they’re growing, they have to learn how to deal with things, or they need to try another way, or this is just how they assume things should work. There is definitely a lag between people now talking about things and then how it gets introduced. Funny thing is sometimes I get questions from clients in Belgium from 10 years ago. I wouldn’t dream of talking to them and they were like, oh, do you want to lead our DevOps transformation? I was like, what? We’re like 10 years later. And it’s like, again, surrealistic, but I get it. Change takes time. It also takes time for you to recognize that you need to change. Depending on your situation, you might feel like safe, you’re in a good spot. You know, it’s really hard to sometimes see yourself honestly in the mirror, and, you know, as an individual or as an organization, of the things you need to do to change and, you know, to get better at things.

Matty: [00:13:40] I think that’s really true, and I think it’s going back to something you were saying a little bit earlier, with when we think about kind of the mindset of the DevOpsDays community has always had this underlying human factors approach, right? That’s the thing that sometimes people don’t like. They’re like, I don’t want to see culture talks. I just want someone to tell me how to use Chef, right? But because I think, as a community, we’ve been thinking about human factors so much, that then when we start to look at the things that are coming out of the resilience engineering space that are very much about human factors, because resiliency is all about the people, it seems it’s not orthogonal, right? Like, there’s a really nice connection, and I think that’s why, you know, maybe we’re seeing it there, whereas if you’re thinking of DevOps more as, like, an automation story and you aren’t thinking about human factors, things like SAFe 2 and resilience engineering and stuff they don’t marry as much to where you’re coming from that’s top of mind, maybe.

Patrick: [00:14:43] Yeah, and it’s interesting now that I got more into the word DevSecOps because it’s now part of my daily life, I started researching how is it different, right? So how is the perspective different? And again, a lot of the presentations I see It’s kind of similar thoughts as we were explaining on the DevOps side, and sure, there’s tooling. But recently I read an interesting book. It’s not out yet. It’s from Jeffrey Fredericks and Douglas Squirrel. It’s going to be on IT Revolution again. But they talk about conversations, right? They talk about conversations between people at companies and to be able to have honest conversations. So how often you go into a meeting and say, okay, whatever they say, we need to use tool A because I’ve decided it’s gonna be tool A. You go into the meeting and they say, well, you know what, how about this, how about that? And you kind of give these answers just to be compliant in the discussion. But you’re thinking, no way, you know, they’re going to do something else. And having these honest conversations, what was interesting in the book, they almost like lay out this conversation. He said A, he meant B, this caused that. And then being able to be transparent about the things you say, the safety at the workplace, you know, being able to do that, I think that’s also part of the human aspect to have a look at things. It’s fascinating. I do have to say, quite often in this space, when we have speakers like sometimes me or you, Matt, you speak up, and we feel like we’re amateurs on these topics, but it does resonate somehow. So as long as it makes people look at more, maybe more professional things or more things in that that we can reach out to. You know, that’s interesting. You know, that’s the caveat. They don’t have to believe me by seeing it. Go to one of the specialists that know that field. But, you know, being able to see similarities, you know, translate this messaging, these feelings, these kind of opportunities, Yeah, again, learning, right? For me, it’s like fascinating stuff.

Jeff: [00:17:18] You know, you’ve said a couple of times, sort of in a theme in some of your responses, is around honest conversations, around looking at yourself or the organization in the mirror. And one of the things that I’ve always seen when I talk to people, and I’d love to get your opinion on this because you’ve talked to just so many more people, so many different teams, people are notoriously sort of like bad at measuring their own capabilities, right? Like what their teams are capable of delivering, whether it be due to workload, whether it be due to skill set, and I think this is an important thing in the DevOps transformation. How have you seen teams evaluate and sort of have those conversations around what they’re capable of delivering as part of this DevOps transformation, right? Maybe they get to a point where they’re like, yes, we’re going to jump straight to Kubernetes, right? But Kubernetes isn’t DevOps, and there’s ways to do that without delivering that. So how are folks sort of measuring themselves to say like, this is what we’re capable of delivering today?

Patrick: Well, it begins a little bit with if you’re aware that you’re not good at something, that’s the first step. And that’s sometimes hard because if nobody tells you or you are not self-evaluating yourself, that’s hard. Once you kind of get a feeling where your problem might be, that’s something you can measure. It’s harder to measure the number of deploys a day or uptime and stuff. But quite, you know, in the beginning, and it’s a little bit of a dilemma in my head. So in the beginning, I thought like the more people sit together and the more they talk, you know, that’s a sign of, you know, good, healthy collaboration, right? But then I read an article and it said like, it’s not the number of interactions at a party that make it a better party. It’s just the quality is important in what we talk about and how we deal in the conversations. And then the real kind of paradox comes to me is that, but we’re using services and we don’t talk to them anymore. So is this the end of the conversation? Is this how DevOps ends? Like everything is a service that is kind of behind like an API or something. You know, we’re back to silos and, you know, where are we at? But I think the difference there is you don’t necessarily need to communicate as long as the other kind of helps the other. So if a SaaS is aligned with your goal, and it works well, there is no specific need to talk. And I think that’s the difference between a lot of the kind of old ops style is that they weren’t empowering people to do their jobs in a way that they needed to. It was very much like, yes, we are doing our jobs and that’s our jobs, but they weren’t looking to help another person. And interestingly enough, the fact that somebody would help you, coming back to the point of trust, actually builds part of that trust. Is the other person willing to understand what I’m doing and really help me get through, you know, help my goals? And so it’s almost like if you don’t hear too much of the friction points, then things are good. Obviously, if you don’t talk to each other, you don’t hear about the friction points either. But I mean, in an honest way, if you look at the friction points and everything’s going smoothly, or you have less incidents, or the things that mature, whether it is in the technology, in being uptime, or in the human conversations, or expanding what you need to do, I found that kind of personally maybe the best measurement when I see people doing it. But it is really hard to look on this meta perspective to yourself. And sometimes an external person can help, or friends. It depends on that. But I think it’s almost like human that you think everything you do is kind of great, although there’s, you know, definitely people who think like we’re not doing great. So it’s like hard to tell.

Matty: [00:21:58] Well, yeah, it’s like a couple things, right? Part of it is Dunning-Kruger effect, right, where we overestimate our capability. But then what can lead into that is the aperture by which you understand what capabilities are. So If I’m trying to put myself on a spectrum of capability, if I think that X is the furthest you can be and I’m close to X, I’m like, I’m doing a damn good job. But what I don’t know is that really the spectrum goes all the way over to Y. So I’m only halfway there because I, you know, and I think to your point about sometimes having those external factors who have context, and I think that’s why One of the things that’s really, really fascinating to me is how the sharing around when it comes to DevOps Days and thinking about things like DevOps Enterprise Summit and how companies and enterprises are so much better about sharing their stories than we used to be. You know, so when we understand that, wait a minute, you can do more. It’s capable, that capability exists, that kind of resets where we feel we are on the, you know, I don’t want to say maturity model, but where we are on the journey, because that map is— and that’s like what, you know, Dr. Forsgren talks about, right, is that map is always changing. You know, it’s expanding, and our knowledge of how big the map is is changing, as well as the map itself getting bigger. So we constantly have to be able to, to look at how we’re evaluating ourselves, and it’s always within the context of what we already know. That makes it hard.

Jeff: [00:23:36] And I love what you guys said about— what you said about trust too, right, sort of being the focal point. And I think one of the things that we struggle with on a very, very micro level is having the vulnerability maybe to be the first person to say that they don’t know, to sort of get the ball rolling, right, because I’ve definitely been in a meeting where, you know, 4 of us are talking about a thing that none of us knows what the hell we’re talking about, right? We’re all talking out of our ass. And then it just takes someone to say like, I don’t know what that acronym means. And then suddenly everyone’s like, yes, okay, thank God we can have an honest conversation about this.

Matty: We used to, it’s just a little side note. So, and this is telling you about the time because the story involves two-way pagers. But I had a colleague of mine, a fellow system engineer, and we had a game we ran for over a year at our organization where if we were ever in a meeting together, one of us would text the other on the two-way pager some phrase, just some made-up phrase, and then the other person had to use that phrase in the meeting as if it was a saying. We played this game for a year and nobody ever questioned anything we came up with because people were like, oh yeah, yeah, it’s definitely a redheaded woodpecker, you know.

Jeff: [00:24:47] And we’re—

Matty: and they get— but it goes back to that point. It’s interesting because nobody wants to be the one to say I don’t know what that is. And when you have that as part of your culture, people don’t question it. And it’s hard. Like, you have to have that vulnerability and you have to— and that requires creating such a culture of learning and a culture of safety, right? Like, that it’s okay to do that. That’s hard stuff. But I think it’s great that we are getting better at that as a community by sharing more stuff.

Patrick: Yeah, it’s nice when you get older, you feel less of the stress that you have to comply. So you just say, you know, you can kind of speak your mind. It reminds me of, you know, in 2010 at a conference, a gentleman called Nelson, Stephen Nelson-Smith. So he’s like this impeccable Englishman, like perfect British accent, you know, well dressed, like, you know, the perfect man. He goes to the microphone because there was a panel on stage and he just says like in this very nice voice, in all due respect, I call bullshit. Right? That was like, you know, he really tried to express that. But, you know, we need to be able to do that. And it’s so hard sometimes. And even we doubt ourselves. I was at the airport recently and the person— I was trying to get into the country and so the person looks at my passport and he says, okay, what are you doing here? Yeah, I’m speaking at a conference. Okay, what kind of conference? Yeah, IT. And he looks at me like, why are you speaking and not me? And I was like speechless, like, yeah, I don’t know. And it’s like, why did they pick me? Yeah, it could have been you. And he started to say, well, you’re evading my questions.

Jeff: [00:26:46] I was like, what?

Patrick: But yeah, you kind of have to put yourself in perspective. And it is easier when you live in Belgium. You’re this tiny country. You’re not in the US. I sometimes compare myself to Asterix and Obelix. This kind of little town, you know, being somewhere in the world. But, you know, I learned that it doesn’t really matter how big your company or whatever, you know, if you’re saying the right things. And that could be, you know, you being a manager, you being, you know, another position, you know, speak your mind. And that’s important. And that comes back again to trust. Create that environment where people could do that. I don’t mean just blurt out things, you know, that’s another thing.

Matty: We’re trying to live in a society here, you know.

Jeff: In your experience when you were, when you were starting out, right, was that, was that something, that sort of courage to be that vulnerable person, was that something that came naturally to you, or was it something that a leader inspired you to be able to do, or did it just come with time and age and experience?

Patrick: [00:28:01] So I don’t think I had this in me from the start. I was kind of a very shy person and thinking like whatever I think like my neighbor could have come up with. So it’s like never special, but maybe it’s because people kept asking, what do you think about this? What do you think about that? That I learned to speak up and be less afraid because they let me speak my mind way more on it. So that was nice.

Jeff: Yeah, and I think sometimes too it makes it easier when people are seeking out your opinion, and then it also makes it easier when your opinion isn’t like, you know, you’re not taking it as like the de facto fact, right? Like this is absolutely the way it is. When you’re allowed to have some give in your opinion and state like, hey, this is an opinion and I could be wrong, it becomes a little easier to have that sort of vulnerability, I think, at least in my experience.

Patrick: Yeah, one of the talks I was preparing, I didn’t know where it was going, right? So I was just like putting down some slides.

Matty: [00:29:07] Sounds like standard talk preparation.

Patrick: My favorite talk. And then I was trying to explain that, that I didn’t feel like secure because how, you know, I did some research, but I’m like no expert. And, you know, you talk about that stuff. And then somebody said to me, well, you don’t have to talk like you know everything. Just say that you found this and that you would like another opinion. And that was really helpful in reframing how I felt about the presentation of, you know, just, you know, if we could talk about this stuff and then, you know, you learn, you get like new ideas and people say, hey, yeah, you know, what about this?

Jeff: Yeah, so you had poked a little bit of fun at the echo chamber of the DevOps community a little bit, and that’s one of my favorite pastimes, is just stepping out and saying, like, hey guys, we’re a small sample set, and in reality, there’s a lot of people that are still struggling with some issues that we may consider basic or whatever, but they’re not, for various organizational reasons. One of the things that I think I see a lot in my conversations are the organizations where One group is particularly fired up about the whole DevOps concept, and they’re moving forward and they’re making progress, but there’s other laggards in the organization, right, for whatever reasons. It could be, it could be they’re just not bought into it. It could be that they think it’s a waste of time, or it could be that they think what they’re doing is actually working. Have you talked with folks that are experiencing that, and how would you suggest folks go about tackling those conversations to say like, hey, you know, there’s this movement and we should really be on this train because it has all of these great positive outcomes, as well documented by things like the State of DevOps Report and blog posts and all of that fun stuff.

Patrick: [00:31:00] So I would definitely not go in saying, hey, there’s this cool stuff and it’s what everybody’s doing.

Jeff: All the cool kids are doing it.

Patrick: No, but actually, I think the fact that I was known for some things as actually sometimes, I’m not saying used against me or backfired on me. No, we’re not doing it like this here, right? So yeah, I haven’t even said anything. So I’m just trying to get a conversation with you and try to understand what your problem is. I’ve seen, it’s not that I do consultancy like for hundreds of companies, but from my personal experience, I’ve experienced one company where I went in and said, okay, let’s get this together and so on. And there was a couple of folks that just weren’t happy. It didn’t convince them. They didn’t see the benefit. I learned that sometimes because they just had so many bad experiences. So for them to, you know, coming back to the word trust, you to do something that will improve stuff, you know, that’s, you know, for some people that’s really hard given the context, the company, the history you have. And I think what I learned about it is that it almost starts with a belief And if you don’t have the belief, for example, that while working together that things will improve, if you still believe, for example, not still, that’s a judgment. If you believe like, yes, we can document everything and then we can work through an API, that’s how we work together, that’s a different way of working. Sometimes I would say, yes, we have all the research and the data to back it up, But, you know, you might be special and I don’t know the context. So I would never go in with this one way of thinking and so on without knowing history and context of a place. It’s like when I did firewalling, right? You get an auditor and they look at your rules and they say, this is like so many open ports and this is so unsecure. And then we tried to explain to them, well, you know what, this is what’s needed to do the business, right? You know, we had to open the port. If we didn’t, we lost this client. If we didn’t, it was this. And it’s kind of this history and perspective that, you know, you first kind of have to learn. Maybe it’s also because it’s less my style to go in and be on the barricades and try to do a change, you know, by pulling people. I would rather go from supporting people, gain confidence by doing little things that they kind of make see that there’s some progress. But again, you can’t change the beliefs, and if you can’t change the beliefs, you have 2 options. Either you leave or they leave. And it’s hard, but I think part of having a company sometimes is that you’re entitled to say, well, this is a company and these are our beliefs. If you don’t agree with them, then maybe there’s not a place for it. But on the flip side, obviously you want to have diversity of opinions. So otherwise you’re just like cloning your opinions and they become worthless as well. So yeah, it’s a thin line, but looking for history, looking for context, why this is happening. I would say this is the first thing. And then try to see by little successes. And in that way, it’s not different than any change, introducing any change, whether it’s Agile or ITIL or whatever. Like any new cultural change in a company is just like baby steps. Find the champions, find people who think like mine, book some successes. If you don’t have successes, question yourself. If you do have success, question yourself. So it really never ends. And I think what the interesting part is that the bottleneck will always move. And it might be that you’ve just set up your CI/CD and it’s working beautifully and you’re bleeding money because you don’t have like an invoicing system. I don’t know. So many options you have to look at.

Jeff: [00:35:52] Yeah, and I love what you said there. There were 2 things that you said that really jumped out at me. One, you know, organizations have preferences, right? And, you know, the preference isn’t right or wrong. It’s in the context of the organization, and like you said, you can exercise your free will, hopefully, by finding another company. Now, I know that not everyone is as mobile as everyone else, so, you know, there’s concerns there, but recognizing them as preferences sort of helps to set your sort of mind and your context around that. The other thing around like business context I thought was so insightful because there’s oftentimes as technologists, we’re so focused on the technology and what’s right and what’s wrong with how to implement technology that we forget about the purpose of the business is not the technology necessarily, right? It is to achieve some sort of business outcome and how do we massage and merge our technical preferences, our technical beliefs with the needs of the business to make sure that, you know, we are one, not putting the business at jeopardy by making terrible technological decisions, but at the same time not being so iron-fisted that we’re strangling the business’s capabilities.

Patrick: [00:37:02] I think 4 years ago, I had to make a decision whether to go into a tech company again or not. I decided, okay, I’m going to try to prove that DevOps Day— DevOps— not DevOps Days, DevOps, that too, but DevOps is like an awesome thing and we can make a difference by adhering to the ideas. I didn’t go into a tech company, but I was on mobile and video streaming for television shows, so kind of like a different segment. It took us 1 year to get the tech straight, and then we came from Git pulls on production machines to what we should do. But after 4 years, I realized working really hard that we were— if you look at a company from a global perspective, we improved sales, we improved marketing, You know, we worked with the legal people to kind of make sure everything was okay, GDPR, you know, all the stuff that we needed to do. And I think my final thought was, but we’re not making any money, so there is no business fit. So whatever we do, it’s like a tiny part and all the cogs have to work together, but even that might not be enough. Just to make things work. And if you look at, you know, again, the bottleneck just moved, moved, moved while we improve things in our company. And then the only thing that we can improve was, you know, market fit.

Jeff: [00:38:42] So yeah, it’s one of the reasons you got to really celebrate your wins, right? Because, you know, the win that you did this week is next week’s bottleneck. So when it happens, you really got to be like, yeah, we did it. Next week you’re like, oh man!

Matty: Oh man, we did it!

Jeff: Right, right. That’s a thing that always pops up. So talking about teams, companies, organizations that are going through their DevOps transitions and whatnot, one of the things that comes up sometimes is you get this alignment between Dev and Ops, right, and things are going great. You’ve got your synergies, right? The teams are driving, but Who’s left out of that conversation is project, right? And the project organization, project management teams are, are still sort of left behind in this very waterfall, surrounded by Gantt charts sort of world, and it creates friction as they try to engage with some of these teams, especially ops, right? Have you seen like good interaction patterns between DevOps and project in this sort of new DevOps and Agile world where there are some organizations that still need a project plan, need a Gantt chart, and they’re not necessarily okay with things evolving as we, as we build solutions out?

Patrick: [00:40:08] It’s interesting. I think there’s a book called No Estimates which says like no projects. But, and you know, there’s a huge debate on things, you know, whether you should make estimates or planning or like how long ahead of time. I usually think of it as, you know, kind of a projection, like we think in story points, that it’s not a definitive thing. It’s like always making sure we’re working on the most important thing. Right? So if we go to projects that have been set and they, you know, they made this planning a year ago and they said this is the way it’s gonna be and we already know when our milestones are gonna happen and everything’s fixed, I think my usual approach is that, yeah, well, we will dance around it in a way that will kind of make something happen that deadline. But obviously, if you’re not willing to negotiate features or timing or resources, you know, it’s like an endless discussion on those things. So you need a degree of freedom to work with that. Usually when you start building up the confidence again that instead of them seeing something at the end of the project that you can deliver like that smaller chunks, they get more accepting of you willing to change the plan. If you don’t give them anything, like nothing is happening, they get nervous. So my usual approach is, yeah, okay, well, you know, we’ll play this game along. You know, we’ll do the milestones, but we— if we do this, we need like a stake in the ground in discussions as well. And if you don’t have that, I don’t think there’s any way that you can solve it. But if you can, you get on this personal level, you kind of make this, you know, explain things more. So the key there is like talk to them. And sometimes it’s not only talking, it’s about educating them or listening to them. What are their real goals? You know, can we rephrase how you plan things and still hit your goal in a way, the real goal, not the one you wrote down, and then work from there? So that’s been helpful for me a couple of times.

Jeff: [00:42:51] Yeah, because really a lot of times project managers are really just looking to see how your task is going to connect or interact with another task, right? So, you know, understanding that chain of events, you know, can, can go huge. I think one of the reasons why it was fresh in my mind is like I’m recently engaged in a scenario where I’m being asked to estimate things that I’ve never done before, right? So there’s a whole host of, you know, known unknowns and unknown unknowns, right? Things that are just gonna pop up. So that is very, that felt very antithetical to the way product or the project team is accustomed to working, right? They’re like, oh, well, you know, if you’ve built one bridge, you’ve built many bridges, and therefore all the bridges should take roughly the same amount of time. So sort of like dovetailing into that, right? Another thing that comes up is, you know, for example, in this specific scenario I’m talking about is a Kubernetes implementation. I’ve never implemented Kubernetes, right? There’s a whole bunch of stuff that I don’t know. The conversation that we were having with a friend of mine was, at what point do you feel like with the DevOps toolchain that it is appropriate to perhaps jump over a particular technology to get to the end state? So, right, you’ve got a company that’s in the data center, and instead of going from the data center to the cloud using EC2 instances, they want to jump straight to Kubernetes because, you know, EC2 is old. Right? So I think of it like, you know, third-world countries that are like, we’re not going to develop underground phone lines because that doesn’t make any sense. We’re going to jump straight to mobile, and we’re going to get rid of all the legacy baggage that comes with those phone lines. Do you think that’s appropriate in a technology organization, or do you think that, you know, we should do the whole crawl, walk, run in most circumstances?

Patrick: [00:44:38] Well, it seems you already made up that it isn’t a good idea, so— You’re already biased in a way. I’m absolutely biased. Coming back to the honest conversations, you should have the conversation saying, well, what are we trying to achieve here? Instead of, okay, what’s the tool we’re going to use? People find it surprising that me working in DevOps, and we had this meetup last week about Kubernetes, and the presenter asked them to raise their hand. Who is not using Kubernetes? And I was the only one raising my hand. And like, why wouldn’t I do it? Because I did not feel friction in the technology I was using. So, why would I go to something else if this was enough for me to do it? Maybe in the future, I have like a more compelling need to do that, and sometimes I understand the need is to be more up to date because you might find more people for hiring or you will get still the patches and so on. So it’s not that you need to neglect updates, but if you’re feeling fine and you’re happy and you see like in the near future that’s still gonna be okay, you shouldn’t just jump on things. We had the same debate on serverless. Oh no, everybody has to go with serverless. Understand your use case and go for it. I sometimes think being mature is to be able to figure out which tool you apply at the right time. It doesn’t mean that you don’t have to know all the tools, but learning all the tools gives you perspective on when to select the right tool. The same with programming language. Should we just all go for Go? That was a pun I didn’t intend. It kind of gives that feeling like, what problem are you trying to solve? And that makes sense. Sometimes people might think that I’m a hype person, but I think I always try to understand why we should use that tool and to articulate why that is useful. So, I can see a need for Kubernetes. Or I can see a need for multiple things, but I would have to know more about your context to see whether it’s the most appropriate tool and not because it’s like the tool that everybody uses at the same time. I think the same has happened with squads of Spotify, that everybody’s trying to copy this model inside of their company. They kind of forget like what the history was, why it was useful. Spotify doesn’t use it anymore themselves. So it’s kind of, you know, learn why these things are doing it. And again, like you said before, it comes back to the why. Why should I do this? And be able to articulate that and not just being like a resume-driven development or operations.

Jeff: [00:47:53] So you guys heard it here first. Patrick Debois said, I do not need to run Kubernetes. Episode title, boom!

Patrick: Yeah, so you’re a smart guy, so, you know, I’ll trust you.

Jeff: So, you know, you’re a big fan of learning, you’re a big fan of, you know, staying educated. You know, what sort of tips would you give for those folks that are, you know, trying to stay on top of things, trying to stay on top of how the community is moving, and the sort of conversations that are taking place?

Patrick: I myself, every time I go into a new domain, have a way of doing it. So the first thing is to understand which keywords match the domain. So you kind of have to figure out. And usually I do that by reading some blog posts. You do a Google search, you find some blog posts, and you go from there. The second phase is usually like when I know these keywords, And I understand this is not given for everybody, but it could be if you’re not doing things the legal way. But you just like, you buy or something like several books, like get multiple perspectives from that domain and not just one. And you will see they have usually about 70% in common. That makes you learn the correct keywords that you kind of have to find, matches that stuff. And then you’ll get some different perspectives that are working in that field. Then I usually go through following a couple of more blogs because then I know where these people hang out, which communities, what words, what concepts. I look at some slides on SlideShare or somewhere. I get an even better understanding. And then usually when I get more and better on that stuff, I will go to Twitter and follow people there. Because then you almost got from knowing nothing but a couple of words to the direct feed of thoughts of people. I’m not saying this is suitable for everybody, but this is kind of my process how I try to learn new domains.

Jeff: [00:50:15] That’s great. That’s great. Well, Patrick, I want to thank you for making my debut episode extremely easy. It was a great conversation. Where can our listeners catch up with you?

Patrick: I think I’m mostly on Twitter, so Patrick Debois on Twitter. I try to do my research on the ocean— on the ocean. That sounds great.

Jeff: That’s right. I’m game. Let’s do that.

Matty: DevOps Days Bahamas.

Jeff: Yeah. We’re on a boat, y’all. We’re on a boat. Awesome. What do you got going on, Matt?

Matty: Do you have— well, actually, Patrick, do you have any upcoming conference stuff to talk about? Any speaking stuff coming up in the near future?

Patrick: Yeah, I will be speaking at QCon in London. I will be speaking in Melbourne for DevOps Talks. I will be speaking at DevSecCon in Sydney. I will be in San Francisco for the new O’Reilly conference. So how long do I get?

Matty: That’s probably a good start.

Jeff: [00:51:17] Slacker. Yeah.

Matty: That DevRel—

Patrick: It’s my job now.

Matty: Yeah, exactly. Isn’t that great? Yeah, so I’ll be at DevOps Days New York, March 3rd and 4th. I’m pretty excited about that. They do a great event, and there are some stellar speakers. Me, so they got to have somebody to bring the curve down, I guess. And I’ll also— I’m really excited, I’m doing a workshop at SRECon Americas West in Santa Clara at the end of March. So my colleague George Miranda and I will be doing a workshop on, with a very clever title, Blameless Postmortems: How to Actually Do Them, which is why I should never be allowed to name anything.

Jeff: For me, I’ll be at— every Thursday I’m at Panda Express. They’ve got a really great lunch special that I enjoy, and it’s close to the office, so that’s fantastic. But no, I don’t have any speaking engagements lined up yet. It’s still early in the year for me, but you can catch me on Twitter, @darkandnerdy. That’s where I like to have my fun.

Matty: [00:52:18] Now, if you want to do something about those upcoming speaking engagements that you don’t have, Jeff, you can always— and listeners as well, don’t forget— if you go to devopstays.com, That’ll give you a great list of all the open CFPs at DevOps Days around the world. Speaking of that, by the time you’re listening to this, because it’s tomorrow when we’re recording it, the CFP for DevOps Days Chicago will be open, and we’d love to get your proposals. Go to devopsdays.org/chicago to check that out. It’s going to be our 7th year of doing DevOps Days Chicago. This is the beautiful thing about being a podcast host. Plug my own event. Jeff has been at every single DevOps Days Chicago, so he’s—

Jeff: I’m going to keep it going, baby. Yeah, keep it going.

Matty: We got to get you there one of these times, Patrick, so we’ll work on that.

Patrick: You can see Matt’s jacket. I totally love Matt’s jacket. You can only come for that as well.

Matty: Yes, yes, absolutely. Head over to arresteddevops.com/godfather. Of DevOps for this episode’s show notes. If you go to arresteddevops.com/itunes, you can leave us a review in the iTunes Store. This actually does help other people find the podcast, and who knows, we might read your review on the air, so to speak, whatever that is. And if you’re into Spotify and iHeartRadio, you can find us over there too. We are all over the internet.

Jeff: [00:53:45] Awesome. Well, Patrick, thanks so much again for joining us today. Had a really good time. Time chatting with you.

Patrick: Yeah, it was really fun. So I am not saying that just because I have to. It is because I had fun with you guys, and I’m trying to have an honest conversation with you guys.

Jeff: That’s right, that’s right. Keep it real.

Matty: So with that, I’m Matt @MattStratton.

Jeff: I’m Jeff @DarkAndNerdy. This is Arrested DevOps, and remember, there’s always DevOps in the bananas bag.