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.
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!
george sibbald (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!
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.
Viewing 3 posts - 31 through 32 (of 32 total)