Module communication_metrics 

Communication and Collaboration Metrics

Communication and collaboration, the C in SPACE (chapter 3.1), measures how information actually flows between people and teams: how discoverable documentation is, how evenly knowledge spreads, how well cross-team dependencies get coordinated, and how new team members onboard into shared understanding. This dimension is often the least instrumented of the five, precisely because it is harder to observe than delivery data — and that gap matters, because breakdowns here frequently show up, misattributed, in every other dimension: a rising change failure rate that looks like a testing problem is sometimes actually a communication problem, a team that did not know about a dependency’s change until it broke in production.

Formula

Cross-team dependency resolution time = resolved at − raised at
    (a request, API change, or coordinated release, team-to-team)

Time to first contribution = first contribution at − joined at
    (onboarding proxy for how well shared understanding flows)

Why it matters

A team that consistently waits weeks for a dependency another team owns has a collaboration problem that will not show up cleanly in either team’s own internal delivery metrics — it needs a direct, inter-team-specific signal, the same cycle-time discipline chapter 2.6 applies within a team, applied here across a team boundary instead. The time from a new team member joining to their first meaningful, independent contribution is a complementary, practical proxy for the same underlying property: a team where knowledge lives entirely in people’s heads onboards slowly and unpredictably, while a team with genuinely good documentation, clear ownership, and accessible mentorship onboards faster and more consistently.

Example

use software_engineering::communication_metrics::{
    cross_team_dependency_resolution_time_days, time_to_first_contribution_days,
};

// A shared-library change request raised on day 10, resolved on day 24:
// two weeks of inter-team coordination friction.
let resolution_time = cross_team_dependency_resolution_time_days(10.0, 24.0);
assert_eq!(resolution_time, 14.0);

// A new engineer joins on day 0 and lands their first independent
// change on day 18.
let onboarding_time = time_to_first_contribution_days(0.0, 18.0);
assert_eq!(onboarding_time, 18.0);

Pitfalls

• Measuring only intra-team cycle time — a slow cross-team dependency will not show up in either owning team’s own internal delivery metrics; it needs its own direct signal.
• Treating documentation existence as sufficient — track discoverability (is it actually found and used), not just whether content technically exists somewhere (chapter 4.6).
• Ignoring onboarding time as “just an HR concern” — a long or highly variable time to first contribution is a genuine collaboration signal about how well shared understanding flows.
• Assuming the org chart describes real communication — periodic, lightweight analysis of who actually collaborates with whom (code review networks, meeting overlap) often reveals a bottleneck or an isolated pocket the formal structure hides.

Sources

• Chapter 3.5, Communication and collaboration metrics.
• Forsgren, Storey, Maddila, Zimmermann, Houck, and Butler, “The SPACE of Developer Productivity,” ACM Queue (2021).

Topic doc: software-engineering-metrics/locales/en-001/chapters/03-05-communication-and-collaboration-metrics.md

Functions

cross_team_dependency_resolution_time_days

Time from a cross-team dependency being raised to being resolved: a shared-library update, an API change request, a coordinated release, team-to-team rather than within a single team.

time_to_first_contribution_days

Time from a new team member joining to their first meaningful, independent contribution — a practical proxy for how well shared understanding flows in an organization.