Unleashing Agile: Empowering Agile Teams for Managers

Empowering your teams isn’t about allowing them to make decisions in a vacuum and giving them free rein to do whatever they want. The days of providing a little guidance here, some methodology there, and letting the teams self-organize their way to success are behind us. As the world of business increases in complexity, it will take more than user stories, estimation, and OKRs to build a trustworthy system that management can delegate into.

But if managers want a trustworthy system, it’ll be up to them to create it. You see, the real work of a manager is to understand that each team is different, then find ways to continuously elevate the teams to meet their collective needs, all while creating the conditions for the teams to thrive. Join Dennis Stevens for this talk, where you’ll learn the secret to creating a high-trust environment where teams have what they need to live boldly, work fearlessly, and deliver the highest quality work for your customers while releasing maximum value into your business.

Video Transcript 

I think if you’re not getting what you want from your teams as a manager, you have failed to lead appropriately. You haven’t created the conditions to be able to delegate to that team.

(Muscial Interlude)

The Challenges of Empowring Agile Teams

I’m Dennis Stevens, Chief Methodologist at a company called LeadingAgile. The genesis for this talk is around the fact that we go into a lot of organizations, and we often hear that management won’t let us form these teams or that they don’t know how to empower teams. When you look at the literature that’s out there, I was reading an article recently about empowering teams, and the very first line in the step of the five steps for how to empower your teams was “manage your teams in an empowered way.” Like, what the heck does that even mean?

What does it mean to empower teams? I think there’s an interesting challenge in our industry, too, that the Agile community has been fighting for a long time to be allowed to be empowered. But we don’t understand what must be in place to empower teams. Why would I trust a team that can’t do what they say they’re going to do, right?

Why would I put my credibility and my job on the line as a leader in an organization and just give the team everything they need? “Just trust me, get stuff done.” There’s some sort of a bargain, some conditions we have to strike to make this a healthy relationship that makes sense. So, I think we don’t pay attention to that all the time.

What I’ve been doing is talking about this with clients and going to different places, sharing with people some of how I’ve been getting them to see both sides of the coin of what it takes to empower teams. I hope you walk out of here with a set of questions that you can shape for your own purposes, where you see it not working, to walk in and ask, “Why is this not working?” Because it’s probably not that the manager is deliberately trying to make everyone in the organization fail or trying to undermine the health of everybody. That’s not what’s happening, right? And the teams, they want to be given the rights to make decisions and do work the way they want to do it.

But what would have to be true for that relationship to work well, is that a good topic? And so that’s what it said on the piece of paper, so I assume you’d like the topic. The slides are going to be available if you go to three, three, seven, seven, seven and just text managers, you’ll get the slides.

I want to talk about. Here is the conversations that we have to navigate through with management to get them to empower our teams. How many people are in here who are managers and want to understand how to empower their teams? How many people are consultants or team members that feel like managers don’t know how to empower their teams? Yeah. So why is it important to empower teams?

Like why do we need to actually give teams empowerment? Why do we need to move decisions closer to the work surface? So that’s the topic. But I think I think it’s important we all know what just kind of Scrum, Agile, the whole world knows that if we have to escalate every decision, it just takes forever. And then the people making the decisions don’t have the nuanced craft.

Understanding the few in place to make the decisions they need to make. Right? So we want decisions to be made within empowered teams if we possibly can, so we can move at the speed that we need to. Everybody agree with that? Why is it hard to to empower teams? Like why is it necessary? What does it mean? Why is it hard?

We can talk about why it’s hard. And let me give you three strategies. Actually, for strategies to build systems to ensure the right attributes are in place to empower your teams as a as a group. I just a couple questions. Why is it hard for managers to empower teams they want control? Why do they want control? Fear, fear.

What are they afraid of losing? Oh, you think it’s a win? What do you think it’s all about winning failure so big, right? You think it’s about winning? Okay. Why do they want to win? Ego. Fascinating. That’s an interesting path. I would suggest that that is not the healthiest path to take that conversation. Now, I would suggest that if we start out believing that the managers and organizations have bad aspirations to win at all costs, at everybody else’s expense, this is a really hard conversation to have.

