For internal docs, just like external (user-facing) ones, the key is for them to be focused around what the user needs. In this case, that means things like:
- overall architecture of the system, what lives where
- how it's meant to work, what the main interfaces to users are, and what users expect from them
- common tasks and troubleshooting, eg stuff that often goes wrong
One of the major problems with internal docs is keeping them up to date. So that brings the second key point which is minimalism: don't document everything. Stick to what is genuinely relevant and useful to developers on your project. It's a hard balance to find, but you have to be practical and recognise that if you write something you can't commit to maintaining, it may not be worth writing at all.
(it's still hard with user-facing docs, but at you have releases which you can use as a drive/reminder to update things)
Thirdly, structure really matters. If people can't find things in your docs then they become much less useful. Good information architecture is hard, though. I'm a tech writer and I honestly believe that most engineers can write decent docs, given a bit of training (eg I've given something like this and people have found it useful https://youtu.be/8TD-20Mb_7M) - but working out a clear structure is something that it helps to talk to someone with practise about. If that's not possible, look at products similar to yours and see what their high-level structure is - if it looks good, do something similar, and if it doesn't, that gives you something to avoid.
- overall architecture of the system, what lives where
- how it's meant to work, what the main interfaces to users are, and what users expect from them
- common tasks and troubleshooting, eg stuff that often goes wrong
One of the major problems with internal docs is keeping them up to date. So that brings the second key point which is minimalism: don't document everything. Stick to what is genuinely relevant and useful to developers on your project. It's a hard balance to find, but you have to be practical and recognise that if you write something you can't commit to maintaining, it may not be worth writing at all. (it's still hard with user-facing docs, but at you have releases which you can use as a drive/reminder to update things)
Thirdly, structure really matters. If people can't find things in your docs then they become much less useful. Good information architecture is hard, though. I'm a tech writer and I honestly believe that most engineers can write decent docs, given a bit of training (eg I've given something like this and people have found it useful https://youtu.be/8TD-20Mb_7M) - but working out a clear structure is something that it helps to talk to someone with practise about. If that's not possible, look at products similar to yours and see what their high-level structure is - if it looks good, do something similar, and if it doesn't, that gives you something to avoid.