Too many technical writers live in style guides, single sourcing, FrameMaker, processes, and methodologies. They can sometimes escape from the business of software development. This monk like college advanced composition teacher existence can separate the technical writer from the realities of today’s dysfunctional workplace.
When facing down ambiguity, technical writers have two choices:

• Wallow in the dysfunction and complain how the organization doesn’t understand technical documentation and that they can’t do anything right. At least they get out of taking meeting minutes because the organization isn’t so formal. They get to spend plenty of time on Instagram. But that last until project gets on the critical. Demands come down for documentation deliverables. Then a mad scramble begins to complete the documents under tight timelines.

• Chart their own course for your documentation projects by building strong cases for decisions and take documentation off your management’s worry list leaving  the manager to fight real fires. It’s always better to be controlling your documentation efforts.

Ambiguity should be seen as an opportunity to take the reins over technical documentation and help your client or manager cross out one worry from their list. Technical writers can rise and fall from the opportunities that happen in ambiguous environments.

Technical writers need to take ownership of their projects in such environments.