Your Team Isn’t Underperforming. It May Be in the Wrong Mode.

Teams in various modes like... Forming, Norming & Performing!

We often diagnose teams through the visible symptoms: delivery is slow, meetings are messy, ownership feels weak, decisions keep reopening, or people are not "collaborating enough."

Then comes the usual prescription: more accountability, tighter planning, a new process, more stand-ups, stronger management, or perhaps a re-org.

Sometimes those interventions help. Often, they make things worse.

The reason is simple: not all teams need the same kind of leadership at the same time. A newly assembled team, a team navigating conflict, and a mature team operating with high trust should not be managed the same way.

A useful lens is the classic team-development model: forming, storming, norming, and performing. It is not a perfect or strictly linear model, but it gives leaders a practical way to diagnose what their team needs next. The key is not memorising the stages. The key is matching the leadership intervention to the team’s current mode.

The mistake: treating every team alike

Imagine this scenario.

You hire several strong engineers, appoint a capable tech lead, define an ambitious roadmap, and expect delivery velocity to rise, instead....

1. Architecture discussions reopen the same decisions every week.

2. Product and engineering disagree about scope and quality.

3. Code reviews linger because standards are implicit.

4. Meetings multiply because nobody knows which forum makes which decision.

5. The manager becomes the default escalation point for every trade-off.

6. People are polite in meetings, but disagreements move into side conversations.

It is tempting to call this a talent, accountability, or communication problem. It may be none of those. You may simply be managing a forming-and-storming team as if it were already a performing one.

Asking a new team for autonomy before it has a shared context feels like abandonment. Continuing to tightly direct a mature team, on the other hand, destroys ownership and slows decisions.

A better question is:

What mode is this team in, and what does that mode require from leadership?

The four modes

Tuckman's model describes four common phases of team development: forming, storming, norming, and performing. Teams build clarity in forming, surface and work through disagreements in storming, establish repeatable working agreements in norming, and operate with greater trust and autonomy in performing.

Simple viz of how to think about the various stages.

An important caveat: teams do not move through these modes unidirectionally, or only once.

A healthy, mature team can return to forming or storming after a re-org, a new manager, rapid hiring, a major incident, a strategic pivot, or a change in its mission. Team development is better understood as a recurring cycle than a one-way maturity ladder.

Forming: clarity before autonomy

Forming is what happens when a group of capable individuals becomes a team.

The people may be talented. They may have worked in strong organisations. They may even know one another. But the team still lacks shared context: what it owns, how success is measured, who decides, what trade-offs matter, and how work moves across boundaries.

This is the phase where leaders often make a subtle error. They see strong people and assume strong people need little direction.

Strong people do not need micromanagement... they do need a coherent system in which to operate.

What forming looks like

In an engineering organisation, forming often shows up as:

1. Engineers ask the manager for decisions that should eventually be delegated.

2. Product, engineering, design, and data use different definitions of success.

3. Ownership is clear in an org chart but unclear in actual execution.

4. Dependencies are discovered during delivery rather than before commitments are made.

5. Senior people make reasonable but conflicting assumptions about architecture, quality, timelines, or customer priorities.

6. The team starts many things because no one has clearly defined what not to do.

The team is still creating its internal map of the world, do not assume it to be dysfunctional.

The leader’s job in forming

The most valuable artefact a new team can create is not a roadmap, an architecture diagram, or a sprint board. It is a team contract.

A good team contract should answer:

1. What customer, business, or platform outcome do we own?

2. What is explicitly out of scope?

3. Which metrics define success?

4. Which quality, reliability, security, or cost constraints are non-negotiable?

5. Who owns which domains and interfaces?

6. Which decisions are delegated, and which require escalation?

7. What are our planning, execution, review, and incident-management cadences?

8. How do we handle disagreements and changing priorities?

For a platform team, this may include service ownership, API boundaries, SLOs, on-call expectations, and a dependency map.

For a product squad, it may focus on customer outcomes, experimentation velocity, feature quality, roadmap boundaries, and the relationship between product decisions and engineering constraints.

A simple rule that helps here:

In forming, ambiguity is expensive. Clarify the goal, the boundary, and the decision-maker before optimising the process.

Storming: conflict is not failure

Storming is the most misunderstood phase.

Many leaders interpret visible disagreement as evidence that the team is unhealthy. They try to restore calm quickly, often by making decisions themselves, avoiding difficult conversations, or rewarding people who are easiest to manage.

That creates a more dangerous outcome: artificial harmony.

A team without visible disagreement is not automatically a high-trust team. It may simply be a team where disagreement has gone underground.

Healthy teams do not avoid conflict.

What storming looks like

In technical organisations, storming often appears as:

1. Architecture reviews repeatedly revisit decisions that should have been closed.

