Here's how it's done at Amazon: schedule an hour long meeting with the people you want to read it. Make sure that the meeting invite includes no description or agenda, and has only a vague subject. If anyone declines your meeting invite, forward the invite to their manager and say they are blocking you by not joining your meeting. Do not provide a link to the document until 1-5 minutes before the meeting starts.

During the meeting, spend the first 5 minutes giving people access to the doc (which is made stupidly difficult because you're using the worst collaboration software known to the tech industry: Quip). Spend the next half hour in silence while everyone reads the document for the first time. Then spend 20 minutes going over the comments left on the doc, bikeshedding about minor details. Finally, spend the last 5 minutes talking about how you ran out of time to discuss the important topics and have to schedule a second meeting while everyone groans.

One thing I've found is that outside the formal design cycle its often nice to write short technical memos to document some small portion of what you're working on. It could be a feature, it could be why the CI is setup the way it is. If anyone asks a question about some technical subject you have written about, give them a short answer, but point them to your written document and invite more questions if anything is unclear. If you get repeated questions on something that isn't written up, it's a good clue it might be useful.

Also nice if your org has some internally searchable wiki or doc repository. Having a commonly designated "Tech Memo" area can be helpful too, though often the best place for it is near the code it describes or that you've set out to build.