Empowered Teams Still Need Leadership

Most project managers have watched empowerment fail in one of two ways. In the first, a team is told it owns its decisions, and then the first decision that surprises a sponsor is quietly overturned. Nobody announces that the arrangement has changed, but the team learns quickly and starts checking everything upwards again. In the second, a team is told to self-organise and then left alone, with no shared sense of what it may decide, what it should raise or what good looks like. When something goes wrong, the conversation about accountability becomes a search for someone to blame.

Both failures rest on the same assumption: that empowerment and accountability are a trade, and every decision handed to the team is a piece of control the leader has given away. Teams can be empowered without losing accountability, but only when three things are designed deliberately: which decisions have moved to the team, the limits within which those decisions hold, and how results will stay visible to the people who answer for them. Empowerment done properly is not less leadership. It is a different kind of leadership, and in several respects a more demanding one.

Decisions can move without accountability disappearing

It helps to separate three things that are often blurred together. Authority is the right to make a decision. Responsibility is the obligation to do the work, or make the decision, well. Accountability is answering for the outcome. When a project manager empowers a team to decide how a piece of work is done, authority and responsibility for that decision genuinely move. Accountability for the project's results does not evaporate; it changes shape.

The leader stops being accountable for each individual choice and becomes accountable for the conditions in which those choices are made. Did the team understand the purpose of the work? Did it have enough authority to act, and enough information to act sensibly? Was there a reliable way for problems to surface before they reached a customer or sponsor? If the answer to any of those is no, a poor decision by the team is at least partly a leadership failure, even though the leader never touched it.

Empowered teams also carry accountability of their own. A team that commits to a sprint goal, a work package or a handover date answers to its colleagues and stakeholders for that commitment. Empowerment without that mutual accountability tends to drift into comfortable autonomy, where the team decides freely and nobody feels the consequences.

The idea is consistent with Section 3.8 of The Standard for Project Management, Build an Empowered Culture, where empowerment is treated as people contributing, deciding and learning within clear boundaries rather than as an alternative to leadership or governance. It sits naturally beside the principle of being an accountable leader. The two are meant to work together, not to be chosen between.

Boundaries are what make empowerment usable

A team cannot use authority it cannot see the edges of. Telling people "you own this" without saying where ownership stops tends to produce one of two behaviours: cautious teams escalate everything to be safe, and confident teams make decisions that belong to someone else. Neither is empowerment in any useful sense.

A practical test before handing a decision to a team is whether the leader can answer four questions in a sentence each. What outcome is this work protecting? Which decisions sit with the team, and which sit elsewhere? At what point does a decision stop being the team's alone, whether that point is cost, date, customer impact, compliance, safety or risk? And how will both the team and the leader see whether things are on track without the leader inspecting every activity? If the leader cannot answer, the team certainly cannot.

It is often more useful to think in tiers than in a single line. Some decisions the team simply makes. Some it makes and then tells others about, because they affect neighbouring work. Some it researches and recommends, while someone with wider authority decides. A small number go straight upwards, because they involve legal, contractual, ethical or safety matters outside the team's remit. Much of the friction in empowered teams comes from decisions that were never placed in any tier at all.

None of this is new to experienced predictive practitioners. Tolerances on work packages, where a manager can absorb variance within agreed limits and escalates beyond them, are empowerment expressed in governance language. Adaptive teams do something similar with different vocabulary: in Scrum, for example, the developers decide how to deliver the work while the product owner orders the backlog, and neither role sets aside an organisation's security policy or a contractual date. Hybrid environments often make the pattern easiest to see, with fixed regulatory milestones set above teams that are free to sequence and shape the work beneath them.

Once boundaries are clear, the leader's attention moves away from how each piece of work is done and towards two other places: whether the outcome is still on track, and whether the boundaries still fit the situation. Boundaries should be as wide as the team's capability and the level of risk allow, and they should be revisited. Limits that were sensible for a new team on a high-risk release can become a quiet form of distrust six months later.

When an empowered team crosses a line

