For those of us who work on helping teams develop and embrace agility, we preach quite often about the importance of team empowerment, often talking about self-managing or self-organizing teams.

One reason we want to empower teams is that they are the ones doing the work where the rubber meets the road - who better than those doing the work to decide key elements of how they can best complete that work. A second reason we strive to empower teams is that people are happier, more engaged, and productive when they have a certain level of autonomy over their work. Autonomy, along with competency and connectedness/purpose/mission, are key motivational factors according to Self-Determination Theory (and popularized by Daniel Pink in his book Drive: The Surprising Truth About What Motivates Us).

But what does team empowerment really mean? One way to look at it is how much we allow the team to decide for itself.

Can the team choose when and how often they meet? How about if they don’t want to meet real-time for a daily scrum meeting every day? That’s team empowerment going head to head against a standard practice. My take there is that as long as the team is collaborating enough together, I’d have to defer to the team to at least experiment as they want to see what the results are of not meeting real-time in a daily scrum every day. If it turns out, as is likely, that they are better off meeting as a team every day, they will learn that from their experiment, and they will have a much stronger conviction of the importance and value of the daily meeting by virtue of their experience rather than being told that it is important to do so

Can the team pick a team name? I’m all for that, although the team that chose the name “Yo Momma” - you know who you are - really tested my resolve on team empowerment (we decided to not use the team name in front of customers as a stipulation for keeping the name).

Deciding who works on what? Deciding what work they pull into a sprint? Both seem very important things to let the team decide for itself within some high level guidelines and as dictated in Scrum.

We could go on listing specific things the team should or shouldn’t be allowed to decide for themselves, but even more important is to help the team to understand that there is no arbitrary limit to what is up for discussion and change. I will often encounter a team which knows that their current process is not optimal, or even downright stifling, but won’t even consider trying to improve the way things work. They suffer from “learned helplessness” which manifests itself when they state to me, “You don’t understand. That’s just the way things work around here.” They’ve been told “no” too many times or they feel the decisions are made several levels above them that they’ve given up even mentioning the issue and just adjust their work practices to just live with it. That is a travesty, and often times a silent travesty as the team has given up on offering suggestions to change how things work.

What we can give to teams is a set of core, guiding principles (e.g., “Customer data privacy is paramount and must be at the forefront of all we do.”) through which they can determine what practices and processes are consistent with those principles and which would not be. This increases the speed of decision-making and supports team empowerment by allowing them to apply those principles to make appropriate decisions without seeking approval outside the team - a win—win situation.

Another step we can take to increase team empowerment is to reduce the dependencies between teams. If a team can go from ideation to implementation to deployment all by themselves, the more they are free to determine the best way for them to work. When they have dependencies on others, they must standardize on processes and procedures that may not be optimal for them. In fact, often times, teams are often stuck working on the “least common denominator” process that is not optimal for any of the teams involved. Of course, there will be some minimum level of standardization and coordination needed across an organization, but this should be kept to the absolute minimum required to support the organizational mission.

We can really unleash the full potential of our people and our teams when they feel empowered and encouraged to speak up when we need to change the way things work around here. Developing a regular habit of experimentation and curious exploration in conjunction with truly empowered teams will drive continuous improvement, a bias to action, and innovation better than top-down directives or initiatives.