What a team is
The difference a shared task makes
Two people who have shared one piece of work know things about each other that no amount of friendly conversation produces. This note is about what those things are.
The people this page is about, and which of them have ever worked together
- 01The team's managerFive of this person's six pairs are with people not in this grid
- 02The senior engineerThe one working pair on the whole team that does not involve the manager
- 03The second engineer
- 04The engineer who joined in MarchNo pair with anybody
four people · 6 possible pairs · 2 of them have worked on something together · 4 have never done either
Four of the eight, and only the pairs that run between those four.
For a distributed group, time tracking for project teams provides a practical way to review where work travels, where it stalls, and whether responsibility is concentrated in one person.
The broader organisational question can also be checked against resources from IDEO.
Two people on the same team have been in roughly two hundred meetings together over a year. They know each other's job titles, voices, backgrounds and time zones. They have made each other laugh. If you asked either of them whether they know the other, both would say yes.
Neither of them could tell you how the other works. Not what they do — how. Whether they think by writing or by talking. Whether an early draft from them is nearly finished or deliberately rough. Whether silence from them means agreement, disagreement, or that they are reading. What they are good at that is not in their job description, and what they quietly avoid.
All of that arrives in the first piece of work two people do together, and almost none of it arrives any other way.
What a shared task transfers
- The first time you work with somebody you learn their defaults. You discover that they will not send anything until it is tidy, so a request to them produces nothing for two days and then something complete. Or the opposite: they send the rough version immediately and expect you to argue with it, and if you treat that version as a proposal you will spend a week on a decision they had not yet made.
- You learn their vocabulary, which is not the team vocabulary. You find out that when they say "done" they mean merged, and you meant deployed, and the gap between those two meanings is where a week went.
- You learn what they are actually responsible for, as distinct from what the chart says. Most people on most teams own something slightly to the side of their title, and that is never written down anywhere. It is discovered by needing it.
- And you learn the cost of asking them something, which turns out to be the single most important fact. Before the first shared task, asking a colleague a question has an unknown price: you do not know whether it will cost them three minutes or interrupt an afternoon, whether they will find the question reasonable, whether they will think less of you for not knowing. Unknown prices get treated as high prices. After one shared piece of work, the price is known, and it is almost always lower than the estimate.
Why conversation does not substitute
This is the part that catches people out, because the obvious remedy for a thin network is more contact, and more contact is easy to arrange. Put two people in a recurring call. Pair them for a coffee chat. Make them buddies.
Contact without a task has no stakes, and the information above is all stakes-dependent. You find out how somebody handles disagreement by disagreeing with them about something that matters. You find out how they handle being wrong by watching them be wrong in front of you. You find out whether they will tell you something inconvenient by giving them something inconvenient to tell you. A pleasant half-hour about holidays and pets produces none of it, and produces instead a warm feeling that both people mistake for knowing each other.
That warm feeling is not nothing. It makes the first shared task easier when it comes. But if it never comes, the feeling decays within a few months and leaves the pair exactly where it started.
The size of the task
It does not have to be big. The best first task between two people is small, finite, slightly awkward and genuinely needed by somebody else. A single review. One afternoon of looking at a problem together. One document that neither of them could have written alone, with a deadline that is close enough to prevent it drifting.
Big tasks are worse for this purpose, not better. A six-month project shared by two strangers produces three months of careful politeness before anybody says anything real, and by then the structure of the project has been set by that politeness. A two-day task produces the real conversation on the first morning, because there is no time for anything else.
What this implies
If the point of a team activity is to create working pairs, the activity has to contain work. That is an unwelcome conclusion, because work is harder to organise than fun, and because the word "team-building" has come to mean specifically the things that are not work.
But it narrows the field usefully. Any proposed activity can be checked against one question: at the end of it, will two people who had not produced anything together have produced something together? For most of the standard catalogue the answer is no, and those activities are doing something else — which may still be worth doing, as long as nobody expects the network to change.
The things that pass this test are covered in the last part of this site. They are unglamorous, they mostly cost nothing, and several of them are already on your team's calendar being used for something else.