Was thinking about moderators, and how users always have plenty of opinions about what moderators are doing wrong, but seems like you see less commentary from the moderators themselves about what it takes to do a good job.

Which is probably true across any situation where there’s a smaller number of leaders and a larger number of people in other roles.

Having experienced it, what does it take to lead a project, be a supervisor/boss, board member, pastor, dungeon master, legislator, etc?

  • thelastknowngod
    link
    fedilink
    arrow-up
    8
    ·
    1 year ago

    Remarkably similar to software engineering.

    I will add that there is a system widely used in the software world that is genuinely life changing and should be adopted everywhere. We call it “blameless post mortems”.

    The idea is that, if something goes wrong, it’s not the fault of the person who happened to do the thing that caused something to break. It’s a problem with the system that allowed that thing to happen in the first place. It gives people the freedom to be wrong without fear of repercussion and for your coworkers to work as a team to solve for this shortcoming together instead of heaping blame on one person.

    A pallet of glass bottles fell over when Tony tried to move them with the forklift. Where they stacked correctly? Maybe less flexible packaging would reduce flex. How were the forks positioned when he started to lift? Could we make color coded indicators for where the forks should be before attempting to lift? If the forklift was moving, how fast? Should we have speed limiters installed/adjusted? etc etc…

    • lightnsfw@reddthat.com
      link
      fedilink
      arrow-up
      4
      ·
      1 year ago

      That’s how I always approach complaints directed at my team. “Oh, so and so shouldn’t have done that way? Is that process documented? Are the instructions clear?”. A lot of the time it’s not their fault because they were doing the best they could with the information they had available. Of course the people responsible for providing these documents don’t want solutions, they want to bitch.

      • afraid_of_zombies@lemmy.world
        link
        fedilink
        arrow-up
        3
        arrow-down
        1
        ·
        1 year ago

        Generally you are right but it amuses me when the opposite extreme happens. Like a month or so ago I had a client insist I document how the electrician should put wires into terminal blocks. I suggested that they get a new electrician if they couldn’t figure out that a screwdriver is the correct tool for screw terminals and that the wire labeled 100 should go in the terminal block marked “100”.

    • Cryophilia@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      Sometimes someone is just to blame though.

      Finding a scapegoat is obviously an awful practice, even though many companies do it. But the opposite is just as useless: you end up doing a bunch of mickey mouse bullshit “process improvements” that make everyone’s job harder while everyone avoids talking about the fact that Tony should never have been allowed within a hundred feet of a forklift because he’s a terrible driver.

      Typically in our after action reports we’re good at finding both the systemic and human error causes of issues. And the root cause of most issues is not human error per se, just unintended consequences of what seemed a good idea at the time. Which should not be punished (unless someone was just being really stupid). But sometimes an incident is a result of a total failure to do your job - cutting corners, going through the motions without thinking, failing to notice something that’s obviously wrong, etc.