Episode 71: Broadridge’s Daniel Ritchie Talks Cacti, Rice Paddies and Software Development

Brian Dawson: Hello, this is Brian Dawson. Today, I'm hosting a special edition of DevOps Radio, which is coming at you live from DevOps World/Jenkins World 2019 in Lisbon. And today, we've saved my favorite guest for last among a parade of esteemed guests. We have Daniel Ritchie of Broadridge and, while I'm not sure if Daniel remembers all the conversations, over the past two or three years, I've had the privilege of having multiple conversations with Daniel; some of them more free flowing than others with red wine and other things involved. [Laughter]

Today, I get a chance to finally get him on the podcast and to go a little deeper. Daniel, before we dive all the way in, can you take a moment to introduce yourself to our listeners and tell them a little bit more about who you are, what your role is, and what DevOps is at Broadridge?

Daniel Ritchie: Absolutely. So, Daniel Ritchie, I've been a DevOps practitioner here for, I guess we'll count it five years formally and my role over the last five years has changed quite a bit, but five years ago, it was trying to convince the organization that DevOps was something that we even needed to pay attention to.

Brian Dawson: Okay. And of course, what is DevOps was a big part of that.

Daniel Ritchie: Right, defining that.

Brian Dawson: Defining that, which we should talk about.

Daniel Ritchie: And, you know, there’s a lot of misconceptions, I think, within the industry and, you know, are you gonna sell somebody some units of DevOps or, you know, what does that mean?

Brian Dawson: Mm-hmm. Here, come buy this, I have some DevOps for you, do you wanna buy some?

Daniel Ritchie: There you go, there you go.

Brian Dawson: Okay.

Daniel Ritchie: So, you know, five years ago, we were kind of deciding what our North Star was gonna be for DevOps in the organization.

Brian Dawson: Okay. And you're saying as a community or at Broadridge?

Daniel Ritchie: Uh…

Brian Dawson: Both, it sounds like both.

Daniel Ritchie: I think the community had it figured out better than we did at the time. And for an enterprise, saying we're gonna take care of each other and create an environment where everybody is gonna be successful, that sounds great, but what does that look like on paper, right?

Brian Dawson: Okay.

Daniel Ritchie: Enterprises need to know what that looks like on paper.

Brian Dawson: Right.

Daniel Ritchie: So, figuring out how to provide the guidance that was gonna be necessary for the organization without getting in the way or stifling innovation, those types of things.

Brian Dawson: Right.

Daniel Ritchie: You know, we had to figure that out. So, I think five years ago, we were defining what that was, convincing executives that this was something that was gonna be valuable. Practitioners, people with boots on the ground that were doing this really could see the value.

Brian Dawson: Mm-hmm.

Daniel Ritchie: But figuring out how to bring that to the enterprise was what—

Brian Dawson: Was your job to be done then.

Daniel Ritchie: Exactly.

Brian Dawson: And it’s now changing?

Daniel Ritchie: Well, you know, I think the idea that, or what DevOps is has been pretty well defined, right? We know what that is now, we know how to—

Brian Dawson: What is it?

Daniel Ritchie: - have that for an organization.

Brian Dawson: What is it? Because we had a conversation about the definition of DevOps, maybe jumping there early, but I do beg the answer. So, it’s been defined at least for Broadridge, and if so, what is that?

Daniel Ritchie: Yeah. Well, it’s listening to the people that are trying to accomplish their jobs and understanding what their intentions are, what their interests are.

Brian Dawson: Okay.

Daniel Ritchie: I'm not gonna tell a development team what technology to use, what code to write, right? I'm not gonna tell them, “Well, this has to be an application written in Java” or, you know, something like that.

Brian Dawson: Right, right, right.

Daniel Ritchie: They're free to choose these things.

Brian Dawson: Okay.

Daniel Ritchie: But those ideas are a little bit less clear when you get into operational aspects of bringing code all the way into production.

Brian Dawson: Mm-hmm, and where you dictate, where you don’t dictate, where you listen—like that, yeah.

Daniel Ritchie: Yeah, yeah. So, for us, it really meant, you know—well, doing a lot of listening and figuring out how to pave the way or kind of clear cut a path that the organization could then follow comfortably, right?

