Selling Agile to the C-Suite to Get Buy-In

What do we have to do to make Agile tangible for our executives? How do we get our executives to have more confidence than fear in the changes we’re trying to make? There’s a reason they don’t move with us. They don’t understand it, they don’t trust it. And by not addressing the factors that are required to build trust, we’re making it more difficult for ourselves.

Are Executives Getting in the Way of Agile?

When I was seven years old, we moved from Huntsville, Alabama, where my dad was working on the Apollo missile systems. My dad is a rocket scientist, and we went to Georgia Tech, where they had installed a nuclear reactor. That nuclear reactor had a PDP-8 computer from a company called Digital. Have you ever heard of Digital? It’s an old, old company.

At seven years old, I learned how to program on a PDP-8. It was attached to the nuclear reactor beneath the university campus in downtown Atlanta. I thought it was unreasonable that Dr. Harmer and my dad wouldn’t let me load the tapes that contained the programs into the computer. I thought I could do it. I was writing programs and could load data. It was cool, using paper tapes instead of cards because they didn’t have digital tapes back then.

Looking back, I realize there was probably some rational thinking on their part for not allowing a seven-year-old to arbitrarily load programs into a computer attached to a nuclear reactor. Did that make sense to you all? At the time, it didn’t make sense to me, and I couldn’t explain to them why it was important.

Later on, when I was in the Marine Corps, I found the rules imposed by my superiors to be ridiculous. I questioned why there were so many controls and regulations. But it turns out, those rules were actually quite important. When you put a 19-year-old in challenging and chaotic circumstances with significant responsibility for people and equipment, rules are necessary.

Does that resonate with all of you? As I grew into a professional and thought my bosses were absurd, I realized I am completely unemployable. That’s why I’m part of a company I helped found. We learned over time that there is a reason behind all those seemingly ridiculous rules when you’re the boss of a company too.

One of the challenges we face is the perception that executives don’t care about Agile. There’s a belief that executives are the number one obstacle to successful Agile transformation in organizations.

Have you all heard that sentiment in the community? Managers are evil. They intentionally try to destroy our ability to perform. But is it possible that there may be reasonable and rational behaviors behind the actions of those executives, managers, and people who obstruct what we’re trying to do? Do you think we should consider that perspective? It’s an important thread for us to follow because I don’t think we always pay attention to it.

In fact, at conferences, we often talk about how managers are bad and executives are foolish people who want to derail the company. But that’s probably not true, right? So what can we agree on? Organizations need to move at market speeds sustainably, and that pace is getting faster and faster. We agree with that, don’t we?

Old ways of working won’t solve it, and simply implementing practices like Scrum, DevOps, FinOps, or ProOps are not sufficient to create the organizations we need for the changes we must make. We need executives to buy into doing things they might not be comfortable with. Alright, with that in mind, let’s consider that executives are not intentionally trying to make you fail at your job. Do you believe that? Or does it feel that way? It varies, right? It’s a sliding scale.

Now, let’s explore why executives may not participate in our transformations or why they obstruct what we’re trying to do as we strive to build organizations differently. What experiences have you had with executives getting in your way, and what might be the reasons behind their resistance? Lack of understanding, too busy, concerns about cost, fear – these are all valid considerations. We need to speak their language, understand their different experiences, and address their concerns. Our goals and their goals may not be aligned.

So, who is responsible for closing that gap? Is it their responsibility to come to us, or should we participate and try to move them in the right direction? It’s a shared responsibility, don’t you think? We cannot simply claim that managers are evil or executives are foolish. That won’t bring them closer to us. Instead, we need to consider how our actions, conferences, and the literature we read can either bring them closer or push them further away.

It’s up to us to take ownership. So, based on what we know, what doesn’t work at this point? Have any of you tried to get executives to follow your lead, but they haven’t? Can you share an example of something you’ve tried that didn’t work? Let’s identify what doesn’t work. Remember, our actions play a significant part in this process.

It’s crucial to get the executives to stop thinking that way. Yeah, we’ll have a chance to discuss it further towards the end. Now, let’s talk about why estimating in hours is absolutely critical for what they’re responsible for and what cannot be done without it. Yep, speaking in a high-level manner, this is their mindset at this point. You mean they care about achieving profitability?

