The overlap you have and the one you need

Doing the overlay

Write the eight people across the top of a page and the rows down the side. Put a mark where each person is in each row. Then look down the columns instead of across the rows.

What you are looking for is people whose columns match. Two people who appear together in four rows out of six are a sub-group whether or not anybody has called them one. A person whose column matches nobody's is isolated in a way that the pair grid will also show, and the two pictures agreeing is worth something.

On the team here the overlay produces three clusters and one person outside all of them, which is the same answer the pair grid gives. When the two methods disagree, the pair grid is the one to believe: shared attributes predict collaboration and are not it.

Which overlap you actually need

The list of rows a team has is not the list it needs, and the gap between them is the actionable part.

Start from the seams rather than from the rows. Go through the last quarter and find every place where the work crossed between two people: a handover, a decision one made that landed on the other, a problem solved twice in two places, an outside party getting two different answers.

Each seam names a pair. Now check that pair against the rows. If they share four rows and still had a bad seam, the problem is not structural and this site has nothing useful to say about it. If they share nothing — no artefact, no hours, no duty, no history — then the seam was always going to be rough, and the fix is to give them one row rather than to give them a conversation.

Which row to give

Cheapest first, and the ordering is fairly reliable.

• A shared obligation is the cheapest and the strongest. Put the two of them on the same rota, the same review roster, the same duty week. Costs nothing, recurs on its own, produces a handover every cycle.
• A shared artefact is next. If there is any document, dataset or component that both of them touch, make it explicit that both of them own it rather than one owning it and one requesting changes.
• A shared deadline is the sharpest and the most disruptive. Two people, one date, one output that needs both. It forms the pair fastest and it is the one that requires somebody with the authority to arrange work.
• Shared hours are the hardest to give and the least often necessary. If a pair has a real seam and no overlap, the answer is usually to make the handover explicit and written rather than to move somebody's working day.

The seam audit in detail

It is an afternoon and it produces the only list on this site that is specific enough to act on without further thought.

Go back through the quarter and look for four things. A handover that cost more than it should have. A decision one person made that arrived as a surprise to another. The same problem solved twice in two places. And an outside party who got two different answers from two members.

Write down the pair of people involved in each. Do not write down what should have happened, which is a different exercise and will take the rest of the day.

What comes out is usually four to eight pairs, several of them the same two names repeatedly. Those repeats are where the money is.

What not to conclude

A thin overlay is not a sign that the team is badly constructed. Most of the rows on a pyramid are consequences of what the organisation asked these eight people to do, and a manager cannot usually change them.

What a manager can do is notice which of the seams are being paid for, and give those specific pairs one row each. Four pairs given one row each in a quarter is a realistic amount of change and it is visible on the next count.

Trying to raise the whole pyramid — getting everybody into the same product area, the same codebase, the same hours — is the kind of ambition that produces a reorganisation, and reorganisations have their own costs that are well outside the scope of a site about counting pairs.