Bryon Kroger

All right. Hello, everyone. I'm Bryon Kroger. I'm the founder and CEO of Rise8. We help our customers achieve elite software development performance, and I'll talk about "elite" in a minute, for critical missions. Welcome to part two of Enterprise Comedy: my take on Dante's Purgatorio. We'll explore the seven deadly vices of DevOps transformation.

Quick note: if you're not religious, don't worry. Neither am I. I think you'll still enjoy this. If you are religious, though, also don't worry. You won't be offended. At least I hope not. I do love theology, including St. Thomas Aquinas, and that is why I love Dante's Divine Comedy. Fun fact: it's often referred to as Summa Theologica in verse.

I get way into symbolism too much. In fact, for Inferno, I wore all black. For Purgatory, I wore beige. Next time you'll see me in white. It's weird, I know.

Now, I wanted this series to be equal parts fun and educational. I use fun to create an opening to then hit you with the hard truths. Part one involved a lot of external reflection on the bureaucracy. Today is going to be a bit more internal, but don't worry. I'll introduce you to a lot of tools and tricks that can help you climb to the DevOps Promised Land.

So here we go.

Prior to Rise8, I spent 10 years in the Air Force using really terrible software for critical missions. It's not funny, though, because I saw missions fail. I saw people die. I then decided to lead this really cool transformation called the Air Force Kessel Run, and that established continuous delivery to the battlefield. It was pretty incredible. Now I help other organizations achieve similar outcomes.

This three-part series draws on those experiences of the biggest bureaucracies on the planet by every measure. So if you missed part one of Inferno, we talked about navigating the 12 parsecs of bureaucratic hell, drawing on Dante as our inspiration.

As I mentioned, Inferno is often referred to as Summa in verse. If you're not familiar, this is a summa-verminoth of Star Wars fame. At the end, we faced summa-verminoth, escaped the inferno, the bureaucratic hell, and now we're in purgatory. So here we go.

That wasn't the only summa in verse, though. Eminem, also in "Rap God," features summa in verse, and weirdly features Inferno on the shelf. So we wondered, is Em secretly a DevOps divinity sent to guide us through the enterprise comedy?

I closed with the question, does he really have the key and the secret to DevOps immortality? Is the blueprint simply rage and youthful exuberance?

That, my friends, was 12 slides in two minutes. So here we are, to pick up where I left off: rage and youthful exuberance. They might help you overcome the sins of bureaucracy and escape bureaucratic hell, but they won't get you to the Promised Land: elite software delivery performance.

You lost my monitor here.

There we go. Let's try that again.

All right. We want to get to elite software delivery performance, and for that, we're going to have to transform our vices into virtues and become better practitioners.

At the risk of overdoing the 12-parsecs thing, I'm just going to go with the original here. Stick with a two-plus-seven-plus-one theme. Yeah, it's a thing that he does. More symbolism.

Before we can enter purgatory, we have a couple of holding areas: the excommunicate and the late repentant. So I want you to look around your enterprise. There are probably many John Wicks in your enterprise who know where the proverbial bodies are buried and can really help you get ship done.

Unlike Dante's purgatory, DevOps is a team sport. In DevOps enterprise purgatory, we need to climb it together to get to the DORA Promised Land.

We found that in our Space Force project called Section 31. The team on the ground had written off some of the battle-scarred enterprise operators. They were excommunicated. They excommunicated them from their DevOps church, we'll say. But a few of us convinced them to add a little bit more compassion to their approach, and through compassionate assertiveness, they were able to bring them onto the team side.

That proved critical when there was a fight over resources between two innovation programs. Those excommunicates are actually the ones that wrote the report that secured their next year of funding and kept the transformation alive.

Then, late repentance. At Kessel Run, actually, a late repentant is the ace in my sleeve. Have you ever heard the phrase, "There's no zealot like a convert"? This is really important. Our convert knew all the ins and outs of the bureaucracy and had a zeal and a passion for what we were doing. At first, I kept him at arm's length because he wasn't one of the so-called pioneers, right? He was a late repentant. But it wasn't until we brought him in that we were able to make the Kessel Run in 12 parsecs.