Right. And so if you’re if you’re if you’re showing up that way and that’s the conversation you’re having, you’re not going to get the collaboration with the management that you need to be. How many the managers in the room feel like that you’re here just to win at all costs, exploit everybody, just bring people on the ground. Just raise your hands up on that one.

How about if I started the conversation with that? You know, the way you’re leading just to soothe your ego and win at all costs just to burn the place down? Let’s talk about that, because I need you to change your ego. What do you think? It’s not going to go well, is it, Managers? Why are you afraid to empower your teams?

What are the challenges with empowering teams? Why does it not happen? Trust. Trust. Fascinating trust. So I need to be able to give the team things to do and have them deliver in a way that is still safe for everybody. Because I’m kind of responsible for the people looking at me for making sure that dollars are spent well, that outcomes get achieved.

It’s a reasonable place to be, right? So you’re not just trying to win at all costs? No. Okay. But it’s interesting because it feels that way when we can’t have healthy conversations. Right. And I think that the agile industry, to a certain extent has promoted that just empower the teams and get out of the way. I think the servant leadership coaching world has talked about just be there for your teams and support them.

And I’m a huge advocate of agile teams and empowering teams. I’m a huge advocate of servant leadership and taking care of your teams.

What Does It Mean to Empower Agile Teams?

Let’s talk about like, why is that really hard to get to and some of the things that industry has tried to do to solve for this and maybe why they don’t work. But team empowerment happens when a group of employees has the responsibility and authority to make decisions every good with that, right?

So if we look at things like Agile and Waterfall, these are methods of operating in organizations that are kind of well known. And I mean, waterfall is a little bit of a of a straw man, but just bear with me on that. But basically agile small teams working together are close to the surface. Making decisions in real time Agile is really good for solving problems that have a high level of ambiguity.

But it’s not great when there’s a lot of dependencies because okay with that, okay, so we put Agile in place. There’s a lot of ambiguity and what gets away from us is the dependencies. How many of you all work in organizations have? No dependencies like end to end can just ship stuff to your customer after talking to a customer.

Okay, so there’s some challenges with with. We have to do something to figure that out. What waterfall attempts to do? Waterfall is really good at managing dependencies interdependencies, but in order for that to work, we have to know everything about it upfront. How many of you all work in industries or solving problems where you can know everything about the work upfront and have no variation how to do it or what problem your solving?

So this is the problem, right? It’s kind of a cool, let’s really clear our problem. So. So how can I trust a team is at the point that a team does something they decided what they’re going to do and how they’re going to do it. It make sense at the point in time that a team operates, there’s not a lot of ambiguity or not a lot of interdependencies are actually managing in the moment of action.

Right? So this is why agile teams work and it’s also why we actually want Agile teams in Big Waterfall, big complex projects because we need those teams to operate close servers. We can make our bottom box bigger with some technologies and some expertise, some experience. I might be smaller in some cases for outsourcing things. You know, there’s like different that box can kind of shape, but as this picture makes sense, all so the goal is how do we create the conditions for teams to make decisions and be able to perform work in a trustworthy manner?

Good call right here to read the deck. Right. So the goal is, is as managers, how do we make that happen? And it’s a collaborative thing. It’s not a one way street. You’re with me. So the problem is the problems we’re solving are up in that big green box. And the avenue for solving this problem is in between.

I ambiguity, high interdependency problems and the point of execution. And what I’m going to talk about a little bit is that we need to figure out how to solve that and come up with an intentional plan. Do we solve it by putting in specific practices in place like scrum of scrums or dependency boards or like that’s a set of practices.

Okay. With that, do we solve it with a culture? Just trust the team, stand back, let people figure it out. They’ll self-organize, they’ll figure it all out. Right now, practices are critical and culture is core to being able to operate in new methods, right? We have to change the way that we think about things, but our belief is in order to change that, we actually have to get the systems in place.

