"Fix the problem, not the blame." The problem can be a training, documentation, skill, process, hardware/software quality or failure, or other similar issue.
Repeated mistakes, ignoring known or expected good process is a problem to be fixed, not an issue of blame. That fix may require training, documentation, updated or improved skills, better processes or software, or hardware failure mitigation strategies, or management/HR action. None of this involves blame. On Fri, May 30, 2014 at 10:59 AM, David Lang <[email protected]> wrote: > I agree, no ramifications to repeated mistakes is bad as well. However, some > of it depends on the type of mistake. > > If you have a process that requires manually entering IP addresses, and > someone repeatedly makes mistakes in doing so, but repeatedly being one in > every couple hundred of IP addresses entered, that's a very different > situation than the one you describe. I've seen cases where managers were > trying to get people fired for such cases. > > using wire cutters on anything other than wire ties in an active datacenter > should be a big no-no. > > David Lang > > On Fri, 30 May 2014, Michael Tiernan wrote: > >> Date: Fri, 30 May 2014 09:54:01 -0400 >> From: Michael Tiernan <[email protected]> >> To: [email protected] >> >> Subject: Re: [lopsa-discuss] Yup, been there done that. >> >> On 5/30/14 1:11 AM, David Lang wrote: >>> >>> One of the most corrosive things you can do to a team of sysadmins is >>> to start playing the blame game and punishing people for making >>> mistakes. I've seen it happen. >> >> There's another side of the equation too and that is not punishing for >> mistakes at all. >> >> I worked with a [character] who was worse than a bull in a china shop. >> At one point he was "cleaning" the racks (good idea and did a fair part >> of it well and yes I told him) but he got overly enthusiastic and *cut*, >> with wire cutters, the connecting cable to a big Sun storage array for >> our most important customer. When he saw what he'd done, he pulled the >> power connection to the rack. >> >> Either one of those actions could have been dealt with but both caused >> massive disk corruption. >> >> Okay, massive screwup. Took me and another person 18 hours to return the >> system to the land of the living. I've done stuff probably close to as >> bad. Learn from the mistake and move on and don't do it again. >> >> However, when he *did* do it again, three weeks later to a different >> storage array in a different rack and didn't learn from the previous >> mistake, it is a disaster and should not have been permitted to continue >> but it did. No ramifications. >> >> So, we all learned that make a mistake, you're forgiven. Keep making >> mistakes and no one cares. >> >> Give out a root password to an outside contractor who called on behalf >> (supposedly) of one of the corporate branches. No ramifications. Zero. I >> quickly changed the password on the specific machine and told the boss. >> No ramifications. Found out an hour later he also gave the password to >> our divisions Root CA. No ramifications. >> >> >> Wow, look how short this message is. So *that's* what a delete key is >> for.... Hmmm.... >> >> > _______________________________________________ > Discuss mailing list > [email protected] > https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss > This list provided by the League of Professional System Administrators > http://lopsa.org/ _______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
