Evan Leybourn - Business agility and the Theory of Agile Constraints

Jen Frahm:

Welcome to A Conversation of Change with Dr. Jen Frahm, where we talk all things leadership, change and transformation. And welcome everybody, back to another Conversation of Change, with Dr. Jen Frahm.

Hello, everybody. It's Dr. Jen Frahm here with the latest Conversations of Change. I thought as this is actually the first Conversations of Change for 2020, I thought what would be a really, really good topic to pick up on this year is the topic of business agility and the implications for leadership. The hype and the buzzword bingo around business agility is not going away, and for that reason, I thought there was nobody better than we could speak to than Evan Leybourn, founder of the Business Agility Institute.Now, I've known Evan for a couple of years now and when I first got introduced to the Business Agility Institute, I was pretty blown away in terms of the content and the value and the integrity of the research that's on it. It has been a mainstay in all of my client engagements since. So, I'm really delighted to introduce you to Evan. Evan, welcome to Conversations of Change.

Evan Leybourn: Thank you, Jen. It's an absolute pleasure to be here and I always enjoy our conversations, whether they're recorded or not. So much fun. And I have to say that the respect is mutual. I've always loved the work that you do. Your book, Conversations of Change is, like you say, it's a mainstay, it's a go-to. I shared it with a good friend recently who was working with a government department and she was having those same challenges. So, I'm looking forward to the conversation.

Jen Frahm: Fantastic. Thank you so much. Evan, you've got an interesting backstory. For the benefits of the listeners, could you share how you came to be the founder of the Business Agility Institute?

On the Business Agility Institute 

 Evan Leybourn: So, Business Agility is something I've been doing for a little over 10 years now. It really started almost by accident. There's a concept called the Peter Principle, which is where you get promoted to your level of incompetence. I'd sort of reached that point. I'd run a startup, I'd moved into the public service, and in the public service I became a director and I was suddenly in charge of a $35 million budget, a section.The skillsets required, from running a team, from running a project, whether they're agile or not, and it was agile at the time, vs. running a business or running a division are completely different, and I was not very good at that. Luckily, I have enough introspection to know what I'm good at. So, when I realized that wasn't the case, I started to look at why. I realized that this thing is coordination, getting people to cooperate, getting outcomes achieved. These were the same challenges that I'd had as a developer, as a project manager, the same challenges I'd solved using agile.At the time, I had this idea that maybe agile will help me be a better manager, and it did. Then over the years, I think, at the beginning it was like agile business, which I will say was a mistake. It was better than what I was doing. But a couple years on, I learned more and what was agile business became business agility. I then spent the next 10 years working with organizations around the world as a consultant, as a trainer on everything from HR to finance strategy to how organizations are designed and structured.That led me to the institute which, in 2017, I ran the first Business Agility Conference. This actually predates ... So, people think the conference and the institute's one and the same, but the conference actually came first because what happened was I was getting very frustrated with the ... I know a lot of your listeners are agilists and agile coaches and so forth and they may not like what I'm about to say, but the agile community is very insular. It's inward-looking. Right? There's a bit of an echo chamber.So, I would go to these agile conferences and I'd talk about business agility and they'd go, "Yes, this is fantastic." But they would do nothing about it. They either have no ability to do anything or no interest. So, I realized I was talking to the wrong people or I was talking to this echo chamber and it just bounced around inside. So, a friend of mine, a Canadian coach, we were sitting in India, because this is a global world, it's global. We're sitting in India and she was talking and we were having this conversation about how frustrating these conferences were. She challenged me to start a business agility conference, which I did.I can be arrogant, and at the time, very arrogantly I assumed that I would know 80% of the attendees. I was like, "Evan, I've got my finger on the pulse of business agility around the world." If you can probably guess from the sarcastic tone, that wasn't the case. I think in the end, I knew maybe 20%, maybe 30. What I realized was that there was this massive community out there that needed a place to call home.They were coming out of the agile community, they were coming out of the business communities and the HR communities and the change management communities. But none of them belonged to those communities directly. They all pushed outwards. So, when we realized that this sort of metacommunity was there and that it had no home, we made the decision that, yeah, let's create a home for it. That's where the institute was born. That's where the institute was born.