Yeah, I like this one. Just trust the teams. Yeah, they should just trust us, give us everything we need, and have faith in us. That’s what the Agile Manifesto says, right? How about we let the teams decide how to work? No controls, no accountability. However, it doesn’t make me feel entirely comfortable, especially considering the Equifax data breach a couple of years ago.

Alright, you’ll get what you get when you get it, right? Shareholders don’t care, markets don’t care, customers don’t care. Just work as hard as you can, and I’ll be completely satisfied when it’s done, right? Here are some books you need to read, try this article, attend this conference, or go to this two-day course. We need all of you to embrace agility yourselves. Start doing stand-ups and think the way we do. We need you to change your behavior, right

But do any of these things actually help us solve the problems that executives present? They mostly assign blame. Yeah, that’s what’s interesting.

How to Get Executives to Buy into Agile

What do we have to do to make Agile tangible for executives? How can we instill more confidence than fear in the changes we’re trying to make? The reason they don’t move with us is that they don’t understand it, and they don’t trust it. Moreover, by not addressing the necessary elements for building trust, we’re making it even more challenging.

We need to have deep empathy for the issues and problems they are trying to solve. We must understand what matters to our managers, directors, and executives. We need to have a point of view and show them how following our model will help them achieve more of what they need. Let me ask, are you all familiar with the ladder of influence? It’s a useful tool that explains how people act, what they believe, and what experiences and data they have.

We can’t argue with them at the level of what they believe. Saying “You’re wrong” or “No, I’m right” won’t resolve the disagreement. We need to delve deeper, understand their beliefs, and then present a reframed perspective of what might be possible if we try something different.

So we need to take their beliefs into consideration. If we don’t start with what they believe, we won’t make progress. Once we have reframed their point of view, we must create a high level of safety for them to engage in conversations about what we might try. We need to work our way up a path.

Now, I’m going to discuss four elements that I believe are crucial in that conversation to gain permission to try something and how we can earn the opportunity to attempt something more significant. It’s not a one-time switch; it’s a gradual process. I’ll provide you with valuable insights if you stay tuned.

Executives aren’t solely focused on delivering software to customers. They deal with numerous complex problems that often conflict with one another. Regulatory compliance can clash with speed, and having strategy goals and budgets that we can communicate to the markets and achieve may conflict with the need for continuous learning and adaptation.

Let me share an example. I had a client who used to say that their clients start growing in March, but they start selling in July, and the contracts begin in March. From the moment we start marketing, there is no optionality because people begin arranging financing, making purchases, clearing their fields, and preserving cash to prepare for the next season’s release. We can’t just say, “You’ll get it when you get it.” If we make a commitment, we need to fulfill it to make sense.

These problems are highly intricate. Our technologies often impede our ability to achieve our goals in infrastructure and operations. That’s why some people within your organizations may resist implementing DevOps. We haven’t created a safe environment for them to operate in. They have the responsibility to protect something that may directly conflict with what we’re trying to accomplish. It’s important to consider the bigger systems and all the concerns that come into play when we’re looking at Agile, Scrum, or solving small problems. We shouldn’t overlook the broader view.

When facing these challenges from an executive, manager, or leader’s perspective, it’s crucial to understand all the issues they’re addressing and where conflicts may arise. It’s also important to recognize that, like us, most of these executives are striving for promotion, bonuses, and taking care of their families. If they put themselves at risk for us and we fail to deliver, their personal interests are jeopardized. So, it’s a big win for everyone when we succeed. However, if we naively approach the situation without first putting ourselves in their shoes and considering the complex view they’re dealing with, we won’t be able to gain their trust and move towards a safer environment.

I find it fascinating to consider the big picture and all the interconnected pieces as we engage in these conversations. So, the first step in thinking like they do is to genuinely care about what matters to them. Executives are responsible for three broad areas, although there may be more, but let’s focus on these three for now.

Executives have a primary responsibility to generate revenue for the company both now and in the future. They are accountable for fulfilling commitments and getting paid for what they were hired to do. Making money is of utmost importance for the success of the organization in the marketplace. Executives are focused on acquiring customers, growing market share, and increasing brand awareness. They care deeply about the overall health of the firm, although it may seem challenging at times.

However, we often fail to provide them with answers on how to resolve conflicting concerns. In fact, many of the transformations we propose seem to jeopardize the organization’s health because we haven’t demonstrated how we can transition to a new state while maintaining or even increasing safety. We need to be more thoughtful and not simply assume that we have all the right answers while disregarding their perspectives.