2. Product and engineering disagree about deadlines, scope, quality, and technical debt.

3. Senior engineers compete for technical authority.

4. Teams debate implementation details because the underlying product or business trade-off remains unresolved.

5. A new manager changes the operating model before earning enough context and trust.

6. People agree in planning meetings, then quietly renegotiate commitments during execution.

7. Slack and side conversations contain more honest debate than the formal decision-making forums.

Storming is not just about personality conflict. Most recurring conflict is a signal that something in the operating system is missing:

1. An unclear strategy.

2. Ambiguous ownership.

3. Undefined decision rights.

4. Missing technical principles.

5. Incompatible incentives.

6. A lack of shared evidence.

7. No agreed way to resolve disagreements.

The leader’s job in storming

The goal is not to eliminate disagreement. The goal is to make disagreement explicit, evidence-based, bounded, and resolvable.

A leader should create a few mechanisms that allow the team to challenge one another without making every disagreement political.

Mental Model for Conflict Patterns

Make decisions explicit

A simple decision record can prevent months of recurring debate:

Example Decision:
Use Kafka as the event backbone for entitlement changes.

Decision owner: Platform Lead

Input required from:
- Identity team
- Billing team
- SRE

Why now:
We need replayable, auditable entitlement events that can serve
multiple downstream consumers.

Trade-offs accepted:
- Higher operational complexity
- More on-call responsibility
- Better replayability and fan-out than direct synchronous integrations

Revisit if:
- Event volume remains below 5,000 events per minute for two quarters, or
- The team cannot sustain reliable operational ownership

This does not guarantee that everyone agrees. It does something more valuable: it makes the disagreement concrete.

The team can now argue about assumptions, constraints, operational costs, or revisit triggers. It no longer needs to argue through status, memory, or personal preference.

A practical storming toolkit

1. Separate facts, assumptions, and preferences. Technical arguments often become personal because these categories get mixed together.

2. Name the decision owner. Consultation can be broad, but accountability should be explicit.

3. Classify the decision. Is it reversible, difficult to reverse, or best resolved through an experiment?

4. Create a disagreement window. Debate hard before the decision, then commit for a defined period unless a stated trigger occurs.

5. Record dissent. People do not need to “agree” in order to commit, but meaningful concerns should be visible.

6. Design escalation paths. Escalation should resolve deadlocks, not become a political shortcut.

7. Review recurring conflicts. If the same debate keeps returning, the team likely needs a principle, boundary, owner, or strategy decision.

A useful leadership question is:

Are we dealing with a difficult person, or are we exposing a missing decision mechanism?

Often, it is the second.

Norming: culture becomes operational

Norming is not simply the moment when people begin getting along. A team has normed when it has developed reliable ways of working together, especially under stress.

This is where culture becomes less about aspirational values and more about operational behaviour.

The team has learned:

1. How decisions get made.

2. What good work looks like.

3. When to use synchronous versus asynchronous communication.

4. How to review code and architecture.

5. How to surface risk early.

6. How to give feedback.

7. How to recover from mistakes.

8. How to challenge one another without damaging trust.

Norms are compressed coordination.

They reduce the number of things a team needs to negotiate repeatedly, which lowers decision latency and frees cognitive capacity for the work that actually matters.

What useful norms look like

For an engineering team, norms might include:

1. Pull requests receive an initial review within one working day.

2. Architectural decisions that are difficult to reverse require a short decision record.

3. Every production service has named operational ownership, service-level objectives, and an escalation path.

4. Incident reviews focus on system improvements, not blame.

5. Scope changes after a commitment require an explicit trade-off: timeline, quality, capacity, or another committed item.

6. Meetings exist to make decisions, unblock work, or build shared context. Status updates should default to asynchronous communication.

7. Feedback is direct, specific, and raised early rather than stored until a performance cycle.

The point is not to create a heavy process layer. The point is to make the team's coordination model visible and repeatable.

How leaders accidentally break norming

Leaders often undermine norming in two ways.

First, they dismiss working agreements as bureaucracy. The result is that every new problem creates a fresh coordination debate.

Second, they treat existing norms as permanent. Norms need to evolve when the team’s size, composition, product surface area, reliability needs, or strategic context changes.

A useful test is:

Do our rituals reduce uncertainty, or are they merely proving that we are busy?

If a ritual does not produce a decision, an insight, a commitment, or a risk signal, it may be process theatre.

Performing: optimise for context and decision velocity

Performing teams are not conflict-free, manager-free, or meeting-free.

They are teams that can make good decisions close to the work. They understand the business and customer context behind their tasks. They surface risks early. They resolve most tension without requiring management escalation.

The manager’s role changes significantly at this stage.

In forming, the leader provides structure. In storming, the leader makes conflict productive. In norming, the leader reinforces good operating mechanisms. In performing, the leader provides context, capability, and organisational leverage.

