Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 123»»»

The Disappearing DBA Expand / Collapse
Author
Message
Posted Saturday, April 4, 2009 11:04 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: Administrators
Last Login: Yesterday @ 12:33 PM
Points: 569, Visits: 1,015
Comments posted to this topic are about the item The Disappearing DBA
Post #690497
Posted Saturday, April 4, 2009 7:11 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: 2 days ago @ 10:06 AM
Points: 839, Visits: 1,267
I generally tend to agree with this, but the disappearing act is more often a detriment to the career of a DBA. Few people remember that the servers ran for 10 months without a hiccup and few people will care that the cause of that one hiccup was bad code released or perhaps a hardware failure. They'll remember that one hiccup if the DBA hasn't done some self-promotion. It's very easy for the DBA to be completely satisfied with being an unknown player and I'll admit that I like that to some extent as well. I just know that if the only time my name tends to come up is when the servers are having trouble, that's a bad thing. Even if I fix the problem quickly and prevent it from happening again, it won't matter as much. Kind of like newspaper stories may tear people down but never follow up when those people are found innocent, or if they do - only in a short corrective article buried somewhere in the paper.

Some good thoughts, but I think career-wise, the DBA should definitely be encourage to do more self-promotion if they're not doing any currently.



Post #690531
Posted Saturday, April 4, 2009 8:24 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Thursday, February 6, 2014 12:28 PM
Points: 38, Visits: 84
This is also true of particular types of "systems". For Example, if payroll operates as expected, nobody pats you on the back. BUT if there is an error (especially if it an error affecting a group or everyone), there is a question of "HOW did this happen?".

There are other jobs that also come into this "genre". For example, a Project Manager is most successful when they are nearly invisible. This is not unique to DBAs, but it is noted that the traditional DBA position has become this type of position. If you perform your job well, your are invisible. If you do not, you are front and center (and often not for long).




Post #690536
Posted Saturday, April 4, 2009 8:32 PM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Yesterday @ 8:15 AM
Points: 3,214, Visits: 2,325
Very well written and oh so true. All too often a company only knows they have a 'good DBA' when the rare occasion arises that he or she was the one to perform that last 'critical' restore to alleviate some major issue (or crisis as it usually is). There are lots of 'good DBAs' out there and even more growing into that role through perseverance, knowledge gathering, and problem solving each and every day. It is almost as if it is our collective career-wise lot is to begin to work ourselves out of a job from the onset of day one. Thankfully this is not usually the case. SQL changes, application technology changes and applications change over time - basically the only constant for a DBA is change.

We need to set our sights much. much higher though. We need to aspire to what was once espoused to me on what a day in the life of a 'great DBA' was.

- get to work
- get coffee, possibly even breakfast
- log in, eat breakfast and start reading emails
- look at the days calendar
- plan or replan the days activities
- deal with the problem tickets from the night before - there should be none
- answer email, read your email monitoring
- attend the daily turnover call
- attend the daily change management call
- replan the days activities
- read about 1/2 the daily morning newspaper
- get more coffee (or the beverage of your choice)
- attend the development related meetings needed
- continue your education through groups like SSC
- get lunch, read the rest of the newspaper
- answer email, read your email monitoring
- replan the days activities
- maybe and development steering committees
- deal with the problem tickets that are application related
- more coffee (or the beverage of your choice)
- an afternoon snack
- answer email, read your email monitoring
- replan the days activities
- finish the daily newspaper - the sports section or reading want-ads
- continue your education through groups like SSC

If you can get to this point career-wise you have almost achieved 'greatness'.

However there are a few more hurdles left before you can claim that accomplishment. If things are running that smoothly not a soul really knows that you even exist - well with the notable exception of your management and those who take you for granted. That is really how it should be. You should be that enigma that HR annually poses the following queries about.
- who is this person ?
- what do they really do ?
- how come we pay them so much ?
- how come we never hear anything about them ?

The final hurdle of achieving this espoused 'greatness' is making sure that your immediate management and all other management groups that affect your career path are aware of exactly what you do and how you get things done. Sounds like quite a paradox, being an unknown enigma and yet one of the enterprise's crucial players. Well, that is where knowing people and politics comes into play. There is really no online reference or book in print that teaches that to you what you need to do - it is basically experience and the mentoring tat you have received.

One might not think that this is possible. Well ... it is definitely achievable.








Regards
Rudy Komacsar
Senior Database Administrator

"Ave Caesar! - Morituri te salutamus."
Post #690537
Posted Sunday, April 5, 2009 10:31 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 1:46 AM
Points: 5,989, Visits: 12,916
good article with a lot of truths in it. It is also often true that there is more credit to be gained in fixing a high profile incident then preventing it in the first place. thats just a fact of life (and poor management).

