Documenting difficult product, or how to train your dragon

As we know, technical writers are divided into “physicists” and “lyricists.” “Physicists” try to understand the product from the inside, while “lyricists” use their rich palette of communication skills. For simple products, the skills of either type of technical writer are usually sufficient. It's a different story, when it comes to documenting a complex product, such as Managed Kubernetes or a game engine. Is it enough to be just communicative and able to extract information from a knowledge source, or is it sufficient to understand the product's workings and involve the knowledge source only at the final stage for fact-checking the document?

In my presentation, I will attempt to answer these questions. Next, we will discuss where to start when studying the product, whether everything needs to be studied in detail, at what stage communication skills should be involved, and how to avoid irritating the knowledge source, establish a good relationship with them, and win their favour.