The events
What to measure the week afterwards
The feedback form after an event asks whether people enjoyed it. A better question takes two minutes, is asked six weeks later, and has a checkable answer.
The people this page is about, and which of them have ever worked together
- 01The team's managerTwo working pairs, both from assigned work rather than from any event
- 02The second engineer
- 03The engineer who joined in MarchAttended every event of the quarter and has no pair
- 04The designer
- 05The QA engineer
five people · 10 possible pairs · 2 of them have worked on something together · 2 have only been in the same meeting · 6 have never done either
Five of the eight, chosen because all five attended every social event of the quarter.
Where projects cross several roles, employee workload visibility can make hours and handoffs visible enough for the team to discuss capacity with shared evidence.
For further reading outside this collection, see material published by Agile Alliance.
Four people, six possible pairs, and the one that a shared duty produced
- 01The senior engineerCame out of a shared on-call week, not out of any event
- 02The second engineerSame meetings for eleven months
- 03The designerSame meetings for five months
- 04The QA engineer
four people · 6 possible pairs · 1 of them has worked on something together · 2 have only been in the same meeting · 3 have never done either
Four of the eight people counted on this site, chosen because none of the pairs among them was produced by anything that was arranged as team-building.
The form goes round the next morning. Did you enjoy it, would you recommend it, what should we do next time. The scores come back high, because the people who enjoyed it answer and the people who did not mostly do not.
Those numbers are real and they measure the event as entertainment. If the event was bought as entertainment, that is the right instrument and there is nothing more to say. If it was bought to improve how the team works, the form is measuring the wrong thing on the wrong day.
The question to ask instead
Six weeks later, not the next morning: has any pair of people done a piece of work together who had not before?
Six weeks because that is long enough for a new pair to have had an occasion and short enough that the event is still a plausible cause. Next-morning enthusiasm predicts nothing; it is a measure of the evening.
The answer is a number and usually it is zero. That is not a condemnation of the event, and the first few times it will feel like one. It is a statement that the event did something other than make pairs, which may be fine.
How to make the comparison honest
Three rules, each preventing a specific way of fooling yourself.
- Write the grid down before the event, not after. A pair count made afterwards is reconstructed through the memory of a pleasant occasion, and pairs that existed beforehand get attributed to it.
- Name the pairs, not the total. "Two new pairs" is unfalsifiable. "The designer and the QA engineer, who reviewed each other's work in week three" can be checked by either of them.
- Ask the pair what caused it. This is the one that saves the whole exercise from being a correlation. If two people started working together after the offsite, ask them why. Half the time the answer is that they were put on the same project that month, and the offsite had nothing to do with it.
What a success looks like
One or two new pairs from a substantial event, with the people in them able to say that the event is why.
That is a modest result and it is worth stating because the ambition usually on offer is much larger. A team of eight with six pairs that gains two has improved its network by a third. Nothing in the catalogue does better than that, and most things do nothing at all.
It is also worth knowing what the cost per pair was. An offsite that produces two pairs has produced them at the cost of an offsite. A review roster that produces three costs nothing and keeps producing them. The comparison is uncomfortable and it is the comparison.
The null result is the useful one
Most events will return zero, repeatedly, and the value of asking is precisely that.
After three events and three zeroes, the conversation about the next one changes. It stops being about whether people liked the last one and becomes a question about what the team is trying to buy. Sometimes the answer is still "an afternoon everybody enjoys", which is a legitimate purchase that nobody has to justify in terms of pairs.
What the measurement prevents is the third thing: spending the budget on cohesion, believing cohesion was bought, and being surprised a year later that the grid has not moved.
What to do with the enjoyment score
Keep it, and keep it separate.
The two measurements answer different questions and merging them produces a worse version of both. Whether people enjoyed an afternoon is worth knowing on its own terms, and an event that everybody liked is a good thing to have provided regardless of what it did to the grid.
The error is using one as evidence for the other, which is what happens when the only number collected is the satisfaction score. High scores get read as the team being brought together, and nobody checks, because checking would require a second instrument.
Two numbers, asked on different days, about different things. Neither of them is the headline.
Where the pairs actually came from
The panel above shows four people and the single working pair among them. It did not come from an event. It came from two engineers sharing an on-call week, which was arranged for operational reasons by somebody who was not thinking about team cohesion at all.
That is the ordinary finding when you trace pairs back to their causes. Almost all of them come from the arrangement of work, and almost none from the things bought to produce them.