How does team familiarity shape coordination in distributed software teams?

Why does familiarity make coordination easier?

In distributed software teams, members often work apart and cannot rely on casual hallway conversations. Familiarity helps because it builds shared mental models—common expectations about who does what, how work flows, and what others need [1]. When teammates already know each other's habits and the software parts they have worked on, they can coordinate with less explicit back-and-forth. A study of software teams found that prior familiarity with the same software parts and projects reduces coordination effort [1].

This does not mean familiarity eliminates the need to communicate. Rather, it changes the kind of communication required: instead of spelling out every detail, teammates can rely on implicit understanding. The effect is strongest when the work itself is familiar, because team members can predict both the task and each other [2].

Does it matter whether the task or the team is familiar?

Yes. A field study of geographically distributed software teams examined both task familiarity (experience with the work) and team familiarity (experience working together) and found that they interact with coordination complexity to affect performance [2]. In practical terms, a team that knows the codebase but has never worked together may still struggle, while a team that knows each other but faces a brand-new task may need more explicit coordination.

The same study suggests that the value of familiarity depends on how complex the coordination challenge is. When coordination is simple, familiarity may add little; when coordination is complex, familiarity can help teams avoid misunderstandings [2]. This is consistent with the idea that familiarity works by reducing the need to negotiate every handoff from scratch.

What about familiarity with tools and technologies?

Familiarity is not only about people. In globally distributed teams that span onshore and offshore sites, coordination also depends on members acquiring familiarity and expertise with the tools and technologies they use [5]. When offshore team members become fluent in the company's tools, they can coordinate more smoothly with onshore colleagues because they share a common technical vocabulary and understand the constraints of the systems they work with.

This kind of tool familiarity complements team familiarity: knowing the technology reduces the number of things that must be explained, freeing up communication for the genuinely novel or ambiguous parts of the work [5].

Can too much familiarity backfire?

In a different setting—English Premier League soccer—researchers found that current team familiarity had a reversing curvilinear effect on coordination: moderate familiarity helped, but very high familiarity was associated with worse coordination [4]. That study also found no main effect of prior team familiarity on coordination, and the negative effect of losing a team member on outcomes was stronger when prior familiarity was low [4]. These findings come from sports teams, not software teams, so they should be treated as a caution rather than a direct prediction for distributed software work.

For software teams, the implication is that familiarity is not a simple “more is better” resource. It may need to be refreshed when tasks change or when team composition shifts, because familiar routines can become stale or misaligned with new work [2][4]. The exact point at which familiarity stops helping and starts hurting is not established for distributed software teams.

Sources used in this answer

Related research questions