Collaboration network analysis

Collaboration network analysis is the practice of mapping how people in an organisation interact, then measuring the structure of those connections to find where work flows and where it stalls. Each person is a node. Each working relationship, a shared document, a recurring meeting, a thread of messages, a co-authored project, is an edge between two nodes. The result is a graph, and the shape of that graph tells you things an org chart never could.

An org chart shows who reports to whom. A collaboration network shows who actually works with whom. The two are rarely the same. The network reveals the engineer two levels down whom every team quietly depends on, the department that has gone silent and stopped talking to the rest of the business, and the person whose departure would sever a critical link. These are structural facts about how the organisation really operates.

The analysis is built on a handful of graph measures. Density tells you how interconnected the whole network is. Centrality tells you who sits at the busy crossroads of information. Clustering tells you where tight pockets form. Read together, these turn a fuzzy sense that collaboration is good or bad into specific, locatable structure you can act on.

Collaboration network analysis is not a single figure but a set of graph measures read together. The foundational one is network density, the share of all possible connections that actually exist. Around it sit centrality and clustering measures that locate the important people and groups. To produce them, you first build the graph, then compute the measures across it.

1. 1

   Define what counts as a connection

   Decide which interactions form an edge: a co-edited document, a two-way message thread above a threshold, a shared project, a recurring meeting both people attend. Set a minimum so trivial one-off contact does not create noise edges.

2. 2

   Build the node and edge list

   List every person as a node, then create an edge for each qualifying connection over the period. Weight edges by frequency if you want intensity to matter, so a daily collaboration counts more than a single exchange.

3. 3

   Calculate network density

   Divide the number of actual connections by the number of possible connections. With 10 people there are 45 possible pairs. If 18 pairs actually collaborate, density is 40 percent. Low density signals fragmentation, very high density can signal meeting overload.

4. 4

   Compute centrality and clustering

   For each person, count their connections and how often they sit on the shortest path between others. High betweenness marks a broker. Then measure how tightly local groups cluster to expose silos that barely connect to the rest of the network.

The measures only mean something in combination. High density with low clustering is a healthy, evenly connected team. High clustering with low cross-group connection is a set of silos that look busy internally but do not talk to each other. A single node with extreme betweenness is a bottleneck and a risk, because information and decisions all route through one person who can become overloaded or, if they leave, take a critical pathway with them.

A network graph shows you the structure. A metric tree turns that structure into something a leadership team can own and act on. The graph might reveal that engineering and sales barely connect, but the graph alone does not tell you whose job it is to fix that, or what specifically to change.

The first level of the tree decomposes overall collaboration health into its structural drivers: how connected the network is, how evenly information is distributed, how much teams cluster into silos, and how exposed the organisation is to single points of failure. Each of those breaks down further. Connectivity splits into within-team density and cross-team links. Single-point exposure splits into broker concentration and the number of critical edges held by one person.

This is where the gap between a dashboard and a decision closes. A network diagram is fascinating and inert. The tree assigns each branch to an accountable owner, so when cross-team connectivity drops, the leader responsible for that interface is pushed the change rather than learning about a silo months later. Ownership on every node is what makes the analysis operational instead of merely interesting.

There is no universal target for network density, because the right level depends on the work. Teams doing tightly coupled creative work need high connectivity, while teams running independent parallel streams are healthy at lower density. The useful benchmark is the pattern of the measures together, not any single threshold. The ranges below give a starting read for a department-scale network.

When comparing your network over time, watch the direction more than the absolute level. A density that is slowly falling after a reorganisation is an early warning of forming silos, well before anyone reports feeling disconnected. A betweenness score concentrating in fewer and fewer people is an early warning of growing key-person risk. The benchmark that matters most is your own network three months ago.

Improving a collaboration network is not about telling everyone to talk more. Blunt density targets backfire into meeting overload. The work is structural: build bridges where they are missing, reduce concentration where one person carries too much, and connect the isolated. Each move targets a specific weakness the analysis already located.

The decomposition is what makes the network actionable instead of a wall art diagram. KPI Tree lets you break collaboration health into its connectivity, distribution, silo, and exposure branches and attach the accountable leader to each one. When cross-team connections fall, the owner of that interface is pushed the change, and the verified impact loop then checks whether the bridge they built actually lifted the connection rather than just adding another meeting to the calendar. That is the difference between a network you observe and a network you steer.

1. 1

   Treating density as a target to maximise

   Pushing density ever higher creates meeting overload, not collaboration. Above a point, more connections crowd out focused work. Aim for the right structure for the work, not the densest possible graph.

2. 2

   Counting noise as connections

   Large distribution lists, all-hands invites, and one-off mentions create phantom edges that make the network look healthier than it is. Set a real threshold for what counts as a working relationship before you build the graph.

3. 3

   Confusing the org chart with the network

   The reporting structure is not how work flows. Analysing the formal hierarchy instead of the real interactions misses exactly the hidden brokers and silos the technique exists to surface.

4. 4

   Ignoring single-point exposure

   A network can post healthy density while quietly routing every critical path through one person. Density alone hides this. Always read centrality and betweenness alongside density to catch key-person risk.

5. 5

   Mapping once and stopping

   A single snapshot cannot show whether silos are forming or brokers are concentrating. Without a repeated read over time and an owner on each structural risk, the analysis describes a moment nobody is responsible for improving.