Team Development Stages: Where Is Yours Stuck?

Your development team isn't moving as fast as planned, and you can't tell whether you have a people problem or a timing problem. The team development stages model, formalised by psychologist Bruce Tuckman in 1965, answers exactly that question: every team, including a remote technical team, goes through predictable phases before it becomes genuinely productive. I've been running a team of Vietnamese developers for over ten years, and I've watched this model play out almost identically on every new squad we've built for a client.

Tuckman's model: the 5 stages of team development, explained simply

Tuckman's model describes five phases that any group of people goes through before it functions as a real team: forming, storming, norming, performing and adjourning. Bruce Tuckman, a doctor of psychology, built the model in 1965 by analysing more than 50 studies on group dynamics, according to rhperformances.fr. Twelve years later, with Mary Ann Jensen, he added a fifth phase, adjournment, to cover the end of a team's life.

Why is this model still the reference for managing technical teams?

Because it fits into five memorable words, and because it matches what a squad of developers actually lives through. At the forming stage, members are still sizing each other up: polite, cautious, waiting for clear direction from management. Then comes storming, where roles, working methods and sometimes egos collide. Manager-go.com captures this shift well: the team moves from individual energy to an attempt at coordination, and it's often painful.

Norming then puts shared rules in place, stand-up rituals, a common approach to code review. The performing stage is where the team becomes more than the sum of its individuals: it makes decisions without waiting for the manager, it absorbs the unexpected. That's the stage every CTO outsourcing part of their development wants to reach as fast as possible, and it's exactly where the way you build the team makes all the difference.

Why storming lasts longer with a remote team

An offshore team doesn't go through storming differently in substance, but it goes through it more slowly if nobody compensates for the missing informal signals. In an office, a team lead picks up on tension in five minutes in the hallway. Remotely, between France and Vietnam, with a six-hour time difference, that same signal sometimes takes two weeks to surface as a ticket that has stopped moving.

How do you spot storming in a remote team?

Three symptoms show up every time: sprint estimates that blow up with no clear explanation, developers who stop asking questions in meetings, and a product owner who starts micro-managing because they've lost track of where the project stands. I don't think this is ever a technical skill problem at this stage, it's a framing problem. Tuckman's model warns as much: this phase is necessary, you can't skip it and jump straight to performing, no matter how much you pay.

Where a lot of clients get it wrong is in assuming that a cheaper offshore team will inevitably stay stuck in storming for longer. It isn't a question of cost, it's a question of organisation. A senior Vietnamese team, with a single technical point of contact on the client side and a non-negotiable weekly demo ritual, comes out of this phase almost as fast as a local team.

How a structured offshore agency speeds up the move to performing

The main lever isn't team size, it's the management structure. A well-built Offshore Development Center, with a permanent point of contact and written coding standards from day one, absorbs most of the ambiguity that normally feeds the norming phase. The French tech sector remains squeezed on senior profiles, which mechanically pushes companies to look elsewhere: according to Syntec Numérique, the industry employs several hundred thousand people and struggles to cover its need for experienced developers, an imbalance that largely explains the rise of offshore over the past few years.

Should you insist on a single project lead to shorten the norming phase?

Yes, no exceptions. Tuckman's model stresses the leader's role at every stage, and that responsibility doesn't split well remotely. Across the squads I've seen start up at GoLive Software, the ones with a single technical lead on the Vietnam side come out of storming in two to three weeks. The ones where two people share coordination with no clear hierarchy sometimes stay there for two months, with the same developers and the same project.

The table below compares observed durations, stage by stage, between a conventional in-house team and a Vietnamese offshore team run with an ODC method.

A badly built offshore team is never a victim of its time zone, it's a victim of its lack of structure. That's the one sentence to take away from this guide if you only keep one.

The role of AI in speeding up team development stages

Artificial intelligence doesn't remove any of the five stages in Tuckman's model, but it does change how fast a team moves through them, norming in particular. When every developer uses Claude Code or Cursor to produce code that arrives already documented and tested, the phase where the team negotiates its quality standards mechanically shortens: the standards are already partly set by the tool.

Can AI let you skip a stage of Tuckman's model?

No, and this is where a lot of companies are getting it wrong in 2026. I don't think AI replaces good developers, it amplifies what they can produce, but it doesn't replace the time a team needs to learn to trust each other. A non-engineer generating code with an AI agent can produce lines that run, but they won't handle architecture, security or the edge cases that a real team learns to manage by going through storming and norming together.

I've worked out the real savings of an offshore team assisted by Claude Code across several recent projects, and the conclusion is clear: what AI actually changes is the ratio between the number of developers you need and what gets delivered. A small, senior, well-organised Vietnamese team with AI support can now hold its own against a much larger and much more expensive European team, provided it has already reached the performing stage. That's exactly why I believe Vietnam's advantage gets stronger with AI rather than eroding: sensible costs, a solid engineering culture, and now higher individual productivity.

A team that has understood this doesn't wait until hiring is finished to put its AI-assisted coding standards in place. It sets them at the forming stage, which shortens the storming that follows by the same amount.

If your team has been stuck at the same stage for more than two months, the problem is almost never the people you have. It's the absence of a single point of leadership and non-negotiable rituals, two things a serious offshore agency puts in place before the first sprint even starts. A well-built team, even a remote one, clears storming and norming in a few weeks, not a few months, and it's that timeline, far more than the day rate, that should guide your choice of provider.