Ask Lemmy
A Fediverse community for open-ended, thought provoking questions
Please don't post about US Politics. If you need to do this, try [email protected]
Rules: (interactive)
1) Be nice and; have fun
Doxxing, trolling, sealioning, racism, and toxicity are not welcomed in AskLemmy. Remember what your mother said: if you can't say something nice, don't say anything at all. In addition, the site-wide Lemmy.world terms of service also apply here. Please familiarize yourself with them
2) All posts must end with a '?'
This is sort of like Jeopardy. Please phrase all post titles in the form of a proper question ending with ?
3) No spam
Please do not flood the community with nonsense. Actual suspected spammers will be banned on site. No astroturfing.
4) NSFW is okay, within reason
Just remember to tag posts with either a content warning or a [NSFW] tag. Overtly sexual posts are not allowed, please direct them to either [email protected] or [email protected].
NSFW comments should be restricted to posts tagged [NSFW].
5) This is not a support community.
It is not a place for 'how do I?', type questions.
If you have any questions regarding the site itself or would like to report a community, please direct them to Lemmy.world Support or email [email protected]. For other questions check our partnered communities list, or use the search function.
Reminder: The terms of service apply here too.
Partnered Communities:
Logo design credit goes to: tubbadu
view the rest of the comments
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.
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".
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.