Lead the Team in PMBOK 8 — Complete Guide

Article updated in March 2026 for the PMBOK® Guide — Eighth Edition.

Lead the Team in PMBOK 8 — Complete Guide

Formerly known as: Develop Team + Manage Team (PMBOK 6) — merged into one process in PMBOK 8

Two software project managers each inherited a technically capable but struggling team halfway through an 18-month development project. The first PM diagnosed the problem as a skill gap and immediately enrolled team members in technical training courses. The second PM sat with the team for a week — attending standups, reading the retrospective notes, having one-on-one conversations. The second PM’s diagnosis was different: the team had adequate skills, but no shared understanding of project purpose, no psychological safety to raise risks early, and a conflict between two senior developers that had been simmering for four months with no resolution. The first PM’s training investment produced marginal improvements. The second PM’s interventions — a team alignment session to reconnect the team to project purpose, a facilitated conflict resolution meeting, and a new escalation norm that rewarded early risk flagging — produced a measurable performance improvement within three sprints. Technical skills were never the constraint. Leadership was.

In PMBOK 8, Lead the Team is Process 4 of the Resources Domain, and it represents one of the most significant structural changes from PMBOK 6: the merger of the separate Develop Team and Manage Team processes into a single, unified process. This merger reflects the fundamental insight that team development and team management are not sequential activities — they are simultaneous, inseparable dimensions of the same leadership responsibility. Leading a project team means both improving its capability and directing its work, every day, throughout the project.

This complete guide covers every dimension of Lead the Team as defined in PMBOK 8:

• What it is — definition, the PMBOK 6 merger explained, and what changed
• Why use it — direct benefits and the cost of poor team leadership
• Full ITTO — every input, tool, technique, and output explained
• Step-by-step application guide — practical leadership framework for project teams
• When to apply it — triggers and continuous leadership responsibilities
• Two real-world examples — Project Phoenix (website launch) and Project ProjectAdm (SaaS PM platform)
• Templates and tools — with free downloads
• Five common errors — and how to avoid each one
• Tailoring — predictive, agile, and hybrid approaches
• Process interactions — what feeds into team leadership and what depends on it
• Quick-application checklist — 10 items you can use today

1. What Is Lead the Team

Lead the Team is the process of applying knowledge, skills, tools, and techniques for managing and leading the team by improving competencies, team member interactions, and the overall team environment to enhance project performance. This process also involves tracking team member performance, providing feedback, resolving and escalating issues, and managing team changes to optimize project performance. The key benefit of this process is that it influences team behavior, manages conflict, and resolves issues among team members.

In PMBOK 8, this is Process 4 of the Resources Domain. It is an execution process, performed throughout the project lifecycle — not a one-time planning activity. The process explicitly integrates two dimensions of leadership that were previously treated as separate processes in PMBOK 6:

• Management activities: Focus on the means of meeting project objectives, including effective processes, planning, coordinating, measuring, and monitoring work.
• Leadership activities: Focus on people, encompassing influencing, motivating, listening, enabling, and other activities related to leading the project team — all of which are important in delivering the intended project outcomes.

The PMBOK 6 merger: why Develop Team + Manage Team became Lead the Team

In PMBOK 6, Develop Team and Manage Team were two separate processes:

PMBOK 8’s merger reflects the reality of experienced project management: the most effective project managers do not separate “developing the team” from “managing the team” in their daily practice. They influence, coach, direct, and develop simultaneously — in every standup, every one-on-one, every sprint retrospective, and every conflict resolution conversation.

Common aspects of team development in PMBOK 8

PMBOK 8 identifies the following common aspects of project team development that apply regardless of management approach:

• Vision and objectives: Communicated throughout the project; referenced when the team makes decisions and solves problems.
• Roles and responsibilities: Ensuring team members understand and fulfill their roles; identifying knowledge gaps and developing strategies to address them through training, mentoring, or coaching.
• Project team operations: Facilitating communication, problem-solving, and consensus building; developing a team charter and operating norms.
• Guidance: Directed to the overall team to keep everyone aligned; individual guidance on specific tasks or deliverables as needed.
• Growth: Identifying where the team performs well and where it can improve; setting improvement goals collaboratively; supporting individual skill development.

2. Why Use Lead the Team

The characteristics of high-performing project teams

PMBOK 8 identifies the following factors associated with high-performing project teams — factors that effective leadership can cultivate:

