Companies reshuffle engineering teams constantly, moving people between projects to chase priorities, and they treat it as free. Research on software teams says otherwise. How many times people have worked with each other before, what researchers call team familiarity, turns out to be a significant predictor of both quality and speed.
Key Takeaways
- Harvard research on Indian software services found team familiarity significantly improves performance (Huckman, Staats & Upton).
- Familiarity is measured as the average number of prior collaborations among team members (Huckman et al.).
- Teams with more prior working ties delivered higher quality, faster.
- Reshuffling teams destroys accumulated familiarity, an invisible cost.
What the Research Found
Robert Huckman and Bradley Staats, with David Upton, studied a large Indian software services firm and asked a question most companies never think to measure: does it matter whether team members have worked together before (Team Familiarity, Role Experience, and Performance)? They defined team familiarity as the average number of times each member had previously worked with every other member, and found it had a significant positive effect on performance (Management Science).
The striking part is the comparison. Their work and related research indicate that team familiarity matters more than task familiarity: a team that knows each other, working on something new, tends to outperform a group of strangers working on something they individually know well. Prior working ties translated into higher-quality software delivered faster (the study).
Why Familiarity Compounds
The mechanism is mostly communication overhead. A team that has worked together has shared shorthand, knows who's good at what, knows how each person communicates, and has already resolved the friction of figuring each other out. Every one of those is coordination cost a fresh team has to pay again from scratch. Familiar teams also have trust, which is the substrate for psychological safety and for surfacing problems early.
Reshuffling resets that. The new team has the same individual talent and none of the accumulated familiarity, so it pays the coordination tax again while the org books the move as neutral.
| Familiar team | Freshly assembled team |
|---|---|
| Shared shorthand | Re-establishing norms |
| Knows who's strong where | Discovering it |
| Trust already built | Trust to be earned |
| Lower coordination cost | Pays the tax again |
A Concrete Version
A company reorganizes quarterly, redistributing engineers to whatever is most urgent. On paper the same headcount covers the same work. In practice, every reshuffle resets each team's familiarity to near zero: people spend weeks learning how their new teammates operate, redoing the norms, rebuilding trust. Velocity dips after every reorg and recovers just in time for the next one. A competitor that keeps stable teams pointed at shifting priorities gets the flexibility without repeatedly paying the familiarity tax.
The Honest Counterpoint
Keeping teams together forever has real costs too, and this isn't an argument for freezing the org chart. Long-unchanged teams can develop blind spots, insularity, and stale approaches, and fresh perspectives genuinely help. People also need mobility to grow, and locking someone onto one team for years is a retention risk. The finding is about the cost of churn rather than a case for never changing anything: recognize that reshuffling destroys real accumulated value, so do it deliberately and less often than convenience suggests, and prefer moving work to stable teams over moving people between teams.
What This Means for Staffing
Team familiarity reframes turnover and reshuffling as a performance issue rather than a scheduling one. Every departure and every reorg destroys familiarity that took months to build, which is part of why retention matters so much and why we track it closely: our placed engineers hit 97% retention at six months, so the familiarity a team builds with them compounds instead of resetting. It also argues for adding capacity to existing teams and keeping them intact, rather than constantly re-forming teams around the priority of the month, a theme that connects to team size and cognitive load. See available engineers.
Frequently Asked Questions
What is team familiarity?
The average number of times each team member has previously worked with every other member. Harvard research on software services found it has a significant positive effect on team performance.
Does familiarity matter more than individual experience?
The research indicates team familiarity is a stronger driver than task familiarity: a team that knows each other tackling new work often outperforms skilled strangers working on familiar work.
Why does reshuffling teams hurt?
It resets accumulated familiarity to near zero. The new team has the same individual talent but must re-pay the coordination cost of learning how to work together, so output dips after each reorg.
Should teams never change?
No. Long-static teams can get insular, and people need mobility to grow. The point is that churn has a real, usually invisible cost, so reshuffle deliberately and prefer moving work to stable teams over moving people.
The Bottom Line
How often people have worked together predicts how well they build software, and Harvard's research found team familiarity a significant driver of quality and speed. Every reshuffle quietly destroys months of accumulated coordination value. Keep teams stable, move work to them rather than moving people around, and treat retention as the performance issue it is.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
