One thing I have seen in my years in the business is that some companies don't really understand what a DBA is and why they need one. They hear the term "Database Administrator" and seem to think this is not any fulltime job - just someone to clean up messes and occasionally do a backup or two. When they find themselves in some crisis, they job out the DBA work and never think that so many hands in the "soup" might be hosing things up worse than they were before.

I have also seen a couple situations where the DBA role is played by another employee. I worked at one company where the lead QA guy was the DBA, and another where the hardware support guy had the DBA responsibilities. In both of these situations things were a mess and of course, trying to play multi-roles meant stressed employees, requests going unfulfilled, and SQL Server itself often in abysmal states.

But I have seen the flip-side as well - like the time I interviewed a "DBA" for a DBA position who didn't know what an Inner Join was. It's true! This fellow had been doing the SQL backups at his last job and therefore felt he was a DBA because he had been "administering databases".

My Father used to say that the worst companies are successful companies because they presume that being financially successful implies that they have all the right staff, doing all the right things. I think this is true and the hard part is making it clear to upper level managers why the DBA role really is a fulltime role with plenty to do. Then there is the problem of ensuring that any DBA you might hire is really a DBA. I still occasionally interview developers who say they are also DBAs. When asked why they think that, the answer is usually that they wrote some stored procs, and did a backup, and therefore must be DBAs.

...to me thats like someone saying that they have once worn rubber gloves and carved a turkey, therefore, they are surgeons.