5 Stages of Team Development with Examples

The five stages of team development are forming, storming, norming, performing and adjourning. They describe a pattern that many teams move through as people learn the work, test boundaries, agree on working habits, deliver together and eventually close the project.

Managers can use the model to decide what a team needs next. A new group may need clear roles. A group arguing about priorities may need a decision process rather than another team-building activity. An experienced group may need fewer check-ins and more freedom to solve problems.

The model is useful, but it is not a timetable. Teams do not spend a fixed number of weeks in each stage, and they can move backwards when the manager changes, a deadline slips or several new members join at once.

What is Tuckman’s model of team development?

Psychologist Bruce Tuckman described four stages of small-group development in his 1965 paper, “Developmental Sequence in Small Groups”: forming, storming, norming and performing. Tuckman and Mary Ann Jensen added adjourning in a 1977 follow-up paper.

In everyday workplace terms:

Stage	What is happening	What the manager should provide
Forming	People are learning the goal, roles and each other	Direction and context
Storming	Differences over priorities, ownership or methods become visible	Clear decisions and fair conflict handling
Norming	The team develops dependable working habits	Consistency and useful feedback
Performing	People solve routine problems with less supervision	Autonomy and obstacle removal
Adjourning	The work ends or the team changes shape	Closure, handover and recognition

These stages are easier to recognise in hindsight than in the middle of a busy week. Look at behaviour rather than trying to label the team’s mood. Missed handoffs, repeated debates and unclear ownership tell you more than whether a meeting felt positive.

A running example: launching a new customer portal

Imagine a six-person project team responsible for launching a customer portal. It includes people from product, engineering, support and marketing. Most have not worked together before, and none reports directly to the project lead.

The same team will look quite different at each stage:

• During forming, everyone agrees that the portal matters, but nobody is sure who approves scope changes.
• During storming, engineering pushes back on the launch date while marketing has already planned a campaign.
• During norming, the team agrees on a weekly scope review and a written process for urgent decisions.
• During performing, members resolve most questions directly and raise only the choices that need sponsor approval.
• During adjourning, the team hands ongoing work to support and records what should change before the next launch.

The example matters because the model is often explained as five neat definitions. Real teams are messier. A group can be performing in its routine work and storming over one new decision at the same time.

Stage 1: forming

Forming begins when a team comes together around a goal. People are usually careful and polite because they are still working out who has influence, what the manager expects and how much disagreement is safe.

Signs that a team is forming

• Meetings contain basic questions about the goal, deadline and roles.
• Team members wait for the manager to make most decisions.
• People agree quickly in the room, then ask different questions in private.
• Work starts, but ownership at the boundaries remains unclear.

In the customer-portal project, the product manager may assume engineering owns the launch date while engineering assumes the business sponsor does. Nobody has necessarily made a mistake. The decision was never assigned.

What managers should do

Write down the outcome, important constraints and decision owners. Give each workstream one named owner, then explain where that person’s authority stops. A RACI chart can help on a large project, but a short table is often enough.

Use the first meetings to surface dependencies. Ask each member what they need from the others, what could block their work and which decisions cannot wait until the next scheduled meeting.

Do not confuse politeness with agreement. Before closing a discussion, ask people to describe the decision in their own words. Differences show up quickly when everyone has to say what happens next.

Stage 2: storming

Storming starts when the work becomes real enough for disagreements to carry consequences. People may dispute priorities, deadlines, quality standards or who gets the final say. Strong personalities become more visible, but quiet withdrawal can be just as important as open conflict.

Signs that a team is storming

• The same issue returns because nobody records a final decision.
• Two people complete overlapping work or leave a task untouched.
• Meetings become debates about method rather than decisions about the work.
• Team members copy senior leaders into routine disagreements.
• Feedback becomes personal, vague or delayed.

For the portal team, marketing may see a delayed launch as a commercial problem while engineering sees the proposed date as a reliability risk. Telling both sides to “collaborate better” avoids the actual choice.

What managers should do

Separate the disagreement into facts, constraints and preferences. Write down which points are supported by evidence, which limits cannot move and which options remain open. Then name the person who will decide.

Set rules for disagreement that people can follow under pressure. Critique the proposal, not the person. Bring a workable alternative when rejecting an idea. Record the decision, owner and review date before the meeting ends.

The manager should step in when conflict becomes personal, information is being withheld or one person cannot participate safely. Ordinary disagreement does not need to be suppressed. Teams need a fair way to finish it.

Stage 3: norming

Norming begins when the team has worked through enough friction to build dependable habits. Members understand who owns what, how decisions are made and when to ask for help. Trust grows because people can predict how colleagues will respond.

Signs that a team is norming

• Handoffs use an agreed format rather than improvised messages.
• Members raise risks earlier because they expect a useful response.
• People can disagree without reopening every past argument.
• Meetings spend more time on exceptions and decisions than status recitals.

The portal team might settle on a Tuesday scope review, a shared launch-risk log and a rule that only the sponsor can accept a high-severity unresolved risk. That routine is not glamorous, but it stops the same argument from consuming every meeting.

What managers should do

Protect the working habits that are helping. If the team agreed to respond to review requests within two days, do not bypass the process whenever a senior stakeholder asks for an exception.

Give specific feedback. “Good collaboration” is too vague to repeat. “You flagged the integration risk before development started and gave support time to adjust the help content” tells the team which behaviour worked.

