023 Jeff Dalton––Being "Agile!"

There's a powerful and growing movement in technology industries called Agile, and this means continual incremental processes based on a highly responsive and collaborative workspace environment. Our guest on this episode is one of the leaders and pioneers in this movement, and in this episode of Walking the Walk, we'll talk about how we can all be Agile with the President and Founder of Broadsword Solutions, Jeff Dalton.

Welcome to Walking the Walk. The program for people who want to become better leaders and leaders who want to become better people. Start walking the walk with your host, renowned leadership speaker and author of The Sensei Leader, Jim Bouchard.

You know, the most powerful philosophy that the martial arts gave me in my life and had the most impact on my life and continues to is this one: perfection is not a destination, it's a never-ending process. You know, Jeff Dalton embodies this philosophy, and his innovations in agile processes seem to me to be one of the most powerful expressions of this, of this thought of this ideology. Jeff's the President and Certified Lead Appraiser at Broadsword Solutions and the author of Agile CMMI. We'll talk about what that means in a couple of minutes. That's Broadsword's leading methodology for incremental and iterative performance improvement, and much more. He's also the principal author of CMMI Institute's Guide to Scrum and CMMI. See, keep coming up with that one. Which means Improving Agile Performance with CMMI. And he's in high demand internationally as a keynote speaker. But you know, he's also one of the most genuine human-centric leaders that I've ever met, and I say this from firsthand experience. I've worked with Jeff and his remarkable team at Broadsword. They're people who achieve incredible results by expressing authentic compassion and a continual commitment to self-improvement, both as individuals and as an organization. So Jeff, since we last talked, I've done a bit of reading about agile, and I know you've got a real gift for making the complex stuff understandable. Can we start with just a little bit of an overview of Agile and a little bit of the differences between what Agile, Scrum, Extreme, and some of the other terms we run into?

Oh, sure. Thanks, Jim. I appreciate that great introduction.

You earned it. Don't worry about it.

I think what you're calling my gift for making things simple comes from the fact that my college degree was in music and not in computer science. There you go. There you go. And I actually, I'm not sure I know what I'm talking about.

But you were a jazz guy, so you can get complicated.

That is true, but it's a great subject, and I really appreciate you having me on. You know, the Agile software movement— and I call it a movement because it's the fastest-growing approach and methodology to developing systems and software that we've ever seen over the last, you know, 70 or 80 years that this technology has been with us— and the growth is truly astounding. You know, thousands and thousands of companies are embracing it or trying to embrace agility. And it's interesting because it's, it's a global movement, and, and it's not so much that agile is a global movement as much as self-organization is a global movement. We're starting to see this all over the world, and if you look at— we don't have visuals here, but, but there's a fantastic study that Gartner did last year about how people worldwide are just throwing off the the yoke of bureaucracy everywhere we look in government, in education, especially in politics, in technology, in, in just about every field. We're starting to see people really crying out for self-organization, for more autonomy and less oversight and less rigor around the process. And, and this is super interesting because in the software business, we've overprocessed ourselves over the years. We've gotten to the point where we have so much oversight and so much process and so many gates and so many artifacts that a lot of software engineers talk about their jobs being creators of documents, not writers of software.

Yeah, yeah.

This is certainly true in many big companies and some of the really large companies I work with. So this idea of self-organization has really taken hold and the Agile software movement is a symptom of that, not a cause. And we're starting to see, especially the younger people coming into the business, really focused on having control of their own environment and having control of their own destiny in a way that we've never seen before in the industry. So it's a really fascinating trend. Ironically, you can't have self-organization without strong leadership. And then it's something that is a new idea at all levels, though.

That's the— That's the key.

Right. So, you know, if you look at the majority of today's corporate leaders, I heard an expression the other day that in order to become a leader in corporate America, you have to learn how to climb a greasy pole and you have to learn how to stay there.

Amen. Yeah.

And that, the values and the lessons you learn by doing that are antithetical to the values and lessons of Agile and self-organization. Because like you said, you need to have leaders at all levels to have successful self-organization. And you need to have leaders at the top that understand that empowerment means truly giving people the, the infrastructure they need to self-organize and be successful. And that's hard for a leader to do.

So that requires a tremendous amount of trust, which is a theme we keep hitting on, right?

Yeah.

