Running a collaboration diagnosis for a team under 50: a data checklist

The ceiling on how much you can trust a diagnosis is set the moment you assemble the data. All the model can do is compute the relationships you handed it, faithfully — whatever dimension you dropped, the conclusion cannot recover.

This checklist covers the fields you must prepare, the parts you can skip, and the four mistakes that most often distort the result.

Why 50 people

Scale first. Collaboration network analysis has a physical limit that no tool changes: past a certain node count, the network map degenerates into a hairball, and structural measures like density and centralisation lose their discriminating power — they converge.

Above 50 people, the answer is not to push through. It's to split by project or sub-team into groups under 50 and diagnose each separately. This is usually more accurate anyway: collaboration patterns across projects and within a project are different animals, and mixing them in one map contaminates both.

The four fields you must prepare

Every relationship (every edge) needs at least these four:

Field	Meaning	What you lose without it
from	Initiator	Can't tell who drives and who absorbs; bottlenecks and isolated members become indistinguishable
to	Receiver	Same as above — direction is what reveals collaboration quality
channel	Channel type	Information density and handling cost differ by channel; merging them distorts weights
count	Frequency or strength	Knowing there's a connection but not how often distorts density and centrality

Add one time dimension, your choice of two:

• timestamp — for continuous collection, enables trend analysis
• period — for manual assembly, e.g. "August 2026"

Without a time dimension there is no trend analysis, only a single snapshot. And structural change is often more informative than structural state: a channel going from active to zero tells you more than ten notes saying "so-and-so communicates little."

What you can skip

• Content. Not needed, and shouldn't be collected. See our separate piece on data boundaries.
• Precise weights. Whether an edge is 12 or 13 carries no signal. When assembling by hand, use magnitudes (1 / 3 / 10 / 30) — more honest and much faster.
• Per-interaction timestamps. Unless you're doing fine-grained rhythm analysis, aggregating by period is enough.
• Job titles and levels. They don't help structural diagnosis, and they invite readers to misread a structural problem as a hierarchy problem.

The four mistakes people make most

Mistake 1: handing over an undirected, unweighted graph

Recording only "who relates to whom," with no direction and no frequency.

It's the most common shortcut and the most expensive: it deletes the two most valuable dimensions on this list. For the same product–engineering edge, "product reached out 20 times, engineering 0" and "10 each way" are entirely different organisational states. On an undirected graph they look identical.

Mistake 2: collapsing every channel into one

Folding all interactions into a single "communication" channel.

Group chat, email, meetings and tickets differ in information density, traceability and handling cost. Once merged, a team with three meetings a day and a team with three hundred chat messages a day can present the same edge weight. They are different problems needing different fixes.

Mistake 3: choosing a window that's too short or too long

• Too short (under a week) treats accidents as the norm. Someone happens to be on leave and an island appears on the map.
• Too long (over six months) keeps already-solved problems on the books and averages away recent change.

Aim for 3 to 6 weeks, ideally avoiding obvious holidays and release peaks. For the next round, use a window of the same length so the two datasets are comparable.

Mistake 4: referencing undeclared members

A relationship whose from or to points at an id that isn't in the member list.

The damage isn't just a node that fails to render. It makes the real node count diverge from the member count, which corrupts the density denominator, which skews every density-based judgement downstream. Cross-check before you submit: every id appearing in a relationship must exist in the member list.

A suggested assembly process

1. Set the scope. One project or sub-team, under 50 people, with an explicit time window.
2. List members. Produce the member list first, one stable id each. Leaving role blank is fine; filling it in is better.
3. Collect relationships. Metadata only: who, to whom, which channel, how many times, when.
4. Cross-check. Every id in a relationship resolves to a member. Every member either appears somewhere or is deliberately included as isolated — in which case the isolation is part of the finding.
5. Self-audit before submitting. Are the windows consistent? Are channels categorised? Is any count off by an order of magnitude — an edge larger than the whole team's total, say?

One warning for small teams

If the team is between 10 and 30 people, note this: anonymisation barely works at small scale.

Even with names stripped, whoever reads the report can work backwards from "who interacts a lot with whom" to who is who. That isn't a failure of de-identification. The topology of a small team carries identity in it.

So run the first round at team level, and look at individual-level findings only with explicit authorisation. Small does not mean low risk — quite the opposite.