To echo the comment of a previous poster, it could be super painful to extract information from engineers
Coder here. I’ve also worked as management consultant for several years, where I was basically writing up pretty looking PowerPoint documents a plurality of my time. So I *think* I should be able to get both sides of the debate here.
There are two separate types of issues that can happen when you try to extract information out of engineers:
1. Some engineers like to be the “key parson” and resist sharing knowledge. This is surprisingly common. It’s a wider culture problem of such behavior can survive in the organization. There is no good, win-win solution here that you can implement strictly within your tech writer role. You need to try to do the best of a bad situation here.
2. Some engineers are just frustrated at being asked to dumb down the complex trade-offs they make every day to such a degree that it becomes misleading. Just yesterday, I took a decision that increased the risk of failure in our system dramatically in the short run, only to make sure I can de-risk the eventual, big release next week. An engineer will likely take that kind of decision, with varying degree of impact, very frequently. I sometimes find it deeply frustrating to have to paraphrase every sentence of the ‘status report’ or ‘run book’ or ‘usage guide’ when a non-technical project manager is assigned to our project. It is much easier dealing with a PM or tech writer who had a technical background.
Relevant to the OP, to do really good as a technical writer, you either need some technical background in the domain or be very quick to learn.