To bridge the gap, we must truly understand and care about what executives prioritize. If we can establish a connection between our efforts and incremental, iterative market sensing, and sustainable adaptation, we stand a chance. We need to demonstrate how our approach aligns with their goals and addresses their concerns. If we can’t achieve that, we won’t be able to have a meaningful conversation. It’s crucial to recognize that without this alignment, our efforts will be futile.

Demonstrating the Benefits of Agile to Executives

So, how can Agile help us accomplish the objectives on the right? Let’s consider predictability. When we walk in and claim that estimating is impossible and we can’t determine when we’ll deliver, it won’t resonate with an executive who is responsible for making promises to the market, customers, and their own family regarding bonuses. We must be able to deliver what we commit to, as scheduled. Incremental and iterative delivery, gathering frequent feedback, creating options, and adapting early are essential for predictably delivering large and complex projects.

Allow me to share a story from my experience. I once worked with a large agriculture company that aimed to implement a software solution for their tractors in March. However, our project started in July, and a couple of months into it, I had to break the news to the board that we couldn’t fulfill their market promise in the intended manner. Nonetheless, I presented them with three alternative options that would meet their expectations. I explained that the desired outcome was scientifically impossible to achieve before March due to the intricate technical requirements. I provided viable alternatives, but one of the board members named Lyle responded by spinning his glasses on the table and stating, “I knew this agile stuff wouldn’t work here.”

By understanding the concerns and priorities of executives, we can better align our Agile practices with their expectations, demonstrating our commitment to delivering results in a predictable and dependable manner.

We never have these types of problems with our traditional projects until they’re 80 or 90% of the way done. So following my advice of not condescendingly scoffing at him and laughing so I could actually encourage his engagement moving forward, I said, I think we’re in a better place than right. And he thought about it for a minute. In fact, we moved forward.

He actually laughed about it later. He felt stupid saying it, but it was actually what popped into his head in the moment. Right, Right. I knew early that we were going to fail. We had driven down risk early. We had done it the way that we thought it was possible would fail. And I gave him some options. Now, who wouldn’t rather have that in their pocket?

Then going dark for nine months and coming back a week before it’s supposed to ship, we have a customer. I just flew back from Brussels Monday. I’m not even sure what day it is was today. Tuesday. I flew back Sunday from Brussels and one of the challenges they had, what they had a product that was supposed to launch and they found out two days before the launch $30 million of market branding in place that it’s a six-month delay.

Do you think that was knowable a little bit earlier on? Some optionality could have been created around it? Yeah, right. But because the way they’re running their stuff, they didn’t know. So predictability is critically important. Quality is critically important. We get better quality out of Agile because we test it more often, We do it more frequently. We understand the math and the science of smaller batch validation.

Is that a giant last minute validation? It kind of goes to the options and predictability side of it. So we get better quality out of Agile when we do it well than we do when we don’t. But if we go in and we try to sell automated testing and test driven development and pair programing and DevOps and test data automation, all those sort of things, those aren’t interesting to an executive, but improving my quality so I can make more money or be more successful in a market, have options in performing or increasing the health of my product, we can connect it there.

So these are things that I can create. This is a way more compelling story from an executive standpoint in every regard or from a management standpoint. If you try to get somebody promoted, you can go have these conversations and we can deliver on it. It’s a way more compelling conversation. Then tell them they need to have small teams or care about each other more, or all the Kumbaya stuff, which is critically important and matters.

I just went to systems of systems of compassion, totally agree with the concept on the content, totally agree that we have to design organizations to take care of our people. Right? But when we’re actually going and setting our teams up to fail, we’re not doing that, are we? We’re not building systems that executives don’t trust. They’re not going to be built systems of compassion to understand the systems of domination sort of model, right?

These things are all connected. So we have to get people to believe what matters. But at the end of the day, these things matter. So care about what they care about.

Speaking the Language of Business (Metrics, OKRs, and KPIs)

Speak their language. What is the language of business? Money. Money. It’s actually interesting. You know, 50 years ago. Oh, no. And some people are saying the language of business is the customer’s language, which I think is cool.

And it’s been it’s probably true and probably accurate, but it’s not what gets moves in most organizations. But I think it still matters. So I’m going to say down here, the language of the customer and market success is still critically important. But if if you do that, you don’t make money, you’re not going to move the organization. So these two things have to be connected as well, right?

