Agile Leadership Myth #1: Telling people “You Are Empowered” Actually Works

A major challenge we run into when helping organizations shift or improve is leadership misconceptions. Agile leadership myths cause a lot of these misconceptions. We need to help avoid falling into the trap of these common myths because they limit our success. A root cause of many of the myths is that people simply don’t know what else to do. For example, Myth #1: ‘telling people “you are empowered” actually works.’  Leaders often don’t know what else to do, other than tell teams they are empowered. We see this with Development Teams, Scrum Teams, Delivery Teams, AND Leadership Teams.

A bit of background — there are many agile leadership myths out there. These myths (or assumptions) limit leaders ability to improve, help others, and succeed. Many myths seem to occur at a nonconscious level, meaning they function like many biases. People are not even aware, consciously, that they are happening.

Tricia Broderick and I focused on identifying and naming leadership myths so we could focus on helping people overcome them in our advanced leadership training (Agile Leadership – Leading Amazing Teams as well as our Executive Leadership Program). We started asking questions and examining leadership experiences. We wanted to take a look at where leaders were stuck. We had both worked in various leadership roles within organizations. We both have personal successes and failures as leaders. We also work with many leaders and organizations now and see many all kinds of issues. But, we wanted to know if the things we experienced were common or if somehow, they were only specific to us. In the end, we found that most of them are not unique to us.

Myth 1: Telling people “You are empowered” actually works.

Empowerment means much more than telling people “you’re empowered!” We hear this all the time. Then we hear, “I don’t know what is wrong with the team. . . I told them they’re empowered, but they will not step up.” It takes a long time for a behavior to change and it does not happen overnight.

People need safety as the base need to be able to change. If that is not there, they will not consider the change. You might say “oh, it is safe, trust me”, but like the myth, that is not sufficient. People will not change their behavior because you decide they’re empowered — and that assumes they even believe you.

Empowerment doesn’t mean “do whatever you want.” Explaining the difference can be challenging. Most organizations are looking for self-organizing teams (typical agile approach). There is confusion between self-organizing and self-managing. Self-organizing is about figuring out HOW to do the prioritized work (coming from someone else, like a product manager). Self-managing is about figuring out WHAT work to do (sometimes called self-directed), as well as all the aspects of management (hire, fire, raises, etc.). So self-managing teams choose what projects they are working on. Even within self-managing organizations, there are generally guidelines with how these things happen.

What does Empowerment Really Mean?

A topic that comes up a lot when I’m talking about what empowerment really means, is the definition of empowerment itself. Looking up the definition, we find:

Empowerment: authority or power given to someone to do something.

This idea of empowerment implies you have the power. Thus, if you are going to “empower” someone, be aware that it implies you have the power. It also implies that you will and can give it to someone else. Everyone also needs to be clear on what “power” is being given away. This might sound obvious, but people misuse the word a lot. If you don’t have the power, but want to empower others, that can sound insulting. For example, an agile coach does not have power over a team. If they say they want to empower the team, they ideally mean they want the team to have the power to act. But they, the coach do not have the power to grant to the team. There are other examples, such as a when one ‘group’ wants to empower another (gender, race, etc.). I’m not going to dive into that here, but if a ‘group’ wants to empower another, that implies they have the power. This might not be the intention, but that is the implication. This is why I have tended to move away from the term over time. I am generally not in a position where I can give power to people, as an external trainer and coach.

I say empowerment, but I actually mean. . .

People sometimes say they are empowering others but mean something else. They might mean they want to help others recognize the power they already have or should have. This is different because it is not about giving someone your power (or telling people they need your power!). They might also mean they want to create the kind of environment where ‘everyone is empowered.’ There are some terms that I use to replace “empowered” but I don’t have one I love.

What Can You Do

  • As leaders, we need to determine what end-state goal we want, then we need to practice patience and be consistent with our behavior to get to our end-state. If every day turns into an emergency exception to what we want, we will never reach the place we want. For example, a team will never believe they’re empowered if every time there is an urgent issue, you step in. You need to find ways, in advance, to work with teams to help them improve how they handle challenges. Teams should be consistently improving their ability to deal with new challenges, with help from you, as needed. Where are you inconsistent? Where are you messing up your long-term opportunities?
  • As leaders, seek to understand the situation before acting. What is really happening? There are cases I run across everyday where a team already has the power to act, but does not fully believe that they can. There are many potential VALID reasons for this. The team may not buy-in to the safety of the situation, the leader might change behaviors each day which confuses the team, or the leader might micromanage in some situations. Of course there are other reasons as well, but you get the point. As a leader you should aim to understand and meet the team where they are.
  • As leaders, we need to help teams uncover what is holding them back. If they actually have the authority to act, what is holding them back? Do they even know? Are you hearing the same concerns or issues, but never hearing the problem? You may need to work with them to unravel what is stopping them. Then help them by facilitating the removal of the impediment(s). Be aware that what is holding them back, might be you.
  • As leaders, look to engage people early with potential change.  Leaders often tell everyone about a change (e.g. moving to agile) and expect them to get on board instantly. However, they may have considered and processed that change for months (or longer). It took the leaders months (or longer) to get a handle on the change — why would everyone else adopt it immediately? Consider including people in discussions about change earlier, so they can step into the curve of change with you. That gives everyone more time to process the change and can help gain buy-in from everyone involved. Be sure to start with a goal and explain the goal to everyone first — including why the goal is valuable.
  • As leaders, we need to clearly work to define the boundaries teams can make decisions within. This should be visual and simple, not in a 6pt font 45 page document. Everyone, including the team themselves should compare the issues they struggle with and the authority they have. Is it possible that they could resolve an issue themselves? How apparent is it that they could? Note that this might not mean that you as a leader are defining this. It could be doing it with the team or some other leaders. The goal is to make sure teams know what the boundaries are for decisions. For example, can teams purchase equipment under some dollar amount? Can they decide on a new automated test strategy? Can they determine how to automate builds? I’m not suggesting you spell it all out, but because I run across situations just like this, where a leader says “they can decide that” and the team says “we are not allowed”, there is clearly a mismatch. You can work with teams and decide as you go, just be aware that you need to be on the lookout for areas you are not aligned.
  • As leaders, we need to know that it is okay to ask for help. If you don’t have the answers, ask for help. The worse thing you can do is pretend you have the answers. When this happens teams know and they will lose respect for you if you are not straightforward. This is an important part of being a leader — knowing when to ask for help — and asking.

Try some of these options. I’d love to hear how things are working for you! Have you have experienced this Myth? Have you already tried some of the ideas here? Did they work?

Share

4 thoughts on “Agile Leadership Myth #1: Telling people “You Are Empowered” Actually Works”

  1. Hi Jake,
    I am facing exactly this problem right now. I tell to my teams “you are empowered, you can choose which is the best solution and what works best for you!”. But I see no reaction. After observing the team, I realized that they have a Product Owner that acts as a manager for the team. He is also half developer in the team, and is the one with more experience. The team won’t start a task, if they do not have the permission of the PO. They will take decisions, but first they will ask the opinion to the PO.
    I liked very much your post, it helped me to put order in some of my ideas!

    Reply
  2. Hi Jake,

    Just want to express my appreciation for this short article. It does make sense and has so many valid points. It was quite helpful.
    I merged it with the key authority areas board to define the particular pain points in a multidimensional team environment and altogether I have a working measurable and controllable empowering process.

    Cheers,

    Michael

    Reply

Leave a Comment