Brian Dawson: Mm-hmm. That’s interesting. Now, you're giving me a whole new analogy of a guy with the machete clear cutting, you know, paving down the obstacles for the team. Anyway.

Daniel Ritchie: Yeah.

Brian Dawson: So, that’s a bit of what you guys have done, understood where the team needs to go.

Daniel Ritchie: Mm-hmm.

Brian Dawson: And DevOps, from your standpoint, operationalizing it—and correct me if I'm wrong, I probably am—is understanding where the teams are trying to get, clearing a path for them so they can travel it.

Daniel Ritchie: Mm-hmm, mm-hmm.

Brian Dawson: Is that—

Daniel Ritchie: Absolutely. One analogy that we used during this process was, we build the highways, right? We figure out where you need to get to, we'll lay the pavement down.

Brian Dawson: Okay.

Daniel Ritchie: We'll set some speed limits, we'll say, you know, use your turn signals and things like that, but you know, if you wanna drive a motorcycle or a sports car or a minivan or a semi-truck, that’s your choice. You get to have some freedom with that.

Brian Dawson: Right, right.

Daniel Ritchie: If you wanna press the gas a little bit harder or push the brakes, that’s also up to you. You've got control of the steering wheel and you can get to your destination whenever you wanna go and those types of things.

Brian Dawson: So, okay—so, the questions are pouring into my brain, which is, when it becomes a problem, I get a backlog of them.

But so, earlier, and I don't know, maybe you can correlate for me, we started on this, “What is DevOps?” question before we hit record, and you started to come up with an interesting analogy that I termed as managing environmental factors. How does this relate to this conversation of defining DevOps within Broadridge and these other metaphors or analogies that we used? Are they correlated, or?

Daniel Ritchie: I would say so. You know, managing environmental factors, if we talk about this in the context of agriculture, right, or cultivating, okay, we're creating the conditions under which teams thrive, under which developers or engineers are able to be extremely productive.

Brian Dawson: Okay.

Daniel Ritchie: And I think a lot of the times when you get into, well, why—why are we not getting the results or the outcomes that we're looking for, it’s very easy to blame the plant, right?

Brian Dawson: Okay, right, right, right. [Laughter]

Daniel Ritchie: You can look and say, “Well, look, it’s an apple tree and it just doesn’t have any apples.”

Brian Dawson: Right, it’s just a flawed strain or whatever it is.

Daniel Ritchie: It’s a bad apple tree, yeah, there’s something wrong with this one.

Brian Dawson: Ooh, double entendre. [Laughter]

Daniel Ritchie: Oh, yeah, there you go. Not even intentional. We could have a lot of fun with that one.

Brian Dawson: Right, right, right.

Daniel Ritchie: But you can—you know, if you take a step back and say, “Well, clearly, this plant, this product, this team knows how to be successful.”

Brian Dawson: Right.

Daniel Ritchie: You're talking about experts within their domain, sometimes career experts who have been doing these types of things. If you can ask—okay, well, what are the right conditions, right? And I like the comparison for plants, because I grew up on a farm in Pennsylvania.

Brian Dawson: Yeah. Okay, right, right.

Daniel Ritchie: But the idea is, you know, sunshine is always going to be sunshine, right? You can’t really affect that. Now, you can maybe choose where the sun happens to be in relation to the plant.

Brian Dawson: Right.

Daniel Ritchie: You can give it some shade or give it false sun.

Brian Dawson: Right, figure out how much—yeah, ________.

Daniel Ritchie: You can irrigate, right? You know, and some—you know, if you look at the desert plants, they need very little water. So, the answer is not simply flood, you know, with water.

Brian Dawson: Ah, interesting [Cross talk]. It’s understand the—I'm sorry, I'm jumping in because I'm getting this. But do you have a cacti, do you have an apple tree or part of what, how you treat it environmentally, right?

Daniel Ritchie: Absolutely or, you know, if it’s a rice paddy that you're gonna absolutely, literally flood with water, there’s a lot of other plants that wouldn’t survive those conditions.