And a system is a group of interacting and interrelated elements that act according to a set of rules to form a unified whole. So those scrum teams don’t operate as a as an independent agent when there’s dependencies, right? The people asking for stuff don’t operate as a as an independent group when they’re operating in the complex organizations that we’re in.

So we have to think about it like systemically, we have to get the teams that do some things different, get management, do something different is probably a more complex layering of concepts we can get into. But in 45 minutes, I’m going to go through just some basic core things about what are the attributes of how we solve that problem.

We’ve got to be able to clarify the intent and cast vision so the team knows what it’s operating with. Then we can’t expect the team to invent its own clarity. That’s a failure mode. It’s in a lot of organizations we don’t sufficiently address, where are my  gaps in clarity. We have to clarify the path forward, aligning the competence and capacity of the teams doing work with what we need.

So sometimes we ask teams to do things that they have to figure out, or we give them ten times too many things to do and then expect them to be trustworthy. Right? Doing it, you’ll have teams that are working on ten times more things and they’ve capacity to do that happen a lot? So if we’re doing that as leaders, if we’re putting that burden on the organization, how can we expect that team to be trustworthy in its production?

Like we’re creating the conditions that the team can’t be trustworthy, right? So one of the things that Scrum tries to do is solve that is they give us a capacity, they give us a velocity. We say they control the velocity with the backlog, right? So, that’s a way that we try to create bounce capacity and then we have a sprint planning where we balance out the competence.

This is going to be hard, this is going to be easy. And we have them commit to things they understand, right? So Scrum kind of tries to address that a little bit. And teams have a cadence where they’re operating with intent but within constraints. So those are the sort of the attributes that that’s those are the attributes of solving from that problem up there.

And if you’ll notice, I put another team up in the upper box. I think this concept of stacking of teams and getting real clear about what it means because I think that team up there probably has a team that it’s responsible for. That team also needs clarity for its intent. Maybe the organizational strategy, right? Maybe what they’re allowed to spend and operate from, maybe the decisions that they’re allowed to make, maybe about safety performance.

There’s like there’s a set of dynamic conversations that take place amongst multiple layers of teams. Good with me so far.

The Attributes of Empowered Agile Teams

So these are the pillars of empowered teams, clarity on value and decision right? So if I don’t know what to do or what is that a problem that involves teams you think teams are operating? I don’t have clarity.

Is that a reason why you don’t get what you want out of the teams? Right? They don’t know what to do. And do you ever have the problem where we don’t know who makes a decision? If a lot of people can say no, but nobody can say yes, right? So it becomes really expensive competence. Do we ever have teams do things like this?

Is this to me is like a Scrum master failure mode in a lot of places. The Scrum Master is going to remove the impediments, but the impediments to the thing, to the team are things in in the Devsecops group or in my enterprise operating center or in my architecture group or in my somewhere, my customer or my market, like the Scrum Master can’t go change those policies and impacts on the organization, right?

So we’re asking teams do things that have the competence to do and is an a moral thing. Like I’m not going to ever be your accountant. You don’t want me balancing your checkbook. I have demonstrated that many times, right? So balancing my checkbook now and I love her and I trust her so and then capacity balanced with with demand and then a cadence of measurement and feedback seems like the pillars.

And really we’re going to walk through each of these questions. If I were walking in as a manager and I was trying to assess with a team, what do we have to do to put these things in place? This is the avenue that I have the conversation, worthwhile conversation for all.

Empowerment Strategy 1: Stable Teams & Clear Boundaries

Okay, This is also the first time I’ve done this trimmed down version of it, so I’m trying to figure out it’s going to take enough time or think I’m going to fit in fine. But I think we’re in good shape.

So empowerment strategy number one, establish a team structure with stable teams and clear boundaries. We talk a lot about chartering teams, getting decision right, How many people have really, really well, charter teams that understand their roles, responsibilities. So I want I need to hold this team accountable. I need to go and I tell them, here’s how you’re going to operate or work together, collaborate, How are you going to operate so we can agree on it?