So if we can do Agile and we can deliver more frequent to our customers and deliver more of what our customers want and less of what they don’t and have the ability to respond to market changes, they’re coming. We can increase the revenue for the firm. We have the will to make that connection end to end. So speak the language of the business.

We can do that through strategic objectives and OKRs and KPIs and things like that. How many of you all are doing like, okay, our work? Oh, fewer than I thought. It’s interesting how many people are doing like KPIs and measuring KPIs in your organization at the same hands. Pretty cool. How many of you all don’t have a way of measuring the ability of the organization to improve, to do a better job of making money?

What if we walked in and said, Here, here’s what is possible, right? We start talking about how we can keep track of the stuff in the changes we’re making. We connect it to more revenue for you may not be a perfect connect the dots. Maybe, but I can show you a model that will work consistently. Pretty interesting when we talk about productivity work in the system.

So we got market success, work in the system. Here’s how much we can produce in a period of time. Here’s how much we can produce in the next period of time. The things that you’re asking me to do, well, either increase the number of things that I can produce in that period of time or reduce the number of things I can produce in a given period of time.

Like that’s a conversation that you can have with an executive that’s meaningful. They’ll look at it and they’ll go, I’d like to produce more things for the same number of dollars in the next period of time. Well, these things will help you get there. Then we can measure it, improve it, face up to our productivity, our efficiency numbers.

I can reduce your risk of missing your mark. I can reduce your risk of building something a customer doesn’t want. I can reduce your risk of missing a commitment to the market. I can create tremendous transparency and optionality in the system to you to deal with the uncertainty in the marketplace. That’s what we’re doing with Agile. How many of you all are talking this way to your executives are making these types of moves or have an opportunity to have these conversations?

How many of you don’t think you have an opportunity to have these conversations in your firm around this stuff? And we say enough opportunities? Well, I think it’s interesting. Yes. So you can you can do in a small circle, but you won’t be able to do it in a bigger circle. It needs to happen in an even bigger circle to get some of the changes that we need.

So the plan over time is to figure out where you can operate, where you can have these conversations, make this available, leverage your partners level, leverage the the director is an executives and vice presidents that you’re working with. Help them be successful. Give them the ammunition to tell the story bigger and bigger and then deliver on it every single time or most of the time.

CapEx efficiency. Transformation. We’re going to make the output, we’re going to make the system work better. We can have less rework in it or have less overhead in it. We’re going to get things to the market with fewer non-consumable features, non-performing assets being deployed, not going to build stuff. You have to throw away as much. I can actually increase your balance sheet value with this model.

We can elevate the competency of the people in your organization demonstrably through our transformation, and that elevation of competency will result in better throughput. Your ability to achieve better strategic objectives and eventually connect to more revenue if your strategy is correct, this path making sense. So talk about what the business cares about. None of this is about Agile or Scrum or stand-ups or product ownership or DevOps or that stuff.

Right now, we have to get there and you have to know in your mind how you’re producing this. But every slice of promise we make has to be wrapped up in a bit of a business case.

Creating Safety & Coming Up with a Credible Plan

Create safety for your executives or your vice presidents or the directors that you can influence. And we create we align on purpose as the first step of creating safety because we’re not going to get to do anything if they don’t feel safe about it.

The risk of not moving has to be greater than the risk of moving. The fear of being static has to be greater than the fear of trying something new. Right? So what do we do? First, we agree on a purpose. How are you going to be able to prove what you need to prove with this move we’re about to make?

How are we going to do this in a way and tell the story around it? So when you’re done with it, it looks like we were successful in one of those top two stories. When you do this thing where this result and you’re going to look smart because we did it so aligning on purpose, devise a credible plan that I support.

Credible, right. That’s good. That’s good. It felt wrong at one point. I’m sure it was scary. The delight wouldn’t type a word Iran. So she wrote I typed in wrong from theory, but devise a credible plan. I hear a lot of conversation about agile should be organic. It should be bottom-up. We don’t know what is going to happen.

It’s a chaotic system. It’s a complex system. You can’t plan or predict things that just isn’t really a viable approach if you’re trying to get your boss to step into it. So what you have to do is you have to scope the change you’re going to make down to something. You know, you can commit, get a purpose of what you want to solve for to a small enough slice so that you can do a credible plan, come up with an answer.