• Open communication: An environment that fosters open and safe communication allows for productive problem-solving, brainstorming, trust, and collaboration. Psychological safety — the belief that one can speak up without punishment — is the single most consistent predictor of team performance.
• Shared understanding: When team members share the same understanding of the project’s purpose and goals, decisions are faster, alignment is more natural, and conflicts are resolved against a common reference point.
• Shared ownership: The more ownership team members feel over outcomes, the more likely they are to perform at a high level. Micromanagement destroys ownership; empowerment builds it.
• Trust: Teams composed of members who trust each other are more willing to do the extra work required for success. Trust is built through consistency, competence, and care — and it is destroyed much faster than it is built.
• Collaboration: Teams that work together rather than in silos generate more diverse ideas and deliver better outcomes.
• Adaptability: Teams that can adjust the way they work to their environment are more effective in changing conditions.
• Resilience: When issues or failures occur, high-performing teams recover quickly. Resilience is built through retrospectives, psychological safety, and a culture that treats failure as information rather than evidence of incompetence.
• Empowerment, delegation, and autonomy: Team members who feel empowered to make decisions about how they work perform better and have higher satisfaction than those who are micromanaged.
• Recognition: Team members who are recognized for their contributions continue to perform well. Recognition reinforces positive behaviors and demonstrates that leadership sees and values the team’s effort.

The cost of poor team leadership

• Team attrition: Talented people leave projects — and organizations — where they feel unseen, unsupported, or micromanaged. The cost of replacing a senior developer in a software project is typically 50–150% of their annual salary in recruitment, onboarding, and productivity loss.
• Conflict escalation: Unaddressed interpersonal conflicts consume team energy, slow decision-making, and poison team culture. Conflicts that could have been resolved in a single facilitated conversation in week two become team fractures by week twelve if they are ignored.
• Performance decline: Teams without clear leadership lose direction. Unclear roles, unresolved conflicts, and absent feedback generate anxiety and disengagement that translate directly into lower output quality and velocity.
• Risk concealment: In environments without psychological safety, team members do not raise risks early. They wait until the risk has materialized into an issue — because the cost of being wrong about a risk is lower than the perceived cost of speaking up.

3. Inputs, Tools & Techniques, and Outputs (ITTO)

The following table presents the complete ITTO of the Lead the Team process as defined in PMBOK 8 (p. 190):

Key tools explained

Conflict management: The structured process of identifying, analyzing, and resolving conflicts between team members or between the team and external stakeholders. PMBOK 8 recognizes five conflict resolution approaches: withdraw/avoid (temporary measure for low-stakes conflicts), smooth/accommodate (yield to the other party’s perspective), compromise/reconcile (find middle ground), force/direct (one party’s position wins — appropriate for urgent, safety-critical decisions), and collaborate/problem solve (joint exploration of all positions to find a solution that satisfies all parties — the highest-quality outcome but most time-intensive). The PM’s judgment in selecting the appropriate conflict resolution approach for each situation is a core leadership competency.

Emotional intelligence: The ability to identify, assess, and manage one’s own emotions and the emotions of team members and stakeholders. High emotional intelligence in a PM contributes to better conflict resolution, stronger trust-building, more effective motivation, and greater capacity to operate in high-stress or ambiguous project environments. PMBOK 8’s inclusion of emotional intelligence as a specific tool reflects the body of research demonstrating its correlation with leadership effectiveness.

Servant leadership: A leadership philosophy in which the leader’s primary role is to serve the team — removing obstacles, providing resources, protecting the team from organizational interference, and enabling team members to do their best work. Servant leadership is particularly effective in agile and hybrid contexts where self-organizing teams require enablement rather than direction.

Tuckman ladder: The Forming-Storming-Norming-Performing-Adjourning model of team development. Understanding where the team is in this developmental progression allows the PM to apply the appropriate leadership style: directive during Forming (team needs clarity), facilitative during Storming (team needs conflict resolution and norm-setting), coaching during Norming (team is building its working patterns), and delegating during Performing (team is self-managing). Applying a directive style to a Performing team creates unnecessary friction; applying a delegating style to a Forming team creates confusion and anxiety.