Well, that’s not acceptable to me, but that’s unacceptable to me. Well, what is an acceptable thing to go? We don’t charter teams and get this clear because sometimes it’s hard work and we don’t want to end up in a disagreement as we just let it go unresolved. Right? We don’t have clarity on our roles and responsibilities. The decision, writes One to me is a really big one where a team wants to make certain decisions.

I’m going to decide what’s the most valuable thing to build in your job. We actually have a whole product group and a customer that we’re doing that up here. Why are we getting that decision clearly communicated to the team? So that breakdown is not between the backlog and the team that can do working in that backlog. It’s in deciding which decisions get made up and down the stack.

So one of things I talk a lot about is different types of teams. Here we have delivery teams, product teams, portfolio teams, investment teams that might be too complicated. You might need to you might just need flat teams. But most delivery teams can’t orchestrate their own dependencies. There’s too many dependent. You can’t self-organize around them because they take more than a week or two to get in place.

So I’m going to have a team structure that’s responsible for orchestrating dependencies, identifying risks and removing risks around the teams for the areas the teams can’t go after. Is that does that make sense? And that team’s going to have a charter and that teams can have a charter that talks about what their roles and responsibilities are. And it’s going to be very, very clear what decisions they get to make and it’s going to be shared between the delivery teams, the product teams, which decisions each team gets to make.

Now, is it going to be the same in every slice of the organization? Now, there are some decisions that we’re going to push down to the work surface because the conditions exist and it’s appropriate. There are some decisions around how we’re going to do something were to decompose and break down the work and do things in the small that the delivery team is going to do.

They’re going to self-organize around the constraints and the boundaries that were established and then negotiated agreements on the system. So when something is going wrong in an organization, ocean and teams are and the first thing I’m walking into going is what was the decision that got made in the wrong time? How did they build something that you didn’t want?

Like, how did that happen? That they built something you didn’t want? Who was responsible for sorting all that out? Because the problem is it’s the vagueness of the system. It’s a lack of intentionality around the team design and who makes which decisions. This isn’t super complicated. You dry up the teams, you have a group, you get together and you talk about what are the decisions that each team gets to make and you get agreement on it.

This will be hard too, because you have people that don’t want to give up some decision rights. We’ve been dealing with this actually here in town recently with a guy who’s been running an IT group for 15 years with an out of control sort of stack of stuff above him. And so he doesn’t trust giving any decision rights up.

He wants to control what they’re delivering to customers and he wants to control how they’re going orchestrate stuff. The problem is, is that that portfolio or product team here where they’re actually talking to customers, nobody has any idea what the status of anything is, what they think is going to get done. So he’s not only making decisions, but he’s not radiating any of the information that problem.

Guys familiar with that problem, that classic problem. All right. So how do we get past that? Sit your teams down, get extremely clear on what value means to that project or that team. What we’re going to reward, what we’re not. Get really, really clear on the rules, responsibilities that exist on the different teams and make it explicit which decisions get made at which tier.

If you don’t make it explicit, then things are getting dropped. Then you have to get better at making decisions. What does it mean to make decisions and communicate it? There’s this whole sort of theory around commitment-based management. Have you guys have you seen any of that where I’m going to ask for something? You’re going to make a promise, You’re going to do it.

You’re going to go tell it. You can tell me what it’s done. Like the process of managing the interaction between those teams becomes really important, too. So if you’re responsible for doing something that you trust, for doing it, your response for telling other people has been done and making negotiating explicitly the criteria. So it’s cool that that from a value standpoint, acceptance criteria.

OKRs There’s a whole bunch of things that are built into our agile world that we can use for creating clarity on value. We can get clear on who negotiates the different aspects and what are the tradeoffs is who gets to make the tradeoffs, and then we can get the work down into the teams. The team can operate there.