Yeah, and that's why I love talking to you about the subject, because I think you're really tuned into this, that the level of trust we see in the corporate sector is, you know, it's what we— there's a term for it in the Agile community. They call it the low-trust environment, and it's a real problem. We can't let people self-organize, self-subscribe to work, be responsible for their own destiny if we're going to have, you know, very powerful oversight and punitive measures are being used to control behavior, which is really common. In traditional software development, we have a function we call process quality, and this is something where somebody literally goes around with a clipboard, or a virtual clipboard these days, and, you know, asks pointed questions about what you accomplished and how you did it. And it's, it's turned into a policing function in most companies, and it's destructive to the basic values of self-organization and personal accountability.

I was just gonna say that at the At the same time, a lot of people that operate with that type of environment or culture are the ones that are most challenged about engagement, right? How do we get people engaged? Well, you know, certainly not by following them around with clipboards.

Right, that's exactly right. But here's the interesting part is more and more large companies who have this culture, this sort of what I call punitive culture, are asking, you know, why aren't we being more agile? Why aren't we adopting this agile framework, this self-organizing framework for our software development? Because they see the benefits of it in the industry. They see that that it produces higher quality, more rapid incremental delivery of solutions, and they see those benefits. So, you know, CEOs and CIOs, Chief Information Officers and so forth, are asking, why can't we be Agile, and I want you to be Agile. But they're not making the connection that they're the ones that are the impediment to Agility, not the people that are working for them.

So, you know, that's huge. That's true. And you have a beautiful graphic on your website, and I think this will help us understand this disconnect. You have the Mona Lisa, right? And you see incremental, and you see the, you see completed pieces being delivered throughout a process, right? As opposed to iterative, where you start from the top and you don't really see anything until and if, right, there's a successful completed project. And if I'm understanding it right, there's a huge percentage of these completed projects that never end up being implemented, right? Because for whatever reason along the line, there was a disconnect that wasn't detected because there weren't complete pieces delivered. Is that anywhere close?

Yeah, no, that's right. And so the reason agile methods have worked so well is because they emulate human behavior, emulate natural human behavior. You know, I always tell the story, as you know, I'm a pilot And, you know, one time I got a brand new GPS for my plane. And GPS is a pretty important item when you're in an airplane because, believe it or not, you can't really see anything when you're up there. And it's real easy to get lost. So I got this brand new GPS and I got a 500-page manual with it. Now, I have basically two approaches I could have taken. I could have read the entire manual.

Yeah.

Understood it all, right? Understood it all and then climbed in the plane and depended on the knowledge, quote unquote knowledge, that I gathered. To guide me in a high-risk, high-cost type of a situation, right, where I have the likelihood of getting lost and crashing and burning. Or I could read the chapter on what button do I press to find the nearest runway, which is really important when you're a pilot. And there is such a button on every GPS, believe it or not. For a plane, there's a button that says, whatever, you know, whatever happens, show me the nearest runway. And I want to read the chapter that tells me that. So I want to incrementally learn. And I learned incrementally and I went up and I flown— flew and I pressed the button and I found the nearest airport and I landed. Next I said, okay, I want to read the chapter about plotting waypoints so I can go from one airport to another. So I learned to do that. So human beings generally learn best incrementally and iteratively, and we generally do work best incrementally and iteratively. When I do a home project, I like to first plan it out and then I like to go get my tools organized and then I like to do a little piece and see how it works and I learn as I go. Traditional software development is the reverse of that. It's create this massive plan upfront, 900 pages long, and then pretend everything in the plan is real because—

Work to the plan exclusively. Right?

Without— Right. And you know, we've got this scenario in software development where we believe that the plan is real. You know, we believe that all of the resources will happen as planned, that the timing will happen as planned, the customers will agree as planned.

And of course, don't make the dragon laugh, tell them your plans for tomorrow, right? But isn't there a lot of ego involved? And when we're looking at from a leadership lens, is that part of the obstacle? You know, I created this plan. You're going to do this plan. I've invested in this plan, right? It cost me money.

Yeah, right. And that's what I mean by saying we actually believe it because we telegraph the contents of the plan to all levels of the organization and we tell them and we put our personal lives and careers on the line by, by saying, here's the date and here's the plan. And I only need to mention the Affordable Care Act to, to give you an example of what a disaster that can be when, if you remember that October 1st, 2010, that day that will live in infamy in the software in the software world where the largest software development project on the planet failed miserably for this very reason and it failed very publicly. Some people are saying a billion dollars was spent on the development and it failed miserably because somebody put a huge plan up front, somebody telegraphed all of the dates and the resources and politically they weren't able to step back when things went wrong and of course we all know what happened. Ironically, the savior of the ACA, of the healthcare.gov, was an agile organization.

