I work with a person that went presented with a problem, works through it and arrives at the wrong solution. When I have them show me the steps they took, it seems like they interpret things incorrectly. This isn’t a language barrier, and it’s not like they aren’t reading what someone wrote.

For example, they are working on a product, and needed to wait until the intended recipients of the product were notified by an email that they were going to get it. the person that sent the email to the recipients then forwarded that notification email to this person and said “go ahead and send this to them.”

Most people would understand that they are being asked to send the product out. It’s a regular process for them.

So he resent the email. He also sent the product, but I’m having a hard time understanding why he thought he was supposed to re-send the email.

I’ve tried breaking tasks down into smaller steps, writing out the tasks, post-mortem discussion when something doesn’t go as planned. What other training or management tasks can I take? Or have I arrived at the “herding kittens” meme?

  • rainynight65@feddit.de
    link
    fedilink
    arrow-up
    8
    ·
    7 months ago

    Any company with reasonably involved processes (read: more than three steps) should have clearly documented SOPs, policies and process documentation. This has nothing to do with the level people are at. I’m at senior level and sure as shit don’t remember every detail of something that was verbally communicated to me months ago unless I do it every single day, and even that’s error-prone. I write step by step instructions on processes for myself and everyone else.

    Benefits of this approach:

    • It’s not stuck in my or anyone else’s head, but clearly spelled out
    • people can follow the process again and again, no matter how much time passes between each time - you’d be surprised how much people forget if they don’t do something on a daily basis
    • clear documentation removes doubt
    • clear documentation is beneficial to newly onboarded staff. Nobody gives them a half-baked version scraped together from memory fragments
    • people can point out potential issues with the process, and the documentation can be amended/updated
    • I myself can go back to it if I have even the slightest amount of doubt on a detail.

    Drawbacks of this approach:

    • someone has to write the document
    • someone has to maintain it