What you share
What a shared codebase actually buys
The strongest row on most technical pyramids is a shared artefact, because it creates occasions between people without anybody organising anything.
The people this page is about, and which of them have ever worked together
- 01The team's managerEvery working pair in this grid includes this person
- 02The designer
- 03The data analyst
- 04The product managerWrites the brief everybody reads
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.
A fair pilot starts with a written purpose and shared baseline; managers can visit the service online before comparing what changes after a new working practice.
An independent source worth comparing with this example is Fortune.
Four of the eight people counted here share a codebase. It is the fourth-widest row on their pyramid, well below the manager and the all-hands, and it is the only row above two that reliably produces pairs.
The reason is worth generalising, because the property is not about code. It belongs to any artefact that more than one person changes, and it is the closest thing in this subject to a mechanism that works without maintenance.
The property
When two people change the same thing, one person's change arrives in the other person's work whether either of them wanted it to. That arrival is an occasion. Somebody has to look at it, understand it, possibly disagree with it, and say so.
Nobody organised the occasion. No meeting was scheduled, no introduction made, no buddy assigned. The artefact did it, and it will keep doing it every week without anybody remembering to.
This is what distinguishes a shared artefact from the other wide rows. A shared manager produces eight separate conversations. A shared all-hands produces an announcement. A shared document that nobody edits produces nothing. A shared thing that people change produces a stream of small, unavoidable, two-person exchanges.
What counts as one
Not only code, and it is worth listing the others because teams that are not engineering teams assume this note does not apply to them.
- A document that several people edit, where edits get questioned.
- A dataset or a model that several people maintain, where one person's redefinition of a field shows up in another person's numbers.
- A design file with shared components, where changing a component changes other people's screens.
- A spreadsheet that drives something real, which is the most common and least acknowledged example in most organisations.
- A runbook or a rota, which is shared precisely at the point where one person's night becomes another person's morning.
The test is the same in each case: if one person changes it, does another person have to notice?
Why shared ownership of a backlog is not the same
Teams that have no shared artefact often try to manufacture one, and the usual candidate is the board. Everybody's work is on it, everybody looks at it, it is unambiguously shared.
It does not have the property. Two people's cards sit next to each other and never touch. Moving mine does not arrive in yours. The board is a shared view of eight separate things, which is a reporting instrument rather than an artefact, and it produces exactly the pairs that an all-hands produces.
The same is true of a shared goal, a shared dashboard that nobody edits, and a shared channel. Visibility is not arrival.
What to do if there is no shared artefact
Some teams genuinely have none, and for them this row is zero and cannot be faked.
The substitute is a shared obligation rather than a shared object: a rota, a duty, a review roster, an on-call rotation. These work by the same mechanism one step removed — the handover is the arrival. Somebody finishes a week and has to tell somebody else what is outstanding, and that conversation is a real exchange with stakes, repeated on a schedule, between pairs that rotate.
A review roster is the cheapest version and the one most teams already half have. Making it deliberate — who reviews whom, rotating — converts an existing process into a pair-making device at no cost, and it has its own note in the last part of this site.
How a shared artefact stops being one
Usually without anybody noticing, and by the same route every time.
Somebody becomes the person who understands that part. Changes to it get routed to them, first as a courtesy and then as a rule. Others stop touching it because the review takes longer than the change. Within two quarters a shared artefact has one owner and seven requesters, and the row on the pyramid that said four is now true of one.
The signal is quiet: reviews on that area get faster and less contentious, which reads as the team getting better at it. A shared thing that nobody argues about any more has usually stopped being shared.
The caution
A shared artefact produces pairs and it also produces conflict, because the arrival of somebody else's change in your work is intrinsically an interruption. Teams that share a codebase argue more than teams that do not, and some of that arguing is the pair forming.
It is worth knowing that the row has a cost, so that nobody reads a drop in apparent harmony as a failure of the thing that is actually working. A team that never disagrees about a shared artefact is usually a team where one person has quietly taken sole ownership of it, and the row is narrower than it looks.