Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


More Tips for New (and old) DBAs


More Tips for New (and old) DBAs

Author
Message
Anipaul
Anipaul
SSCertifiable
SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)

Group: General Forum Members
Points: 6283 Visits: 1407
Excellent advice...Smile



SQLBOT
SQLBOT
SSChasing Mays
SSChasing Mays (660 reputation)SSChasing Mays (660 reputation)SSChasing Mays (660 reputation)SSChasing Mays (660 reputation)SSChasing Mays (660 reputation)SSChasing Mays (660 reputation)SSChasing Mays (660 reputation)SSChasing Mays (660 reputation)

Group: General Forum Members
Points: 660 Visits: 836
Lee Sloan (1/13/2009)
We define our levels of service at an organizational level to ensure that everyone can clear the bar every time

Hmmm... that sounds suspiciously like we need to cover for people in the organisation that don't know what they're doing. Mind you, since only about 25% of people that work in IT do actually know what they're doing I guess we shouldn't rock the boat, should we?

Seems to contradict the point made that teams need "to hear about their mistakes if they are ever to learn from them". IMO, if useless members of staff could be identified because they were not allowed to hide behind organisational process then we would really create winning organisations.



I don't believe that is a contradiction.
Process development and process improvement are two sides of the same coin.

Say you have an uninformed Windows team that reboots whenever they want to.... let them hear about it so that they can develop a process that EVERYONE on their team (not just the "good ones") can follow so there is a consistency in service. This is what I'm meaning with my comments.

It also follows my "no heroes" philosophy from the first article.

~BOT

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
el-slo
el-slo
Grasshopper
Grasshopper (13 reputation)Grasshopper (13 reputation)Grasshopper (13 reputation)Grasshopper (13 reputation)Grasshopper (13 reputation)Grasshopper (13 reputation)Grasshopper (13 reputation)Grasshopper (13 reputation)

Group: General Forum Members
Points: 13 Visits: 42
SQLBOT with respect, I think you miss my point.

What I'm trying (and obviously failing) to say is that the advice points toward setting the processes at the ability of the lowest common denominator. But if the lowest common denominator is useless then perhaps a more effective strategy is to get rid of them and employ a team that can do the job required.

The IT industry seems to be populated by far too many people whose only notable ability is to read a step-by-step process manual and to hide behind those processes when they reach the limit of their intelligence, using phrases like "we have processes in place to best serve the organization". Sounds more like processes in place to best keep their jobs if you ask me.

These people seemingly have no idea about thinking around a problem and developing proper solutions, or indeed servicing customers - many of whom probably have better ideas about fixing the problem than they do. I guess this is the problem with working in an industry where too many people have in the past seen an opportunity to make a quick buck.

To be clear though, I do fully agree with you that solutions and processes should be properly documented to protect corporate knowledge. That is just common sense.
Christian Buettner-167247
Christian Buettner-167247
SSCrazy
SSCrazy (3K reputation)SSCrazy (3K reputation)SSCrazy (3K reputation)SSCrazy (3K reputation)SSCrazy (3K reputation)SSCrazy (3K reputation)SSCrazy (3K reputation)SSCrazy (3K reputation)

Group: General Forum Members
Points: 2951 Visits: 3889
Great Article!

Regarding the "just say no" - I think this is a good general baseline.
But I also think this problem mostly arises when the service level and / or job description is not defined well enough and therefore leaves too much room for interpretation.

And instead of saying no, it makes sense to forward the "unofficial request" to the manager and let him/her sort it out or at least give advice.

Best Regards,

Chris Büttner
Jeffrey Torres
Jeffrey Torres
SSC Rookie
SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)

Group: General Forum Members
Points: 48 Visits: 122
Craig,

I have enjoyed reading the articles you submitted. I have read all four of the articles you posted on SSC and I would like to encourage you to continue. You have a very readable writing style and the content has sound advice that is very applicable for today's DBAs.

Have you published any books? I would be interested in reading more of you insightful advice to help me become a better DBA. Thank you for your contributions to our society. Best regards.

Jeffrey "Woody" Torres
SQL DBA\BI Developer :-)
venoym
venoym
Ten Centuries
Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)

Group: General Forum Members
Points: 1355 Visits: 2082
Lee Sloan (1/14/2009)
SQLBOT with respect, I think you miss my point.

What I'm trying (and obviously failing) to say is that the advice points toward setting the processes at the ability of the lowest common denominator. But if the lowest common denominator is useless then perhaps a more effective strategy is to get rid of them and employ a team that can do the job required.

