It seems like just about everyone wants a technical writer to be “detail-oriented.” Whether written in a job posting, spoken by a hiring manager, or how technical writers describe themselves. It’s typically one of the first few desirable qualities expressed in any of those situations. In fact, many career experts and resume writers will claim “detail-oriented” to be clichè, overused, and should be omitted entirely from resumes and job postings (citing the very subjective nature of the words).
I’m inclined to agree with the experts on this one, but not entirely for the same reason. While we all want detail-oriented at the beginning of a project (I’m no exception), as the project moves closer to the finish line, detail ultimately gets sacrificed for the deadline. Unless, of course, you don’t mind being the obstacle to project completion (and the negative attention you’ll receive thereafter). Yes, there are exceptions, such as a company that highly values quality, but that’s not too common.
The one essential question you should ask hiring managers, project managers, or any decision-makers is, “do you prefer detail or deadline?” This will help you plan your approach to ensure a successful finish.
Adopt a prioritization policy, that is, consciously chose to omit non-essential details with the hope you’ll be able to go back and add them. Writers in Agile development environments are especially good at prioritization. This involves a risk-analysis of what is “non-essential,” but you’ll get good at it in no time. Plus, by analyzing the risk you’ll be able to explain your reasoning later, if necessary. We, as technical writers, will get so close to the product by that point, even our own thinking can be clouded. Yes, there might be a hundred variables in a task and you want to document all of them, but chose one and go with it. Let the end-user figure out the other variables. It’s called discovery and will contribute to making the product interesting and fun.
Prioritization is what I call “making hard decisions.” I’d love to please everyone, but the reality is, as I writer, I need to please most of my end-users – even over pleasing everyone on my project team. It also isn’t a reason to document a product poorly, it’s a reason to keep it simple, which is what a most end-users prefer anyway.