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?
Facilities engineer here, but also part construction manager since our building is halfway under construction.
A good sense of prioritization. We get requests from dozens of teams and they all say they’re urgent. Some of them are, some of them aren’t. Learn to ignore the unimportant stuff, and more importantly learn how to tell someone with a fancy job title to piss off.
Communication. A good portion of problems I’ve solved have been from half-remembered conversations. “Oh, the doohickey is acting weird? I remember John was talking with one of the Doohickeys International designers the other day about a new issue they had, let’s go talk to John”. But not just office talk, also documentation. Every time you see something or fix something, document it, because it might break again in 6 months and it might be someone else trying to fix it, and you can make their job a whole lot easier.
an eye for details. The difference between “oh wow that was almost a major problem” and “OH GOD WE ARE SO FUCKED” is often someone walking past and saying “huh, that doesn’t look quite right”
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…
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.
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.