We think about 90 days, 220 days. It’s about the horizon. You get to prove something in an organization, a relatively small slice, and it can’t put the entire organization in jeopardy. So what’s a relatively small thing look like? What it look like to be successful there? And then what does it look like? How would I check in every two weeks to make sure we’re making progress in it?

You know what’s interesting to me about this approach? So a lot of the executives you’re talking to are product people or business people and product people. And business people get this when they’re trying to sell something into the market or get a customer to move. Right, or change the relation with a vendor or supply chain, they get that you don’t know the perfect end state.

You can have a conversation how you want to shape this and move with them to Here’s what we think we have to do, here’s what we think we’ll get there. Here’s the plan I’m going to put behind it. Here’s our going to measure it, keep track of it, incorporate feedback. We’re going to learn as we’re going. We’re going to be able to get feedback from you if you think we’re off track or feedback for you.

So a cadence of reviews of the moves that you’re making and whether you’re getting progress or not and what you’re learning and what they’re hearing, keeping your executives or whatever level you’re working with involved in the shift that you’re making, because it’s got to be their play, not just your play or have them participate in it. You’re getting their feedback, then connect actions to their success.

The things that we’re doing produce this result, and that result was we won the thing that said we would win and we get more influence. So this kind of talk about the influence trust cycle, if you’ve ever seen that got some talks on I thought about putting their bets a whole hour talk on its own. We’re sort of walking that trust cycle, influence cycle because you got to earn your way up the influence cycle and then help them see how they contribute to the success and engage them in the pride.

Pride progress towards the goals. This is how we’re getting our executives to buy into where we’re heading and what we’re doing. So there’s a process you can put in place. And here’s something you guys kind of know. It’s a backlog with an objective slice up and relatively small slices with some really clear acceptance criteria where the team has together a plan and delivers, it demonstrates the value, gets feedback from the stakeholders.

You understand this model. You don’t know that your organization is a product and that you’re going to manage your stakeholders same way that our product and executive people are managing customers. So think about it that way. You understand this process. It looks scary, but it’s what you do. Here’s what’s interesting to me, by the way, and I struggled with this for a while.

I think that if you don’t understand that Scrum is a change management for your customers model incremental delivery with lots of feedback cycles, Is it creating safety for your customers? Model that’s really hard to coach? Scrum Well, it’s really hard to get into an organization and get them to move. We’re just going through the mechanics of it, but if you deeply understand that it’s a social thing that we’re doing as much as a technology thing, that’s why Scrum works when it works well and it’s why it doesn’t when we don’t know that’s what we’re doing, right?

It’s not the mechanics of it. It’s the creating safety for all the people involved. The team has some safety. They can stay in a box, get it going to get your product quality, customer has safety. We’re not going to run down the road and disappear for nine months and come back with something they don’t know. We’re not spending money wildly and not knowing where it’s going.

Scrum and Agile creates a lot of safety for people. We’re going to do the same thing with our change approach going to executives to buy into the moves that we’re making. So kind of cool. Y’all are really good at this already and then demonstrate results. We said we were going to do it. We showed up, was got to tie together.

We connected together, paying attention all the time to what you’re measuring, improving so that your management of the change or making progress on the roadmap. Here’s the work that we’re producing. Here’s the options we said you would get. Here’s the data. We said you would show. Here’s some simulations or examples are producing the type of thing that we said we would.

So managing the change and the connecting to value and look, we move this, okay? R And look, the customer bought that and look, we reduce this cost and look we had the lower quality. So when you’re planning that plan upfront, when you’re doing that reliable plan, you got to be making a plan about something you know you can deliver within the scope you have agency for because the goal is to work your way up.

And what’s interesting is you won’t have agency upfront to do all the things you want to because you’re executives won’t give it to you, but you can’t go tell them to give it to you until you prove that they should trust you with it. So we’re building up trust over time by making this be real and actual to them.

We’re letting them understand the changes that we’re making. So the reason your executives won’t trust you is because we haven’t given them reason to trust us in this work, even though we may be exactly right, but not in their language, not in their experience. And even if you all this might be this might be a far-reach who have really been involved in any kind of Agile or Scrum or DevOps implementation that didn’t quite deliver the business value.

It was promised. Right? So, they signed it up to trust you off of off the backbone of that, right. So, we can establish a new way of working into it that gives them a lot of safety and feedback to follow it.

Executive Buy-In Action Plan for Agile

So, this is kind of the how do we do it? And then I have time for questions here at the end.