Brian Dawson: Yeah, right.

Daniel Ritchie: And likewise, the soil. You need the right pH, you need the right organisms and micronutrients and everything that exist and can be healthy soil.

Brian Dawson: Love it, right.

Daniel Ritchie: You know, the humus that makes us all successful.

Brian Dawson: Right, right.

Daniel Ritchie: And even then, you can add fertilizer and you can do all these things. So, we focus so much on the team, the individual, the engineer, whatever it is, and we don’t spend nearly as much time on that environment, cultivating those conditions, you know?

Brian Dawson: Right, yeah, yeah.

Daniel Ritchie: And that’s, I think for me, DevOps is not worrying about—you know, not trying to tell the plant how to grow or what it’s supposed to become, but asking.

Brian Dawson: Identifying, asking what it needs.

Daniel Ritchie: Identifying—what do you need?

Brian Dawson: Right.

Daniel Ritchie: What do you need? So, sit down with your stakeholders and all this. I mean, DevOps talks about empathy, talks about, you know, breaking down barriers, you know, removing this wall of confusion as, you know, ________.

So, all these things, you know, really focusing on the environment and then the hard sell, of course, especially with an executive in an enterprise is, we're not actually gonna make the tree produce more apples, we're gonna focus on the right amount of sunlight and soil and these other things.

Brian Dawson: Right, but they're like, “I want apples.”

Daniel Ritchie: “But I want apples. And the tree is what produces the apples. Why aren’t—build me a better tree or whatever.”

Brian Dawson: Right, yeah.

Daniel Ritchie: I mean, they're not saying that to us at all, but it’s, the focus is shifting away from the thing that’s doing the production, the team or whoever’s doing the production to creating the right conditions.

Brian Dawson: I love it, and obviously, there’s—so, first, I encourage you to explore that further. I know this is kind of a new premise or new thought, I love it, and there’s a bunch of different ways it can go, so I have to control myself. But—

Daniel Ritchie: That’s the joy of these things.

Brian Dawson: - right, right. [Laughter] So, there’s a couple of things I really like about that, but then a challenge I wanna question you on. What’s really cool is, it almost inherently does talk about culture, but not just local culture, right? What’s implied is, organizational culture signaling incentives, et cetera, are all—you know, have a place in that analogy, right?

Daniel Ritchie: Yeah.

Brian Dawson: So, that is cool—so, I love that. Now, where I find a challenge, okay, so you can help me through this, this will get to a place—so, I don't know who’s who. I hate to say this for mainframe guys, right? But maybe, you know, mainframe is your old, you know, sturdy cactus that will just run, doesn’t need a lot of water. As a matter of fact, if you feed it, you give it too much water, it may drown out. Maybe our next gen cloud native innovation teams are teams that need to be flooded with a bunch of water.

In my experience, and I believe this exists in Broadridge, I’d be pretty sure it does that you have cacti, right? You have rice paddies, you have some apple trees, you need them all to produce. Their environmental factors and needs are different.

Daniel Ritchie: Absolutely, absolutely.

Brian Dawson: Right? And how do you manage that? Because now, it’s not just an apple farm.

Daniel Ritchie: Totally. This is massively challenging, right? And I mean, Broadridge in particular, we have a lot of acquisitions, we have a lot of products that have been brought in from all kinds of different places and, you know, kind of—you mentioned mainframes. The two extremes I like to use just for conversation are, well, mainframe is on one end and serverless on the other end.

Brian Dawson: Yes. [Laughter]

Daniel Ritchie: And then you've got, you know, everything that happens in between. So, different technologies, different cultures, even, that those different teams come onboard with. So, how do you—how do you provide a place where everyone can thrive? And the analogy of building the highways, right, is kinda where we have to look at—okay, the lowest common denominator between a cactus and a rice paddy, right, this is a challenge, right, because there’s clearly, this is your polar opposites for what those things need.

Brian Dawson: Right, right, right.

Daniel Ritchie: So, we still try to find those commonalities and clear that way, whether it’s the products that we're using or the workflows that we're implementing, you know, I can say—I think I can say this. We have a ticketing system that often has to be used for service requests.

