I'd say it's much easier for a person with technical background to learn writing for non-technical audience than for a writer without such background to learn writing technical texts in non-inane manner. The two factors are needed: a deep understanding of the problem and ability to convey the essentials, and learning the latter is much easier than the former in good instruction-writing.
It's easy to describe point by point every single obvious element of whatever you're writing about. It's much harder to describe usage patterns, write competent tutorials that don't introduce negative training (teach how to do things wrong) or getting a troubleshooting section to be better than a long row of "contact the service" and simultaneously not get the user killed by trying to rewind the coils in electric motor at home.
Of course there is still a wide market for inane manual writers, that's why we have so many completely inane, content-free instructions that are a complete waste of time and provide no help. If that's satisfactory to you, you're sure to find employment with many importers from China or "rebranding" companies.
Unfortunately, if you want to do better than that, you're up to face an uphill battle: you need the technical background and if you don't have it, you must get it, no way around that. As you probably correctly imagine this short phrase boils down to years of work.
But there is a position where a non-technical person might fit perfectly in this domain: an Editor. The fundamental problem of technical writers is that they tend to forget their audience is not nearly as technical, and explain the problems in a manner that is 100% factually correct, definitely the right way to do it, and 100% useless to the reader who is unable to parse a single line of that.
This is where the editor should step in and keep asking the writer to explain, clarify, rephrase, simplify, until the non-technically-inclined writer has a perfect understanding of the problem. Then the user will face the same clear, understandable manual and will be able to learn the process just fine.
Now comes the problem of finding a company with management wise enough to understand the need for this and employ the editor while they already have "this guy in R&D who writes manuals". Unfortunately I can't help you with that.