This is also a good stage to review workload. Reliable people often receive more work because they make delivery look easy. Check capacity before the team’s new rhythm turns into an unfair load for two or three members.

Stage 4: performing

A performing team can handle routine decisions and recover from ordinary problems without waiting for the manager. Members know the goal, understand each other’s strengths and challenge weak ideas without derailing the work.

Performing does not mean constant agreement or perfect output. It means the team’s disagreements usually produce a decision, and mistakes lead to correction rather than blame.

Signs that a team is performing

• Members solve cross-functional problems directly.
• Progress continues when the manager is unavailable.
• Risks are raised with options, owners and likely consequences.
• The team adjusts its process when the old version stops helping.

For the portal launch, support might spot a confusing account-recovery flow during testing. Instead of passing the issue through several managers, support and engineering agree on the correction, tell marketing about the wording change and update the launch checklist.

What managers should do

Give the team room to work. Keep the outcome and guardrails clear, but avoid inserting yourself into decisions the team can make safely.

Remove obstacles that sit outside the team’s authority, such as a delayed vendor response or a conflict between departmental priorities. Keep reviewing results and workload. Autonomy is not neglect.

Managers also need a record of goals, feedback and agreed follow-ups. EasyHR’s performance management software is one option for keeping those records together instead of splitting them across email, documents and appraisal spreadsheets.

Stage 5: adjourning

Adjourning happens when a project ends, a temporary team disbands or a reorganisation changes who works together. It is easy to skip because everyone is already looking at the next deadline. That usually leaves weak handovers and the same lessons to be rediscovered later.

Signs that a team is adjourning

• Ownership is moving to an operations or support team.
• Temporary access, meetings and project channels are no longer needed.
• Team members are uncertain about their next role or priority.
• Important decisions exist only in individual notes or chat history.

For the portal project, launch day is not the end of the work. Support needs ownership of common customer issues, engineering needs a route for production incidents and product needs a backlog for improvements that did not make the launch.

What managers should do

Plan the handover before the final week. List ongoing responsibilities, new owners, open risks, access changes and the location of important records. Confirm that the receiving team can use the handover rather than simply sending it a folder.

Hold a short retrospective while details are fresh. Ask what helped delivery, what repeatedly slowed the team down and what the next project should do differently. Record a few specific changes instead of producing a long list that nobody owns.

Recognise contributions with detail. Mention the difficult problem a person solved or the habit they introduced. Generic praise is pleasant, but it is not very useful.

Can a team move backwards through the stages?

Yes. A team that was performing can return to forming or storming after a new manager arrives, priorities change, several members leave or the group takes on unfamiliar work.

Treat the model as a map, not a promotion ladder. Moving backwards does not mean the team has failed. It means an earlier management need has returned. If three new members join, clarify roles and decisions again. If the deadline changes sharply, expect old trade-offs to reopen.

Different parts of one team can also sit in different stages. A long-standing operations group may perform well on monthly work while a new cross-functional initiative is still forming. Diagnose the work in front of you rather than assigning one permanent label to the people.

A manager’s team-stage check-in

Use these questions in a one-to-one discussion, team health check or project review:

1. Can each person explain the team’s outcome and their part in it?
2. Which decisions have no clear owner?
3. What disagreement keeps returning without a conclusion?
4. Where does work wait during a handoff?
5. Which team routine saves time, and which has become ceremony?
6. What can the team decide without the manager?
7. If the work ended next month, what would be difficult to hand over?

The answers point to action. Confusion about ownership suggests forming work. Repeated unresolved conflict suggests storming. Stable handoffs suggest norming. Independent problem solving suggests performing. Handover concerns suggest adjourning.

Avoid turning the check-in into a score. A team does not earn points for claiming to be at the performing stage. The useful result is one change that makes the next week easier.

How HR can support team development

HR does not need to sit in every project meeting. It can help managers use a consistent set of practices:

• define roles and reporting lines when teams form
• train managers to handle disagreement and document decisions
• provide simple templates for goals, check-ins and retrospectives
• watch for workload or conduct issues that a project lead cannot solve alone
• preserve useful feedback when people move between teams

The records should support the conversation, not replace it. A system can show that a goal has no update or a review is overdue. It cannot decide whether the team needs clearer authority, a difficult conversation or fewer meetings.

For companies reviewing a connected system for employee records, goals, approvals and payroll, the EasyHR HRMS and payroll overview explains the wider workflow and the questions to test before choosing software.

Frequently asked questions

What are the five stages of team development?

The five stages are forming, storming, norming, performing and adjourning. They describe common changes in a team’s relationships and working habits as it starts, handles conflict, establishes routines, delivers and closes its work.

How long does each stage last?

There is no standard duration. A small team with a familiar task may settle quickly, while a cross-functional project with unclear authority may spend much longer in storming. A change in membership or priorities can also move the team back to an earlier stage.

Is storming always a bad sign?

No. Disagreement often appears once people understand the work well enough to see real trade-offs. Storming becomes harmful when conflict turns personal, decisions remain unresolved or people stop sharing important information.

What is the difference between norming and performing?

A norming team has established dependable roles and routines. A performing team uses that foundation to solve problems and deliver with less manager involvement. The difference is visible in how much the team can decide and recover on its own.