Jeffrey Fredrick and Douglas Squirrel

Jeffrey Fredrick: Well, hi, Squirrel.

Douglas Squirrel: Hi there, Jeffrey.

Jeffrey Fredrick: Welcome to our DevOps Enterprise Summit presentation. For the audience, I'm Jeffrey Fredrick. I am the managing director of a fintech company in London, and also a consultant and executive coach.

Douglas Squirrel: And I'm Squirrel, and that is actually my name. I live in England, where I'm a consulting CTO, and I've worked with something like 90 organizations in the last five years on all kinds of transformations and improvements, which is the sort of thing we're going to talk about with you today. And of course, together, we wrote a book.

Jeffrey Fredrick: Yep, published by people you may have heard of: IT Revolution.

Douglas Squirrel: Yeah, I've heard of them.

Jeffrey Fredrick: We launched that earlier this year, and we're very happy with the response and being part of the IT Revolution family. Although we'll say a bit later about why we're not quite as happy with the response. There's something missing, which is what we're going to talk about today.

Douglas Squirrel: That's true. That's a really good point. This is something that we've picked up since launch. We've had some really good feedback from people, people happy with the book, but there's something about the dynamics that aren't quite right.

Structure and dynamics was a bit of vocabulary that I personally picked up from this DevOps Enterprise Summit community, back in the London virtual event earlier this year. What was really key for me was Dr. Steven Spear. He was a keynote in London earlier this year as well, and he shared some excerpts from his book, "High Velocity Edge," which were just really fantastic. I went and bought it and read it, and it has become one of my top recommendations to executives who are looking to understand the kind of organization they want to have if they want to be what I would have in the past called a learning organization, now a high-velocity organization. Really, just operational excellence.

The term structure and dynamics is very interesting. I'm sure there are a lot of other conversations about that in the IT Revolution community, both here at DevOps Enterprise Summit and, if you listen to Gene Kim's "Idealcast," this is something that's come up many times. I want to narrow it down to: structures are the things we put in place or the things that we do, and dynamics are what result.

Jeffrey Fredrick: So structure would be having a standup.

Douglas Squirrel: Exactly.

Jeffrey Fredrick: That's what you need. You need a standup, and you need lean methods, and you need DevOps methods. As long as you have those, you're fine, right?

Douglas Squirrel: Well, yes and no, but mostly no. This is the challenge, and this is what makes having a really high-performing organization so challenging: we can't just copy the cookbook from somewhere else. We can't look around somewhere else to find the best practices and put them in place and get the same results.

Jeffrey Fredrick: So Kubernetes and retrospectives, those are not going to do it for me.

Douglas Squirrel: They're not enough. They're not sufficient. It's not that there isn't valuable information in other people's experiences. We can learn a lot from the structures in other places, but we always have to keep in mind the dynamics. Are we getting the dynamics, the results that we want?

Jeffrey Fredrick: And this interplay between structures and dynamics, for you and me, Squirrel, often the gap between these when we work with people is that they're having trouble when they're trying the right structures, or interesting structures, or changing their structures, but they're not getting the dynamics.

Douglas Squirrel: Aha, I know if I get the Spotify model, that'll be enough.

Jeffrey Fredrick: Yeah. There are some really important elements that come down to conversations, and that is where our point is.

Now, this idea of structure and dynamics, for me, has a very close tie to the Cynefin model. People who are coming across this for the first time will see this "Cynefin," but you have a good tip for how to pronounce it correctly, right?

Douglas Squirrel: It's easy to do, although here's another tip: if you want to make sure people remember your framework, don't use Welsh to name it. This is the only word of Welsh I know. You say the word "Kevin," and you say "nuh" in the middle. So it's Cynefin. That's how you pronounce this goofy word.

The helpful idea that comes from this theory, and that we want to focus on here, is just a little piece of the whole picture. The whole thing is really valuable as a way of understanding how systems work, especially their dynamics: how they're changing over time, how the elements are evolving. The one we want to focus on is the complex domain, where you know that there's a connection between what you're doing and what the effects are. There is some connection. Nobody seems to know what it is.

Unlike some of these other domains, and these things have changed their names and so on, this itself is a dynamic framework. But the idea is that when you move into the complex domain, and that's usually the domain of humans and startups and rapidly evolving situations, exactly what "High Velocity Edge" is all about, the situation you're in is one in which it's most helpful to do something and then see what happens. They call that probe, sense, respond. I might call it ready, fire, aim. You start trying something, you figure out whether it worked, and then you respond by adjusting. That's exactly the sort of thing that agile software development and DevOps and all these wonderful things are supposed to give us.

The problem is that we keep using structures that don't involve any probing, and certainly not any responding, in the way we're implementing them. Then we're kind of surprised that our system didn't adapt. We didn't get better.

