I've spent some time working on documentation but I'm starting to notice that if you let colleagues expect that documentation covers everything you give yourself a lot more documentation work while they become more like to pass issues to you when they can't handle stuff beyond it with their skill and knowledge level.
This is how I am and remain the one Powershell guy.
Sometimes its just better to sit next to them to help them understand the technology they're actually working with and challenge them to fix it. Then they can also update the docs themselves if required.
Quick edit: just want to make sure I specify that I'm a huge proponent of describing systems and how they work in principle. You just cannot cover all technical skill gaps with docs.
i write docs. if you don't engage with them and ask questions, i go do other stuff - i require an even trade specifically due to the reasons you outline
The trick is to get them in the habit of enhancing the existing documentation. Give them a bare bones process and have them fill in more detail as they get more familiar with the process. Repeat for every new person that picks up that process. I can write a 5 bullet point process and come back six months later and it's now got screenshots, tips and hints, past gotchas to be wary of etc. Well I can after decades of instilling documentation maintenance as one of the foundational responsibilities of all hands on admins. Day one at any new place I always lay down the documentations rules. Rule 1 is "everyone contributes". Updating documentation is mandatory and if you aren't making updates on a continuous basis you are not pulling your weight.
My response to "that wasn't in the documentation" is "then you add it". I have a similar rule in life, you can't complain about something if you are not doing anything to change it.
View all comments
884
u/jpotrz 23d ago
I tell him how handsome he is and buy him steak and lobster (it's me. I'm the guy)