The first time most people open a collaboration network map, the reaction is "that's a lot." Nodes, edges, colours, line weights all arrive at once, and the takeaway is usually just "we talk quite a bit."
The problem isn't the map. It's how we read it. Only a handful of signals in a collaboration network point directly at an action; everything else is background. These five are the ones worth checking first.
1. Density: deciding whether this map is worth reading closely
Density = connections that exist ÷ connections that would exist if everyone talked to everyone.
It answers a basic question: is this one team, or several small circles sharing a name?
Rough bands for a 10–30 person team:
- Below 0.15 — clearly low. Most people deal with one or two neighbours, which usually means the team actually runs as sub-groups with narrow cross-group channels.
- 0.15 to 0.4 — the common range.
- Above 0.4 — high. Everyone interacts with everyone. Not automatically good: often a sign of unclear ownership, where every decision needs a sync.
Density is not a conclusion by itself. Its job is to set the direction: when density is low, "communicate more" is the right move. When density is already high, more meetings only make it worse.
2. Degree distribution: bottlenecks and isolated members are two ends of one problem
Sort members by connection count and look at both tails.
An even network gives you a flat curve. An uneven one produces outliers. Both ends matter.
The high end — bottlenecks. A few people have far more connections than average, and most of those interactions are others reaching out to them. They aren't necessarily the most senior people, but everything routes through them. The tell is in-degree (others initiating) far exceeding out-degree.
The low end — isolated members. Connection counts well below average, or zero. Distinguish two cases: someone who should be connected but isn't (a module owner who never talks to the team depending on them) is a real problem; someone isolated by the nature of their role is not.
One pattern people miss: isolated members are rarely disengaged. Their work simply isn't being caught by the team's communication structure.
3. Betweenness: find the brokers, then find the single points of failure
Degree counts who you know. Betweenness counts how many shortest paths must pass through you.
High betweenness marks a broker: information and decisions between two groups that don't talk directly have to be relayed by this person. That's valuable, and that's the risk — the day they take leave, leave the company, or simply get busy, the channel goes down.
The condition worth flagging is not "high betweenness" but "high betweenness, with no other direct connection between the two groups." That is a single point of failure.
The usual fix is not to offload the broker — they're often a key role. It's to add a direct edge: give the two groups a route that doesn't run through them.
4. Edge direction: who initiates, who absorbs
Collaboration networks are directed. For the same pair, A→B and B→A mean different things.
Reading the graph as undirected throws away one of the most useful signals: whether one side always initiates.
If every interaction from product to engineering starts on the product side and engineering never reaches back, the edge exists but its quality is poor — closer to being notified than to collaborating. One-directional flow is an early sign of collaboration degrading, usually visible months before the problem becomes obvious.
Directed data is also what separates bottlenecks from isolated members. On connection count alone, a person constantly interrupted and a person nobody contacts can look similar. One has in-degree exploding; the other sits near zero.
5. Weak ties: springboards or breaks
Weak ties are low-frequency connections that cross group boundaries.
Their total weight is small, so they always sort last — which is exactly why they get ignored. But a durable finding in organisational research is that new information and cross-domain opportunity travel mainly through weak ties, not through the tight core. The core's information is highly overlapping.
So watch two things:
- How many cross-group weak ties exist. Too few means no springboard between groups, and the inputs that drive new work get cut off.
- Whether they are disappearing. If a channel had traffic a year ago and sits at zero now, that isn't communication getting leaner. It's a channel that closed.
Don't read all five at once
The sensible order:
- Density first, to set the direction — more communication, or less.
- Then the two tails of the degree distribution, to name the bottlenecks and the isolated members.
- Then betweenness, to confirm whether a single point of failure exists.
- Finally direction and weak ties, to explain why. The problems you found earlier usually have their structural cause here.
Jump straight to weak ties and you'll read noise as signal.
Curious what your own team looks like structurally?
Run it on your own relationship data. Provide members' work relationships, we will analyze only the collaboration' content.