• i've often felt less of a hero, more of a priest. i'd rewrite the 'hero' tip a little:

    Tip Number Two: No Priests

    I have had the privilege of working with many great DBAs who have used their skills and talents to overcome great challenges, and these are not the priests that I'm talking about. The DBA Priest that I will warn you about is a much more insidious sort. This is the DBA who has tremendous knowledge of source of all knowledge - the RDBMS; This priest has developed and designed all the support systems, processes, routines and rituals. S/he has been in the department long enough to have built relationships with all the customers and management, and has had his or her fingers in most projects. Furthermore, s/he is the ONLY PERSON who has done so. Many of you may be reading this and asking yourself: What's wrong with that DBA? Or: Hey! I'm that DBA!! The problem is not with the DBA, per se. The problem is the dependency which has built up around this one individual.

    What priest systems typically lack is what organizations truly need: Documentation, repeatable processes, managed solutions, and sharable and centralized institutional knowledge. Dependency on a priest can only cripple the efforts of the organization in its efforts to mature.

    As a new DBA, taking steps toward the "no priest" philosophy are some of the most important ones that you can take for yourself and for your organization.

    A great first step for a new DBA would be to volunteer to document the organization's existing processes. This kills two birds with one stone by giving you first-hand knowledge of the documentable processes and also helps the organization to exorcise its dependency on priests.

    the biggest problem you'll have is persuading the rest of the organisation to make the paradigm shift from the roman catholic model to the protestant model.