Jen Frahm: Fantastic. I think one of the strengths and also potentially one of the weaknesses of the website with the Business Agility Institute is the volume of content that it has on it. So, I'm kind of curious, what's your advice to someone, a leader who is just getting into the space of business agility? They've had the call from their organization that they have to be more agile. They've Googled and they've found you. How should they go forward? What's the path of bringing themselves up to speed?

Evan Leybourn: That's a powerful question and I'm going to answer a slightly different question to begin with because I think if you're just getting started, coming to our website's probably the wrong place to start. The right place to start is a little bit inwards and look at why you want to be an agile organization. If you're becoming agile because keeping up with the Joneses or keeping up with Jones Inc. because we're talking corporate here, or are you trying to survive because your competitors are outcompeting you, they're releasing products faster, they're serving their customers better?Or do you have issues within engagement, employee engagement? Do you have attrition problems? Or are you going perfectly fine and you just want to look at ways that you can be better in the future vs. change who you are today? There's a thousand different reasons to start this journey. Some are better reasons than other. I honestly say keeping up with Jones Inc. is probably not a good reason, but it's a reason nonetheless. But once you know why you are starting this journey, that is definitely the first step.What we published, one of the first research publications that we came out with was what we called the Domains of Business Agility. This is a, I call it the Don't Forget model because it's not a framework. It won't tell you how to do business agility. There is no framework for business agility. It's impossible. But this is a model that will explain what it is that you need to look at, what you need to focus on, those areas you can't forget, because for those of you, for the listeners who are running transformations right now, I guarantee they've forgotten something.They're probably transforming processes. Everyone transforms processes. That's the easy part. Maybe you're doing some restructure, some structural agility, but are you changing how you measure people? OKRs or KPIs? Are you changing how leaders, how managers operate? How do they delegate? Are you changing mindsets of people? Are you inculcating a growth mindset? Are you giving people a sense of ownership and accountability in their work? Have you changed the board of directors? Have you changed your contracts with your suppliers and your distributors and your vendors? If the answer is no to some of these, then you've forgotten something. This is an area that will constrain your agility. So, check out the domains.

Agility outside of technology

 Jen Frahm: Yeah, if I could just interrupt on that one, I think that's been one of the really, the strongest insights I've got from listening to you speak at other events is the notion that you're only as agile as your slowest or non-agile division. I know a lot of the work that Lena and I have gotten out of the Agile Change Leadership Institute has been how to translate agile into domains or to parts of the business that are not tech. How to translate tech-speak. So, marketing and HR and stuff like that. Do you get a sense that we are currently weighting our activity in one particular area over another? Is there a standout area that if we shifted our lens to, we'd be getting better results?

Evan Leybourn: Okay. So, there's a couple of things to unpack in what you just asked me. So, so I'm going to give you two answers. So, the first is the statement about you're only as agile as your least agile division. For your listeners, this might be a little bit familiar because it's, with apologies to Eli Goldratt, is drawn out of the Theory of Constraints. Theory of constraints comes out of manufacturing, lean manufacturing. You have a production line. The production line is building cars. You have a bunch of bits at one end and a car at the other, and you can only build cars as fast as the slowest part on that production line. If that's installing the engine, it doesn't matter how much you transform the door team. Right? Your cars are only going to roll off as fast as the engine team. So, you focus on the engine team, you get them better. But theory of constraints has ... I have a stutter. I can't say that word. Corollary.

Jen Frahm: I was going to say I don't, and I'd still struggle with that word.