Jeffrey Fredrick: That's a great way to put it. I think that's the challenge: when people don't take the system view, don't understand that there's an emergent property. That's what these dynamics are. They're the emergent property of the organization from the structures we put in place. They're only focused on the structures and not sensing that emergent dynamic property.

That's where people fall down: they're not understanding how to move back and forth from sensing the dynamics that are occurring, trying experiments with the structure, and seeing the new dynamics, and back and forth.

There's one other thing I found interesting when I went back to this paper. This is the 2003 version of Cynefin, and I'm sure people here have looked at more recent versions. If you go to Wikipedia or something, you'll find different labels for the domains, but the idea is still the same. One thing I found very fascinating about this complex domain, and I've highlighted it here, is that when we're dealing with this place where it's not something where it's just best practices, where it's not a question of expertise and being able to know ahead of time what's going to happen, it's very valuable to increase the number of perspectives available to the decision-maker.

That's true whether your decision-maker is a single person or whether it's a committee. The decision-making rule isn't important, but what we know we want is as much information as possible, as many different perspectives as possible. Actually, I think people kind of already understand it. Let's try a test with our audience here and see whether your intuition matches this framework.

Douglas Squirrel: Sounds great. This usually gives me a chance to test my telepathy.

Jeffrey Fredrick: I'm telepathically going to predict what you guys are going to respond. We're now going to give you something to do.

Douglas Squirrel: Interactive talk, even though we're recording it a month ahead of time.

Jeffrey Fredrick: That's right. Hands on the keyboard. This is a chance for all of you to type and test Squirrel's telepathy. Here's the scenario. We're going to make an important decision, and it really doesn't matter what important decision. Let's pretend we're going to ask you in the audience, as individuals, each of you individually, to put your answer into Slack.

Here's the question: where should we have next year's DevOps Enterprise Summit Conference? Where would you choose? Now, don't answer that question, because that's not what we want you to type.

Douglas Squirrel: Although Antarctica would be great. I'm looking forward to it.

Jeffrey Fredrick: But as a group, we need to make a decision. You individually are going to decide how we go about it. What's the protocol we're going to follow to make the decision? How would you recommend we go about making this decision? You're the chair of the committee. How are you going to decide?

Douglas Squirrel: So go ahead and write that in Slack, and I predict that I'm going to be able to know what you're going to say. I'm a month ahead of time. It's only September.

All of your answers would have had these properties. You would have said that you want to get input from everyone who's here, you want to know what everyone thinks and why they think that, and you would share it yourself. That's what people always say, and that's what we've seen over and over again, because people advocate the probe, sense, respond, high-diversity approach that we all know is going to work.

Jeffrey Fredrick: If you look back, you would have put in structures. You would have said, "I'm going to ask everyone to say their ideas, and I'm going to share mine." But why? What's the reasoning behind it? It's because you can see the value of those diverse viewpoints that inform your decision.

But there's a paradox here. You and I have asked this question of lots of people. We've asked it of multiple DevOps Enterprise Summit groups, both in person last year in Vegas and virtually in London. We've asked many small groups. We always get the same kind of responses. And yet, when we deal with people and actual decisions they're trying to make, we see something different. What's different when people are dealing with their actual decisions?

Douglas Squirrel: It's just like when I've been trying to lose weight. I don't eat cake except on these special occasions when I do eat cake. And the special occasions turn out to be just when there's cake. That isn't a good way to lose weight, and it's not a very good way to change your organization either.

What happens is people say, "Well, yes, that's the right way to do it for something that's kind of not so vital, but this important thing, well, everybody knows we have to convince everyone to adopt this practice. Everyone knows a retrospective would be very helpful, so we just have to convince them that we have to uphold that practice. In this special situation, differences would be a threat. Why would I want somebody to have a different opinion? Listening to them would derail our process of adopting the new practices that we're trying to bring in. So just this one special case, which is actually most of the cases, we're going to do it differently."

That's exactly why people get caught, and this is why the Agile Conversations have been hard for people to implement. It's been hard for them to adopt some of the ideas we're going to describe here. We're also going to tell you a way out, how to get past that and how to get the results that you want: good decisions, probing, sensing, responding, and being a high-velocity organization. There are some specific mechanical things you can do that will help you.

Jeffrey Fredrick: The good news is there are concrete steps you can do, and the general conversational transformation has a playbook that you can follow. This is based not just on our experience; we went and looked back at the literature. This is really something you and I learned from looking back at the work of Chris Argyris. The idea is that we can use our conversations to become self-aware. We can study them to start finding gaps between what we believe about ourselves, what we believe about our behavior, and our actual behavior in practice. Because that's the thing: we have this idea of how we would make decisions, we have how we behave in practice, and we're unaware of the difference.