Brian Dawson: Okay.

Daniel Ritchie: And I think it’s probably fairly common, right?

Brian Dawson: Yeah, right, [Cross talk].

Daniel Ritchie: And, you know, a lowest common denominator is, everybody hates logging into the system and punching in interface and entering all this information.

Brian Dawson: Right.

Daniel Ritchie: But it’s necessary at all these different steps along the way, right? And it doesn’t matter if you're, you know, whatever the technologies are.

Brian Dawson: Right, whether you're the cacti or a rice paddy, whether you're Java or .NET.

Daniel Ritchie: It doesn’t make a difference, right.

Brian Dawson: Right.

Daniel Ritchie: So, you know, is there a way that we can—I mean, this is a really straightforward thing to have here, but is there a way that we can, I don't know, provide some type of automated—

Brian Dawson: Automated log in, right.

Daniel Ritchie: - way to access that.

Brian Dawson: Regardless of whether you're using RCS or Git, for instance.

Daniel Ritchie: It should make no difference, right? So, whether you wanna think of that as, you know, an API or, you know, some type of contract that we're creating to do those types of things.

Brian Dawson: Right, right, right. No, I think that’s awesome, and you're kinda just looking to kind of think ahead. And where that's really relevant to some questions that I asked and what I'm seeing is, I am running into a couple of things. Developers, I just had a conversation with one of—with a customer that said, “Yeah, you know what, we wanna involve developers in the development of pipelines and the decision around the platform,” which, I think you and I both agree that it’s important they're involved.

But there are some people that have the sentiment, “You know what? I don’t wanna know. I don’t wanna care. I just want it to work. Just allow me to commit code and have it come out of the other end,” right? And that is, starts to align with what I'm starting to see in parts of the industry, and I can’t really quantify, you know, where it’s coming from, but it’s, “You know, I just want an easy button.” Which is a fair ask, but in other words, I don’t want to have to understand what my pipeline does, how to build it or anything. As a matter of fact, I don’t wanna deal with tools. I wanna go out and buy an all in one solution, press my easy button, and have it go.

There’s two things I'm bringing that to you with. I don’t actually believe that, in any mature enterprises, that’s viable. Because as we said, we have cacti and rice paddy, and they can’t both thrive with a generic all in one solution. So, my question is—is one, what are your thoughts, do you agree, and do you have people trying to treat it as a black box and ask for the easy button within Broadridge?

Daniel Ritchie: I mean, everybody loves easy buttons, right? I mean…

Brian Dawson: There’s nothing wrong with liking the easy button.

Daniel Ritchie: Right. Don’t we all—wouldn’t that be wonderful?

Brian Dawson: Right, right.

Daniel Ritchie: I mean, we are at Jenkins World, so I'll mention this. We've used Jenkins as that easy button, right? So, we have very complex deployments that cover, you know, just a number of technologies, different domains, different teams that are responsible for all these things. I mean, you can have, I mean, I think of one that has probably 15 different stages. So, various points of interaction that they have to deal with, and there’s one single variable, which is the version of the product that you would like to deploy.

Brian Dawson: Okay.

Daniel Ritchie: You identify that and you push the button, and then all this stuff kind of happens behind the scenes.

Brian Dawson: Okay, okay. So, yeah, you provide the easy button.

Daniel Ritchie: Well, that’s the thing—we don’t provide the easy button.

Brian Dawson: Okay.

Daniel Ritchie: Right? So, the challenge with technology and especially emerging technologies—I mean, we've having a conversation, you know, we mentioned serverless here. If this was even two or three years ago, we would be talking containerization.

Brian Dawson: Yeah, yeah.

Daniel Ritchie: I mean, virtualization, right?

Brian Dawson: One thing that is constant is change in technology, but yes.

Daniel Ritchie: So, you need the technical experts, right, whether they're existing experts who know even mainframe or the latest and greatest bleeding edge fill in the blank, whatever it happens to be.

Brian Dawson: Right, right.

Daniel Ritchie: You need those experts to do the real heavy lifting—

Brian Dawson: To get to the right—

Daniel Ritchie: - to get to the point that you need to be at.