Nice.

And came in and said, look, we need to take really small pieces and incrementally work through this and build it a little bit at a time. And every step of the way, we're going to check. And one way to think about agile, Jim, is every couple of weeks you go to the customer and you say, is this what you wanted? Oh, is this what you wanted? Is this what you wanted? Is this what you wanted? And keep asking that question over over again. And each time you learn, and each time you learn something new. And, you know, people— it's like music, you know, people don't know what they like until they see it.

But again, that requires strong and, dare I say, courageous leadership, right? Because to go to the customer and, you know, ask those types of questions, not positioning yourself as the person with all the answers today, right? I mean, that's a big step for a lot of people, no?

Yeah, and this is what I was getting at about it's, you know, you need strong leadership in self-organization, but it's not the kind of leadership you think. And the kind of leadership that's pervasive in corporations is low risk, low trust, not admitting to issues or problems or risks because you will appear weak. And so not having the courage, as you often say in your podcasts, Agile leadership is the opposite. It's transparent, it's collaborative, it's constantly questioning the direction and being willing to admit failure. As a matter of fact, there's an expression in agile leadership called fail fast and fail early. And so the notion is we are going to fail because we're human, and 70% of all technology projects end in failure. So the data even tells us. That we're going to probably fail. So let's plan for failure. Let's build that into the model so that as leaders, we're constantly admitting failure and we're constantly celebrating it by learning from it.

That is beautiful because, you know, so many studies have revealed that highly successful people in organizations fail at a high percentage because they're out there taking risks, right? And yet we still got these vestiges of this command-and-control leadership structure. That really, really rewards an absence of failure rather than the production of a great success.

And that's right. So the problem is not failure. The problem is— we were saying this, you know, in the pre-call— the problem is how you react to failure, right? Absolutely. Our culture has created a place where failure is a negative, and it isn't.

We fear it terribly. Our job's on the line if we fail.

And I've come to a place in my career, maybe it's my age, Jim, but I don't care anymore. I want to fail because I want to learn. But the key to successful agility is make the failures small enough to manage, right?

That sounds like a martial arts principle at its heart right there.

It really does. It really does. It's funny because, you know, of course everybody thinks they invented everything, right?

Well, I know because I read Lao Tzu and Confucius.

I know.

I know it's old stuff, right?

Yeah, but, you know, kids think they invented politics and, you know, kind of stuff.

Right.

The agile, you know, the leaders of the agile software movement believe they invented all of this. And I always say, hey, you know, go look at musicians, go look at martial arts, go look at Lao Tzu, go look at all that stuff because this stuff's been around. I mean, Shu-Ha-Ri, has been around since, you know, the beginning of time, and it's something that software people are talking about now as if they invented it.

It seems like there's actually a lot— in fact, you know, I know we have mutual respect for the ancient masters, but there's a lot of Socratic method in what you're talking about.

There sure is, yeah. So this notion of leadership here is sort of the next frontier because The younger developers and engineers, they're pretty tuned into self-organization because this is really their culture and what they really want out of the world. But when the corporate leaders at all levels say, "Hey, I want to be more agile. I want us to be more agile," but they don't really understand that that means they change. It actually means they change more than the team members change. So we're kind of focused on that. And so, you know, there's two things going on with that. This CMMI thing that you were mentioning at the beginning of the call, this is a— the Capability Maturity Model is a globally accepted framework for high performance in the software business or in the technology business in general. And we've combined that with this notion of agility and agile values into a single model. And we call that the Agile Performance Hierarchy. And what this is, is a model for helping leaders transform their organizations into the kinds of organizations you advocate, I think. You know, high trust, high courage, transparency, collaboration, and openness. You know, these things sound like warm and fuzzies to some people, but they're really, really foundational to success.