Evan Leybourn: Which is, there is always a constraint. So, you transform the engine team and now the door team might be the constraint. It's not a bad thing. It just is. There is always a constraint. So, with apologies to Eli Goldratt, Evan's theory of agile constraints, there's always, you're only as agile as your least agile division. Now, let's take Agile, capital A, Scrum, Kanban, SAFe, all those wonderful, wonderful things that work so well in technology. The problem with agile is that we do it in technology.So, 30 years ago, software teams were the constraint to agility in our organization. It would take us years to bring a product to market, a technology product to market. With the growing digitalization of the world, that was important. The faster we could bring those digital technology products to market, the faster we could, well, thrive, sell. Now, I remember being a developer back then and every two weeks we were using Scrum. This is maybe back 2003. We were using Scrum, but where was our work going?Our work was then going into staging. It couldn't go to production because we needed a release window. So, we as a community invent dev ops, continuous integration, all those wonderful technology things. What does that let us do? That let us now deploy every second if we wanted to. I think Amazon's statistic is they deploy a change to production every 11.7 seconds or something. Now, there's always a constraint. So, if back then, the constraint was operations and we've solved the operations constraint, here's the constraint today?This is sort of part two of your question and that is in our experience, those organizations that are running these agile transformations are investing in the transformation in the wrong place because it doesn't matter if you can like create change every two weeks using Scrum or whatever else. It doesn't matter if you can deploy every 11 seconds because we have an 18 month budget process, we have a three month recruitment process, we have audit governance compliance gates every two months to check how is progress going? Every single one of these is the, well, one of these, I should say, is the constraint to the system. It's no longer technology.So, all those agile coaches that are out there are transforming and supporting the wrong part of the business. It's what is downstream or upstream from the work that we're doing. What is supporting it that needs to be agile? Now, the research that we've done, I said finance, HR, governance. Right? PMO, governance compliance depends on the organization. Now, that's generic. Let me be specific. The research that we have done in the institute says that the number one predictor of transformation success is transforming finance, specifically funding models.

Jen Frahm: Interesting.

Evan Leybourn: How do you fund work? Organizations that transform towards adaptive funding, continuous funding, rolling budgets, whatever you want to use, however you want to call it, are an order of magnitude more successful than those that either don't or haven't done it yet.

Agility and governance 

 Jen Frahm: That is really interesting and for me, it then raises that ecosystem of, well, if you're changing the funding, then you do need to change your board or you need to change your shareholders.

Evan Leybourn: One of the interesting things is there's organizations out there that are literally doing that.

Jen Frahm: I was just going to say, are there people that we can look at that are best practice in this regard?

Evan Leybourn: Not many, and I'll be honest. So, one of the domains that we have is called the board. It is our weakest domain in terms of the material that we have, but only because so few companies are doing this. There are a few and they tend to be on the smaller side, to be fair. But we're seeing organizations out there where ... Actually, let me take a step back. There are two big challenges with the board. Number one is they are the furthest from the customer. Okay? Number two, you get what you measure.So, if the board only cares about its financial measures, if that's what they see as their fiduciary responsibility, then that's the only behavior that the organization is going to have. So, what we're seeing is in the first case, we're seeing organizations send board members down to help desks, down to customer service for a day. So, all new board members have to go sit on the help desk for a day, listen to the problems of the customers, understand what the marketplace truly looks like so they get that empathy for, I suppose, the people you're in business for.In the second case, the measures, we're seeing organizations start to actually care about nonfinancial metrics. I'll be honest, every organization has a customer satisfaction score. But who gets fired if they don't meet their customer satisfaction score? No one. Who gets fired if they don't make their financial numbers? Well, half the sales team probably. So, for the numbers that matter, the board is very clear. You may give us customer satisfaction, but that's not the one that matters.So, what we're seeing now is organizations actually start to put the same due diligence around nonfinancial metrics, whether it's about customer satisfaction, whether it's about employee engagement, whether it's around some of the third industries or Industry 4.0 elements, innovation. There's a whole bunch of different metrics that organizations are starting to bring in and which ones depend on the organization. But we are seeing it happen, not fast enough for my liking, but it is starting to happen around the world.

