A common model for establishing database administrator (DBA) job roles is as follows: The guy who has been doing the job longest takes charge. He becomes the top level, or Senior DBA; the others drop into the lower levels, take no part in the decision making process and are simply given tasks to accomplish. What could be simpler or more appropriate?
While it is clear (I hope) that I am being facetious about this being "appropriate", we all know that this is what often happens. So the first question is – do we want/need a DBA hierarchy with levels?
In an organization where, as in your case, you still talk to each other and try to work together, it sounds as if levels are inappropriate. My advice would be to work as a team, split the work up between all DBAs and keep the hierarchy flat.
How do you segregate the work? The tempting answer is to split it up by both existing skills and preference. So, if you have a DBA who is good with indexes, put him or her in charge of indexing and so on. The problem with that, however, is the old one of redundancy. What happens when the indexing guy goes? So, in an organization with a limited number of DBAs, my temptation is to share the work evenly, learn from each other, expand your own skill sets and provide redundancy for the company at the same time.
Of course, in large organizations with many DBAs there are very good reasons for developing levels. In a perfect world those with experience and vision lead while those who are new and gaining experience are led. As the comic character Dilbert suggests, this ideal in not always perfectly achieved...
More on DBA jobs and roles
This was first published in January 2008