Postmortems are important to drive home what went wrong, but newcomers won’t read them all.
That’s why you need people with experience and people with tenure.
What companies sometimes do: They encode lessons into rules, which tend to survive turnover. But that comes with its own set of problems, where you end up having a lot of rules who’s reason is forgotten.
The reason employee retention is so important for software companies (or at least should be!) is that the loss of knowledge associated with replacing one employee is much greater than at first glance.
(Well, that and the fact that some things have really long feedback cycles, and you have to stick around for a few years to truly see the consequences of your decisions.)
Keeping notes for yourself can be handy, though.
This was not a perfect system - nothing is - but the culture of the group just baked this behavior in to the timeline for 'done'. When the majority of people had that expectation, it seemed to work decently. In 25 years of professional work, that's the only place I can remember seeing it done that disciplined. And... they were only around 100 folks total - not sure it could necessarily scale as they grew.
Also, when you leave the company you keep your own notes.
[1] https://henrikwarne.com/2016/06/16/18-lessons-from-13-years-...
Honestly, keeping documentation up to date, and writing accessible documentation is a different job than making the system. If it's important, you need a technical writer on staff to do it, and a commitment that developers need to work with the writer to get things accurate and as complete as possible. It's the same as testing; you can try to make developers do it, but some developers aren't capable of good testing and some aren't capable of good writing, and in both cases, having an independent person doing the work will result in more coverage, since the other person may not share the same "implicit" ideas that the one developer might not document or test.