You know, I hate that people talk about it in warm and fuzzy, and it's an exact parallel in the martial arts world. Martial arts is divided into soft arts and hard arts generally. Hard arts, you know, the easy-to-see karate, boxing, punching, kicking, explosive. Soft arts dealing more with leverage, right, with borrowing, combining energies, getting people, you know, getting things to work in the same direction like aikido, tai chi. And the soft arts are actually exponentially more powerful, you know what I mean? And we're seeing the same thing in organizations when people— yes, when people denigrate the soft skills that we're talking about, they're really losing out. And the research is bombproof on this now, right? I mean, now we're quantifying what the benefits are of respect, trust, loyalty, these things— courage, compassion— and the huge expense, right, and cost if you ignore these things. So no, I don't, I don't like the idea that anybody talks about these things in terms of warm fuzzy. They are quantifiable. They're important. They're either costing you money or they're making you money, and you got to get on board with it, right? And I'm not the lollipops and puppy dogs guy, right? You know that.

I know that.

Yeah.

You're totally right. And so what we're trying to do is we're trying to build a traceability model from the behaviors that teams execute to the values and soft skills that leaders demonstrate. So in the Agile community, there's 9 core values which will sound very familiar to you. Things like collaboration, transparency, and fail fast, and those iterative and incremental experiences, and continuous learning and improvement. These are things that I'm sure the martial arts has their own version of. And what we're advocating is that for every behavior you as a leader would like to see, so for instance, if as a leader you want your teams to be more agile and more incremental, trace those uphill to the values and behaviors that you're projecting to your team. And really do an in-depth analysis of this. And what we encourage teams to do is literally write down what are the core values of your organization, and then trace a direct line to the behavior that you want to see your teams perform.

Right, right, right.

And what we find is in the software business, there's a defect called a type mismatch. And it's a technical thing, Jim, but it's when one type of data tries to communicate with another type of data, say a fraction tries to communicate with an alphabet, right? Like, they can't talk to each other, and they call that a type mismatch in software. We call it an organizational type mismatch for software companies when I have a value of, say, we want to have low risk and low cost. So that is in conflict with, say, an Agile ceremony that might be a high-risk ceremony, the high-risk short-term. So we're looking for looking for those mismatches from the organizational values to the behaviors that are being expected of the teams. And we're trying to align those because without alignment, you have friction there, and that causes all kinds of issues with the culture. So that, that's how we address it, is we map the behaviors that are desired by the teams to the values of the organization and make adjustments as necessary. But The hard part of all of this, all of these leaders, you're seeing it at GM and Lockheed Martin and IBM and all these big companies want to be adopting these Agile frameworks. The biggest impediment is that the organizational values conflict with Agility, and it's the leaders that have to change, not the team so much.

Well, that's fascinating because now we're hitting seeing exactly, you know, the parallel of our work there. Isn't it more— it's the mindset, right, of people that are in positions of authority. I know we make that distinction, position of authority and leadership, because to me, if someone is genuinely a leader, the more I'm learning about Agile from you, that is a quality of genuine leadership where the dictatorial process, it just doesn't fit. And what's interesting, and I wish I could remember where I got— this guy who did an interesting study. And the way he termed it is, as these organizations are scaling— and that's really what we're talking about— the bigger the organization gets, based on the command-and-control model that we still so often see, they tend to be more dictatorial or authoritarian and controlling as they get bigger. They think they need to. Really, the opposite is true. And this guy talked about it in The Return to the Farm. And you said it earlier. It's the way people work best naturally that we're starting to recognize again, right? So the bigger you get, you actually have to return, right, to this more human-centric, collaborative, agile process, right?

Yeah, I think you're right, and it reminds me of— I don't know if you're a Star Trek fan, Jim, but—

Original series. That's how much of a geek I am, right?

There's a Next Generation episode, and I wish I could remember it. I think it's called The Booby Trap, but Essentially, it's— they're trapped in a, in a, in a power vacuum of some kind, and they keep applying more and more power to get out of it. And of course, they learn, as you might guess, the more power they apply to getting out, the more powerful the trap gets. Right.

And they find that sounds like a Tai Chi thing right there. Yeah.

And the— and they finally, at the end, they realize if they just turn everything off, they can escape and float away, which is what happens. But it's kind of the same thing with leading Agile organizations is the more your hands are on, the worse it gets.

Yeah, there are times to punch back. You know, I don't want to discount that. There are times when we have to use the tactics of opposition, but those are few and far between. You know, I would talk about that, for instance, in defending values and principles. Sometimes we have to take a stand, but it's never efficient, and it's very often not as effective as others. Just sometimes we have to to do it at a certain point. But yes, absolutely right. Sometimes the best thing to do is turn off the power, relax, go with the flow, right?

