This is a passion and pet peeve of mine. Here are my takeaways:
1) Technical documentation should be coupled with code, so devs will update it as services change (especially in a large or microservice oriented company), and that documentation is pulled into the general purpose system (read: non-tech, mgmt) This also vastly helps with versioning and finding old info (confluence versioning sucks)
2) Diagrams should be diagrams as code, for the same reasons, especially the versioning part. Can you tell me what your infra looked like exactly 3 iterations ago? This helps in problem solving when you've had long-tail undiscovered complications.
3) Make it part of product ownership, KPIs and OKRs. Product managers are the literal worst at this, and will try to push stuff to prod without it otherwise. Coming from the Ops end of things, I can't tell you how infuriating it is to get told "this product is going to prod next week" and when I look there are no ops docs!
4) Management really has to support these efforts, up to hiring someone just to manage documentation. Not just that, but the culture. One thing I've seen repeatedly, especially in high-speed/low-drag places full of PHDs and heavy engineers, is using no docs as a way to judge prod teams. I've made much progress explaining in detail why when an ops engineer is at the tailend of a shift and a sev1 happens, they don't have time or the right mental clarity to go read the code to understand your bullshit!
5) All that said, the biggest division is between the non-tech and tech teams. Do not forget to give non-techs good usability and visiblity into these systems, or management will eventually stop supporting it.
6) Some people will have a passion for documentation, despite being in teams that might not be related to it. Utilize them, and reward them!
Bonus) Include lack of documentation in your after-actions/post-mortems, to keep it relevant to uppers in a concrete way.