Distributed-team operating model

The question it helps answer

Use the distributed-team operating model to organise the reasoning behind this question: How should a distributed team design participation, cohesion, communication, and in-person contact? The working view makes time zones, synchronous core, and async norms visible so discussion can move from general opinion to a specific action or decision.

When to use it

Use the distributed-team operating model when people working on team development are using different mental models for time zones, synchronous core, and async norms, and that difference is changing choices or coordination.

What it is

The distributed-team operating model is a set of connected concepts for examining one situation from several necessary angles. Its core working elements are time zones, synchronous core, async norms, and access. Those elements belong together because each changes how the others should be interpreted or acted on.

Core elements

Time zones

Capture time zones only at the level needed to answer: How should a distributed team design participation, cohesion, communication, and in-person contact? Use observable evidence, name any unresolved judgment, and state what action or choice this entry can change. Within the distributed-team operating model, connect this entry to synchronous core so the relationship can be reviewed rather than inferred.

Synchronous core

Capture synchronous core only at the level needed to answer: How should a distributed team design participation, cohesion, communication, and in-person contact? Use observable evidence, name any unresolved judgment, and state what action or choice this entry can change. Within the distributed-team operating model, connect this entry to async norms so the relationship can be reviewed rather than inferred.

Async norms

Translate the idea into observable behaviour, including what good practice looks like under pressure and which anti-pattern to avoid. Within the distributed-team operating model, connect this entry to access so the relationship can be reviewed rather than inferred.

Access

Capture access only at the level needed to answer: How should a distributed team design participation, cohesion, communication, and in-person contact? Use observable evidence, name any unresolved judgment, and state what action or choice this entry can change. Within the distributed-team operating model, connect this entry to inclusion so the relationship can be reviewed rather than inferred.

Inclusion

Capture inclusion only at the level needed to answer: How should a distributed team design participation, cohesion, communication, and in-person contact? Use observable evidence, name any unresolved judgment, and state what action or choice this entry can change. Within the distributed-team operating model, connect this entry to social cohesion so the relationship can be reviewed rather than inferred.

Social cohesion

Capture social cohesion only at the level needed to answer: How should a distributed team design participation, cohesion, communication, and in-person contact? Use observable evidence, name any unresolved judgment, and state what action or choice this entry can change. Within the distributed-team operating model, connect this entry to travel so the relationship can be reviewed rather than inferred.

Travel

Capture travel only at the level needed to answer: How should a distributed team design participation, cohesion, communication, and in-person contact? Use observable evidence, name any unresolved judgment, and state what action or choice this entry can change. Within the distributed-team operating model, connect this entry to review so the relationship can be reviewed rather than inferred.

Review

Set a review rhythm and define the evidence, threshold, or event that should trigger an earlier review. Within the distributed-team operating model, connect this entry to travel so the relationship can be reviewed rather than inferred.