Yeah, well, this is what I mean about changing leadership models. It's popular in the Agile movement to say that Agile teams don't need leaders and they're all self-organization. And that's a very popular notion. But I want to fine-tune that and say, look, We need leaders. We just need a different kind of leader. And the kind of leader we need is one that focuses on values and one that focuses on culture and one that provides an infrastructure. Because I like to say it's not magic. You don't get effective agility and self-organization magically. There's an infrastructure involved.

It requires discipline, doesn't it? And you know what you're hitting on too? It's fascinating because we have a lot of military leaders that we talk and network I work with too. And what you're describing, and a lot of people have a hard time accepting this at first, but the Marine Corps model of leadership sounds to me like an Agile leadership process, right?

Yeah, I was just talking to somebody about this yesterday. It was the CIO of a big company in DC I was interviewing, and, you know, he said, "Man, I just started working, doing work with the Army.", and I was amazed how agile and self-organizing they were. And yeah, that's, you know, that's the magic of the U.S. military. I mean, people always ask, you know, why is the U.S. military so successful? And the reason is, is they trust their people. They have to.

It's a matter of—

they have to.

If the head gets cut off, the next person has to step up.

Yeah, that's right. And, you know, you look at, you look at some of the other competing militaries in the world, you know, the Russian army or, or, or North Korea or some of these other ones, and they're very much You've used the term command and control a few times, and that's exactly what they are. And that's exactly what a lot of our corporate leadership is like. They're command and control. We have, you know, a lot of times we have a cult of personality leading a company. You take like a Bill Gates or somebody like that where, you know, it's a cult of personality. And, and I think leaders today need to really focus on building an infrastructure for self-organization where you can, you know, not just grant people the power they need to make their own decisions, but give them the infrastructure to really work with it so that you don't have to be there.

Now you're hitting it— empowering. But now here's the flip side, and I think this is what a lot of current leaders may see as an obstacle to accepting this, is isn't it also just as important— and we talk about this a lot in the idea that leadership and followership are not so much fixed positions, but they're roles that that we each play, and the best leaders know how to flip the switch, right? Right. But on the front line sometimes, and we're seeing this more, we've seen this a lot in workshops lately, where people are worried about this entitlement mentality, right? That people are coming in new without experience and they lack the deference and respect for, and I'm going to say it in the most positive terms, authority, right? People that have the experience, the wisdom, the knowledge to share. Instead of that young person coming and say, well, I know it all. Well, no, you don't. I mean, one of my friends in finance a few years ago asked me to define MBA, right? As I said, well, Master's of Business, something. Yeah, he said, no, no, might be acceptable. And he was talking about just that, that people come in, they've got the degree, they're young, they're cocky, they can— they know everything. So we also have to train leadership on the front lines in the idea that they sometimes have to understand that they have to be deferential, right, either to the supervisor to the person with more experience, so on and so forth, right? Is that something that this reconciles? Yeah, I think so.

I mean, I think this notion of a self-organizing infrastructure can help. I think I might have talked to you about Brian Robertson, who wrote a book called Holacracy a couple years back, and it's a, it's a, it's an in-depth self-organization infrastructure, and it's not something we use, but we use much. But one of the things it does is it provides a governance infrastructure at every level of the organization. And what— so you've got even, even the new people in the company are involved in governance in some way. And they have these governance bodies that exist sort of like pods throughout the organization. And people can make local decisions on their own based on, you know, a set of guidelines and rules that are governed by the organization. So the issue is not deference to supervisor as much as deference to the infrastructure. Nice. And so we try to, you know, we've said for years that, you know, don't blame the person, blame the process. That's a common expression in our business. And, you know, this is more like build the appropriate healthy infrastructure and then use that to interact with everybody instead of the individual. Now, you have an excellent point. That— and I suffer from this with my company sometimes— people don't always do what you expect them to do. Well, people are complicated, right? Yeah, right, exactly. Darn it, you know. But, and sometimes people let you down. And, you know, the question is, is how do you deal with that? So, in a traditional corporate setting, you know, if you are a senior manager and someone lets you down, you punish them. You know, maybe you try to coach them a little bit, but usually they're on the outs. You know, then fast— you've heard the expression career-limiting move. A CLM is— that expression is very common in the corporate environment. And, you know, a wise leader will, will look for opportunities to improve and coach people and, you know, be very deliberate about, about how to grow and help people learn and improve because the cost of replacing somebody is just torrentially high, right? And So yeah, it's going back to what you were saying earlier about it's counterintuitive, right? So, you know, I strive as a leader to be, you know, extremely patient and focused on improvement. And I often say to my people, you know, when they start getting into whose fault things are, I'm saying, I don't even want to know whose fault it was. What I want to know is how are we addressing the infrastructure to fix that problem, right?

