I've used that strategy a few times now, albeit mostly with "user" facing docs where the users were other developers. My current company is tiny but I wrote both internal and user facing docs from day one, so practicing what I preach. It's pretty useful. Writing stuff down is permission to forget and I often end up consulting my own docs, especially for procedures that only happen occasionally.
In prior projects I did it too and success was mixed. On one hand, the docs we got out of it were objectively great, as in, users complimented us on the docs regularly, they were a source of competitive advantage and we could tell they worked because users would regularly show up successfully using advanced features of the product without having asked us any questions.
On the other hand, creating a self-sustaining docs culture was hard. People would do it when faced with the expectation of doing it, and often the resulting docs were fine - tech writing isn't as hard as it's sometimes made out to be - but getting other devs to really buy into it and become docs evangelists themselves was much harder. Also of course you'd have inevitable team friction when someone really hated writing stuff and would have to be forced to do it, and then they'd submit min-viable or low quality work. No different to having a team member who refuses to write tests, of course.
I think this can be solved with time, with cultural change in the industry. One problem, and please don't take this personally because I'm talking really generally here, is the view that source code is as good as documentation. I feel like lots of devs convince themselves of this because they like writing code and don't like writing docs, but I never found it to be true in practice. Any time I have to use an API or tool that has tons of missing or obsolete docs my heart sinks, partly because rummaging through source code is slow and tiring compared to reading a well written document, and partly because it tends to be a proxy for low effort work in other ways. The claim that docs are always obsolete is self-fulfilling. If you don't put in place procedures to ensure they're kept fresh and good then they'll rot, and then that's used as a justification for not putting in the effort, so it's a vicious circle. Again by analogy to testing, competent teams don't just let devs comment out tests instead of updating them, it's just not culturally accepted in high-functioning environments. Same can be true of docs.
In prior projects I did it too and success was mixed. On one hand, the docs we got out of it were objectively great, as in, users complimented us on the docs regularly, they were a source of competitive advantage and we could tell they worked because users would regularly show up successfully using advanced features of the product without having asked us any questions.
On the other hand, creating a self-sustaining docs culture was hard. People would do it when faced with the expectation of doing it, and often the resulting docs were fine - tech writing isn't as hard as it's sometimes made out to be - but getting other devs to really buy into it and become docs evangelists themselves was much harder. Also of course you'd have inevitable team friction when someone really hated writing stuff and would have to be forced to do it, and then they'd submit min-viable or low quality work. No different to having a team member who refuses to write tests, of course.
I think this can be solved with time, with cultural change in the industry. One problem, and please don't take this personally because I'm talking really generally here, is the view that source code is as good as documentation. I feel like lots of devs convince themselves of this because they like writing code and don't like writing docs, but I never found it to be true in practice. Any time I have to use an API or tool that has tons of missing or obsolete docs my heart sinks, partly because rummaging through source code is slow and tiring compared to reading a well written document, and partly because it tends to be a proxy for low effort work in other ways. The claim that docs are always obsolete is self-fulfilling. If you don't put in place procedures to ensure they're kept fresh and good then they'll rot, and then that's used as a justification for not putting in the effort, so it's a vicious circle. Again by analogy to testing, competent teams don't just let devs comment out tests instead of updating them, it's just not culturally accepted in high-functioning environments. Same can be true of docs.