Who is still here
Tenure on the team against tenure here
Two numbers per person, one of them usually much smaller. Reading them together is the cheapest way to see how old a team actually is.
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.
Where projects cross several roles, teams can review the setup here to make hours and handoffs visible enough for a useful capacity discussion.
For a separate perspective on teams and working practice, consult Atlassian Team Playbook.
The four longest-serving people in the company, and how little of that service has been on this team
The team's manager
14 on the team61 in the companyFourteen of sixty-one months
The QA engineer
9 on the team52 in the companyNine of fifty-two
The designer
5 on the team44 in the companyFive of forty-four, after moving across in June
The data analyst
4 on the team19 in the companyFour of nineteen, and shared with two other teams
four people · median 9 months on this team · the longest-standing has 14 months · four of them have been on it for less than half the time they have been in the company
One further line was given to this panel and is not drawn. It puts twenty months on a team inside fourteen months at the company, which cannot happen: the segment would run out past the end of its own track. The row came from a date typed with the wrong year, and the drawing is where that became obvious.
Take each person and write down two figures: how long they have been in the company, and how long they have been on this team. The second is always smaller or equal. On most teams it is much smaller, and the distance between them is the useful quantity.
The panel above draws the four longest-serving people here. Between them they have a hundred and seventy-six months in the company and thirty-two on this team. The track is the company time; the filled segment at its right-hand end is the part of it spent here — the latest stretch of one service, not a second quantity set beside it.
Why the two numbers are read together
Each answers a different question and neither answers the other.
Company tenure predicts whether somebody can navigate the organisation: who to ask, how things get approved, what has been tried before, which rules are real. It is the better predictor of whether a person can get something done outside the team.
Team tenure predicts whether they can answer a question about this team's work: why the retry limit is three, what the customer asked for originally, which of the two deploy paths is the real one. It is also the better predictor of how many working pairs they have, because pairs take a quarter or so to form.
Confusing them produces two specific errors.
A long-serving person newly moved into the team is treated as a resource for team history they do not have. They are asked why something was done and they guess, plausibly, from how the company usually does things, and the guess is wrong in a way that is hard to detect.
And a team of experienced people with short team tenures gets read as a senior team that should need little support. The individuals are senior. The team is four months old.
What the gap tells you
- A wide gap for most members — long in the company, short on the team — means the team was assembled from inside. The people know the organisation, the onboarding was fast, and nobody can answer a question about last year's decisions because the team did not exist then.
- A narrow gap for most members means people joined the company and this team at the same time, which usually means the team was built by hiring. More decisions are documented, because none of the shortcuts existed yet, and there is less organisational navigation available.
- A mixed picture — two people with no gap and four with a wide one — is the commonest, and it tells you who to ask for what. The two with no gap are the team's memory. The four with the gap are the routes out of the team into the rest of the organisation.
The row that could not be drawn
One line given to the panel claims twenty months on a team inside fourteen months at the company. It was a typing error: a start date with the wrong year, carried from a spreadsheet, and the kind of thing that reads perfectly well in a column of numbers.
Drawn, the segment would have run past the end of its own track and out of the panel. The sign declines it for that reason, and the refusal is worth more than the row would have been: it caught an error that no amount of reading the table would have caught, because a table has nowhere for an impossible number to look wrong.
Where the dates come from
All of this requires two dates per person, and only one of them is reliably recorded anywhere.
Company start dates exist in a system. Team start dates mostly do not: somebody moved across in June, somebody's area was transferred in a reorganisation, somebody has been half on the team since the spring. There is frequently no record and no obvious answer.
Ask the person. They know, within a fortnight, and their answer is better than any system's, because what is being measured is how long they have felt themselves to be on this team rather than when a field changed.
Where the answer is genuinely ambiguous — a gradual transfer — take the later date. Overstating team tenure is the error that makes a young team look settled.
What to do with the two numbers
Collect them once, when you do the first pair count. They take two minutes and they qualify everything else.
Then use them for one decision: who gets asked to explain things. A team with a short median tenure and a long company median has plenty of people who can find out and almost nobody who already knows, and treating the first group as the second is how a team ends up confidently repeating a mistake it has already made.