Brian Dawson: Right.

Daniel Ritchie: So, what we'll set is, we'll say that the North Star for this for us is, I don’t care what you do, I don’t care what technologies you're using and everything else, but you need to deliver that button.

Brian Dawson: Right.

Daniel Ritchie: Right?

Brian Dawson: Right.

Daniel Ritchie: And we'll define that button, we'll define at a very high level what needs to happen.

Brian Dawson: Right.

Daniel Ritchie: But the technologists need to roll up their sleeves and get in there and get dirty and do the things that need to happen.

Brian Dawson: And that aligns with what I'm thinking, yeah. There’s no—look, at the end of the day, this is supposed to be collaborative, right? I mean, really, at the fundamental—I always talk about almost probably like a fan boy, my interview with Kris Buytaert, and you know, along with Patrick Debois, they launched the first DevOps Days.

And what really struck me in the conversation, if people actually listened to me multiple times, they're probably getting bored with this, but he’s focused—he wasn’t even a fan of containers. He saw containers as potentially lending themselves to an anti-pattern of just moving, passing the buck. And really, what he was focused on was collaboration, and containers are powerful and we've had debates about this, right? And there’s places, technically, where they're very important. His concern was, people looked at it as sort of an easy button of sorts—you know what, I can just package something up and I never have to deal with the people that run the infrastructure, I just throw it out.

Daniel Ritchie: Perfect.

Brian Dawson: His focus was really on collaboration. Now, I go here, because—yeah, I understand we all want an easy button, but to get to the right solution, it’s really about rolling up our sleeves, working together, bringing our individual domain expertise to bear and finding the right solution. Is that fair?

Daniel Ritchie: Absolutely, absolutely.

Brian Dawson: Yeah, yeah. And—well, cool. And I assume, and I'm leading the witness a bit, then, that I've heard this, we talked about rice paddies, bringing to bear to have the technologists in, that you are not in a situation where you're looking to identify a single tool across teams for each solution. It’s like, does everybody use the same packaging tool, or no?

Daniel Ritchie: No, no. And that’s—and actually, your comments on containers and the possibilities of the anti-pattern, what we sometimes will see happen is the latest fill in the blank comes along and somebody says, “Oh, hey, we have containers now. Everybody has to use containers. You have to deliver your application in containers now.”

Brian Dawson: Right, right.

Daniel Ritchie: You hear this all the time. Or, you know, fill in the blank for not just the approaches, but the technologies, products that are out there, and this happens over and over and over again.

Brian Dawson: Yes, that’s for sure.

Daniel Ritchie: Right? And, you know, the first time you heard serverless—“Oh, everybody’s gotta go serverless.”

Brian Dawson: You gotta have it. Stop, everybody, where is my serverless? Yeah.

Daniel Ritchie: Yeah, quit doing infrastructure as code, it’s all serverless now. And creating a space where, first off, we're not gonna dictate what that’s gonna be.

Brian Dawson: Right.

Daniel Ritchie: I think it’s so important to just stay out of the way.

Brian Dawson: Right.

Daniel Ritchie: But also to allow fill in the blank, whatever that next emerging thing is that’s gonna come along is not to have that be a threat or frightening. Like, it’s not disruptive in a negative way, it’s that—listen, there’s space here that’s been created for whatever that next solution is that’s gonna come along.

Brian Dawson: Right.

Daniel Ritchie: The next idea that someone has of, “Oh, why don’t we just do it this way instead?” Right? And allow that flexibility to accommodate.

Brian Dawson: [Cross talk] analogy, we built a framework or we've cleared a plot for when that new thing comes in, we can plant it, we can figure out what nutrients to feed it and grow it.

Daniel Ritchie: Exactly.

Brian Dawson: It’s about building an ecosystem, a framework, a farm, a plot where we can eat—what I was gonna say is, we can safely disrupt or safely embrace disruption, right?

Daniel Ritchie: Well, and disruption isn’t chaotic.

Brian Dawson: Right.

Daniel Ritchie: Right? We can embrace it and react quickly to that.

Brian Dawson: I love that, I love that.

