I've been fortunate in having a scientific background which required writing a lot of essays, later on papers and a thesis. And a lot of technical and user documentation for software in my career.
As the top poster mentioned, "know your audience". You must pitch your material at the right level for the reader. This doesn't mean dumbing it down. It means not including material which isn't relevant for the discussion at hand, and including material which is relevant. As an example, in some internal documentation for end users, one programmer wrote up details about the I2C bus number and addresses and details of some parts on the bus. Not suitable for user documentation, it's just not relevant at that level. They could have mentioned what the user needed to know e.g. configurable options within the application and their effects upon the device function and behaviour. That could be quite detailed, but it doesn't need to include unnecessary detail about the hardware details.
Structure your documentation to introduce concepts that build on each other in order.
For each topic, write an introduction to provide an overview of the concepts and what you will cover, then go into details with examples in logical order, and then wrap it up with a summary and any relevant conclusions at the end. You're taking the reader on a journey with you through some complex topic and you need to treat it like a story with a narrative. It all needs to fit together as a whole, not just a collection of disjoint factoids.
Have a read through various technical books and see how others structure their writing. See how they break everything down into (volumes!), chapters, sections, subsections and paragraphs, and then look at how you can take the system you are documenting, and break it down in a similar way. In many ways this mirrors breaking down a complex set of requirements into applications, libraries, data structures and functions, and depending upon what you're writing about there may be some commonality there. But you aren't just describing the nuts and bolts, you're describing the whole system, conceptually how it is designed and all fits together as a whole, how it's intended to be used, and bring it together in a logical sequence.
Also, look at effective use of figures and tables. With a few good drawings, even very simple diagrams, you can use them to frame what you'll cover in the text. Likewise with tables, don't write out longhand what can be summarised in tabular form.
Just like doing presentations, effective writing comes with practice. And help with review and proofreading will help greatly to spot and improve weak areas. I was lucky to work with a technical writer in my previous job, and she greatly improved the writing technique of many of the software developers on our team. It's a shame that it's not highly prized in software development, because it's an essential tool for effective communication of ideas, and it's a big part of what we should be delivering to our end users and other developers.