So it's a lesson to us all before we enter purgatory. It's a team sport. Bring along the excommunicate. Bring along the late repentant.

The first three terraces of purgatory relate to sins caused by perverted love. It's a really interesting theme throughout Purgatorio. The first three are pride, envy, and wrath. These show up in our transformations as well, and we have to replace them with virtue to get to the next level.

Pride being the first one: loving yourself to the detriment of others. There are two ways that pride manifests. The first is thinking too highly of yourself. The best antidote that I know for this is shipping to prod repeatedly, because prod is a very humbling place.

Establish production feedback loops as soon as you can, because once you do, you nor anybody else can hide behind PowerPoints, white papers, and the gift of gab. That's mine. I often fall into that trap myself. Once that data starts rolling in, you can't do that anymore. Feedback loops force us to be humble.

But I've seen it over and over again that it's really hard to feel the feedback loops. We believe that transformation improvement in software delivery and operational performance will lead to this 2x organizational improvement, right? That's what the State of DevOps report consistently finds. But there's a question then, like, that assumes everything goes right.

So we're like, "Yeah, we got continuous delivery. We've got high SDO performance." But the outcomes aren't rolling in. It could be hard to say, and many managers and leaders will start talking about potential value. They'll start talking about the future in the present tense. That's a big trap to fall into.

But the feedback loops are long. So what do you do about it? I'm going to kind of flip this. Start with the end in mind, right? If we want to get to 2x performance, we believe we can do that by improving our software delivery and operational performance, our culture, our process, and we can focus then on various technical activities.

But how do we know we're actually right? We have these feedback loops. It feeds back onto itself. The problem is, developers and product teams, especially if you come from that level, you can get feedback in days to weeks. But once you move up a level to management, now you're looking weeks to months. You get up to the C-suite, and sometimes you're talking not just in quarters, but in years.

That's assuming that we're right. If we invalidate our assumptions, these feedback loops draw even longer before getting positive feedback. So we need systems to account for that.

At Kessel Run and other GovTech transformations that I've been a part of, we've had great success implementing operating models like this one. We want to get all of the metrics centered around the customer, and then each level of the organization. You might have different labels in your organization. The feedback loops feed the overall context, not just within your own context, but it feeds every other context for the entire organization. The whole organization can see.

One key feature here that will keep you honest and humble is the growth board. I could do a whole presentation on growth boards. I wouldn't want to do it in front of Paul, though, because I learned most of what I know about it from him and some others.

The idea is, much like VCs would do, you meet with your teams and have a regular cadence to discuss their growth. By that, I mean their continuous improvement. What have they learned? What have they achieved? Were our assumptions valid? Should we pivot, persevere, or cancel?

I mentioned that there's two sides to pride as well. We don't want to think too highly of ourselves, but I also don't want you to think that it's healthy to think too little of yourself. Instead, you need to think of yourself less and keep the customer at the center of this operating model. The growth board and other ceremonies take the ego out of it, right? It makes it all about the customer.

In purgatory, after being introduced to humility, Dante and Virgil meet the souls of the proud, who are weighed down by big stones on their back. Dante remarks that when the mark of pride is removed from him and he now has this humility, his load is lessened and it's easier for him to take the next step. Virgil comments that his effort will be increasingly lessened as he climbs.

That's true of our transformation as well. Every time we get rid of one of these vices and replace it with virtue, our climb gets easier.

So let's continue.

Envy is the sin that looks with grudging hatred at other men and women's gifts and good fortune, and takes every opportunity to run them down and deprive them of their happiness. We see that a lot in enterprise transformation as well. Transformation leaders are often put up on a pedestal, and then everybody else in the organization is throwing darts at them. Sometimes, as we discussed in Inferno, the transformation leaders are actually throwing darts at each other as well.

You're probably thinking, "Yeah, they should all be supporting me, Bryon, maybe even worshiping me." I get it. I'm with you. But that's a trap too.

