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 Wednesday, January 14, 2009 8:54 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 5:09 AM
Points: 5,338, Visits: 1,385
Excellent advice...:)


Post #636328
Posted Wednesday, January 14, 2009 3:38 PM


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 (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
Post #636736
Posted Wednesday, January 14, 2009 5:08 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, October 1, 2013 10:01 AM
Points: 7, Visits: 41
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.
Post #636765
Posted Friday, February 12, 2010 5:21 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 12:47 AM
Points: 2,840, Visits: 3,872
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
Post #864547
Posted Friday, June 3, 2011 1:33 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, August 12, 2014 10:54 PM
Points: 26, Visits: 74
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
Post #1119256
Posted Friday, June 3, 2011 7:12 AM
SSC Eights!

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

Group: General Forum Members
Last Login: Yesterday @ 6:05 AM
Points: 998, Visits: 1,654
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.
Post #1119410
Posted Friday, June 3, 2011 8:17 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
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
Post #1119454
Posted Friday, June 3, 2011 8:44 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, August 12, 2014 10:54 PM
Points: 26, Visits: 74
Craig,

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

Jeff "Woody" Torres
Post #1119487
Posted Friday, June 3, 2011 4:55 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, October 1, 2013 10:01 AM
Points: 7, Visits: 41
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.
Post #1119772
Posted Monday, June 6, 2011 6:27 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 8:36 AM
Points: 5,308, Visits: 9,700
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
Post #1120212
« Prev Topic | Next Topic »

Add to briefcase «««1234»»

Permissions Expand / Collapse