Consider a fictional network migration at a telecoms provider. The engineering team has authority to plan and sequence cutovers across a group of exchanges, within an overall programme window agreed with the sponsor. Midway through, the team discovers that one planned cutover clashes with a delayed hardware delivery, so it brings that cutover forward by a week. Technically, the decision is sound. Commercially, it is a problem: business customers on that exchange had been given contractual notice of the original maintenance date, and one of them learns about the change from its own monitoring rather than from the provider.

There are two tempting responses. The first is to take the authority back, so that every future sequencing change comes to the project manager for approval. That feels like accountability, but it teaches the team that empowerment lasts until the first mistake, turns the project manager into a bottleneck and slows hundreds of decisions to prevent a repeat of one. The second is to defend the team completely on the grounds that it had authority. That protects morale for a week, but ignores a broken customer commitment that someone has to own.

A more competent response starts by asking what kind of failure this was. The customer notification obligation had never been stated as a limit on the team's sequencing decisions, and the notified dates were not visible in the plan the team worked from. This was a boundary that was never drawn, not a team that ignored one. The project manager therefore owns the consequence with the account manager and the customer, without passing the blame downwards. Then, working with the team, the boundary is made explicit and deliberately narrow: the team continues to resequence freely wherever notified dates are unaffected, and any change that alters a notified date comes to the project manager as a recommendation, because it involves commercial commitments outside the team's remit. The team is also asked what it would need in order to see the constraint for itself, and the notification dates are added to its cutover plan.

Authority has been tightened on one specific edge, not withdrawn across the board. Had the team known about the obligation and ignored it, the conversation would be different: a direct one about commitment and professional accountability within the team. Even then, the answer would rarely be to recentralise every decision.

Reading empowerment in PMP scenarios and on real projects

For a PMP® candidate, the current PMP Examination Content Outline offers a helpful clue. In the People domain, which accounts for 33% of exam items, the task of leading the project team includes empowering the team among its illustrative examples, alongside setting team expectations, establishing clear roles and responsibilities, and determining an appropriate leadership style. Read together, those examples describe empowerment as something that works inside clarity, not something that replaces it.

PMP preparation can sometimes leave candidates with the impression that stepping back and letting the team decide is the safest response whenever a team situation appears. A more reliable habit is to read the scenario for boundaries before choosing a response. Has the team acted within its authority, at the edge of it or beyond it? Is the difficulty a gap in capability, a gap in information, or a limit that was never set? Does the situation involve compliance, safety, contractual or ethical matters that take it outside the team's remit? Practising that diagnosis across varied team situations is one of the more valuable parts of structured PMP® Exam Preparation, because the leadership response that fits a team working within its authority is rarely the one that fits a team that has gone beyond it.

On a live project, the same thinking shows up in small, practical signals. Decisions the team owns are still being brought to the project manager for permission. Surprises reach the sponsor before they reach the project lead. Choices are reversed without anyone explaining which boundary was crossed. Retrospectives discuss the work but never the limits of the team's authority. Each is a sign that empowerment has been announced rather than designed, and each is better fixed by clarifying boundaries and visibility than by taking decisions back.

An empowered team is not one its leader has stopped leading. It is one where the leader has done the harder work of making authority clear enough that people can use it with confidence, and results visible enough that accountability never has to be recovered after the fact.

Andre Malowney

Interested in going further?

Team scenarios rarely reward a single instinct such as "step back" or "take control"; they reward reading where a team's authority starts and stops before deciding how to respond. Structured PMP preparation gives you repeated practice at making that judgement across predictive, agile and hybrid situations.

For the empowered culture principle itself, and how it sits beside accountable leadership in The Standard, the PMBOK® Guide Eighth Edition is the source worth reading.

Ad · Amazon affiliate link.

References

A042: Why Telling the Team What to Do Is Often the Wrong PMP Answer
A198: When Collaboration Is Better Than Authority in PMP Scenarios
A146: Team Agreements: Small Document, Large Effect
A039: Servant Leadership in PMP: When It Fits and When It Doesn’t
A038: Accountable Leadership: Leading Without Command and Control

PMP and PMBOK are registered marks of the Project Management Institute, Inc.