We do a lot of work. Okay, as an organization, we’ve seen a lot of it going on and they’re not used to actually great clarity. They’re not leveraged when we’re actually making decisions in a good place. That’s cool. We’ve seen a lot of places where it’s disconnected from actually doing the day-to-day work. We’re doing okay, but we don’t.

Clearly, we see a lot of people that write acceptance criteria. Acceptance criteria are functional tests, not the problem we’re solving. We don’t we don’t communicate value and intent and our acceptance criteria. So, when you say, well, okay, here’s acceptance criteria stories, well, form teams, these things are all great. People go, we’re doing all that. But you look at it and you go, but you have really clearly articulated goals and business outcomes, communicate his aims.

Could they articulate why they’re doing what they’re doing and how they can associate that piece of work with that? If not, then you have an accomplish the intent of your OKRs or however you communicate it. Are there clear roles and responsibilities for all members? Yeah, but we don’t really do them because the teams are different and every team might be different, but if we don’t know who’s making which decision win and whose response for doing work and making it explicit, it’s going to kind of fall apart.

There’s a set of dynamic conversations that take place among multiple layers of teams. These are the pillars of empowered teams – clarity on value and decision-making, right? If there’s a problem that involves teams, and they don’t know what to do, or who makes a decision, it can hinder their ability to deliver what is expected.

To empower teams, we need to establish a team structure with stable teams and clear boundaries. This includes chartering teams and getting clear on roles and responsibilities. We also need to make explicit which decisions get made at which tier, and ensure that it is shared between delivery teams, product teams, and portfolio teams.

As a manager, we need to facilitate clear understanding around roles, decision-making, and how to do value. This is a leadership responsibility. We need to charter teams, explicitly agree on working, and use acceptance criteria to articulate value in a way that both groups agree to and can hold on to. However, depending on the domain knowledge of the team, the complexity of the problem, the rate of movement, and the number of dependencies, we might want to charter them differently.

To empower teams, we need to create the conditions to delegate into the team and ensure that they have everything necessary to be successful. We also need to get clarity on how all those things happen. Lack of trust between the groups can make this hard, so we need to solve the problem together, revisit the design of our teaming structure, and hold the team accountable to the decisions they made.

Leadership is responsible for the design of the system, and we need to empower teams by building trust, setting an example of empowering teams, and solving problems to achieve shared goals. Monthly retrospectives at an organizational view or team level retrospectives can help in this regard. This is a simple yet courageous and tenacious process that requires intent and hard work.

But one of the things that makes it hard is this lack of trust between the groups. So, you have to sit down and say, “Listen, we have to solve this problem together and we’re going to get as good as we can.” Now, do you all do like monthly retrospectives at an organizational view or just do team level retrospectives? Some organizations do operations reviews or bigger retrospectives.

Yeah, so every once in a while, you should be revisiting the design of your teaming structure in decision rate and moving things around when something goes really, really south. Sit down and do it. You want to talk about empowering your teams. You want to start as a manager, set an example of empowering your teams, how to about how to solve this class of problems to achieve the goals that we share.

Now, the team actually influences the world. They’re participating in how they want it to be shaped, and if you listen and help them put it in place and hold them accountable to the decisions they made, that’s empowering teams. It’s building trust. This is interesting because I believe leadership is responsible for the design of the system, and we tend to just let this stuff not be done or we don’t do it itnentionally enough.

And then we get messiness and then we’re frustrated and positional power. It’s the frustration on the delivery team. I think if you’re not getting what you want from your teams as a manager, you have failed to lead appropriately. You haven’t created the conditions to be able to delegate into that team.

Empowerment Strategy 2: Explicit Decisioning, Orchestration, & Interaction Models

Competence. The right people in the room at the right time making the right decisions.

We see a lot of big heavy SDLCs or process flows or diagrams about how to build software, how we ship product, how we work. A lot of those things. Very, very little of it is really, really followed closely and without much transparency in the work that’s actually going on in there. One of the cool things about the way that we can do with Agile is we’re pretty familiar with just like this delivery team Kanban, right?

