A big problem is capturing what your team learned, as semi-structured documentation. Otherwise tribal knowledge fades with time and turnover, and you’re finally left with a system you don’t understand but luckily still works.
It has to be something that the team commits to maintaining. IME, often there are a couple of folks in the entire team who contribute with any regularity, or care to update the docs. Its often not an activity that's given credit. When the people who maintained the docs switch teams, there is rot- docs become stale. Because they're stale, other users don't trust them don't update them, just stop using them leading to a vicious cycle where they become totally irrelevant.
True, but I would say that if (thats a BIG if) the code is written to reflect the domain (see Domain-Driven Design), then other developers should be able to pick up the main concepts of the domain pretty quickly. Maybe you have some artefacts leftover from some Event Stomring sessions or a User Story Map or an Impact Map,... all these come in handy.