Well, how long do I go till 40, 40? After that I want to leave 10 minutes. So build a business case, involve the business, spend time talking to your executives, Understand what is strategically important your division, your department, your executives. Depending on the size of your organization and connect this and make it be something that the organization must do to increase their chance of succeeding and what strategically important to them to build a business case make it measurable.

The number of ScrumMasters established is irrelevant. The number of Scrum teams is irrelevant, like the number of defects shipped to customers. Relevant right? The time to value relevant anecdotal stories. This major thing came in. It didn’t break the whole world. We’re able to bring it in, gave you options and you made the right choice relevant. All right, so build a business case.

Know where you’re going to call your shot, build an outcomes based plan, an outcome based plan are measurable changes in behavior that you can do within 2 to 4 weeks that you observe in the organization and the way the system performs or the people are operating. Elevated competence, new behaviors, things that you can measure, you can do every two weeks because we have to go to the table.

If you’ll have anybody read Carter’s change management stuff. Yeah, Carter talked about that. This is interesting because there’s like a -unintelligible-  whatever sort of debate in the world around what change management is. This is organizational change is like a cadre game. Get a small batch, go prove it, earn trust to go move the next one.

All right. We have to wrap personal individual change inside of it as well. We have take care of people’s feelings that where awareness, desire, knowledge, ability, the reinforces kind of go together on the back end of both. But you’re playing at least two games in this model. So building outcomes-based plan every change management model world and also how we build software calls for smaller chunks with measurable progress.

So outcomes based plan, you can’t run them all concurrently. You got to prove something, set up a change to review progress and result, and engage your executives in a purposeful way. Give them create a hole in their heart for this new world. Go win with the things that get in the way and ask for their help to move them, show them the benefit of doing it.

And once you get something moved, go deliver the thing you said you would because you can burn down trust faster than you can earn it in most organizations, especially early on. Right. So don’t overreach, don’t get dogmatic, don’t get to ivory tower pie-in-the-sky scope, prove something because the game we’re playing is earning trust over time and getting our executives to understand it.

The real wins early on, if somebody goes, I fricking get why we have these teams stable now. Like it never made sense to me before, but I’ve got that one show that’s like a real win for us in the change right? So all the things you all talked about at the beginning, executives don’t get it. You know, trust us.

They’re afraid in this model will burn in all those things down a little bit at a time. Not all at once. We’re very purposely paying attention to all the fears and concerns and resistance and obstacles. And our plan of these outcomes is not just to get a change in behavior in the organization, it’s to get people to believe it differently.

Like that’s the game we play and has no to do with Agile, except it has everything with Agile because it’s exactly what you’re doing with your product when you’re trying to move into a new market or new place in your organization. It’s the same game transparently demonstrate progress and refine the plan to ensure we deliver on the business case.

I can’t get this done and by March not going to happen. Let me know what you’ve got now that you never had before. I’ve got three options. I know it’s going to go sideways. I know exactly what trade-offs we have to make to make it work. What do you choose to do? Because I’m not going make the call.

It isn’t appropriate for me to make that strategic call at this point. All right. That’s your call. So you bring them into it. Let them make the shift that creates ownership and shifts ownership to your executives and your directors and your managers and makes it very tangible and real for form. Was that worthwhile? I got 10 minutes for questions and answers.

When are you guys going to make this real tangible? An offer to softer, actionable? Yeah. Let’s let’s, let’s take some questions to make it real actionable if you want the slides here. All right. I was just putting my hands up for a call. If you want the slides, they’re here. You can download them. A lot of the stuff is on our on our blog side of him to go to the blog site.

If you want to get a newsletter from now on, when you accept the thing, click on little boxes. Please send me stuff wherever. If you don’t, that’s cool. So get the slides. But this is a this is to me, what’s really interesting is the game that we’re playing now is an organizational transformation, organizational change game. The game that we’re playing now is is not just an agile game or tactical skills game or competence in the craft game.

All those things are critical. You can’t show up and not do what you say you’re going to do, but it’s insufficient If we can’t get the organization behind us to move, we’re going to continue to get boxed in. And then what’s interesting is when you don’t get to support that you didn’t ask for in an effective way and your initiative fails, whose fault is it exactly?

It’s not the executive’s fault. You didn’t ask them an appropriate way and didn’t buy them in and didn’t have them owning it. We end up carrying the weight for two, right? So this is a whole flipping of the game.

The rest of the video is a Q&A portion with the audience…