Jen Frahm: For the listeners' benefit, I'll link in the notes after this, there's been two previous podcasts which you can go back and listen to, which will give you examples of this. So, the interview with Donna Hardman on the role of the board member in transformation. She talks about her experiences on buddy jacking in call centres and how she introduces that to board processes.That's her firm belief that all board members should be doing it. Then you'll also be interested in the interview with Adam Salzer of the Australian Turnaround and Transformation Association on the research they did on transformational boards and what they measure. So, we can further extend what Evan's just said then with some of the previous episodes. Evan, I want to bring up-

Evan Leybourn: One thing...

Jen Frahm: Yep. Go for it.

Evan Leybourn: I’d like to say, very quickly. Depending on when you're listening to this podcast, we have our global conference in New York. That's on March 11 and 12. So, for some people, that's in the future. In which case, please come along. For some people, that's in the past. In which case, check our website. One of our speakers is Sandra Davey, who is the chairperson of Choice here in Australia. She's coming over to New York to share her story about building an agile board.

Jen Frahm: Fantastic. That sounds great. Now, can I just revisit, there were two things that came up in what you were talking about before, and again, cued us on the explanation of the theory of constraints. So, I've often said your greatest gift is the ability to explain complex things very simply. I know I've had several people talk to me about theory of constraints, but it's been a lot more complex than what you just said. So, well done.But picking up on what you said before, so in the last four months, five months, so again, Lena Ross and I in the Agile Change Leadership Institute have been hosting breakfasts with executives with Momentum Search and Selection. They're basically a dialogue based breakfast with people from different organizations, all in executive, all C-suite. It's always on the topic of the challenges of change and transformation. Obviously, that's within an agile context.What's been really interesting is that there are two clear over the ... We've had 45 people through the breakfasts. There are two clear topics that come up time and time again. One is the struggle with governance and the other is the struggle with business adoption. When we talk about business adoption, we're talking about “How do I get my senior peers on board with this, my other execs with this working in an agile space?” But it also touches on what I call The inconvenient truth of agile, which is that you still need change management because, and you described it so beautifully before in terms of you can be releasing on a daily perspective.But if those people catching those changes are call center people or operations outside of technology and you haven't had sufficient management of those changes, facilitation of those changes, whatever language we want to use around that, they're in a hell of a lot of pain in the organization. Nowhere that I've seen within big A Agile addresses that big A Agile privileges the customer, doesn't privilege the employee. So, at the risk of leading the witness, I'm kind of curious on, let's just start with your views on the role of change management in agile agility.

Agile and Change Management 

 Evan Leybourn: So, we've had this conversation before. So, you do know what I'm going to say.

Jen Frahm: Yes.

Evan Leybourn: Yes. Absolutely. The role, change management, the skill is becoming more and more important. Change manager, the role, some questions about whether that role or what the future of that role is going to look like, because I think it's going to change more broadly...

Jen Frahm: It already has.

Evan Leybourn: ... as a skill. It is a skill that more and more people need to have. As change becomes the de facto state, then the ability to communicate that change becomes necessary. But that communication, the change, the change management becomes a continuous activity. Gone are the communications plans. I used to be a project manager, so I've done all those big comms plans and everything else. When we finish the project, we're going to start rolling out and communicating the changes. That's gone. Change management ironically has changed.But it is now continuous, right? It is “We're releasing change continuously”. We need to have systems and mechanisms to make that clear to people, to help people support them through a continuous rolling improvements to whether it's a system, whether it's a process, whether it's a culture. It doesn't really matter what is changing. It is changing now continuously. Change manager, on the other hand, is a little bit different because change is now ... No. Because many changes are continuous, not all. Then that specific function of someone who is going to sit in a project and write those plans, that is no longer necessary.So, a change manager is become someone who now handles communications across the organization. It's more ad hoc, it's a lot more responsive, and so the role will have to change and the role may be subsumed into other roles. All right? So, project managers or comm specialists or Scrum masters or product owners need to take on change management responsibilities, maybe instead of having a dedicated change manager. That's not to say that change managers will go away. There will always be that necessity. Even if change is continuous, there are still large scale changes that do occur quite broadly and across quite a lot of industries and quite a lot of projects.But even there, how they do it needs to be a lot more responsive, needs to be a lot more organic and continuous. So, even in traditional spaces, the role of a change manager will continue to change. I've used the word change way too many times here...