Maybe DBAs should occasionally cause problems on purpose, after setting up a cover story and having a quick fix ready to go. Just joking of course.

I don't mind developers being higher profile, as long as they don't make a habit of doing two things:

claim coding is the ONLY skill that matters
claim MY database is slowing down THEIR code.


---------------------------------------------------------------------

Post #690608
Posted Sunday, April 5, 2009 11:02 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 12:18 PM
Points: 33,155, Visits: 15,289
I've often thought the production DBA should be insurance. If he/she's doing the job, you pay him/her, and don't worry about things. That's a big IF, however, and when something breaks (no IF here, it's a WHEN), they have to respond.

Since HR and management don't often see it that way, I would say that you do want to give them some sort of dashboard that shows work being done, and you're on top of things. This doesn't necessarily have to be a "server running at 20% instead of 40% after tuning SQL" report. I'd aim more for the "payroll ran in 20 minutes, instead of 22, with 12 more people added after tuning"

You do want to show your boss that you are providing value. You want to build your brand. And as I've mentioned in the past, if you don't have anything to tell him, perhaps that's a problem.

Nice editorial, Tony.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #690617
Posted Sunday, April 5, 2009 11:52 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Sunday, November 4, 2012 12:23 PM
Points: 2,087, Visits: 3,932
Steve Jones - Editor (4/5/2009)
I've often thought the production DBA should be insurance. If he/she's doing the job, you pay him/her, and don't worry about things. That's a big IF, however, and when something breaks (no IF here, it's a WHEN), they have to respond.

Since HR and management don't often see it that way, I would say that you do want to give them some sort of dashboard that shows work being done, and you're on top of things. This doesn't necessarily have to be a "server running at 20% instead of 40% after tuning SQL" report. I'd aim more for the "payroll ran in 20 minutes, instead of 22, with 12 more people added after tuning"

You do want to show your boss that you are providing value. You want to build your brand. And as I've mentioned in the past, if you don't have anything to tell him, perhaps that's a problem.

Nice editorial, Tony.


Hi

I'm a developer (sorry for that ) but I've been in same situation. Since the new requirements for the software just work fine when it comes to production the customer says "That's just as it has to be so why should we speak about?" but if there are any problems you become pointed by everybody.

Some years a go I had a project manager consultant who taught me "Do good things and speak about". This is just right! It is not naturally that everything runs good! If you do your job good, show it. Populate dashboards, reached milestones, ... .

Greets
Flo



The more I learn, the more I know what I do not know
Blog: Things about Software Architecture, .NET development and T-SQL

How to Post Data/Code to get the best Help How to Post Performance Problems
Post #690633
Posted Sunday, April 5, 2009 1:05 PM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Monday, July 21, 2014 12:44 PM
Points: 389, Visits: 1,041
Great editorial Tony!

A lot of people managing large corporations (and some managing small ones) do not understand the value database professionals bring. Finding meaningful ways to bridge this gap is worthwhile any time, particularly at review time.

I think the visibility of the production DBA can be mitigated by a good boss. A good boss will be concerned with "telling your story." My current boss does this extremely well, and I try to do this for members of my team.

Regardless of how cool your boss may be, following the personal branding advice Steve Jones offers is a good idea.

:{> Andy

PS - thanks for the link Tony! :{>


Andy Leonard
CSO, Linchpin People
Follow me on Twitter: @AndyLeonard
Post #690646
Posted Monday, April 6, 2009 1:27 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Friday, August 15, 2014 5:45 AM
Points: 561, Visits: 1,166
One added DBA area for praise is rescuing a bought-in supplier-installed system that you haven't been allowed to touch because "it's been set up by the supplier so it's fine".

Then there's a problem and you are allowed to touch and find the classic Phil Factor's "Pop Rivett and the expanding log" problem caused by the "supplier who knows all" lifting their backup code straight from SQL Server Central, then not implementing it properly, so no log backups on full recovery databases and no system database backups whatsoever!!!

I'm getting really fed up with suppliers who don't seem to know the first thing about SQL Server yet treat the client's experienced staff like idiots
Post #690776
Posted Monday, April 6, 2009 2:50 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, November 11, 2013 2:42 AM
Points: 150, Visits: 245
This is not the difference between a Developer and a DBA, it is the difference between Developers and Support. Some DBA's do development work, even if most are in a supporting role, while most front-end coders have to do support as well as development.
I am pretty sure that it is this mix that is most important, not the technology.


Throw away your pocket calculators; visit www.calcResult.com

Post #690810
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse