Let's talk a little about living technical documentation for software systems.
Our organizations are always in flux.
We have a responsibility to both bring new members up to speed quickly /and/ preserve the mental context of those moving on, for the benefit of others.
If multiple people can consult ground truth documentation for how something works, they're not asking other, more experienced teammates, for the same information over and over again - each time getting a slightly different story.
This often helps the reduce the operational burden, as well as the breadth of context, required for members of your team.
It also makes the team appear to care about their work, and that it incentivizes and rewards learning, and paying down technical debt.
If your team's work portfolio doesn't consider writing or fixing technical documentation relevant to its balance of technical debt, your backlog is leaky.
Are you writing for the team?
These could be onboarding docs, reference materials, localized technical design docs.
Engineers (or others) with suggestions for improvement, owners of dependent systems investigating incidents, owners of dependency systems trying to familiarize with customer use cases.
Curious employees, people considering transfers into the team, authors of new designs researching prior art.
And preemptively write accessible documentation for things you know the team will get asked about.
Also: fresh eyes find bugs