Jen Frahm: Well, at least you avoided transformation.

Evan Leybourn: I hate the word transformation. I try and use the word ‘journey’ as much as possible.

Jen Frahm: How about, transmogrify?

Evan Leybourn: But a transformation is like a caterpillar transforming into a butterfly. It's state A to state B. It assumes that there are known states. The problem with most transformations is that there is no state B. It is this amorphous future that is better than today. So, rather than think of it as a butterfly, let's start thinking of it as a journey and let's see what side streets we go down along the way. Yeah.

Approval based v audit based governance 

 Jen Frahm: So, picking up on the other pain point, which is the notion of governance, what's ... I seem to recall that you did have an article  which again, had a delightful simplification around the world of governance. Can you share your thoughts on governance in business agility?

Evan Leybourn: Absolutely. So, I'm a fan of governance. I think governance is very important and I like it. My first book was actually almost called Agile Corporate Governance. I'm bad at names, to be fair. My publisher was very clear. It's like, "We love the book, hate the title, please change the name." So, I did.

Jen Frahm: What did you change it to?

Evan Leybourn: Oh. Directing the Agile Organization.

Jen Frahm: Okay. Beautiful.

Evan Leybourn: Much better. To be fair, I didn't come up with the name. I went to social media. It's like, "Hey, what should I call my book?" That was the best one that someone came up with. It's like, "I'm stealing that. Thank you very much." Now, so governance, saying that I'm a fan of governance, there is another side to governance that people often forget, and that is risk. All right? So, governance and risk go hand in hand. The problem is most organizations don't understand risk or they don't understand how much risk they're willing to accept. Their risk appetite is the formal term.So, if you don't know what your risk appetite is, if you don't how much risk is enough or too much perhaps is a better way of saying it, then you are going to over-govern. So, what happens is very simplistically, I describe two different kinds of governance. Approval based governance and audit based governance. Approval based governance is “Stop until I tell you to continue”. Audit base governance is “Continue until I tell you to stop”. Now, if a piece of work, a process is within your risk appetite, then you do not want approval based governance.You just want them to continue because the likelihood and the consequence of that risk is acceptable. Of course, acceptable differs in different organizations. If I'm a hospital, death is an acceptable risk. It is literally a risk doctors take every day. Right? If I'm a software company, death is not an acceptable risk and not one I'm willing to take. So, it will differ according to context. But at certain points, if it's something that I'm willing to accept, then keep going.Now, I'm not stupid. I am going to check, and I'm going to find fraud, I'm going to find mistakes. If it's fraud, then we will recover whatever's been lost as best we can and you're fired and possibly even charged. If it's a mistake, okay, thank you. Please don't do it again. Recognize you're doing your best. All right. Do you know what you did wrong? Great. Are we going to do it again? No. Let's not add more process. Let's not add more bureaucracy because one person made a mistake. The worst thing that you can do is say, "We're going to make sure this never happens again." That just leads to additional bureaucracy and additional governance that is unnecessary 99% of the time. So, every stop adds delay, adds bureaucracy, adds a level of pain to the employees and to the customers because you're not delivering what you've promised and your competitors who aren't as governed as you are, they're moving faster. Their products are getting out sooner. They're satisfying and delighting their customers sooner than you, and that doesn't end well for your organization.So, audit-based governance is what we want in most situations. However, there are exceptions and those exceptions are when the risk is too great. That, yes, please stop. Here is a gate. You cannot proceed until we have checked that certain things are in place. Then you can proceed. My recommendation to most organizations is to default to audit based governance. Unfortunately, most organizations default or approval based governance because it, to be honest, is easier. It's easier to have a steering committee check things than it is to actually put in place the effort to check a moving target, than it is to check to something that's stopped and is showing you its papers.

Jen Frahm: Excellent. I think that is a very, very good steer. I'm curious, after all the experience you've had with agile transformations, what surprises you about the work?

Evan Leybourn: It surprises me how hard it continues to be. It's the number of transformational failures and the challenges that organizations go through. We've been doing this for 20 years, more in many cases, and the idea that we're still struggling with the same problems. To be honest, it's because we're not struggling with agile. We're struggling with people, and people will always be people. I suppose, to be honest, it probably surprises me that that still surprises me. It surprises me that companies still forget that they're dealing with people and not just process.I wish it were easier sometimes I wish we could wave a magic wand and have people have that growth mindset, have that culture. But we don't want that. That's actually, even that wish I think is disingenuous for what we're trying to do because people shouldn't be imposed. We shouldn't impose agile on people. We shouldn't say thou shalt, thou must. What we should be doing is saying here's an interesting way of working that might be a little bit more better. It might help you, might give you more empowerment. Do you want it? In which case, here's everything you need to make it happen. So, yeah. That's what surprises me.

Jen Frahm: I think that's kind of the part two of my inconvenient truth of change management is that what we spoke of before was your big A Agile. This is the small A agile. It is a major, major chalk and cheese transformation. Where it struggles is how do you bring people on the journey for the exact reason that you're talking about. We don't want to impose.I think any good change practitioner worth their salt has recognized some time ago that top-down change is folly. We've long moved towards co-creation as part of our process and those kinds of things. But when I see agile transformations being designed, there is often scant regard to the change management of that, whether it be contemporary change management or any at all.

Evan Leybourn: So, you actually just said something that triggered a thought and you mentioned top-own and that top-down doesn't work. I completely agree with. I'm not arguing that.

Jen Frahm: Well, unless you're about to go broke in five days.

Evan Leybourn: True. Okay. Sorry. There is that. There are ... No. It still doesn't work. It might help things in the short term. It might get things moving and you might be able to steer the ship away from the iceberg, but the ship's still not going to be steering particularly well and you need a lot more than just top-down to miss all the icebergs that are ahead. So, it's still only a very short term approach. But one of the things that ... I gave a conference presentation a couple months ago and in it, I got this big glass vase, right?It was full of water. I just took it on the front of the stage and then I ignored it. Oh, sorry. I should explain, it was a big glass vase and there was about five teabags just sitting in it, and I ignored it for the entire talk. Right. I gave this talk about business agilities, about the domains. Here are the 13 domains. This is what business agility means. Dot, dot, dot, dot, dot. Any questions? One person, first question, "What's the vase for?" It's like, "Aha. I'm really glad you asked that question. What color is that?" It's like, "It's brown. It's tea."It's like "What color was it at the beginning?" It's like, "Well, it was water." "When did the water become tea?" Of course, can't answer that question because there is no point. There's a point when it's definitely water and there's a point when it's definitely tea. But the transition point, there isn't one. It's a spectrum. It's less tea to more tea. I use the same metaphor for change, for transformation, or journeys. All right? So, you want an agile culture. Then you don't put teabags at the top and expect the tea, for everything to become tea.You don't put it at the bottom and expect, so bottom-up and expect everything to become tea. You put a couple of teabags in the middle, stir it around, a bit of heat. All right? That's the thing, actually bit of heat, bit of emotion, that's how you get people to change. At some point, enough teabags, enough tea leaves, enough change agents, whatever you want to call them, and your organizational culture, at one point, it is culture A. At another point, it culture B. In between is just a spectrum of different cultures, different elements all mixing together. I find tea is a much, much better metaphor than top-down or bottom-up because both are, it's a false dichotomy, basically.

