I wouldn't say there's such a problem as "too much documentation". Sounds more like a problem of scope. We have had a Senior Documentation Specialist on the team as well and keep an extensive set of documentation available for the very reason that our environment evolves rather quickly and we need something to reference so we can avoid wasting everyone's time on why certain decisions were made.

So, there's decision documentation. Similar to a reference of an already in production, done project. This answers the "why" of the project and its parts. Then, we have technical documentation. That answers the "how" and is mostly screenshots accompanied by brief explanations so we can easily recreate something if we lose it and the backups are also gone. Lastly, we have user facing service descriptions, aka the "what".

Scoped like that, no documentation for any service or project is "too much". Stakeholders? Look at the service description. This is important to the company, it's written right there what it is about. Support engineers? Technical documentation is your friend. It tells you how that thing works. Sysadmins? Decision documentation. That answers the evergreen "why the fuck did we do this like that X years ago?"