What is Empowerment?
Empowerment is the act of granting power or authority to perform actions or duties. It means letting people be in control of some things. It does not mean giving up all control or influence. For example, we can empower teams to make local decisions that concern themselves but escalate decisions impacting other teams or stakeholders.
That Sounds “Soft” Why not Just Tell People What to Do?
When we consult the people doing the work, we get better insights into the issues, risks and level of effort involved. This better data is useful, but the real benefit comes from the motivational advantages of empowered teams.
1.4.1 Organize Around Team Strengths
Letting teams self-organize, make decisions and solve their local problems puts them in control of their work. When team members decide how to work together and which approaches to use, they gain autonomy and mastery of their work. The book “Drive: The Surprising Truth About What Motivates Us” identifies job autonomy and mastery (along with having a clear purpose) and the core components of motivation.
The alternative, giving out tasks and instructions, is like pushing rope; it is unproductive and can go in the wrong direction. Instead, defining short-term goals and letting a team self-organize allows them to pull the rope connecting their progress to that goal. Work is better aligned and more rewarding for the team. They go faster since they enjoy working that way.
These ideas may still sound “soft,” and some teams may need clear direction and close supervision to get any work done. However, where possible, treating people as adults and acknowledging their skills makes sense. Tapping into the motivation for why people pursued their careers and providing trust usually pays dividends.
Who Do We Need?
When starting a project, we need to understand what strengths (skills) will be required and if we have them available to us. For familiar projects, the skills required might be well understood and documented. In which case, building the team starts with collecting people with those skills.
For example, if we were building a house, subject matter experts in our organization would tell us about the types of architects, carpenters, plumbers and electricians we would need.
For new or uncertain projects, we will not be so sure. We can analyze the likely work required and infer the skills needed to do it. This could be done by analyzing high-level scope statements, feature requests, preliminary work breakdown structures or product backlogs.
For instance, building a new door lock that uses AI to recognize approved users from biometric data (gait, facial recognition). We can determine that we will need people with AI skills for the software parts and engineering skills for the door lock components, but the exact nature of the skills may not be knowable in advance.
Before we can organize around team strengths, we need to understand what those strengths are.
SWOT analysis where we identify Strengths, Weaknesses, Opportunities and Threats can be a useful place to start.
Some organizations maintain skill and competency information; others may hold team led SWOT sessions to create lists of competencies and additional skills required. Skills can be grown through training, mentoring, or pairing inexperienced people with more experienced staff. Work should be undertaken by appropriately skilled and experienced people.
Once we know the skills available to us, we can organize ourselves to set up for success. This involves mechanisms for making upcoming work visible so people can see what will be needed and those items they can work on. It also includes creating structures so team members are accountable for tasks.
1.4.2 Support Team Task Accountability
Both traditional/predictive and agile/adaptive approaches have mechanisms for tracking task accountability. If you create a hybrid approach, make sure it has one also. The elements tracked will include details of the work that needs to be done, how to perform the work, and who will perform it.
Work breakdown structure dictionaries and work package descriptions document the relevant tasks and assignees. There should also be descriptions of how this work will be tracked and managed.
Team members select/commit to work items (user stories) from the product backlog that have been identified by the product owner (business representative) as ready for development. These user stories are then typically tracked and managed on a Kanban board or in an agile tracking tool such as ADO, Jira, VersionOne. These tools show who is assigned to each task and the status of the work.
Supporting task accountability is critical for maintaining forward progress. We need to know who is working on what, what the status is, which tasks are still without an owner, etc.
Teams define how they will work together during team chartering and creating team norms. This will include how they select work, show its status and escalate issues.
1.4.3 Evaluate Demonstration of Task Accountability
Organizing around strengths and supporting task accountability are good starting points, but we also need to follow-through and make sure work is getting done well. This involves checking in on the work being done and the workers doing it.
In a traditional project environment, we ensure work packages are defined, assigned and completed to schedule, budget and quality requirements. In an agile project environment, instead of WBS work packages and assigned tasks, we might be using a backlog of user stories and checking that those identified by the product owner are getting worked on in the selected sprint or iteration. The names change, but the ideas are very similar.
Agile has a less formal assignment of work since teams are supposed to self-organize and collectively decide who will do what. The weekly or biweekly demonstrations and retrospectives provide an opportunity to see if tasks are getting done and review task accountability workflow and any potential issues. Retrospectives also provide opportunities to design experiments to try in subsequent iterations to achieve better results.
Traditional projects can use milestones, phase gate reviews and scheduled inspection to evaluate task accountability. The progressive elaboration concept of updating and further detailing plans based on emerging information allows for adjustments and improvements throughout the project.
1.4.4 Determine and Bestow level(s) of Decision-Making Authority
We should make decisions at the appropriate level. The goal is to move decision making to the people doing the work – the team. This means empowering the team to make local decisions that impact them and their work.
However, sometimes the team may not be ready for this initially. They may fail to reach consensus or make decisions that are sub-optimal. Here they may require more direction and support to begin with, progressively adding more decision-making authority until they can successfully make the bulk of their local decisions independently.
Teams may elect to defer most technical decisions to subject matter experts on the team or discuss and vote on major decisions as they arise. Empowering the team to make their own local decisions helps morale but can slow the process if not supported by proper tools.
The one good thing about having just a single person making all the decisions is that they should at least be quick (even though they may not be right or popular). Using an empowered team approach, we need ways to quickly consult with everyone and then move forward with the best option.
Team decision-making techniques need to provide ways to engage multiple insights and arrive at the best option. The following list describes some popular decision making approaches:
Simple Voting. Voting “For” or “Against” by a show of hands is quick and easy but can miss a better third alternative. Perhaps someone has a suggestion to tweak the options being voted on? A simple “For” or “Against” vote omits refinement.
Roman Voting. Using a simple thumbs-up, down, or sideways is a quick way to achieve a simple vote. People with a thumb sideways are then asked why they could not make up their mind. Sometimes they are just neutral; other times, they have a conflict, concern or questions that need further investigation.
Dot Voting. Dot voting is a team activity where everyone gets an agreed to number of votes to assign as they wish to a set of choices that have been identified and outlined. Team members cast their votes by placing sticky dots or ticking on representations of the options. After everyone has voted, the dots (or ticks) are counted, and a winning choice is announced.
Highsmith’s Decision Spectrum. Using this model team members are asked to indicate with marks where on a spectrum from “fully in favour” through “mixed feelings” to “No, veto” they feel about the decision at hand. It allows people to indicate support for a decision and air their reservations at the same time.
Allowing people to register their concerns is an essential component of achieving agreement to go forward while respecting dissenting views and keeping everyone engaged. People indicating they are not entirely in favor are then invited to share the concerns, but often just being able to register reservations is enough to allow people to commit to a new direction.
Fist of Five.The Fist of Five approach combines the speed of thumbs up/down with the degrees of agreement from the Decision Spectrum. Using this approach, people vote using their hands and display fingers to represent their degree of support.
A small problem with this approach is that two standards have emerged, and so you really need to be clear upfront if 5 fingers mean “full agreement” or “no, stop”. One model (popularized by the American Youth Foundation) registers support by finger votes, a fist (no fingers) means no support, 5 fingers means total support and a desire to lead the charge.
More Arguments?
Empowered teams making their own decisions have more debates than non-empowered teams who instead follow instructions. These debates and constructive disagreement allow for ideas to be tested by the team before making a decision. This involvement in the decision process generally leads to more commitment to the choice reached. Yet, it can appear empowered teams debate and argue more than other groups. As long as the opinions are fact-based and respectful, this is not a problem.
However, If arguments become personal or are dominated by the same people, this needs to be addressed. If discussions are not engaging insights from the other team members, this is no longer an empowered team. In this case, the conflict must be addressed and expectations reset.
Usually, calling out non-fact-based criticisms and making sure everyone’s voice is heard only needs to be done a couple of times before the team catches on and self-polices in the future. Some groups build guidelines for discussion and debate into their team norms or team charter.
Further Forms of Empowerment
Empowerment extends beyond decision-making authority to many aspects of the project, including planning, estimating and risk management. The following benefits are achieved when we engage the team in:
- Planning – this results in more practical plans based on what work is viable, given the current situation.
- Estimating – incorporating the first-hand experience of the levels-of-effort and additional work steps that may also be required.
- Risk Management – the benefits of recalling previous issues, integration challenges and 3rd party dependencies not easily identified in planning.
Empowerment Observations
Empowerment means distributing control of some things to team members.
The quote: “We lead teams by standing behind them,” is an oxymoronic reminder that the real role of a leader is to support and empower the team. The team does the bulk of the work, and project success depends upon their success.
A great way to motivate the team is to recognize their insights and make use of that knowledge. Engage them in planning, estimation and risk management. Give them appropriate decision-making powers and tap into the intrinsic motivators of problem-solving, autonomy, mastery and purpose.
This does not mean surrendering all management, instead trialing giving more autonomy through short, controlled periods of work. Then evaluate the results and take appropriate action.
For a further explanation of how agile approaches empower teams, see the exclusive Agile Primer chapter (pages 16 – 38) in the PM Illustrated book.
Deliverables and Tools
- SWOT analysis
- Team Charter
- Team Norms
- Team decision making tools (Fist of 5, roman voting, polling, planning poker, dot voting)
- Retrospectives
Related Topics
- 1.1 Manage Conflict
- 1.2 Lead a Team
- 1.3 Support Team Performance
- 1.6 Build a Team
- 1.7 Address and Remove Impediments, Obstacles, and Blockers for the Team
- 1.10 Build shared understanding
- 1.11 Engage and Support Virtual Teams
- 1.12 Define team ground rules
- 2.4 Engage Stakeholders
- 2.16.1 Discuss responsibilities within teams
Congratulations! You scored 100% and won the Empower Team Members and Stakeholders badge.