Retrospectives: Structured team reflection events that examine what went well, what could be improved, and what specific actions the team will take to improve. Retrospectives are the primary mechanism for continuous team improvement in agile environments and are a valuable practice in any project approach. Retrospectives that produce specific, actionable commitments (not just general observations) drive measurable team performance improvements.

Recognition and rewards: Formal and informal acknowledgment of team member contributions and performance. Recognition must be tied to specific behaviors and outcomes (not generic praise), delivered in the appropriate format for the individual (public vs. private, material vs. intrinsic), and consistent (sporadic recognition is less effective than systematic acknowledgment of effort and achievement).

Individual and team assessments: Structured tools for evaluating team member and team performance, including personality assessments (MBTI, DiSC), 360-degree feedback instruments, team health checks, and sprint-level velocity analysis. Assessments provide objective data to supplement the PM’s observations and support more evidence-based development planning.

4. Step-by-Step Application Guide

Step 1 — Diagnose the team’s current state

Before applying any leadership intervention, diagnose the team’s current developmental stage (using the Tuckman ladder or similar framework), current performance level, existing conflicts, motivation drivers, and communication patterns. A team in the Storming phase needs different leadership than a team in Performing. A team with a persistent unresolved conflict needs conflict resolution before any other leadership intervention will be effective.

Step 2 — Establish and reinforce vision and objectives

Communicate the project’s purpose and objectives clearly and repeatedly. Connect the team’s daily work to the project’s value proposition. Teams that understand why they are doing what they are doing make better decisions, deliver higher-quality work, and sustain motivation through difficult phases of the project. Vision reinforcement is not a one-time kickoff activity — it is a recurring leadership responsibility throughout the project.

Step 3 — Build psychological safety actively

Create conditions in which team members can speak up about risks, issues, and ideas without fear of punishment or ridicule. Concrete practices: acknowledge and thank people when they raise problems early (even if the problem turns out to be minor); share your own uncertainty and learning openly; never punish the messenger; model the behavior you want to see (raise your own risks and uncertainties explicitly). Psychological safety does not emerge automatically — it is built through consistent leadership behavior over time.

Step 4 — Track performance and provide structured feedback

Monitor team member performance against their defined roles and responsibilities. Provide feedback regularly — both positive feedback for strong performance and developmental feedback for performance gaps. Effective feedback is specific (tied to observable behaviors or outcomes, not personality), timely (delivered close to the event), and actionable (focused on what the person can do differently). Avoid the two most common feedback failures: providing only positive feedback (deprives people of the information they need to grow) or providing only critical feedback (destroys motivation and trust).

Step 5 — Manage conflicts proactively and directly

Address conflicts early. The longer a conflict goes unaddressed, the more entrenched positions become and the higher the energy cost of resolution. For interpersonal conflicts between team members: facilitate a structured conversation where both parties articulate their perspective, identify common ground, and agree on specific behavioral changes. Document the agreement. Follow up within two weeks to assess whether the agreement is being honored. If it is not, escalate to the sponsor or HR as appropriate.

Step 6 — Conduct retrospectives and act on their outputs

Facilitate retrospectives at the end of each project phase or sprint. Use a structured format (e.g., Start-Stop-Continue, Four L’s, or the Sailboat retrospective) to elicit specific, honest feedback from all team members. Commit to at most three specific improvement actions per retrospective — more than three creates implementation fatigue. Follow up on previous retrospective actions before opening new ones. A retrospective that produces no changes is a waste of time that destroys team trust in the retrospective process itself.

5. When to Apply the Process

Lead the Team is a continuous process, applied throughout the entire project lifecycle. Unlike most planning processes that are performed once or at defined intervals, team leadership is a daily activity. However, specific events require heightened leadership attention:

• Team onboarding: When new team members join (at project start or mid-project), dedicated onboarding investment prevents the costly performance dip that occurs when new members are insufficiently integrated.
• Transition between project phases: Phase transitions often change team composition, work patterns, and success metrics. Active leadership through these transitions prevents the regression to Storming that commonly occurs when teams change their operating context.
• When performance metrics indicate decline: Velocity drops, quality metrics deteriorate, or team members begin disengaging are all signals that require an immediate leadership diagnosis and response.
• When conflicts surface: Conflicts must be addressed immediately, not allowed to age. The longer the wait, the higher the cost.
• After failures or setbacks: Missed milestones, failed inspections, or major rework events require leadership to process the failure constructively — extracting lessons, rebuilding confidence, and preventing the demoralization spiral that makes the next failure more likely.

