Afraid to Fail or Afraid to Try?

This coming weekend I will have to travel out of town to perform a database export from one database and import it into another database.  That's right - I will have to travel to do something that not only can be done remotely, but can probably be done by anyone with about a couple hour's worth of prep time.  Don't get me wrong.  I am not trying to say that I am so far above this that this situation is insulting.   I am mearly pointing out the time and money that could be saved by not utilizing an outside resource.  I try to keep costs down myself by not dining in lavish places and keeping away from the hotel room's minibar.

Why you may ask is the target party I am doing this for not doing it themselves.  As the title of this post suggests, there could be a couple of reasons.  One is that they are using a professional resource in case a problem arises.  I think this is the most plausible explanation.  The other explanation is the real basis of this post.

Afraid to Fail or Araid to Try
In a different situation, the 'afraid to fail or try' mentality prevailed because of the critical uptime required of the database.  This point was driven home when a resource was fired when they inadvertantly caused an unplanned downtime.  This was a bad (knee-jerk) reaction from the management as it sent a message to the remaining resources that any deviation from the status quo was dangerous.  As such, fear ruled the environment and there was no desire to evaluate new features or drive to improve existing processes.  When this happens, innovators are given the choice to give up or get out.  At this point, complacency sets in (see my 'Complacency Kills' post - http://ora-vent.blogspot.com/2010/04/complacency-kills.html).  Stay clear of these environments unless you are a happy button pusher who does not like to ask 'why are things being done this way'?