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 «««1234

More Tips for New (and old) DBAs Expand / Collapse
Author
Message
Posted Monday, June 6, 2011 7:35 AM


SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Friday, January 3, 2014 10:59 AM
Points: 626, Visits: 836
Lee Sloan (6/3/2011)

... what I'm effectively asking for is suggestions of how we significantly improve this, rather than band-aid it.


I think it comes down to management recognizing issues within their staff and working to address them through training or correction.

Many people don't like the idea, but metrics are a way to improve it.
If person X closes 150 tickets per month and person Y closes 10, it gives management something to work from other than an anecdotal feeling or a group consensus. I understand (all too well) that not all tickets are created equal, so my oversimplification needs to harness some other value matrix that makes sense for your company.

Deriving continuous improvement through measurement is the "next step" in the capability maturity model that many/most places never reach.

~Craig


Craig Outcalt



Tips for new DBAs: http://www.sqlservercentral.com/articles/Career/64632
My other articles: http://www.sqlservercentral.com/Authors/Articles/Craig_Outcalt/560258
Post #1120262
Posted Monday, June 6, 2011 9:00 AM
SSC-Enthusiastic

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

Group: General Forum Members
Last Login: Saturday, June 21, 2014 6:14 PM
Points: 137, Visits: 491
This is a great article pointing some important areas leading to team work spirit within a DBA team and providing superior professional services to an organization for a DBA team.

A DBA team needs to establish proven and consistent procedures to perform support. The purposes for these are to inform the involved parties for a database change to take place, to obtain required responsible parties' approval for a change, and finally to ensure a change to be well integrated into the current application.

Any DBA team members who can solve tough architectural and technical problems are certainly great asset for a DBA team. However, heroes building up with "short-cuts", "back-door" practices, and the like are certainly leaving changes without necessary tracking, undesirable for applications of established organizations, and away from team spirits as well.

Thanks Craig for your nice article!



Post #1120319
Posted Friday, November 29, 2013 4:11 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, July 15, 2014 6:13 AM
Points: 307, Visits: 475
george sibbald (1/12/2009)
SQLBOT (1/12/2009)
Andy Steinke (1/12/2009)
Your organization needs to suppoort saying no; it's easy to say this from an ivory tower perspective but you have to have management and executive support.


This is very true and in the case where management support does not exist, a case needs to be made to get the attitudes, procedures and culture shifted. By not supporting production stability and strongly defined processes the organization is stunting its capabilities (and may not know it).

Thanks for your comments!

~BOT


couldn't agree more, but be prepared to be unpopular with the wrong people! So this is not a task that should be left to a junior DBA.


Something that I find very useful as a "no" tool is the Email chain. Noone should say no without justification, that goes without saying but actually considering the request, making the decision to say no and then justifying that decision is the hardest part. In my experience that request then goes up the chain to someone that knows nothing of your decision and why you made it! I would recommend saying no together with the reasoning in an Email and cc'ing your own supervisor. If that supervisor is worth his salt he will back you up as long as your reaasoning was sound.
Post #1518499
« Prev Topic | Next Topic »

Add to briefcase «««1234

Permissions Expand / Collapse