Here’s what I’m doing the next two weeks, broken down the stories. We have clarity on it because we did that conversation. We’re going to track it apart across through in progress, story done. You know, whatever your flow is at that level, we’re tracking those little pieces of work across and we have a lot of transparent see into the state of the work with a lot of transparency where things are getting blocked.

When we have a lot and when things are getting blocked, what does that mean? It means that we delegated something to a team that the competence didn’t exist within the team to resolve. It is competence, morale. Why should we mad at them? Because we gave them something they’re not competent to do. Should the teams that are interacting with each other get frustrated when we expect someone to do something they’re not able to do? That’s a design of the system problem isn’t it? So what I want to do is make these flows be really explicit. We’ll do stories at the bottom, features in the middle, epics at the top, maybe opportunities or investments, whatever you need one or two or three stacked beginning, extremely explicit that at this point when we’re in solution definition at the epic and feature level, here’s the people that are in the room. Here’s the information they’re going to have and here’s how we’re going to make decisions that we can all hold ourselves accountable to. Right?

Within the design of the system. That’s going to be reflected now in my acceptance criteria. It’s going to bounce off my OKRs and it’s going to be the way I decompose my work because I have a stable team and I have responsibilities for decisions. I’ve agreed on how we’re going to operate. Now I can intentionally manage the flow of work. And when things aren’t working, I can test for that I have a poor team design, can I understand as you make quick decision or I push work into a team they’re not competent for. What do we do if we’re trying to push work into a team they’re not competent to do. What can we do?

We can make it clearer, we can make it smaller, more precise. We can find another team that can do it, or we can invest in elevating the competence of the team. But if I give a team something to do as a Product Manager, Product Owner, or an executive or whatever, and they’re not capable of doing it, is that the team’s fault?

So what is the team responsible for when we’re having that conversation? Communicating what they can do, right? Yep. Being transparent. Here’s what I can do. Here’s what I can’t do. If you could work with me to get these things in place, I could do this for you. But I can’t handle that.

But a lot of times it’s because of the nature of the organization. We put stuff into the teams. We expect the teams to go do it, and they feel obligated to do it because of the positional power itself. So it’s really interesting. It’s the positional power thing that gets sideways, right? And it’s because it becomes individual instead of understanding how the whole system works.

So I get really explicit on how work flows, and I can tie what decisions get made, where, and who has to be in the room to make those decisions. And remember, I tie decisions to the different teams. We built it out earlier. I make sure people have the right information to make the right decisions. It becomes very interesting when in many organizations we walk out to the endpoint and we find a lot of the work at the end, we integrate at the end, we test at the end, we come up with our security requirments at the end , and then we solve a lot of things at the end because we don’t have the right people in the room at the right time, creating a context for the teams to operate within. Or we delegated decisions about how we’re going to operate into teams that don’t have the right to make that decision, and then it conflicted with something we were trying to do from a higher level. So getting very explicit about the flow of value and the decisions and where they fit in, that becomes the critical next step.

Empowerment Strategy 3: Transparency & Radiating Key Info

And then there’s the capacity. One, every organization has more work to do than they can possibly get done in a period of time. That’s just generally true, right? Are we getting things done faster when we’re working on everything at the same time and are pushing everything into the teams? How do we have transparency that what do we do to understand how much capacity can handle? What’s the optimal amount of rate based on their team structure and the competence of the team?

How do you know when you’re pushing in more stuff that you can pull out? This again, where a  Kanban is a really nice sort of tool for understanding that. How do you know when the team is at maximum limit? Do you have an understanding of what the capacity of your teams are and how much you can push in?

Do you know what the dependencies are that are blocking them, and are you orchestrating and managing the dependencies ahead of the teams or expect them to figure it out in real time? So these are things we walk in and kind of look at things when really they go sideways. This is almost always like a big hit, right?