As we said, you already know what the results look like. If they're successful, you have the dynamics that you're looking for. You're having good interplay between people, you're having the diversity of opinions, and you're getting the value. But what you're not necessarily seeing is when your behavior doesn't contribute to that.

There's a fairly simple set of steps that we put forward, and we're not going to spend a lot of time on this. We've talked about this in the past. You can find the past videos and read about it in our book. It's the step we call the Four Rs: number one, record your conversations; reflect on them; revise them; role-play. Of course, you'll repeat them until you get them right, and you'll do role reversal. Okay, there's six. The six Four Rs.

Douglas Squirrel: As you like to say, Jeffrey, this is a book on conversations, not on math.

Jeffrey Fredrick: Exactly. Just a quick overview of what each of these steps are. The record conversation involves very simple steps and very simple materials. All you need is paper. You fold it in half, and you record it on the right-hand side of the paper. In the right-hand column, you put down the transcript of what the dialogue was. On the left-hand side, what you were thinking and feeling. This starts making your conversation visible to you in a way that it hasn't been in the past.

From there, we reflect. What does it mean to reflect, Squirrel?

Douglas Squirrel: You take a look at what was going on in the conversation and how you could improve it. We're illustrating here one of the very basic techniques, but there are lots of different things that you can record and understand about your conversation and score so that you can look to see how to improve it. We won't go into the details here. There's lots more in the book.

Jeffrey Fredrick: With reflect, the reflection step will change based on what tool you're using. From that reflection, you're then going to revise your conversation. We're going to alter the conversation we wish we had had based on the tool we're using and the reflection we did. We found mistakes, and now we say, what would it be if we were more skillful? This is where we start developing the skills of generating a better conversational dialogue. This is a chance to practice. You notice this guy, Norbert, if we were paying close attention, gave himself zero for questions. Now Norbert's asking more and better questions in this revised dialogue.

Finally, once we've developed that skill of generating the kind of words that we think we might use, we're actually going to role-play. Sometimes things look very good on the page, but then you realize that this is not the way that I talk. Or maybe when I hear it, I think that's not the way I'd like someone to talk to me. So the role-play step is part of this.

We're building the skills here. We're learning to see. We're learning to criticize our own language. We're building the skills to generate better dialogue, and then practicing how it sounds to actually say those words. The outcome of all of this is that we begin to have true collaboration, the dynamic of true collaboration, where we are bringing in different viewpoints, having productive conflict from those different ideas, and generating better outputs.

People all understand this is what they want, but we find very common traps when we talk with our clients. Can you tell us a couple of those, Squirrel?

Douglas Squirrel: One is that you wind up having conflict that is unproductive conflict. Instead of finding out, "Oh, Jeffrey, you have an interesting idea there. Let's probe it. Let's try doing something else that's diverse and helpful," I say, "Oh, there's that Jeffrey again. He just hates us. He doesn't want to do it our way. We're going to have to find a way around him or force him to agree." That's an unproductive conflict.

The even more common, more insidious one is where Jeffrey doesn't even speak up. He says, "Well, those folks over there in QA, they never listen. They just have to do it their way. Couldn't possibly automate any of their tools. No way we could do automated tests here. Okay, I guess that's the end of improvement here in our company." That's a very dangerous position to take.

Whereas if you can take these conversational techniques as far as you can, you wind up having a different conversation and might result in a very different solution, which is the true collaboration quadrant.

Jeffrey Fredrick: Again, these quadrants we're putting here are dynamics. They aren't structural. This isn't a question of whether you had a standup or not, how you organize your teams, what kind of meetings you have. Those things can all help. They would change the dynamics, for sure. But really, the test here is: are you having the right dynamics? You can put everything that's seemingly right in place in the structures, seemingly in all the books and the best practices, but not be getting the dynamics that you want. That's what we see over and over again.

There's a problem here, coming back to what's been missing with the book. We've talked to people who say, "Loved your book. I bought copies for my whole team. We've all read it. It's just great." Then, Squirrel, you always ask them a very simple question.

Douglas Squirrel: How many pieces of paper did you fold in half, and how many times did you write?

Jeffrey Fredrick: "Oh, I didn't quite get to that. I didn't feel like I need to. That didn't work for me. I don't really get it. Those other people over there, they need to do that. I'm going to give it to them so they can do it."

The challenge is people like this. They go, "Oh, this makes sense. Yes, I want the true collaboration." But what they don't do is the work. They don't do the conversational analysis. We've laid out this simple model, and it has very good results if you do the work.

Douglas Squirrel: It's just like if you wrote a diet and exercise book, and it said, "What you should do is jog five miles every morning." Then you gave it to lots of people and they said, "Yes, I should definitely jog five miles every morning." If you followed up with a lot of them, I bet a lot of them would not be jogging five miles every morning.

