Developing the team: stages, safety and knowledge transfer

Putting capable people together does not automatically produce a capable team. Teams develop: they learn how to work together, build trust, settle disagreements and gradually become more than the sum of their members. Project managers can speed this process or slow it. This lesson goes beyond the brief introduction in PMP-110 to look at how to diagnose a team's stage of development, what high-performing teams have in common, why psychological safety matters so much, how to plan training, and how to ensure knowledge is transferred within the team and beyond it.

Diagnosing the team's stage

Bruce Tuckman's model, first published in 1965 and extended with a fifth stage in 1977, remains the best-known description of team development: forming, storming, norming, performing and adjourning. Its value for project managers lies less in memorizing the names than in recognizing the signals of each stage and responding appropriately. Teams do not always move neatly forward; a change in membership, leadership, scope or pressure can send a team back to an earlier stage.

Other models complement Tuckman. The Drexler/Sibbet team performance model describes seven stages from orientation and trust building through goal clarification, commitment, implementation and high performance to renewal. Katzenbach and Smith distinguish working groups, pseudo-teams, potential teams, real teams and high-performance teams, arguing that a real team has a small number of people with complementary skills, a common purpose, performance goals and an approach for which they hold themselves mutually accountable. These models agree on the essentials: clear purpose, trust, agreed ways of working and mutual accountability.

What high-performing teams have in common

PMI material and team research converge on a set of characteristics that distinguish high-performing teams. They include open communication, shared understanding of goals, shared ownership of outcomes, trust, collaboration, adaptability, resilience, empowerment and recognition. Google's Project Aristotle study of its own teams, published in 2015, found that the most important factor was psychological safety, followed by dependability, structure and clarity, meaning (the work is personally important) and impact (the work matters).

Patrick Lencioni's model of the five dysfunctions of a team offers the reverse view. It describes a pyramid of problems, each building on the one below: absence of trust, fear of conflict, lack of commitment, avoidance of accountability and inattention to results. A team that does not trust its members avoids honest debate, so its decisions are not really bought into, so people do not hold each other to account, so individual or departmental goals take precedence over team results. The model is popular because it gives leaders a sequence to work on: build trust first.

Psychological safety

Amy Edmondson defines psychological safety as a shared belief that the team is safe for interpersonal risk taking. In a psychologically safe team, people can ask questions, admit mistakes, raise concerns and offer half-formed ideas without fear of being embarrassed, rejected or punished. It is not the same as being nice, lowering standards or avoiding disagreement. Edmondson's research found that high-performing hospital teams reported more errors, not fewer, because they felt safe to report them; the errors were caught and learned from.

Psychological safety matters especially on projects, where uncertainty is high and early warning of problems is valuable. A team member who fears blame will hide the fact that a component is behind schedule until it is too late to recover. A team that is safe will raise it at the stand-up while there is still time to help.

Project managers build psychological safety through specific behaviors. Frame the work as a learning problem: "This is new for all of us, and we will need everyone's eyes on it." Acknowledge your own fallibility: "I may be missing something; what do you see?" Model curiosity by asking lots of questions. Respond productively when people raise problems: thank them, focus on the issue rather than the person and act on it. Use blameless reviews that ask what in the system allowed a problem to occur, not who caused it. And deal firmly with behavior that undermines safety, such as ridicule or interruption.

Training and development

Training is one of the most direct ways to develop a team. It can address gaps found in the skills matrix (lesson 3), prepare people for new tools or methods, meet compliance requirements and support individual career goals. Training can be formal (classroom, online courses, certifications) or informal (pairing, job shadowing, mentoring, lunch-and-learns, communities of practice). On projects, informal methods are often faster and more relevant, while formal training suits regulated or highly technical skills.

Plan training in the resource management plan, including who needs what, when, how it will be delivered and how much it will cost. Time training so it happens just before the skill is needed: too early and people forget; too late and they learn on the job under pressure. Remember that training costs are project costs if the skill is needed specifically for the project; general development may be funded by functional departments.

Knowledge transfer

The ECO task "help ensure knowledge transfer" has three enablers: identify knowledge critical to the project, gather knowledge and foster an environment for knowledge transfer. Knowledge is often described as explicit (it can be written down, such as procedures, designs and lessons learned) or tacit (it lives in people's heads and is hard to express, such as judgment, relationships and know-how). Explicit knowledge can be transferred through documents and repositories; tacit knowledge needs interaction, such as pairing, mentoring, storytelling and communities of practice.

Knowledge transfer is not only an end-of-project activity. Lessons learned should be captured throughout the project, not just at closure when people have forgotten the details and are already moving on. Agile retrospectives make this routine. Knowledge transfer also flows outward: to operations teams who will support the product, to users who will adopt it and to future projects through the organization's process assets. PMP-131 covers the process side of knowledge management; here the focus is the environment. People share knowledge when they trust each other, when sharing is recognized and when they have time to do it.

Knowledge transfer can have legal dimensions. On US federal and state projects, records about decisions may be subject to records management requirements and freedom of information laws, so decision records should be accurate and stored in approved repositories. Where contractors leave a project, contract terms on data rights and documentation should be checked before they go.

Team-building activities

Team-building activities range from a coffee chat at kickoff to a day-long offsite. They help most in the forming and storming stages, when people are getting to know each other, and when they are tied to real work. A workshop where the team builds its charter is team building; so is a joint problem-solving session or a celebration after a milestone. Forced fun that ignores people's preferences or excludes some members, for example evening drinks that parents and non-drinkers cannot comfortably attend, can do more harm than good. Ask the team what it values and vary the activities.

Co-location is the traditional way to build team cohesion: placing members in the same physical space, sometimes in a dedicated team room (a "war room" or "obeya"). It supports informal communication and rapid problem solving. When co-location is not possible, lesson 10 discusses how to build the same connections virtually.