I put a lot of work into writing up decent documentation and SOPs and making them available. Does anyone read them? Pfft, not if my work chat history is any indication. Constantly getting pinged for basic-ass questions I’ve already answered thoroughly when I wrote up the docs and SOPs.

And I’ll go ahead and make sure you get another copy of that memo. Mm-Kay?

  • stoy@lemmy.zipEnglish
    12·
    11 days ago

    I feel your pain, and want to share two tips I have used that has worked well for internal documentation.

    You may already do this, but just in case I thought I’d share.

    1. Use informal keywords at the bottom of the article. Especially rude ones. One monday when I came into the office I was met with a pissed off colleague, he wasn’t angry with me, just the bad situation during the weekend, the server room (a purpose built server room) had had the AC fail during the weekend. So he had biked in and tried to fix it, there was a window that could be opened and we even had bought extra industrial fans, so we should be good right? Nope, they were stored in a locked room with a code lock next to the server room, we even had the code documented in the shared password manager, it was called something like “janitor’s code” and he could not find it. I don’t remember how he solved the situation, but seeing his frustration and irritation made me realize that we needed better keywords for the code. So I added stuff like “emergency code” and “general access code”, but then I also added keywords like “fucking code”, “idiot code”, “damn door”, “fucking door”, “dickhead code” “just fucking get me in”, “i give up” “fucking hell balls”, stuff like that, it worked great, it was funny and made sure that everyone remembered how to get the code. Same goes with other documentation, pour your frustration into the keywords, lean into the office slang for best effect, I am Swedish and have used some rather creative compound words “nätverkshelvete”, “skrivardjävel”, “rövhålsjira” and “förbannade skithusswitch” are just some from the top of my head at this time.
    2. The second tip I can give you is to write every guide in two versions, one summary, assuming the reader knows their way around, and only really focusing on special actions like, “when creating a user with role X, make sure to set extensionAtribute24 to Y”, and the other part is a full step by step part with highlighted screenshots for every step. This is something I tried and it did cut down on annoying people asking the same thing over and over.