Safi calls Loonshots a really great book. It provides an overview of the balance required between what he calls franchises and loonshots. This particular trap of putting people on a pedestal, he refers to as the Moses Trap, where leaders pick their chosen creation and part the Red Seas for it. It might have worked in the Bible, but it doesn't work well in organizations. It makes everyone resent that person, and it usually doesn't lead to good outcomes either.

It shouldn't be that way, but also not maintaining enough separation between the franchises and the loonshots is a recipe for chaos as well. You have to both keep them separate, but maintain dynamic equilibrium between them. That's what he calls it: loving your soldiers and your artists equally.

So if you're a practitioner or a leader, we should all be focused on loving our artists and our soldiers equally, and communicating that throughout our organization. When you do that, everyone wins. Yay.

By the way, if you're a Spanish reader and you decide to pick up this book, don't be alarmed. You don't need to be a lunatic.

So if you are part of the transformation, strong people don't put others down. I used the wrong graphic. Strong people lift others up, both inside and outside the team. Not only is that how we win, but it also ensures that people aren't throwing darts at us from afar. Karma sucks.

When I was at Kessel Run, we started this great practice called Engagement Day, and I've done this with several other organizations and I highly recommend it. We actually just met with others and also with industry, and teach them about what we did and how we did it.

Investing that time, I also spent a lot of personal time investing with teams that I knew we were going to need to work with in the future who were external to us, and many other people on my team did as well. Be generous with your time. It pays back in spades.

That doesn't scale well, though. That eventually breaks at scale. So there's another practice that's really useful. It's called documentation. It's wild. I know we're doing Agile, we can't do documentation. But if you document things well, it's not only great for your team and for your future teammates when they onboard, but it's also great for people that want to learn from you, and they will appreciate it, and that karma will come back around.

The U.S. Digital Service's playbook is actually really fantastic no matter what industry vertical you're in, and I highly recommend checking it out.

All right, wrath. The virtue that counters wrath is meekness, and meekness is a wildly misunderstood term. The original translation from the Bible actually doesn't translate to what most people think of, which is weak. It actually refers to having mercy and intelligence and knowing how to diffuse a potential for violence or war.

Another analogy that often gets used is having a powerful sword but keeping it sheathed. Really interesting way to think about it, right? It wouldn't be a virtue if you were weak, right? Withholding violence isn't a virtue if you're not capable of violence.

And so the virtue is that you're capable of great violence, which leaders are. We don't like to speak in those terms, but power can be corrupted and turned to violence. So if you have a powerful sword, whether you're a manager or a leader, you should keep it sheathed.

In religious terms, it's marked by faith and trust in God. But in our DevOps journey, it should be absolute faith and trust in first principles. So to be meek means to always turn to those principles for help. It means to turn in the sheer joy of their blessings, we'll say.

So let me describe a common anti-pattern. You talk to your team about the wonder of carrots, in this case, DORA metrics, and they just don't do anything with the DORA metrics. They don't even do them. So you dangle a carrot in front of them in the form of a dashboard. When they still don't respond, you start beating them with sticks and talk about sticks.

Love is perverted, and it's wrath. Of course, if we were practicing humility, call back to the first, we'd realize that all along we were actually doing this. It was a leadership problem.

Regardless, this topic of carrots and sticks actually came up in the DORA event on Monday, and to me, it's the wrong conversation. First of all, our people aren't livestock. But in a DevOps culture with meek leaders, as I described before, carrots and sticks aren't needed, and they're actually counterproductive.

What we need instead are transformational leaders that inspire and align and empower. Yet in a conversation usually about carrots and sticks related to DORA metrics, we just overlook this table of cultural traits. I think it's safe to say that if you're talking about sticks in your organization, you're probably not generative.

In a healthy culture, absent control, it's really important to note that freedom and responsibility are a function of accountability. Accountability is not a stick. Lack of accountability actually might be a passive one. It destroys the opportunity for peace, and it creates war among your teams.

Accountability is actually a kindness. Make teams responsible for outcomes and then give them the freedom in how they achieve them. That's a generative culture. Then be patient. You're going to have to over-communicate. You're going to have to coach. You're going to have to put absolute faith in those first principles that I talked about.