Jeffrey Fredrick: That's right. There are some human reasons about this. One of the big challenges of doing this work, especially doing it consistently, is that it's painful. That's why we have the title of this talk, about making change painfully: in our experience, doing this work is a bit painful.

Why is that? It's because we don't like that feeling that we get. We ask people this question, which we got directly from Kathryn Schulz. I first heard it in her TED Talk many years ago, and I've asked many groups since then: what does it feel like when you're wrong? The quotes here are ones she had in that talk. People said it was dreadful. Thumbs down. Someone actually said, "Great. I love the feeling of being wrong because I love to learn and get better." All of them are wrong. All of them are incorrect responses.

Douglas Squirrel: That's right. These feelings, whether positive or negative, are not what it's like being wrong. They're what happens when you find out you were wrong.

Jeffrey Fredrick: Exactly.

Douglas Squirrel: But being wrong feels just like being right.

Jeffrey Fredrick: Exactly. Being wrong feels awesome because you're not aware that you're wrong. That moment of learning is often very difficult. I love Mark Coleman's quote. He had a talk where he was describing cultural change and saying, "Look, this is going to require difficult emotional work."

I have this hashtag that has come up: learning is horrible. Some people really hate that, my wife included. Other people love learning. You're probably here at this conference because you love learning. I'm telling you, this kind of learning is a bit different. Why is that? I think it's because we're learning about ourselves. We're learning that we aren't the people we thought we were. That's really the struggle. Understanding our conversations and how to make them better shows that we don't behave the way we think we do. In a sense, we're not the people we thought we were.

That's why we want to talk about a different structure today and send you away with a solution: you should do this work, but maybe you have more success if you don't do it alone. We're advocating here something called Conversational Dojos. Conversational Dojos are something we've done in groups. We've put them in place in multiple companies.

Douglas Squirrel: It's how we learned these techniques ourselves.

Jeffrey Fredrick: Exactly. We understand that skill development requires deliberate practice. Like going to the gym or doing your jogs every day, if you do the work, you'll get the benefit. The challenge is that people often have difficulty doing it themselves, but when they have a group they do it with, they find it both more effective and more fun. That group holds you accountable.

In this kind of work, because there's something about views of ourselves, our view of ourselves can interfere with our practice. Your colleagues don't have that problem. They can see when your words and your espoused behavior don't quite line up, and they can help you see problems. Even as you're learning together, having other people helps in finding problems. It also helps you see the mistakes that other people are making. Every part of the practice is helpful.

If you want to do a Conversational Dojo, the good news is we've put together a kit about how to do it. You can download it. We lay out the steps for how to run a Conversational Dojo, and it has three parts: an instruction for what the form is, a runbook for how to do it, and handouts to help support you.

As we mentioned, the Dojos can be different based on the kind of reflection you're doing and the different tools you're going to need. In this case, our book "Agile Conversations" is a very good complement, because in the book we lay out five types of conversations, each of which gives you a different tool, effectively a different workout. You can think of these as the katas you're going to do in the dojo, the things you're going to practice and get better at.

That's what a dojo is good for in a way that the book has kind of fallen short on. If you just read the book and don't try to practice, you don't get the full benefits. We've seen that over and over again, which is why we're doing this new initiative to encourage people to try reading the book in groups, using the techniques, practicing things that aren't in the book that work for them, and we're seeing much better results from that.

Douglas Squirrel: What's the outcome?

Jeffrey Fredrick: If you do this practice, you will gain the skills, and then you can test: are you getting the dynamics you're looking for? Are you getting improved relationships? Are you seeing improved trust? Do you feel like you're making better decisions? Is there better leadership?

Now we have a request for you. Try this. Download the kit and let us know if it works for you. Or if it doesn't, we'd be very keen to find out.

Douglas Squirrel: Where do you get it?

Jeffrey Fredrick: You can get it from IT Revolution. We did a webinar with them to describe how to use the kit, and the video of the webinar is available on the same website, so you can see much more detail than we've been able to go into in this short talk about how to use it and what the benefits are.

And of course, this is a good complement with "Agile Conversations." To be clear, you can use the Dojo kit without it. You might start with that, get the basic practice down, and then when you're ready, go ahead and add in "Agile Conversations" to take it further.

We would love to hear any questions in Slack right now. We're also on Twitter and email and Instagram and anything else you can find where you can find us.

Douglas Squirrel: We'd love to hear from you, hear about your experiences, and of course, any questions at any time. You can join our Slack community.

Jeffrey Fredrick: Thank you for coming. We're right here in Slack ready to answer you. I'm not sure where Slack is on the screen, but click that and come and talk to us about this topic. We're very interested.

Douglas Squirrel: That's right. Thank you.