January 13, 2009 at 4:44 am
I like the article, especialy the part about saying NO. While I don't like the rigid attitudes it is a valuable instrument that usually pays off. It helps to think twice (or even three times) and do some verifying before going for a "solution".
From the angle of a developer I have to deal with such situations quite often and wihout the backing of management supported established procedures. I learned to say NO as a way so get people to think before they leap and assign myself a part of the design process as a final sanity/quality check before implementing "solutions". Often I end up with a better alternative on my own once the goal of the change is well expressed (this as I see it, is my real job too).
In practice functional oversight or sudden new requirements for a running application quickly translate in cases that need to be implemented fast. Decissions are made by people without any knowledge of application development nor full awareness of the application and existing data in particular.
If I would simply follow every request, things would turn into an unmanageable mess quite rapidly. Individuals working for customers don't check existing data, designs or the scope of their application, they just want their problems solved. Very often there are no procedures guiding this process, a problem hits one user and suddenly a new project/change request arrises affecting more then initially realised.
Few people are asking questions like:
1. Does this function really need to be in this (part of the) application (scope issue)?
2. Is it worth spending N weeks developing, for just one person while the functionallity is available somewhere else and accessible already?
3. What other effects are there on the existing design?
4. Do we need to take a step back and redesign part of the application to make it a consistent functional whole again?
One could argue that I just have to do what people tell me to, as that is my role (read the previous article). But that is what I ranted against for a reason...with deteriorating quality of design and code due to blind alterations without understanding of the data or scope of the application, my job would become impossible over time. Every additional change would take more time and increase the risk of side effects (resulting in more issues, cycle starts...).
Just because a customer doesn't manage his IT and/or organisation well, doesn't mean we have to follow in that practice every time! A requirement for this attitude is however that you gained some experience and know the relevant application and existing data very well.
For those not yet at that point, it stil pays off to ask questions and verify what people tell you before proceeding. If you do not you might end up having to repair something you did not fully comprehended in the first place and that means the problem got bigger instead of getting solved.
Realize people often only have experience with part of an application. Ask 5 people working with the same application in different roles what the application does and its purpose.
You likely get 5 different answers, so be paranoid!
January 13, 2009 at 7:34 am
Excellent article!
The first two recommendations probably apply to anyone providing a service (which is probably most people!). I've known far to many situations where being asked for someone resulted in focussing on how to do it rather than whether to do it - particularly if it's an interesting technical challenge! 🙂 This naturally leads to the 2nd recommendation of "Just say No!" once you've considered the "whether" aspect and concluded that, although you can, you shouldn't!
I also agree with others that admin tasks are one of the areas where cursors make things clearer and the benefits of saving a few microseconds in executing the batch are often totally outwieghed by the execution of the action.
Derek
January 13, 2009 at 7:46 am
Great job, and good advice for all types of DBAs.
January 13, 2009 at 7:13 pm
interesting article with bonus of knowledgable discussion. keep it up mates.
January 13, 2009 at 8:14 pm
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.
January 14, 2009 at 8:54 am
Excellent advice...:)
January 14, 2009 at 3:38 pm
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
January 14, 2009 at 5:08 pm
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.
February 12, 2010 at 5:21 am
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
June 3, 2011 at 1:33 am
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 🙂
June 3, 2011 at 7:12 am
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.
June 3, 2011 at 8:17 am
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
June 3, 2011 at 8:44 am
Craig,
You are welcome. I look forward to your next article.
Jeff "Woody" Torres
June 3, 2011 at 4:55 pm
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.
June 6, 2011 at 6:27 am
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
Viewing 15 posts - 16 through 30 (of 32 total)
You must be logged in to reply to this topic. Login to reply