Writing good documentation is key infrastructure work. Remove documentation, or fail to provide it, and your products cease to exist, their inner workings left to the imagination of users who have better things to do than divining the behavior of API endpoints or CLI options by looking at obscure code (if code is available at all). Docs are infrastructure because they allow people to use the product without being the product. In that, they share the same importance of servers, routers, and cloud service providers.
You don’t work on docs because they are good for SEO. You work on docs so that multiple areas of your business don’t crumble overnight. Without docs, sales engineers won’t have anything to show to the customers when their proof of concept tests fail. Take away docs and customer support won’t be able provide quick and repeatable solutions to users in distress. Ignore docs and users just won’t know about the new feature you just launched, your growth KPIs taking such a heavy hit that you wished you had something more than a newsletter.
If this sounds dramatic it’s because infrastructure failures are dramatic. When we say docs-as-code, what we’re really saying is that technical writers are performing critical work close to the code and to the reality of its development. Docs-as-code is not, in this sense, a symbolic gesture of writerly solidarity towards engineers: it’s becoming engineers to help products ship, succeed, and sustain themselves autonomously.Fabrizio Ferri Benedetti – What docs as code really means