Leading the Project Team for the PMP: Leadership Styles, Empowerment and Team Roles

Leading the project team means creating the conditions in which the people doing the work can do their best work together: clear shared expectations, real authority over how they work, a leader who solves problems with them and speaks up for them, room for every member to contribute, and roles nobody has to guess at. It is a People task, and it applies whether the project is predictive, agile or hybrid; only the vocabulary changes.

The official task lists seven enablers. Each one maps to a habit you can practise:

A common thread runs through all seven: understand before acting, involve the team before deciding for it, and work through the agreed process before going around it. Neighbouring tasks own related material: building a shared vision, managing conflict and engaging stakeholders each have their own lesson.

Team-level expectations are set by the team itself in a team charter, often called a working agreement in agile teams (the Agile Practice Guide itself uses "team charter"): a short, visible document of the team's values, ground rules and working norms. Typical contents are core hours and response times, where decisions are recorded, how meetings run, the definition of done, how disagreement is raised and how decisions are made.

Why the team writes it

Norms people helped create are norms they own and enforce on each other. The project manager facilitates the drafting rather than authoring it: rules handed to a team from outside, however sensible, tend to be followed reluctantly and enforced only by the manager. The agreement is a team artefact, distinct from the project's management plans; the communications management plan, for instance, covers stakeholder information flows, not team behaviour.

A living document

• Revisit it when conditions change. New members, a new time zone, a new product area or a norm that keeps being missed are signals to rework the agreement with the team, usually at a retrospective, rather than enforce a rule that no longer fits.
• Bring newcomers into it. Walk a new member through the agreement and invite suggestions, so they join the norms instead of just signing them. A wholesale rewrite every time one person joins is unnecessary.
• A norm stands until the team changes it. If someone disagrees with a rule, the route is to raise it with the team (the retrospective is the natural forum) while the rule continues to apply. Granting a one-person exemption, or punishing the dissenter, both undermine the agreement.

When one person misses an expectation

The sequence PMP questions reward is calm and stepwise:

1. Talk privately to understand the cause. A change in behaviour from someone who used to meet the norm usually has a reason, and you cannot fix what you have not understood.
2. Clarify. Unclear priorities or expectations are often the cause; fix that first.
3. Agree a specific improvement plan with measurable steps and checkpoints if the problem continues.
4. Escalate (for example to the functional manager in a matrix organization) only when the agreed plan has not worked.

Any first move that penalises or exposes the person before the cause is known punishes before it diagnoses.

Empowering the team means the people doing the work decide how to do it and who picks up which piece, while the leader sets context, removes obstacles and protects agreed limits. In agile teams this is self-organization: developers choose and pull their own work during planning or from a Kanban board, instead of the project manager, a team lead or a functional manager allocating tasks.

Stakeholders who want predictability are given visibility (the board, the forecast, the team calendar), not control over who on the team does each card.

Empowerment in predictive work

Self-organization is not only an agile idea. In a predictive project, the engineers closest to a work package are usually best placed to decompose it into activities and sequence them. The project manager can delegate activity planning within each work package while the scope, schedule and cost baselines stay under formal change control. Delegating how the work is done is different from letting the team change the baselines.

Decision rights

Telling a team to "just decide" is not empowerment; unclear authority produces either paralysis (the team asks permission for everything) or overreach. Make decision rights explicit:

• Agree with the team which decisions it owns, within which limits, and which stay with a named approver.
• Tools such as a delegation board (delegation poker, from Management 3.0) record, per decision area, how much authority sits with the team, from "the leader decides and tells" up to "the team decides alone".
• Governance sets the outer boundary. Where regulation, safety, security, licensing or contracts require a named authority to approve something, that approval stays where it is; everything inside the boundary can be delegated. Stretching the authority's reach beyond what governance requires starves the team of autonomy; relocating a mandated approval breaks compliance.

When a delegated limit is crossed

When a team oversteps its delegated authority, first work out with the team why the step was missed: was the limit unclear, invisible in the workflow, or ignored? Pulling authority back before the cause is known may feel safe, but it removes empowerment without fixing anything. Changes to the process or the delegation come after the analysis.

The appropriate leadership style is the one that fits the team and the situation in front of you, and for PMI the default stance is servant leadership, adapted using a situational reading of each person's competence and commitment.

Servant leadership

A servant leader puts the team's needs first and leads by enabling rather than commanding. In practice that means:

• Removing obstacles the team raises and shielding it from distractions.
• Coaching and growing people, including handing over responsibilities members want to learn, with coaching, as soon as they are ready to try them.
• Stepping out of the centre. Team events belong to the team, and progress information should come from transparent artefacts the team already keeps rather than from people reporting to the leader in person.

Behaviours that signal command-and-control instead: assigning daily tasks, approving every story before work starts, or reporting each person's output upward.

Situational leadership