You may have to let some people go, right? That's a reality. Not everyone is going to be a fit for the team, but that doesn't require wrath. It doesn't require sticks. Done well, it's actually a kindness to the team.

So be gentle, and most of all, be patient, because your lack of patience will turn to wrath and screw you over.

Perverted love now down. So we're going to move on to deficient and misdirected loves. For Dante, sloth is not laziness. That's the common definition we use, but more something like the besetting sin of our day, which is boredom: a lack of love.

The corresponding virtue here is zeal. For the slothful, you need to foster a zeal in them. As I said before, there's no zealot like a convert. The military is fantastic at this. If you think about military boot camp, I'm not sure what these Marines are actually doing here, but I'm pretty sure if you can get people excited about doing this, then you can get people excited about shipping game-changing software in your enterprise.

Look to Google's Project Aristotle, which talks about what makes teams high-performing: impact, meaning, structure and clarity, dependability, and psychological safety. Get people fired up about the mission impact you're going to have, and that means you have to know it too. Get them really excited about the meaning of the organization. Provide structure and clarity. Show them what team dependability looks and feels like through demonstration. Then get people fired up at work. Make them safe to fail, to take risks, to be vulnerable.

I know you're probably thinking that a military boot camp won't go over well in your organization and probably won't lead to a lot of psychological safety, which is fair enough. Truth be told, in my last presentation, I said that this is actually an area that the military struggles with. And I think the enterprise in general, hierarchies tend to create a lack of psychological safety.

For DevOps transformation, we've all seen in the community great success with dojos. Target is a big one that everybody's usually familiar with. At Kessel Run, a government organization, we brought in Pivotal Labs, and they ran what are essentially dojos with us, and it was a huge key to the success that we had there.

Similarly, we at Rise8 have now gone and done that with the Air Force, the Space Force, Veterans Affairs, and some other public sector organizations. If we can do it there, we can do it anywhere.

So just keep in mind, though, you aren't just teaching continuous delivery. This dojo isn't about the punches and kicks of DevOps. You really need to focus on that impact, meaning, structure and clarity, dependability, and safety, which, by the way, is what dojos are all about if you've studied martial arts.

Now we get to the last three terraces, where it's excessive loving of good things, or in a disordered way. This is an area where we all struggle because it's very easy to love a good thing too much.

Greed is when we love material things more than our neighbors. It manifests in the tech journey when we put tech over people or business over people. When we do that with excessive love, we end up cheating our people.

So if we go back to the DORA metrics, the covetous can't see the people parts, right? They can't see teams choosing their own tools, generative culture, streamlined change approvals, and well-being especially. The focus is entirely on the technical activities and performance, and they covet all the tools.

A great way to overcome this vice is to pair your DORA with some SPACE. Nicole has some fantastic talk tracks on this and wrote a paper on it that you can find as well with some colleagues. SPACE is a great way to force yourself and those around you to consider things besides performance and activity.

The rule that I heard Nicole say is that you need to use metrics from at least three categories. I'd like to add another rule that says, if you only use three, you only get to use performance or activity, not both. That forces you to look at a lot more human elements. That might not hold up in every scenario, but it's at least worth a conversation.

Now, strictly speaking, when we move on to gluttony, that's people who love food more than their neighbors. So how does that relate to DevOps? Well, in our journey, food is a metaphor for information.

So how much information are you consuming? Is it too much? Is it keeping you from tending to the people around you and what they need? Is it harming you? The antidote here is going to be temperance.

So how many of you watch a lot of TED Talks or other tech talks? How many of you probably watch everyone on this list? I actually have it, sorry. Or read all the DevOps books, or listen to all the DevOps podcasts?

The goal of consuming information is learning, right? One way to tell if you are a glutton for information comes from this great lesson from Alex Hormozi. This is going to be a little controversial, so hang in there. Learning is you have the same condition and different behavior.

So if you want to be very particular here, if you're consuming a ton of information but your behaviors aren't changing, you are probably a glutton for information. He also has this bit about intelligence being the speed of behavior change.