Signs of a performing team

A performing team often has these characteristics:

1. Roadmap commitments are credible because trade-offs surface early.

2. Engineers understand the customer or business outcome, not just the ticket.

3. The team can handle ambiguity within clear boundaries.

4. Incidents lead to durable improvements rather than blame cycles.

5. Individuals challenge weak ideas, including the manager’s ideas.

6. Ownership survives absences, organizational noise, and local ambiguity.

7. Leaders spend more time removing cross-team blockers than assigning tasks.

8. The team can explain what it will not do, not only what it plans to do.

This is the moment to shift from task delegation to outcome delegation.

Instead of saying:

Build a new entitlement cache.

A leader can say:

Reduce entitlement-read latency for active playback sessions while preserving correctness during subscription changes. We need a measurable improvement before the next sports season. You own the solution space, but the reliability and reconciliation constraints are non-negotiable.

That is a different kind of management.

It gives the team a meaningful problem, a boundary, and a success condition. It preserves autonomy while ensuring the work remains strategically connected.

Teams in the performing phase generally need leaders to delegate more, provide strategic context, and remove external blockers rather than direct every activity.

Regression is normal

One of the most harmful things leaders can do is assume that performing is permanent. A team can operate exceptionally well for a year and then struggle after:

1. A new manager joins.

2. Several senior hires arrive at once.

3. A re-org changes reporting lines or incentives.

4. The mission shifts from feature delivery to reliability, platform, or cost optimization.

5. A serious production incident damages trust.

6. The organization enters a phase of rapid hiring.

7. A merger, acquisition, or strategic pivot changes the team’s interfaces and priorities.

This is not necessarily regression in the negative sense. The context has changed. The team’s old assumptions may no longer hold. When that happens, do not ask:

Why has this team regressed?

Ask:

Which shared assumptions stopped being true?

That question leads to constructive action:

1. Reconfirm the mission.

2. Reset ownership boundaries.

3. Clarify new decision rights.

4. Revisit priorities and trade-offs.

5. Rebuild the operating contract.

6. Give the team time to form and storm around the new reality.

A high-performing team can revisit forming and storming many times. The difference is that mature teams recognise the pattern earlier and have better mechanisms for navigating it.

A quick diagnosis

Use these questions in your next leadership review, team offsite, or manager one-on-one.

Your team may be forming if

1. People cannot explain the team’s purpose in the same words.

2. Ownership is unclear in day-to-day execution.

3. The manager is repeatedly pulled into small decisions.

4. Success metrics are vague, competing, or absent.

5. Dependencies are discovered after work has already begun.

6. The team lacks shared language for quality, speed, reliability, or customer value.

Your team may be storming if

1. The same decisions are debated repeatedly.

2. People agree in meetings but resist privately.

3. Strong contributors withdraw, form factions, or work around the group.

4. Conflict is framed as a personality issue rather than a trade-off.

5. Deadlines reveal disagreements that should have been resolved earlier.

6. Escalation replaces decision-making.

Your team may be norming if

1. People can predict how work, decisions, and handoffs will happen.

2. Feedback is direct and does not automatically become interpersonal conflict.

3. New members can learn how the team works from artefacts, not only tribal knowledge.

4. Meetings and rituals reduce uncertainty rather than create reporting overhead.

5. The team catches coordination failures early.

Your team may be performing if

1. The team can act with minimal manager involvement inside clear boundaries.

2. Disagreements are resolved close to the work.

3. Risks, dependencies, and trade-offs surface early.

4. The team can absorb normal disruption without losing direction.

5. People take temporary leadership roles based on the problem, not just their job title.

6. The manager mainly removes organisational obstacles and expands the team's capacity to succeed.

The leadership sequence

The practical sequence is simple:

1. Create clarity before demanding autonomy. A team needs a purpose, boundaries, ownership, success measures, and decision rights.

2. Allow productive conflict before asking for harmony. Suppressed disagreement does not disappear. It becomes delay, politics, passive resistance, or attrition.

3. Turn good behaviour into explicit norms before scaling the team. What works through personal familiarity eventually needs to become a shared operating system.

4. Provide context and remove blockers before increasing control. Performing teams should own outcomes, not merely execute assigned tasks.

5. Reset the contract when context changes. A new mission, new leader, or new team composition can legitimately send the team back into forming and storming.

The goal is not to force every team into a mythical permanent state of performing. The goal is to give each team the leadership intervention its current mode requires.

Clarity before autonomy. Productive conflict before false harmony. Explicit norms before scale. Context and trust before delegation.

Great team builders do not demand performance from a team that is still forming. They create the conditions in which performance becomes the natural outcome.

Have you ever mistaken a team in storming for a low-performing team? What changed your diagnosis?