The challenge in technical writing is because you are writing at the worst possible moment to write. This point is made by James Somers on Writing, Technically at Signals & Threads:

I think if you don’t have somebody who focuses on that, your documentation will likely go the way of all documentation everywhere, which is that it’s a bit of a backwater. It becomes a bit neglected, in part because it’s very hard to do well, in part because it’s not as exciting as building a new thing. And I think people are not necessarily natural writers, and they’re not necessarily natural technical writers. I mean, if you think about when people are writing documentation, it’s usually right after they’ve built some piece of software, right after they’ve written a library, say. It’s almost the worst moment possible to write about the thing because you’re so immersed in it. And in particular, you’re immersed in all the implementation details because that’s what took all of your time. And so you’re not really thinking about it the way that an outsider would think about it, and yet you’re the one writing it. And so I’m sort of a perpetual outsider. I think that’s my job, is just to be an outsider all the time, to be the dumbest person who can understand what I’m writing about. And that is usually going to be the level of comprehension that the reader is at. If they’re not as dumb as me, they’re at least less patient or more pressed for time. And so they need the slightly more empathetic version of the document.