Concept

Dynamic Reteaming

conceptorg-designteamsreteamingleadershippeople-ops

Dynamic Reteaming

The ongoing, inevitable changing of team composition in software organisations, treated as a natural and manageable phenomenon rather than a disruption to be minimised. Coined and systematised by Heidi Helfand in her book of the same name.

The term distinguishes itself from “reorg” — a word Helfand considers too loaded with connotations of involuntary, top-down, large-scale restructuring. Reteaming encompasses changes at every level, from a single person switching teams to a company acquisition.

The five patterns

Helfand identifies five recurrent patterns that cover all team change:

One by one. Someone joins or leaves the company. The key lever is not just onboarding the new person but coaching the existing team through the change — especially when a new leader is hired from outside into a role someone internal wanted.

Grow and split. A growth pattern: teams outgrow effective coordination capacity and divide into two or more focused teams. Signals: longer meetings, slower decisions, divergent work tracks, disengagement in standups. Problem-trading warning: splitting one team with a single shared PM or designer may create resource gaps.

Merging. The shrinking pattern: two or more teams (or companies) consolidate. Tactic: “story of our team” — each team makes a milestone timeline, shares it with the merged entity, then builds a shared forward vision. Creates a sense of joint history before tackling joint future.

Isolation / innovation by isolation. A new team placed off to the side with process freedom — a “beneficial silo.” Used for new product lines and emergencies. Deliberately counter to the standard de-silo instinct; the point is to protect the team from the drag of mature process. Success factors: (1) separate location, (2) a senior leader explicitly protecting the team from distraction, (3) knowledge redundancy pre-built in the sending team so the isolated member can leave safely, (4) process freedom, (5) reporting to a senior decision-maker with real authority, (6) relief from heavyweight bureaucracy. Canonical example: Expertcity’s GoToMyPC pivot. Historical precedent: the Chicken McNugget saved by an isolated team at McDonald’s in a separate plant.

Switching. Lateral movement between teams within the same company. Tied to learning, fulfilment, and knowledge redundancy. Extends employee lifespan at the company by providing variety and growth without a hire-or-fire event. Menlo Innovations (Richard Sheridan) built company-wide pair-switching into their founding model. Switching also builds the safety net: if no single person owns any system, departures and downsizing leave fewer dangerous gaps.

Key practices

Whiteboard reteaming. Surface proposed team structures — names, missions, open slots — on whiteboards to the whole affected team before finalising. People identify design mistakes; people spot internal opportunities to apply for; agency creates ownership. Time-box the input phase. Spectrum: closed back-room planning → whiteboard reteaming → open self-selection events (Redgate Software).

RIDE framework (Pat Wadors): Request, Input, Decider, Execute. Clarifies who has each role in a given change. Prevents the frustration of ambiguous authority, and sets honest expectations about which decisions admit employee input (a team splitting) and which do not (being acquired).

Story of our team. For merging teams: each makes a timeline, shares milestones and things they built, then co-constructs a shared forward picture. Creates joint history before joint future.

Anti-patterns

  • Percentage anti-pattern: allocating people fractionally across multiple efforts (10% here, 20% there). Percentages do not add up; context-switching costs are high.
  • “Poof, they’re gone”: changes made without communication. The absence of a transition narrative blocks Bridges’ neutral zone from resolving.
  • Spreading high performers: splitting a high-chemistry team to “distribute the magic” across other teams. Does not work — team chemistry is an emergent property of people, time, and context, not a portable resource. (Jon Walker experiment, AppFolio.)

Where mainstream views differ

The dominant orthodoxy in software team design — drawn from Tuckman’s forming-storming-norming-performing model and from Team Topologies’ emphasis on cognitive-load-optimised stable teams — argues for minimising team change to allow teams to reach and sustain high performance. Dynamic reteaming does not refute this outright but argues that stability is often neither achievable nor desirable in fast-growing or shrinking organisations, and that treating change as the expected state produces better outcomes than treating it as an interruption. The switching pattern in particular runs against Team Topologies’ single-team-identity principle.