6. Practical Examples

Example 1 — Website Launch: Project Phoenix

Context: TechCorp PM Alex Morgan PMP is managing Project Phoenix for CEO Sarah Chen. Budget: $72,250. Duration: 90 days. Team: PM, two developers, one designer, one inbound analyst.

How Lead the Team was applied:

At project kickoff, Alex facilitated a 2-hour team alignment session using the Tuckman ladder as a conceptual framework. The team was new to each other (Forming stage), so Alex’s leadership approach was primarily directive: clear role definitions from the RACI matrix, explicit sprint norms from the team charter, and a shared project purpose statement that connected the technical deliverables to the client’s business outcome (“our work directly determines whether Sarah Chen’s company captures or loses $180,000 in annual qualified leads”).

The first three sprints revealed a creative tension between the designer and the senior developer: the designer wanted visual polish that the developer felt was technically over-engineered for the performance requirements. Alex diagnosed this as a Storming-stage conflict rooted in legitimate competing professional values, not a personality clash. Alex facilitated a 45-minute structured conversation where both parties articulated their perspective. The resolution: designer would produce two variants (a visually optimal and a performance-optimal version) for any element where the tension arose, and the PM would make the final trade-off decision based on the client’s documented priorities. This agreement eliminated the recurring friction in less than 48 hours and was documented as a new team norm in the team charter.

In Sprint 4, Alex conducted individual performance check-ins with all five team members. The inbound analyst flagged that she was concerned about being underutilized in the early sprints and was worried about losing engagement. Alex adjusted the analyst’s involvement: from Sprint 4, she was included in sprint planning as a subject-matter expert on marketing automation configuration, giving her a meaningful contribution to the technical sprints rather than waiting for Sprint 5 when her primary workstream began. Engagement recovered immediately.

Result: Project Phoenix delivered with zero team attrition, the conflict between the designer and developer resolved in Sprint 1, and the analyst’s engagement maintained through a proactive adjustment. Sarah Chen’s end-of-project survey gave the team a 9.2/10 satisfaction score — explicitly citing “a team that clearly cared about the outcome, not just the deliverable.”

Example 2 — SaaS PM Platform: Project ProjectAdm (Software Development)

Context: Eduardo Montes (CEO/PM) leading ProjectAdm with 8 developers, 1 UX/UI designer, 1 QA engineer. Duration: 18 months. The team is building a project management platform and using it to manage their own project.

How Lead the Team was applied:

Eduardo’s team leadership faced a unique challenge over an 18-month project: maintaining engagement and preventing burnout across a team that was simultaneously building and using the product they were creating. The dogfooding principle — using ProjectAdm to manage the ProjectAdm project — was itself a leadership instrument: team members who could see the direct impact of their features on their own daily work had a shorter feedback loop between their effort and its value, which sustained intrinsic motivation more effectively than any external recognition program.

Eduardo applied the servant leadership model consistently: every sprint planning, his first question was “what do you need from me this sprint?” rather than “what will you deliver?” He maintained a personal blockers log for each team member — documented in ProjectAdm — and spent the first 30 minutes of each sprint clearing the highest-priority blockers before addressing any other management activities.

In month 7, a significant conflict emerged between the lead back-end developer and the lead front-end developer over the API contract design for the Tasks module. Both had strong technical views, and the conflict had been running for three sprints without resolution, consuming energy in every sprint planning session. Eduardo applied the Six Thinking Hats® methodology for structured problem-solving: he facilitated a 90-minute session where both developers examined the API design from six perspectives (facts, creativity, optimism, caution, emotions, process). The structure prevented the conversation from becoming positional and produced a consensus design that incorporated elements from both approaches. The session was documented as a team process asset and was reused for two subsequent architectural disputes.

Eduardo ran bi-weekly retrospectives using the Start-Stop-Continue format. Over 36 sprints, the retrospectives produced 108 improvement actions, of which 94 were fully implemented and 14 were deprioritized with documented rationale. The retrospective process was cited in the project close-out survey by seven of ten team members as the most valuable project management practice they had experienced.

Result: Zero developer attrition across 18 months in a competitive talent market. Sprint velocity increased 22% between Sprint 1 and Sprint 18, driven entirely by process improvements identified in retrospectives. The team’s NPS of the project management experience was 8.7/10 at project close.