Daniel Ritchie: Versus if you have desert conditions, you're not gonna be able to grow rice.

Brian Dawson: Right. [Laughter]

Daniel Ritchie: If you have a rice paddy, you're not gonna be able to grow cacti.

Brian Dawson: Right. And just, by the way, I already see the blog post—hopefully you get to it first—it’s cacti and rice paddies. Awesome title, it’s clickbait, I'm gonna open it up. Cacti, rice paddies, and software development.

Daniel Ritchie: There you go, there you go.

Brian Dawson: So—God, Daniel, I knew this was gonna happen. I have a ton of questions I can’t get to. What I’d like to do is dig into, real quick—so first, how have you enjoyed the show? You've been—this is, what, your third DevOps World/Jenkins World, or have you been to more?

Daniel Ritchie: This is my third.

Brian Dawson: Okay, okay. See, I know people. How has it been?

Daniel Ritchie: It’s been great.

Brian Dawson: What’s been anything interesting or a particular note to call?

Daniel Ritchie: You know, here, this is my first time in Lisbon, so—first time in the software space here, as well. And one thing that I've heard repeatedly, you know, kindness has actually been said multiple times.

Brian Dawson: Really? Explain a little bit more. I don’t—

Daniel Ritchie: Different talks that I've been to and people that I've talked to really are kind of internalizing this idea that we need to treat each other with kindness.

Brian Dawson: Yes, yes.

Daniel Ritchie: This very human aspect of the things that we're doing, you know?

Brian Dawson: Yeah, yeah. And—go ahead, sorry.

Daniel Ritchie: Well, I was having a conversation with someone at, I was on a panel at DevOps World San Francisco and someone said, “I don't think it’s about the people, I think it’s all about the automation, automating these things.”

Brian Dawson: I think we might have been in the room together. I remember hearing that, okay? Yeah.

Daniel Ritchie: But I was like, “Wait a second, wait a second!”

Brian Dawson: Yeah.

Daniel Ritchie: Because it’s, like you said, you know, whatever the next thing—you know, if you can automate perfection, right, then the next thing that comes along is, you're screwed, you're not gonna be able to accommodate that.

Brian Dawson: [Laughter] Right.

Daniel Ritchie: You need people to figure those things out.

Brian Dawson: Yeah, yeah.

Daniel Ritchie: And there’s a big focus, I think it’s coming out of Accelerate, but it’s coming up in a bunch of conversations today about cognitive overload and reducing cognitive overload. And it’s not about automating everything, it’s not about automating out humans, it’s about automating the mundane, the automatable, so people can focus on higher level problems and solve the big things. We're not going to solve those without human intelligence, human interaction, right?

Brian Dawson: Yes, yes.

Daniel Ritchie: Yeah.

Brian Dawson: Kindness, empathy—these things that allow us to find the depth of the human existence.

Daniel Ritchie: Yes, yes.

Brian Dawson: Right? And—

Daniel Ritchie: Ooh, we're gonna get deep.

Brian Dawson: The sum of the parts is, you know, the greater—the greater value that comes out of this is not what you can offer plus what I can offer, right?

Daniel Ritchie: Right, right.

Brian Dawson: It’s, we're gonna work together and come up with—

Daniel Ritchie: What we offer, yeah.

Brian Dawson: - we're gonna create something that didn't otherwise exist or couldn’t otherwise exist.

Daniel Ritchie: So, this is actually a great segue. So, I'm gonna do this thing that I try to do, I'm trying to squeeze about 30 minutes of conversation in the remaining three minutes here, so—now, that leads to, I think, what has been a theme throughout the show, and I'm wondering how it applies. It’s, there’s been a discussion about needing to shore up the relationship between the kind of tech concerns, business concerns, the tech function and software function. I think you saw some of that in the keynote.

Any thoughts? Have you seen that theme start to develop here or otherwise, and do you have any thoughts on it?

Brian Dawson: I actually hear this with what CloudBees was talking about for SDN in general, right?

Daniel Ritchie: Right.

Brian Dawson: I don't know, last, we'll call it 5 or maybe 10 years, we've really focused on how do we make the technical boundaries lower?