So if you want to be smart, you have to learn fast. If you want to learn fast, you have to change fast. So there's also a rate mismatch here. Not only should your behaviors be changing, but they should be changing at a rate that matches your information consumption. Otherwise, you're probably still overindulging.

"Bryon, does that mean we shouldn't read, watch, and listen to all the DevOps talks?" That'd be awkward if I told you that right now, since you're here listening to my talk at a conference full of talks put on by a person that puts out a ton of books.

So you should read and listen. But the goal here is read to solve problems, not to make progress. Doing makes progress. So read when it's appropriate. If you're having a problem with value flywheels, read The Value Flywheel Effect. Great book, by the way. Highly recommend it.

The thing I want to note too is, you should do no more or no less. I think a lot of folks spend a lot of time not only consuming, but also regurgitating information when they should be out doing practices, and then come here and report back on all the things that you've done.

The sin of lust is the final terrace of our purgatory, the final vice of excessive love. Everyone's like, "Oh my God, what's he going to talk about on this one?"

While misdirected sexual desire is a problem at the workplace, that's not what I'm going to talk about. Instead, I want to talk about misdirected hiring desires towards the so-called 10x engineers.

This is a violation of DevOps transformation and its first principles. You can't hire your way out of a problem that you managed into. These 10x engineers, they will fail in your broken system. Even if you fix the system, they'll still struggle because they lack context on the enterprise. Context is king in enterprise transformation.

The truth is, you already have them, right? Famously, Adrian Cockcroft was challenged by a Fortune 100 CTO: "We can't copy Netflix because you have all these superstar engineers. We don't have them." And he retorted, "Well, we hired them from you and then got out of their way."

You already have these people. So when it comes to 10x engineers, please practice chastity instead. Invest in the people that you already have.

All right. At the summit of Mount Purgatory is the Garden of Eden. It represents our state of innocence before we fell from grace, and in our case, a natural state of work that actually exists before we fill it with bureaucracy and vices. You know, before that SAFe consultant got a bite of that well-bucketed bureaucracy.

Today I woke up and chose violence against SAFe. Sorry.

It's in the Garden of Eden that you'll find Google's board. No, not Google's board, actually. When PCF died, it went to heaven. Many pray for its second coming.

Jokes aside, in DevOps paradise, you will find elite software delivery performance. They got rid of the elite category, and I do know that, but my DevOps religion is very elitist. So I'm going to fracture our DevOps church and keep it under Protestant DevOps.

Two quick things here. I love getting inspiration from completely different industry verticals. Before closing, I want to pull on the Garden of Eden analogy. If you want to keep your DevOps garden beautiful, you should think like: tend the soil, pull the weeds. These are all great metaphors, right? Help valuable things grow. Work with nature. Respect the circle of life, the natural state of things.

Here I included one of my favorite gardeners, Sepp Holzer. He is one of the fathers of permaculture. There's really interesting parallels between permaculture and DevOps. Many of the principles overlap. So I really want to emphasize that.

For instance, the founder, Bill Mollison, once said that permaculture, like DevOps, is not anarchy. It's urgent, complete cooperation between each other and every other thing, whether animate or inanimate. That's what we're trying to do with sociotechnical systems.

I'm going to skip the rest of these here in the interest of time, but I do want to close with one final note here.

I want to recognize that escaping bureaucratic hell and climbing purgatory is overwhelming, and it's easy to become cynical. So I'm going to be blunt with you. As St. Mad Dog Mattis said, cynicism is cowardice.

Cynicism makes us feel good, right? Because we don't have to hold ourselves accountable for doing something about the broken systems around us. So we externalize the problem. The issue, though, is that our negative beliefs become effective truths.

So if you don't believe in the great persons of history narrative, in other words, that people can change the world, you'll be right in that you won't change the world. If you believe that about your enterprise, you will be right. You will not be.

As your enterprise takes hold quickly, and in your DevOps, you outlaw it. You make laws against being cynical. You shut it down immediately.

As I said in part one, don't accept powerlessness. You betray yourself and everyone around you. So take power and distribute it. The ultimate sin in the enterprise is cynicism.

So with that, go climb the transformation purgatory and become a gardener in the DevOps paradise. Thank you.