7. Free and Recommended Templates

8. Five Common Errors — and How to Avoid Each One

Error 1 — Waiting for conflicts to resolve themselves

Why it happens: PMs are uncomfortable with interpersonal conflict and hope that tensions will dissipate naturally. Unaddressed conflicts almost never resolve themselves — they escalate until they damage team performance or cause attrition.

How to avoid it: Treat conflict as a diagnostic signal, not a problem to avoid. Every unresolved conflict is consuming team energy that should be directed at project work. Commit to addressing any identified conflict within 5 business days of its observation. Use a structured facilitation approach rather than hoping that stakeholder relationships will self-correct.

Error 2 — Treating team development as a one-time activity

Why it happens: PMs run a team-building workshop at project kickoff and consider team development “done.” Team development is continuous. Teams regress through Tuckman stages when members change, when the work context shifts, or when significant stress events occur.

How to avoid it: Build structured team development activities into the project rhythm: retrospectives at the end of every sprint or phase, regular individual check-ins with team members, periodic team health assessments, and deliberate leadership investment at every stage transition.

Error 3 — Applying the same leadership style to all team members

Why it happens: PMs default to a single management style regardless of the team member’s skill level, motivation, or developmental stage. A highly skilled and self-motivated senior developer needs a very different leadership approach than a talented but inexperienced junior developer on their first project.

How to avoid it: Apply situational leadership: adjust the directive/supportive balance for each team member based on their competence and commitment for each specific task. High competence + high commitment = delegate. Low competence + high commitment = direct and teach. High competence + low commitment = support and re-engage. Low competence + low commitment = direct intensively and address motivation root cause.

Error 4 — Recognition that is generic, delayed, or inconsistent

Why it happens: PMs are busy and recognition feels less urgent than delivery. Generic and delayed recognition (“good job, everyone”) is at best ineffective and at worst perceived as patronizing.

How to avoid it: Recognition must be: specific (tied to a named outcome or behavior), timely (delivered within 48 hours of the event), individual (personalized to how the person prefers to receive recognition — some prefer public acknowledgment, others prefer private), and proportionate (calibrated to the scale of the contribution). Include recognition as a standing agenda item in sprint reviews and status meetings.

Error 5 — Conducting retrospectives that produce no changes

Why it happens: Retrospectives become “gripe sessions” that surface complaints but produce no commitments. Or they become theater — the team says what they think the PM wants to hear rather than articulating genuine improvement opportunities.

How to avoid it: A retrospective without specific, assigned, time-bound action items is not a retrospective — it is a meeting. Every retrospective must close with at most three specific improvement commitments: what will change, who owns the change, and by when. Begin the next retrospective by reviewing the previous session’s commitments. If the commitments were not honored, that is the first item to address — not a new list of observations.

9. Tailoring: Predictive, Agile, and Hybrid

10. Process Interactions

11. Quick-Application Checklist

• ☐ Team’s current Tuckman stage has been diagnosed and leadership style adjusted accordingly
• ☐ Project vision and objectives have been communicated to the team and are referenced in daily work
• ☐ Psychological safety norms have been explicitly established and are modeled by the PM
• ☐ Individual performance feedback is being provided regularly and specifically
• ☐ Active conflicts have been identified and a resolution timeline is in place
• ☐ Retrospectives are conducted at defined intervals and produce specific action commitments
• ☐ Recognition and rewards are tied to specific behaviors and delivered in the preferred format for each team member
• ☐ Individual development plans are in place for team members with identified skill gaps
• ☐ Team performance assessments are documented and informing leadership decisions
• ☐ Team charter is current and being used as an active reference in team interactions

Call to Action:

References

Project Management Institute (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition. Newtown Square, Pennsylvania, USA: Project Management Institute, 2025.

PMBOK Guide 8: The New Era of Value-Based Project Management. Available at: https://projectmanagement.com.br/pmbok-guide-8/

Disclaimer

This article is an independent educational interpretation of the PMBOK® Guide – Eighth Edition, developed for informational purposes by ProjectManagement.com.br. It does not reproduce or redistribute proprietary PMI content. All trademarks, including PMI, PMBOK, and Project Management Institute, are the property of the Project Management Institute, Inc. For access to the complete and official content, purchase the guide from Amazon or download it for free at https://www.pmi.org/standards/pmbok if you are a PMI member.