PMP guidePeople domain
Leading the Team on the PMP: Servant Leadership, Empowerment, and Ground Rules
How the 2026 PMP outline tests team leadership: choosing a style for the situation, empowering a team without leaving it alone, building a team charter, keeping the vision current, and transferring knowledge.
Short answer
The 2026 PMP outline expects you to match your leadership style to the situation instead of using one style everywhere. Servant leadership, where you remove obstacles, coach, and let the team decide how to do its work, is the usual fit for a capable team, especially an agile one. A more directive style fits a new team that needs structure, an emergency, and any safety or compliance issue. Around that choice, People Tasks 1, 3, and 7 test whether you keep a shared vision current, set clear roles and team expectations, speak up for the team, and keep critical knowledge from leaving with one person.
What People Tasks 1, 3, and 7 cover on the PMP
Three People tasks in the 2026 Exam Content Outline (revised August 11, 2026) describe leading the team itself. The People domain carries 33% of the exam.
- Task 1, a common vision. Everyone working on or sponsoring the project understands what it is for, and that understanding survives change.
- Task 3, leading the project team. The broadest of the three. It covers how you share authority with the team, how you make sure everyone knows their part, and which leadership style you bring to the team in front of you.
- Task 7, knowledge transfer. Making sure what the project knows does not depend on any one person.
Conflict (Task 2) and the stakeholder tasks have their own guides: PMP conflict management and PMP stakeholder engagement.
Servant leadership on the PMP, and where it stops
Robert K. Greenleaf introduced the term "servant leadership" in a 1970 essay. The Greenleaf Center summarizes his test for it as a question: "Do those served grow as persons?" The 2020 Scrum Guide uses the same idea for the Scrum Master, describing Scrum Masters as "true leaders who serve the Scrum Team and the larger organization." Their service includes coaching team members in self-management and causing the removal of impediments to the team's progress.
In PMP scenarios, servant leadership looks like clearing blockers the team cannot clear itself, coaching instead of instructing, and letting the people doing the work decide how to do it. It is not stepping back from everything. A servant leader still sets direction for a new team, steps in during a crisis, and holds firm on safety, legal, and compliance requirements. Telling these apart takes practice on explained items, which is why the PMP page lists an explanation for every answer, right or wrong, as part of the planned full prep.
Matching a leadership style to the PMP situation
| Situation in the stem | Style that fits | What you do | When to shift |
|---|---|---|---|
| A new team with unclear roles | Set direction | Define roles, agree on a team charter, set near-term goals | As soon as the team runs its own routines |
| A capable, self-managing team | Step back and remove blockers | Let the team plan its work, and deal with what slows it down | When it hits a problem outside its authority |
| A team in friction or low trust | Facilitate | Run the conversation, surface the issue, help the team agree | When the team resolves issues without you |
| An emergency, such as an outage or a safety incident | Direct, briefly | Make the immediate calls and assign clear actions | Once the situation is stable, then debrief together |
| A skilled team that is new to the approach | Coach | Teach the practice, then let the team apply it | When the team uses it unprompted |
These labels describe behaviors, not a formal model. The same leader moves between them as the team and the situation change. One of the 20 free PMP practice questions tests the emergency row, set during an overnight cutover.
Empowering a PMP team without abandoning it
The Scrum Guide describes Scrum Teams as self-managing, meaning they "internally decide who does what, when, and how." The Agile Manifesto's principles make a similar point: build projects around motivated people, give them the environment and support they need, and trust them to get the job done. Empowerment in this sense is real authority over the work.
Empowerment fails in two directions. If you keep deciding for the team, it never takes ownership. If you hand over decisions without a goal, constraints, or support, the team is not empowered, just left alone. Clear decision boundaries prevent both. Here is an example for a fictional hybrid team building a warehouse management system:
| The team decides | The team decides, then informs | Escalate through governance |
|---|---|---|
| How to split stories into tasks and who takes them | Changes to the iteration plan that affect another team | Scope changes beyond the agreed release goal |
| Technical approach inside agreed architecture standards | Moving an unfinished story into the next iteration | Spending above the threshold governance sets |
| Its own working agreements | Changes to the Definition of Done | Any exception to a compliance requirement |
With boundaries like these, "empower the team" becomes concrete. The team knows what it owns, and you know when to step in.
Building a PMP team charter and ground rules
A team charter is the team's written agreement about how it will work. It usually includes:
- Purpose and goals. Why the team exists and what success looks like.
- Roles and responsibilities. Who owns which decisions, including people from vendors or other departments.
- Working agreements. Meeting habits, response times, core hours, and how work is reviewed.
- Decision-making. How the team decides, and what happens when it cannot agree.
- Conflict process. How disagreements are raised and handled.
The team should write it, because people keep agreements they made. It should also change. The Scrum Guide's Sprint Retrospective inspects "individuals, interactions, processes, tools," and the Definition of Done, and the Agile Manifesto's last principle calls for the team to reflect regularly on how to become more effective and adjust.
Here is a short example for the same fictional team, which includes two developers from a vendor:
- Core collaboration hours are 10 a.m. to 2 p.m. Eastern for everyone, including vendor staff.
- Pull requests get a first review within one working day.
- Technical decisions are made by the developers. If they cannot agree within two days, the technical lead decides and records why.
- Anyone can call a pause when a discussion turns personal. The discussion resumes within 24 hours.
- The team reviews this charter at every retrospective and changes it by consensus.
Rule 3 settles roles and decision rights, a gap that can stall a team mixing employees and vendor staff. Rule 5 keeps the charter alive. With a working example in mind, write a five-rule charter for a team you know, then check it against the list above. Short, focused practice sets suit this kind of judgment, and the PMP page describes goal-based challenges such as a Perfect 10 run, planned for full PMP prep.
Keeping the PMP project vision current
A team can be busy and still build the wrong thing. Warning signs include features nobody asked for, priority arguments that are really arguments about purpose, and stakeholders who describe the project differently. When that happens, go back to the source. In Scrum terms, the Product Goal "describes a future state of the product" that the team plans against. Re-anchor on it, find where understanding split, and update the goal if the business has changed.
Knowledge transfer the PMP way
Task 7 is easy to underrate until the team changes. Take a fictional example. Two developers join a project halfway through, and the team's release steps and coding conventions exist only in people's heads. A workable plan follows the calendar:
| When | Action |
|---|---|
| Day 1 | Give each newcomer a buddy and list the steps that are written down nowhere |
| Week 1 | Newcomers shadow a release and turn what they see into a checklist |
| Week 2 | Each newcomer runs one release step while the buddy watches and corrects |
| After onboarding | Keep the checklist in the team's shared space and review it at each retrospective |
The last row turns onboarding into a habit, so knowledge doesn't depend on who happens to be in the room. Knowledge transfer also happens when a project or phase closes, through final lessons learned and retrospectives.
Five PMP leadership scenarios worked through
All people and projects below are fictional.
1. "Just tell us who does what." An agile team asks you to assign its tasks for the iteration.
- Strong response: coach the team to plan its own work, and facilitate the first planning session if needed. Assigning the tasks yourself undercuts self-management.
- Weaker responses: handing out assignments to save time, or leaving the team to sort it out with no help at all.
2. Vendor developers unsure of their role. Two vendor developers on a hybrid team keep waiting for their own manager's approval before acting on team decisions.
- Strong response: clarify roles and decision rights with the team and the vendor's manager, and record them in the team charter.
- Weaker responses: telling the vendor developers to ignore their manager, or escalating to the vendor's leadership before talking to the people involved.
3. The quiet expert. A new team member with relevant experience from another industry rarely speaks in planning.
- Strong response: draw out their view directly, for example with a round-robin in planning or by pairing them on a design spike. Varied perspectives only help a team that hears them.
- Weaker response: assuming silence means agreement.
4. A security alert mid-sprint. The monitoring team reports that a misconfigured test server may be exposing customer records, and the developers start debating causes in the team channel.
- Strong response: take direct control, start the organization's incident procedure, assign clear actions such as isolating the server and notifying the security lead, and communicate often. Afterward, return decisions to the team and hold a blameless review.
- Weaker response: seeking consensus in a long meeting while the exposure continues.
5. A milestone at risk. The team's own forecast shows the integration milestone slipping by three weeks, and two developers have started working late every night to close the gap.
- Strong response: represent the team's real capacity. Bring the sponsor options built on that capacity, such as resequencing or reducing scope for the milestone, and do not let the late nights become the plan. The Agile Manifesto's principles call for a sustainable pace that sponsors, developers, and users can keep up indefinitely.
- Weaker responses: letting the late nights continue until the milestone, or keeping the slip quiet until the date passes.
When you can explain why each strong response beats the alternatives, test the same reasoning in new situations. The PMP page sets the free and planned PMP practice side by side, so you can see what the free tools already cover. For how leadership questions shift between predictive and agile settings, see the guide to agile and hybrid PMP questions, and for the full domain map, the PMP People domain guide.
Trust the source
Official sources
Exam policies can change. Use these primary sources for the most current details.