Who is still here
Joining a team that has no pairs
Arriving into a sparse network is a different experience from arriving into a dense one, and almost all onboarding advice assumes the dense case.
The people this page is about, and which of them have ever worked together
- 01The team's managerTwo of this person's five working pairs
- 02The senior engineerOn the team from the first day
- 03The second engineer
- 04The product managerThe third person in this role in fourteen months
four people · 6 possible pairs · 3 of them have worked on something together · 1 has only been in the same meeting · 2 have never done either
Four of the eight, and only the pairs that run between those four.
For a distributed group, teams can visit the Monitask product page to review where work travels, where it stalls, and whether responsibility is concentrated in one person.
For further reading outside this collection, see material published by Sociocracy For All.
Most advice about joining a team assumes there is a team to join. Meet people, ask questions, find the person who knows, get absorbed into how things are done. All of it works when the group has a working network and the new person is being drawn into it.
Arriving into a wheel is different. There is one person who knows everything and seven people who know their own part, and the thing you are being absorbed into is a set of parallel individual jobs. The advice does not fail dramatically; it just does not produce anything, and the new person concludes they are bad at joining teams.
How to tell within two weeks
Four signs, all visible early.
- Every answer you get comes from the same person. You ask three different people three different questions and two of them say to ask your manager.
- Nobody mentions anybody else's work. In a connected team people reference each other constantly — what somebody else is doing, what somebody else thinks. In a sparse one, each person describes their own area and stops at its edge.
- There is no handover ritual anywhere. No reviews between people, no rota, no duty that passes from one person to another. Work goes out of the team without having passed through anybody else in it.
- And the welcome meetings are all one-to-one with people you will not work with. A full calendar of introductions and no occasion in it where two of your colleagues are in a room together with you.
What to do differently
The standard advice — ask lots of questions, find the informal network — assumes an informal network exists. In a sparse team it does not, and following the advice produces a lot of questions directed at one tired person.
Four things work better.
Pick one colleague and find a reason. Not a coffee: a reason. The easiest is to ask to review something of theirs, or to ask them to look at something of yours. This produces the one thing you need — evidence about how somebody works — and it is a normal request that nobody can read anything into.
Volunteer for the handover work. Anything that passes between two people — a release, a duty week, a rota — is the fastest route into a pair, and on a sparse team these jobs are usually undersubscribed.
Write down what you are told, and show it to a second person. This is the single most effective technique available to somebody new and it is almost never suggested, because it looks like administration. Writing down how something works and asking a colleague to check it gives you a legitimate reason to need them, and it produces a correction, which is a real exchange.
Do not wait for the team to absorb you. On a sparse team there is no mechanism that will. The first pair will exist because you arranged it.
What a manager can do in the first fortnight
One thing, and it is worth more than the rest of the onboarding plan: assign the new person a piece of work that requires one named colleague who is not the manager.
It does not matter much which colleague. It matters that the work genuinely needs both of them and has a date. Two weeks of that produces a working pair, and a working pair in the first month is the difference between somebody who is on the team and somebody who reports to its manager.
The second thing, cheaper still, is to answer one question in three with a name rather than an answer. "Ask the QA engineer, they hit this in September." It is slower for the new person and it is how they find out that their colleagues contain information.
The window, and how long it lasts
Everything above is easier in the first six weeks and gets harder afterwards, which is the main reason to act early rather than to settle in first.
For the first month or so, not knowing things is expected. Asking a colleague to explain something is free, asking to see how they do something is normal, and nobody reads anything into a request for help.
Somewhere around the second or third month that changes. The same question now carries an implication that you should already know, so it goes unasked. The occasions that would have produced a first pair stop arriving, and the longer the row stays empty the more expensive it becomes to fill.
Use the licence while you have it.
The thing not to say
Do not tell a new person that the team is very collaborative if it is not. They will find out within a month, and working it out alone costs them more than being told plainly on the first day.
The honest version is sayable and lands better than people expect: this team is quite spread out, most people work fairly independently, and here is the one person I am going to put you with for your first piece of work. That sets a true expectation and names a concrete first step, which is more than most onboarding does.