But until I have the stable teams and clear decision rights and can actually measure the flow of value, it’s really hard to solve for the capacity in demand conversation. It’s really hard to get to dependency management decisions in the right place because I can’t be finding every dependency late now and expecting the team to resolve it in real-time just doesn’t work.

So, I can design a system that has a lot of late failure, and it will never be predictable. It was never predictable. I’m not going to trust it, right? So, I’m not going to push decisions into a team that I can’t trust. The one about capacity constraints and dependencies are two very, very big ones. You all have good tools for understanding your capacity so that the business is making decisions and pushing things in that are balanced with your capacity.

Are you good at managing dependencies ahead of the team? Are you all good at really working out only the most important things? Why is it hard to empower your teams given this sort of frame? If you were to look at it for a minute, what makes it hard for you to empower your team as a leader?

What’s missing from this is what they all said: it was hard to empower your teams. What makes it hard to empower your teams? Does this frame help you with that conversation? Are there things here that you could go do? What would you go do?

Empowerment Strategy 4: Feedback Loops

Let me go to my last sort of big slide. So, the last one is just the cadence and the cadence of management, the teams getting together and reviewing how work is performing. If it’s hard to see the status quo going to work as performing or where the impediments are or how this thing is performing is very difficult to resolve. And if we’re just managing like every individual crisis, a crisis at a time, instead of understanding the design of our organization, it’s impossible to actually go improve. So, we end up we talk about being in the system versus on the system.

So organ in the system all the time, but having some time to deeply understand how our system works, how our teams are working together, where their challenges are, where their impediments are, what their capacity is, what their competence is, and making sure that we’ve optimized for producing value through that, that transparency is really important and we have to stop and go back and ask the questions.

Is the team designed right? Is the flow of decision-making right? Do I have the right information to make the right decisions or am I just hacking on people? And when we don’t have those things in place, then we end up just bullying on the teams, right? That’s the only way to get things done. And we have to get things done.

Tradeoffs just getting really, really clear in that moment. We want to do that fast, but we want to do it and it’s going to end up eroding the technology and making things worse in the future. Or I can’t do these four things. I can do these two things like having that cadence of using the data performance of the system in place and providing that feedback so you can adapt and respond in real time. That’s a critical strategy. Many organizations are still pushing things in at the top that are not strategically aligned, capacity constrained, or dependency aware and expect it all to get figured out in the middle. All these pieces are in the messy middle there, That Red X, that’s where we need to put these pieces in place.

Part of that is having transparency and an explicit place to make tradeoffs. If we don’t make the tradeoffs above the delivery teams, where those tradeoffs are going to get made? Say, I can only do four things for you, but you give me eight to do. If we don’t decide the four as part of a process, who’s going to decide which four get delivered to the team, some developer, or some vendor? That’s an example of decisions getting pushed down because we’re not taking accountability for it. If I didn’t get back what I wanted, I delegated the decision to a team that I should have delegated authority or competence to do it right. So there has to be an adjustment.

We need to understand what tradeoffs we have to make and how to make them. The last one is continuous improvement. How do we look at this system again and again and improve it? If you’re thinking, we already do all these things and you’re not getting your teams empowered, that’s kind of what I was going to say before. What’s making it hard if you’re already doing all these things to engage with your teams and make them feel empowered?

Are you trying to make your teams feel empowered? Do you know which decisions you want to delegate into the team and give them responsibility for? Do you know which impacts on your system you want them to have a voice in and be able to improve and elevate? They should feel like they’re actually influencing their life because it’s not just about organizing the chaos and crisis around the next piece of work. It’s about actually making a place that isn’t horrible to live in and work.

It’s about having the ability to participate in making it better and better for me to keep the promises that are being made between teams and between management and the team. So that’s the takeaway, empower teams, the four pillars, and sort of the introvert. I know I thought I might have cut this a little bit short. I didn’t go into too much detail on some of the areas. I’ll be really happy to take any questions or work with you all, take any specific and sort of walk through it, take any feedback on what I presented to.