The IT industry seems to be populated by far too many people whose only notable ability is to read a step-by-step process manual and to hide behind those processes when they reach the limit of their intelligence, using phrases like "we have processes in place to best serve the organization". Sounds more like processes in place to best keep their jobs if you ask me.

These people seemingly have no idea about thinking around a problem and developing proper solutions, or indeed servicing customers - many of whom probably have better ideas about fixing the problem than they do. I guess this is the problem with working in an industry where too many people have in the past seen an opportunity to make a quick buck.

To be clear though, I do fully agree with you that solutions and processes should be properly documented to protect corporate knowledge. That is just common sense.


I believe that the point you made is at a tangent to the purpose of the article. The article is primarily about working within the culture you are given, not changing personnel. If you have the power to replace 5 "useless" members of the OS team as a junior level DBA, your organization has many more problems that the issues laid out in the article. Teamwork means you work together as a team to, at a minimum, hit the standards laid out and then exceed them so that the bar can be set higher for everyone on the team. If you set the bar too high you create a very bad reputation for the entire team because some can't, or won't, make the jump. I think you misread his context about setting the bar. You don't set it low and then only meet it, you keep resetting it higher as everyone on your team jumps it every time.
SQLBOT
SQLBOT
SSChasing Mays
SSChasing Mays (660 reputation)SSChasing Mays (660 reputation)SSChasing Mays (660 reputation)SSChasing Mays (660 reputation)SSChasing Mays (660 reputation)SSChasing Mays (660 reputation)SSChasing Mays (660 reputation)SSChasing Mays (660 reputation)

Group: General Forum Members
Points: 660 Visits: 836
Jeff Torres (6/3/2011)
Craig,

I have enjoyed reading the articles you submitted. I have read all four of the articles you posted on SSC and I would like to encourage you to continue. You have a very readable writing style and the content has sound advice that is very applicable for today's DBAs.

Have you published any books? I would be interested in reading more of you insightful advice to help me become a better DBA. Thank you for your contributions to our society. Best regards.

Jeffrey "Woody" Torres
SQL DBA\BI Developer :-)


Thanks, Woody. I appreciate the encouragement.
I've been getting the bug to write about a few different things but have been short on time.
You might have just given me the nudge I needed.

Thanks again!

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
Jeffrey Torres
Jeffrey Torres
SSC Rookie
SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)

Group: General Forum Members
Points: 48 Visits: 122
Craig,

You are welcome. I look forward to your next article.

Jeff "Woody" Torres
el-slo
el-slo
Grasshopper
Grasshopper (13 reputation)Grasshopper (13 reputation)Grasshopper (13 reputation)Grasshopper (13 reputation)Grasshopper (13 reputation)Grasshopper (13 reputation)Grasshopper (13 reputation)Grasshopper (13 reputation)

Group: General Forum Members
Points: 13 Visits: 42
venoym

My point may be tangential to the purpose of the article, but it nonetheless is valid: why do we build systems and processes that allow individuals to contribute minimal amounts to the organization? Why should I have to cover for the ineptitude of some colleagues and why should I, as a customer, have to accept poor service as a result of similar ineptitude elsewhere in the organization?

The more we pander to this situation the more we promote it. I am pragmatic enough to understand that there are certain realities that need to be catered for in the workplace but what I'm effectively asking for is suggestions of how we significantly improve this, rather than band-aid it.
John Mitchell-245523
John Mitchell-245523
SSCertifiable
SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)

Group: General Forum Members
Points: 7502 Visits: 15160
Lee Sloan (6/3/2011)
My point may be tangential to the purpose of the article, but it nonetheless is valid: why do we build systems and processes that allow individuals to contribute minimal amounts to the organization? Why should I have to cover for the ineptitude of some colleagues and why should I, as a customer, have to accept poor service as a result of similar ineptitude elsewhere in the organization?

The more we pander to this situation the more we promote it. I am pragmatic enough to understand that there are certain realities that need to be catered for in the workplace but what I'm effectively asking for is suggestions of how we significantly improve this, rather than band-aid it.

Lee

It's not a question of ineptitude or lowest common denominator. If I bypass process in order to provide what appears to the customer to be exceptional service, I am setting expectations that may not be able to be met next time a similar request is made. This may indeed be because other members of the team are lazier or less talented than I am, but it is just as likely that the next person who attempts it (even if it happens to be me again) may not be able to repeat the level of service due to different priorities or workloads.

You are right that some people hide behind process, but that in itself is not a reason to do away with process. How to stop this from happening is a discussion that needs to be had, but I don't think that it negates anything that was said in the article.

John
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search