There's a vast difference between fault and responsibility, and fault will seldom lead you to the solution. You know what I mean?

And we've implemented what we call a roles and accountabilities model here that we use the term accountabilities instead of responsibilities because we want to give people the authority to be able to self-subscribe to the accountability of their role. So we really struggled with how do you push this responsibility for decision-making down to the person doing the work. Because as a, as a CEO of my company, I found people were always coming to me with requests for decisions every day. And so I said, okay, here's what we're going to do. We're going to define every role in the organization, and we have dozens. And then we're going to define every accountability in every role that you have authority to determine on your own without asking permission. So for instance, as a tester of software, you have the following 10 or 12 accountabilities and you are entitled to make decisions on those things without asking anyone and you own it. And then we had people subscribe to their roles. So they basically said, I am, I am voluntarily taking on the role of, and then a person might have 8 or 10 roles. And this has worked out great for us because it really promotes this culture of self-organization and pushing that responsibility down to the people that are actually doing the work and letting them make the decisions. And we're implementing this with our clients. And it's just amazing how it changes the culture when, you know, A, you give them the authority to make the decisions, you literally cede the authority to them, and B, you let them self-subscribe to those roles and accountabilities themselves. So that they can feel ownership of it.

And that's powerful. You just tied into, you know, Dan Pink did this great body of research and isolated the top 3 motivators, right? Autonomy, mastery, and purpose. And right there, and what you just said, you tied heavily into autonomy and mastery. People want, right? They want the opportunity to learn how to improve themselves and increase their skills. That's self-satisfying. And the autonomy thing, that sense of control, right? Control that you— Yeah, no, that's perfect. Jeff, oh, go ahead.

Just real quick, I know we're running out of time, but this is just an example of what I mean by leaders are responsible for building an infrastructure that supports agility. And this is just one example of, you know, a leader can't just say go self-organize and be agile. You have to actually build an infrastructure and then manage the infrastructure. Right, right, absolutely.

Absolutely. And that requires commitment. Absolutely. So listen, how— and you know, I know you focus on, you know, the software industry and the tech industries. That's cool. This sounds like, you know, we know, we'll agree that this can apply to any organization. Yeah. Let's make sure people understand how to get in touch with you. And because I'd have to say, if you're interested in this at all, Jeff is the person to go to. That's it. So how do we find you?

So the best way to find us is to— well, two things. Our website, which is agile2018.org, is a place where we're doing quite a bit of research around this topic of agile leadership. And we are— and I apologize, I reversed that. It's 2018agile.org. 2018agile.org is a place where you can go sign up for a camp that we put on for Agile leaders. It's a place where we talk about Agile leadership and we feature other speakers and podcasts and those types of things. And this organization is doing research on this subject in the software business. So if you're looking for data on this or models or training, 2018, agile.org is the place to go. And of course, your broadsword-solutions.com, right? Right, so broadsword-solutions.com is our other venture, and that, that company is focused on performance improvement of software organizations. So the Agile organization is focused on data and giving out data about our research, and Broadsword Solutions is focused on actually helping companies implement performance improvements in the software business. Well, that's perfect, Jeff.

You know, I knew this was going to happen. We have to have you back often. So let's, let's get you back on again and we'll dig into this even more. Thanks so much for being a guest today. And thanks for, thanks for being really an example. You know, you're one of the perfect examples that we, we tend to trot out about what a Sensei Leader is all about. And we really appreciate that.

Well, I've learned an awful lot from you, Jim. So thanks for having me on.

I appreciate it 100%. All right.

Thanks for listening to Walking the Walk. Please share this episode. We encourage you to download and share the program with both experienced and aspiring leaders in your network. We also encourage you to suggest guests for future episodes. Complete information at walkingthewalkpodcast.com. Jim Bouchard is in high demand presenting keynotes and workshops for conference, corporate, and community community audiences all over the world. To book Jim for your next event, meeting, or retreat, visit thatblackbeltguy.com or call Alexandra Armstrong at 207-751-4317.