Jen Frahm: I love it. I love it. I need a cup of tea now. You primed me for that.

Evan Leybourn: True. I think I probably couldn't do that in America because they don't understand what tea is.

Jen Frahm: No. No, they don't. Oh, that wouldn't work at all. Oh. We'll have to come up with something else. You up for a bit of word association?

Evan Leybourn: Let's do it.

Jen Frahm: Okay. So, I'm going to hit you with five words, five qualities that I argue agile change leaders require. So, I'd love your view on them. The first one is curiosity.

Evan Leybourn: Necessary. Mandatory. If curiosity, and so there's a saying. Curiosity killed the cat. All right? But I was recently reading a link, like a Facebook post. I had no idea if this is true, Facebook being a wealth of-

Jen Frahm: Big on the truth.

Evan Leybourn: ... information and disinformation, but what I was reading, it's like the full quote is, "Curiosity killed the cat, but satisfaction brought it back." If that is truly the actual quote, then I really liked the quote because that is really what I believe, that it's whatever it is that you're doing in your life, you must have a sense of curiosity. How does this work? What happens with all the parts? Right?If there's a level of change in your organization, it only improves if someone is willing to unscrew the back and figure out how all the bolts, how it all fits together, and then try and put it back together. They might break it along the way, but you know what? You're going to build something different. That is going to be interesting in and of a certain right. So, curiosity is absolutely necessary for any change.

Jen Frahm: Beautiful. Okay. Second word, vulnerability.

Evan Leybourn: I can't say necessary as well, can I? Let me say leadership. Right? I think we've long since moved past the point where this false masculine leadership sort of culture ideal. I think we've passed those days. All right? So, when I think of a leader, I think of people who express their vulnerability, who express the challenges and their concerns, who bring their whole self to work, rather than hide behind this façade of perfection that is like that stereotypical 1980s manager.

Jen Frahm: Mm-hmm. Okay. Third word/quality is empathy.

Evan Leybourn: Success. That might be an odd association, but a while ago, I built out a, what I defined as the three characteristics of success, and it was empathy. hence the word, confidence, and competence. You need all three to be successful. If you have confidence and competence without empathy, you're arrogant. If you have empathy and confidence without competence, then you're a fraud. So, if you don't have all three working in conjunction, well, you can't be successful.

Jen Frahm: Excellent. Okay. Fourth word/quality is courage.

Evan Leybourn: Courage. Tough one, because I've already used mandatory. I keep wanting to saying this. Courage. Let me say “everyone”. Everyone needs courage. Partly, it is a responsibility of leadership in an organization, management in an organization to make an environment where courage is accepted, make an environment where it is, I don't want to say “safe to fail”, but maybe “safe to try”. Right?But the flip side of that is people have to have courage to try. You can't just make it safe to fail or you can't just have this open, engaging environment. You can't have accountability without ownership. You need both sides of the equation. So, courage is the other side of the equation to, well, safe to fail. Safe to try.

Jen Frahm: Okay. Last one is self-compassion.

