posted 7/1/2010 by sqlscottgleason - Views: [1208]
So the big, really-bad, cry-yourself to sleep, "you'll get automatically fired if you do this" thing happened at work this week.
Here is a snippet of the back ground story...
[on second thought.. I've removed the details of what happened, but from the opening sentence.. you can imagine]
A few of the people that work for me were a bit confused as to why I didn’t auto-fire the person that made the mistake. I even surprised myself by how quickly I made the decision that I was not going to fire this person, but I didn’t let them know that for a while.
This person is a 28 yrld ish SQL 2005 MS certified contractor who I don't think has ever owned a DB before. Its one thing to be certed' left to right by MSFT, and have worked a big companies for 3 to 6 months for the past five years. But 'hand on'..'its your baby'..'you will let people down if this fails' type of experience counts for a lot more with me.
I was happy that this person was working for me at 8AM that day, I'm even happier they work for me now; he will never make that 'TYPE' of mistake again. I'm actually able to trust him now more than ever and in the long run, it would have cost me more to replace this employee.
Not every situation calls for firing a person. But it really depends on "the person" and as a manager, I'd ask that you keep that in mind the next time somebody who works for you screws up.
Scott Gleason
Great point of view and greate decision. Nicely done. Thanks for sharing with us this kind of subject.
Interesting. He definately wont make the mistake again.
DBA's and non-DBA's alike make that kind of mistake from time to time. Mistakes like dropping a production table or such sometimes offer learning opportunities to both the person guilty of the action as well as the others responsible for the enterprise solution. I mean, in the case of a non-DBA, why did the individual have those kind of rights in the first place? In the case of the DBA, does there exists routinely scheduled back ups so that restoring a table from a back up may help to mitigate the error? In both cases and in many others, more than one person has the chance to learn from the mistake.
Oh, and my offense: as a non-DBA, dropping a table from a Production reporting database around 4 PM EST at a global financial company. Good thing, there processes to repopulate the table starting at 7 PM EST, and most of the East Coast USA wouldn't catch the problem. However, leave it to my global colleagues to find the issue. Today, access to Production is on a 24 hour request by request basis, and access is limited to read only, with on special access granted with executive approval.
And yes, I was not fired and had stayed with the company a few more years after.
That's a good point of view to have, depending on the person, like you said.
Good way to show some grace, Scott. I know I would have appreciated it at that stage of my career and also would not make that sort of mistake again. :-)
Yeah, we've all made mistakes and learning from them is where we grow. I can remember in my infancy a long time ago, I updated a table in the AS400 while making changes to one individual's menu options and accidentally executed the query before putting in a where clause to limit my update. Needless to say, I had to quickly reload the table from backup. We were only down for about 30 minutes or so, but during that time, we couldn't ship product. That sucked! At any rate, what is that saying... he who has not made a mistake, cast the first stone! Something like that right!
Brian, yes we all make mistakes, this one was an exception for how large and how experienced the DBA is who made the mistake. A good bit of blame 90% in my eyes goes to the Division who thought Raid 5 was their backup on this SQL server. No kidding.