[jzb]

I'm struggling to understand how somebody can be responsible for creating a service but not understand who the audience is for reading its documentation. Some of the questions may be reasonable (one would hope if documentation is a requirement there's at least a standard format, etc.) but "it feels like busy work" and "this will take too long" destroy the premise that this is about not having answers to reasonable questions.

How do you know how long something is going to take if you don't know the format, etc.? Calling something "busy work" is sort of signal that this isn't "I need help getting started" it's "I'm trying to weasel out of this."

[marcinzm]

>I'm struggling to understand how somebody can be responsible for creating a service but not understand who the audience is for reading its documentation.

Documentation can be read by product managers, managers, QA engineers, engineers on call, engineers integrating with the service, and engineers taking future ownership of the service. Which group(s) it is depends on company dynamics, culture and processes. Documentation written for the PM of another team may be nearly useless for someone on call trying to triage a bug. Documentation lifecycle also matters since otherwise you will just get useless stale and inaccurate docs. However if it's a product manager focused documentation then you may have no choice however if it's engineer focused you may want to bake most of it into code (swagger, etc.). Just document it is how you get the 99% of documentation that is never read by anyone in the future.