Evan Leybourn: Rare. I'd also say leadership as well, but I've already said that, but I'll say it again. I think it's something that is necessary in many to bring your whole self to work. All right? You need to have a level of self-compassion. If you don't respect yourself, if you don't believe in yourself, then no one else will. So, think of it, as I mentioned, that triangle, confidence, competence, and empathy. Self-compassion aligns very closely to that confidence angle. I see, we do a lot of research in HR topics. One of the ones we recently did was on recruitments. We published a paper on hiring for culture, specifically hiring for culture add vs. hiring for culture fit. But one of the subtexts and one of the elements that we looked into was around how people portray themselves, how they see themselves in interviews and even in their resume. The amount of self compassion that they show, and I don't mean arrogance because you need to have empathy as well. You have to have compassion for others, not just for yourself. But those people who expressed self-compassion, who expressed respect for themselves were the ones who, in most cases, were successful. The people who hid that part of themselves were not. This is often why we have the gender imbalance because there are typically, we have a lot of challenges with people from minority backgrounds or women who don't portray their strengths, who don't have that level of self-compassion to say, "I am an amazing person and everyone should know I'm an amazing person." They're not brought up that way. It's like, save us from middle-aged, confident White men. That's what I say, speaking as a middle-aged, confident White man.

Jen Frahm: It made me think when you, and thank you, thank you for those, the word association and your thoughts on them, but it did make me think, at the risk of putting you on the therapist's chair, you started off the interview talking about your arrogance and I'm kind of curious, what's that interplay between your self-compassion and your arrogance? What does that look like when you show up with a client?

Evan Leybourn: Oh. I never have been asked that question before.

Jen Frahm: No?

Evan Leybourn: No, no, no. But it's fair. It's fair. So, I have to be very careful to take myself out of the equation when I'm not needed. So, for example, if I'm in a conversation, I have a bunch of mnemonics that run through my head that teach me how to be a good human being. That sounds really bad now that I say it out loud. But one of them is wait. W-A-I-T. “Why am I talking?” If I'm in a conversation, I always say, wait, wait, wait, I always try and answer myself.If I'm saying something that is constructive, meaningful, then I'm going to say something. But if I'm not, then if I just want to hear the sound of my own voice, then I'm going to shut up because that wait tells me, nope. The only reason I would talk now is to have my voice heard. This was something that I learned to help come as my whole self, but without imposing myself on a client or others in the conversation or whatever the context happens to be.

Jen Frahm: Yeah. I don't think that sounds bad at all. I think that sounds incredibly generous to our listeners that you've been prepared to share that. Thank you.Evan Leybourn: Of course. Thank you.

Jen Frahm: So, this has been a wonderful chat and you're incredibly generous to the community. What can the community give back to you? What do you want our listeners to know, do, say, go to?

Evan Leybourn: So, first of all, we [The Business Agility Institute] are a community organization. We are a research organization. So, our survival is based on you using our material. So, go to the library. We have hundreds of case studies. We publish a new research paper about once a month and these are deeply researched in conjunction with academic institutions. We try and articulate those wicked problems. So, if you have challenges in your journey, in your transformation, nothing that relates to agile, everything that relates to the business side of this, then come to us. Learn from what we've brought together, the experts who have contributed their wisdom, their stories to our library. If you would like to go further, we are volunteer-run. So, we're always needing volunteers, people who can contribute to research, people who can run local communities' chapters or meetups in your local city or join one of the ones if we have one. We have 33 meetups around the world at the moment. All right?Lastly, come and join one of our conferences. If you hear this before March, come and join us in New York. We have our flagship Business Agility Conference. In May, we have a conference in Vienna. This year, we'll have events in South Africa, Nigeria, Hong Kong, Brazil. So, all over the world, we have communities and events and we are here for you. So, I suppose my offer and my ask is one and the same, and that is we are your data source for all this information. So, please come and use us.

Jen Frahm: That's wonderful.

Evan Leybourn, thank you so much for joining us on this Conversations of Change.

Evan Leybourn: Thank you, Jen. Loved it.

Jen Frahm: You've been listening to A Conversation of Change with Dr. Jen Frahm. You can find many more resources on leading change at my website, drjenfrahm.com. I welcome feedback on what else you'd like to hear on the podcast.

Why not connect with me on Twitter, @jenfrahm, or LinkedIn.

Previous
Previous

Exploratory Leadership – the frontier work.

Next
Next

What qualities served you best?