If you come up with an architecture that is complicated, just keep working on it and editing, like writing, to make it make more sense. You need good editors / code reviewers on both sides, and they will make you a better reader and writer.
If you struggle with writing skills (not all people are good at some particular language) I find being able to make a good picture is even more essential.
I think one of the things to state is that it's not about writing something that sounds important. It's about writing something that people can understand. Don't get too stuck in the "art" part of it. At least for me, simplicity is beauty.
Another way to try this is to sit down with someone and say "explain what this does" and then see what they come up with. Some people are really good at talking, but not writing. But being able to explain is almost as good, and sometimes more necessary than writing.
Those hires I made from far away were much more carefully thought out and turned out to be much stronger. Equivalent to the ones the senior guy was hiring, if not stronger. I think it's because I couldn't delude myself into thinking "They're fine, I don't need to waste time interviewing. I can just groom them, get them to where they need to be." I had to, absolutely, consider these people as full time remote workers, several time zones away. They had to be crack engineers and crack communicators. And I had to enforce those standards from the get go.
Watching everyone else go through the shift to remote work was fascinating. The pandemic caused us to change nothing.
A big caveat is that you need a team or larger organization where this has already been set up, and that the hires need to be the kind of people who can take direction. It will fail miserably if even one of the above is untrue.
Alternative example: early on in my career, I was a software developer for a PR agency and then a news organization after that. At these organizations, solid writing and editing is drilled just as much as good code review or test coverage is taught in engineering organizations. Their lunch-and-learn sessions aren't about new JavaScript frameworks; they analyze how a particular piece of text was created and find ways to improve it.
My single largest "level-up" in this domain was when I started reading more on character creation in fiction. It forced me to think about how I'm telling stories, which then meant I had to think about how I constructed paragraphs, which then... you get the idea. Some great books I read:
- Robert McKee's "Story," which analyzes how great screenwriting is constructed. You will view action movies in a totally different way after this.
- Corbett's "The Art of Character," which focuses on how characters are created
- Roman/Raphaelson's business writing book, which was recommended by PR legend David Ogilvy
- the U.S. Joint Chiefs of Staff manuals (https://www.jcs.mil/Library/CJCS-Manuals/). These are rigidly structured texts with strange language that forced me to consider writing for a different audience than I normally would (military officers versus tech engineers)
Engineering has the clear benefit of things either working or not, with the reasons why it failed being entirely explainable even if it's not obvious at the time. Documentation is fundamentally a human to human operation, which means that all of the signals are messy and unclear. Writing is harder than speaking too, because you can't adjust course mid-stream if it's clear that your reader is confused or unmoved. Writing demands that you not only get your thoughts organized effectively, but that you reliably predict how people will read it and compensate appropriately. This is not a skill trivially learned.
Most people are not used to paring their writing down and getting rid of the fluff while also being articulate.