Daniel Ritchie: Right.

Brian Dawson: How do we make it easier to do the things technically, right? And almost everything that we talk about, everything that we've talked about—virtualization, containers, serverless, fill in the blank—it’s all about greasing the wheels technically.

Daniel Ritchie: Right.

Brian Dawson: But the thing that we, until very recently, have not talked about very much is that the whole reason for doing that isn’t to be great technically.

Daniel Ritchie: Right, right, right, right.

Brian Dawson: That’s not what matters. What matters is if we're able to deliver that business value.

Daniel Ritchie: Right.

Brian Dawson: And I think we're just starting to hear that conversation change and shift towards—well, look, yes, we are doing these amazing things technically, but because we're trying to deliver this greater, this greater value from a business perspective—

Brian Dawson: Right.

Daniel Ritchie: I don’t wanna say the technology doesn’t matter.

Brian Dawson: It matters, but it’s a means to an end.

Daniel Ritchie: It’s a means to an end, it’s a means to an end. And the end is delivering that business value. So, I think the conversation is now shifting towards that and I think that’s very exciting.

Brian Dawson: Love it. Good, good. Awesome. Alright, so, we'll do—I'm gonna hit you with a DevOops moment. So, we have this thing that we call DevOops—not DevOps, DevOops—and it’s times that we've failed as we should do as we learn if we're pushing the edge and learned a valuable lesson that we wanna share with our listeners.

Are you able to come up with or think of a DevOops moment? And there’s an out if you can’t.

Daniel Ritchie: No, no, I'll give you a DevOops moment. So, you know, along the lines of listening to what the developer, the engineer wants to do and allowing them to grow as they're gonna grow, I think very early on, we had this idea that literally everyone that you encountered wanted to invent their own solutions.

Brian Dawson: Ah, right.

Daniel Ritchie: So, we said, “Alright, we will stay as far away from this as we possibly can, we'll completely stay out of your way, we'll give you a really nice foundation and go forth and do whatever you wanna do.”

Brian Dawson: Right, right, right.

Daniel Ritchie: And what we found out is, some people said, “Well, I want you to tell me what to do.”

Brian Dawson: Yes. That’s interesting.

Daniel Ritchie: Not everybody wants to curate this solution on their own. Some people just say, “What is—tell me what I need to do and I'll follow the path and I'll do that.” And there was a scramble for us to say, “Oh, well, I guess, then, we do need to be very prescriptive.”

Brian Dawson: Oh, so that—and the cost, there was a cost to it, lost time, right? You delivered too generic a solution for some teams, learned, went back, and had to retool. Is that—

Daniel Ritchie: We didn't have to retool, but we did have to then form an opinion.

Brian Dawson: Right.

Daniel Ritchie: And we had to define—okay, well, this, if you don’t have an opinion, you should do this, and we decided to declare what that was.

Brian Dawson: I love that, I love that.

Daniel Ritchie: Which felt like an anti-pattern, right?

Brian Dawson: Right.

Daniel Ritchie: Because we said, “We're gonna create the right conditions for you to be successful,” and they came along and said, “Great, what should I do?”

Brian Dawson: Right, right, right.

Daniel Ritchie: We're like, “Oh, crap, okay.”

Brian Dawson: And I'm sure you had an opinion.

Daniel Ritchie: Of course.

Brian Dawson: ________ Yeah, so, that’s actually a great one, and I love when we get ranges from, “I had a pass and we're going into the clear” to, “I realized that to grow this thing, we have to have both a non-opinionated and opinionated version,” which is awesome.

So, Daniel, thank you for your time. Do you have any closing words, thoughts, advice, thoughts—I said thoughts twice, but for our listeners before we sign off?

Daniel Ritchie: You know, we're all just trying to do our job and be successful. Let’s just keep that in mind as we're working together on whatever that happens to be.

Brian Dawson: Awesome. Thank you, Daniel. Hopefully, you enjoy the rest of the show. I know we're about to wrap up here. I think we have to close out, but I appreciate you taking your time at the end of DevOps World.

Daniel Ritchie: Absolutely. Thanks for having me. Right on, man.