Main idea

A Product Manager who has worked for three years with the same developer doesn't need to write what they would have to write for a developer who joined three months ago. A team that talks every day can leave some things verbal; a new, distributed team, or one working on a risky topic, has to make more explicit. The amount of writing needed is not a property of the topic, it is a function of what both sides already hold in common.

Hence the symmetrical drift from the three-line drop: imposing templates everywhere, adding fields, turning every card into a mini-dossier, writing to cover yourself rather than to work. Reference points like Definition of Ready and Definition of Done help as long as they stay alive; they do harm the moment they replace judgment about what the other person already knows.

Why it matters

This explains why a writing standard imported from one team to another fails so often: it carries an amount of writing calibrated on a shared context that doesn't exist here.

It also gives the real variable to watch. Turnover, a new hire, a shift to distributed work all raise the need for writing without any topic having changed.

Nuances and limits

Shared context makes writing less necessary for the team that's here, not for the one that will come. A ticket understood by two people is no longer understood by the third to arrive, nor by the same team six months later.

And judging what is "already shared" is optimistic by nature: whoever writes overestimates what the other has in mind.

Open questions

• How do you detect that the shared context has dropped, before the misunderstandings show up in the delivered work?