You don't have time for people to not document everything.

Documentation has to be done once. (Well, it has to keep being updated. But for any change, the documentation only needs updated once.) But new people need to know about it over and over, because as you grow, you keep getting new people. You don't have time for each new person to have to go exploring to find the answer to each question. It's far less time to have one experienced person write down the answer... if you have each new person read all the relevant documents, and if you have people update the documents every time anything changes.

The last point is important. It has to become part of the culture. It should also become part of the code review/commit process.

At my last job, I was on the wrong end of this. Much of the initial code was written by two people. One was now a director; the other was incredibly busy. The code was extremely object oriented, to the point that it was very hard to figure out where anything happened and therefore where changes should be made. The documentation was a number of UML diagrams.

The result was that new people (including yours truly) wasted huge amounts of time trying to find their way around in the code. Even after being there for three years (and with over 35 years of experience), I still found the code very hard to work with.

What that code needed was someone (one particular someone) to take a solid month and work on writing good beginner-to-intermediate documentation for the code base. It would have saved literally man-years of time for new people.