The situational model (Hersey and Blanchard, later Blanchard's Situational Leadership II) says the leader's mix of direction (telling how) and support (encouraging, listening, involving) should match the follower's development level on this specific task.

Two consequences matter most. First, the style follows the person and task, not their seniority or job title: high skill with wavering commitment calls for support, not more instruction. Second, the style should shift as the team grows. A leader who keeps directing long after people could take more on keeps them dependent; the aim is to hand decisions back as competence and confidence grow, until the team can organize itself.

Other labels you may meet (transactional, transformational, democratic, laissez-faire, autocratic) describe broad tendencies; the PMP-relevant skill is choosing deliberately and adapting.

Tuckman's model describes five stages a team typically moves through, and recognising the stage tells the leader what the team needs next.

The stages are not one-way. A mature, performing team can drop back to storming when it gains new members, takes on new work or loses a key person: renewed friction over how the work should be done is the typical sign. Because the friction belongs to the team rather than to any one person, the leader involves the whole team in revisiting how it works together.

The stage model pairs naturally with situational leadership: forming tends to need directing, storming coaching, norming supporting and performing delegating. PMBOK also references other team-development models (for example Drexler/Sibbet); the PMP-relevant skill is diagnosing where the team is and adapting.

Emotional intelligence (EI) is the ability to recognise and manage your own emotions and to read and influence other people's, and it underpins every other leadership behaviour in this task. The widely used four-quadrant model (popularised by Daniel Goleman, and described in the PMBOK Guide) splits it into two "self" and two "others" competencies:

The near-twin pairs are the ones to separate carefully. Self-awareness is recognising your own reaction; self-management is acting on that recognition to control it. Social awareness is perceiving someone else's state; relationship management is the action that follows. When a strong reaction arrives at a bad moment, self-management means regaining composure before acting, so that the emotion does not make the decision for you.

Solving problems as a team leader means finding the real cause with the people closest to the work, using data, before anyone commits to a fix. Jumping to a solution, even a plausible one the leader suspects, risks fixing the wrong thing and teaches the team that analysis is optional.

1. Gather the data. Defect logs, cycle times, velocity trends, inspection results.
2. Facilitate root-cause analysis with the team. Techniques include the five whys, cause-and-effect (Ishikawa/fishbone) diagrams and Pareto analysis. The leader facilitates; the team supplies the knowledge.
3. Prioritise by impact. When the team can only absorb a limited amount of improvement at once, rank the causes by the data (for example, how many defects each caused, Pareto-style) and tackle the biggest first. Ranking by opinion replaces evidence, and ignoring the capacity the team agreed overloads it.
4. Choose and trial the fix, then check the data again.

Pressure to decide quickly between competing proposals from senior people is exactly when this sequence matters most. Any shortcut that settles the question before the cause is understood skips the analysis, however senior the source of the proposal. In agile teams the retrospective is the built-in forum for this; in predictive projects quality-management tools serve the same purpose.

Problem solving here is about work problems. Interpersonal conflict between members has its own task and lesson.

Representing the voice of the team means the project manager carries the team's evidence, concerns and constraints to the people who can act on them, and negotiates on the team's behalf rather than passing pressure straight through. The usual counterparts are sponsors, functional managers and the PMO.

• Functional managers. If team members are repeatedly pulled away mid-iteration, discuss the impact directly with the functional manager who controls their time: go to the person who owns the constraint before working around it or escalating past them.
• Sponsors and dates. When a sponsor wants an earlier date than the team's bottom-up estimates support, present the estimates and realistic options (scope, resources, phased delivery) and their trade-offs. A promise the team's evidence does not support trades its credibility and wellbeing for a date.
• PMOs and process burdens. When a mandated process costs the team significant time and duplicates information it already maintains, take the problem to the process owner with an alternative that still meets the owner's real need, such as a report generated from existing board data. Workarounds that leave the process itself unchanged do not solve the problem.

The pattern is advocacy through the right channel: understand the requester's underlying need, bring data from the team, and propose something that serves both.

Supporting the team's varied experiences, skills and perspectives means designing how the team works so that everyone can contribute, whatever their location, schedule, culture, seniority or communication style. The key enabler is psychological safety: a shared belief, described by Amy Edmondson, that it is safe to speak up, admit mistakes and raise risks without being blamed or embarrassed.

Inclusive facilitation

• Change the format, not the people. If some voices dominate, use structured techniques that give everyone a turn (round-robin, silent brainstorming, written input before discussion). The imbalance lives in the format, so that is what to change.
• Respect different norms for disagreement. Where open disagreement in meetings is culturally uncommon, offer written or anonymous input before decisions and agree team norms on how disagreement is shared.
• Design for distance and part-time members. Asynchronous decision windows (proposals posted in a shared channel with a comment period) let people in other time zones or on different hours shape decisions without adding meetings. The test is whether every affected member could shape the decision before it was made.

Psychological safety in practice

• Blameless reviews. After an incident or mistake, review how the process allowed it, not who to blame. A hunt for the culprit teaches people to hide mistakes until someone else finds them, and the learning only comes from actually examining the process.
• Model fallibility. Leaders who share their own mistakes and what they learned make it acceptable for others to do so.
• Reward early bad news. Publicly thanking people for raising problems early reinforces the behaviour. Anything that makes raising a problem feel like a mark against you signals the opposite.

Psychological safety is not lowered standards: the team still holds itself to its agreements. It means problems surface while they are still cheap to fix.

Clear roles and responsibilities mean every team member knows what they do, what they decide and whom they consult, so work is neither duplicated nor dropped. Predictive projects usually document this in a responsibility assignment matrix (RAM), most often in RACI form; agile teams rely on well-understood accountabilities.

RACI

Typical fixes: disputed or duplicated approval is resolved by agreeing on one accountable person per activity. When too many people are "C", decisions stall; revisit the matrix so only the experts the activity genuinely needs are consulted and the rest are informed. Other charts answer different questions: a resource histogram shows resource loading over time, and an organizational breakdown structure maps work packages to organizational units.

Agile and hybrid accountabilities

Two consequences come up often. If anyone other than the product owner reorders the backlog directly, developers receive conflicting priorities; reconfirm the product owner as the backlog decision-maker and route other input through that person. And if the product owner pushes for more items than the developers believe they can deliver, the project manager supports the developers in setting the forecast: the product owner chooses what, the developers judge how much. In a hybrid project these agile roles sit alongside predictive ones, so make the boundary explicit for each stream.