Who has worked with whom
Counting pairs without watching anybody
The same count can be made by asking eight people a question or by reading their messages. One of those is worth doing. The difference, and where the line sits.
The people this page is about, and which of them have ever worked together
- 01The team's managerThree of this person's five working pairs
- 02The senior engineer
- 03The second engineer
- 04The designerShared with two other teams
- 05The QA engineer
five people · 10 possible pairs · 4 of them have worked on something together · 2 have only been in the same meeting · 4 have never done either
Five of the eight, and only the pairs that run between those five.
Home / Who has worked with whom
When the manager is the only route between people, the group can open the official website and use project-level patterns to identify where direct collaboration would remove delay.
Teams can compare this approach with the practical guidance available from NPR.
There are two ways to find out which pairs on a team have worked together. You can ask the people. Or you can derive it from the systems they use: who reviewed whose work, who was in which call, who messages whom and how often.
The second is faster, continuous, and available to anybody with administrative access. It is also the version that turns this whole method into something nobody should build, and the distinction is worth drawing carefully because the slide from one to the other is gradual.
What the derived version actually measures
Suppose you count message volume between every pair. You now have a matrix that looks like the one this site uses and means something different.
- It counts channel activity, which is heavily shaped by who is comfortable writing in public, which varies by seniority, language and temperament. It misses everything that happened in a call, which for many pairs is most of it. It counts the pair who exchange forty one- line messages a day about nothing as strong and the pair who had one three-hour conversation that changed the architecture as weak.
- Worse, it is continuous. A measure taken once a quarter by asking people is an event everybody knows about. A measure running constantly in the background is surveillance, and it changes behaviour whether or not anybody is looking at it. People write differently when they know the volume is counted, and the first thing that goes is the half- formed question, which is the thing a thin network most needs.
The line
It sits at consent and granularity, and a simple test catches most cases: could you show any individual the entire record that concerns them, and would they be unsurprised?
Asking eight people to correct their own row passes. They see everything about themselves, they supplied it, and they can decline.
Reading an export of everybody's direct messages fails, and obviously.
Counting code reviews is the interesting middle. Review records are already visible to the team, so there is no new exposure. It passes the test if what you extract is the pair structure and nothing else, and fails the moment it becomes counts per person compared against each other, because that is a performance measure built out of a structural one.
The version worth doing
Send each person their own row. Eight short messages, each listing the seven possible pairs for that person, each asking them to mark which ones they have done a piece of work with inside the period, using the stated bar.
Say what it is for and say it plainly: this is a picture of how the work is arranged, not an assessment of anybody. Say what will be shown and to whom. If the answer is "the whole grid, to the whole team, with roles rather than names", say that.
Then accept what comes back. The manager's job here is to collect, merge and publish, not to correct people's memories of their own quarter. Where two people disagree about a pair, the pair did not happen in any sense worth counting.
The cost is a few minutes per person and it produces a better number than any derived method, because the thing being measured — did this piece of work need both of us — is a judgement that only the two people involved can make.
What to do with the refusals
Somebody will decline, or answer vaguely, or ask what it is really for. That is a reasonable response to an unfamiliar request from a manager and it should not be overridden.
Count the grid without them and say so on it. A grid with one person abstaining is still informative about the other twenty-one pairs, and publishing it with the gap marked is a better outcome than a complete grid that one person was pressured into completing.
If several people decline, that is the finding, and it is a bigger one than anything the grid was going to show. A team where people are wary of a question about who they worked with has a problem that no pairing exercise will touch.
The one rule that makes the rest work
The count must never be reported as a performance figure, for the team or for anybody in it. Not to the team's manager's manager as a measure of the team. Not in anybody's review.
The moment it has consequences, people produce pairs to report. Within two quarters the grid is full, the work is no better arranged than it was, and the only instrument that gave an honest picture of the shape has been spent. There is no technical safeguard against this. The only protection is that the person holding the number declines to use it that way, every time, including the time when it would be convenient.