September 26, 2016 at 7:56 am
Grant Fritchey (9/26/2016)
Thanks everyone for the feedback. I was hoping someone would come in and argue in favor of hiding information since it sometimes seems to be considered a valid position.
You could surely argue that revealing information too early is bad for all parties because you may be shooting your mouth off until you've had more time to get all the facts. While you may have all intentions of telling all parties, you sit on the information until you can fully understand the issue and solution in completion.
You could also argue that giving too much information about a problem is too much. Like in my example, my boss is not the expert. He hired me to become that expert. I could tell him a great deal of issues we need to address, but the amount of information I could share would cause him to get confused and forget the point(s) I'm trying to communicate. So, filtering information, which is often times being intentionally vague, to give the high-level is often a better approach.
I think withholding major information is a bit hard to justify though.
September 26, 2016 at 8:06 am
Grant Fritchey (9/26/2016)
dmbaker (9/26/2016)
Grant Fritchey (9/26/2016)
Thanks everyone for the feedback. I was hoping someone would come in and argue in favor of hiding information since it sometimes seems to be considered a valid position.Well, sometimes hiding *some* of the information is a good thing.
I've been dinged for over-sharing, but then I'm often communicating with our business users. They usually don't care about all the gory details, they just want to know someone is working on their problem, when it will be fixed and when pertinent, how much it'll cost. So now, I often say "something went wrong with the dinglehopper, I'm working on it now, should be fixed in nnn (minutes/hours/days, whatever). If you'd like more details on what's wrong please contact me, and I'll send an update when I have more information." Sometimes someone will want more details but generally they don't.
And what most people heard was "Wah, wah, wah, fixe in nnnn, wah, wah, wah." Ha!
That's the direction I was thinking. It isn't really hiding, but filtering. If I inundated my boss with every little detail of everything that ever happened, he's want to shoot me because I'd drive him crazy. Think along the lines of "Hey, an implicit cast was performed overnight on a 30-row table...we have to find the code, find the developer and have a meeting. Not only would that be getting him involved in things he doesn't want to be involved in or care about, but it's also a gross over-reaction to an event that could be handled with a simple conversation among two people. I wouldn't call this hiding, but rather filtering it appropriately, so I don't know that it meets your standard of hiding information.
September 26, 2016 at 8:09 am
xsevensinzx (9/26/2016)
Grant Fritchey (9/26/2016)
Thanks everyone for the feedback. I was hoping someone would come in and argue in favor of hiding information since it sometimes seems to be considered a valid position.You could surely argue that revealing information too early is bad for all parties because you may be shooting your mouth off until you've had more time to get all the facts. While you may have all intentions of telling all parties, you sit on the information until you can fully understand the issue and solution in completion.
You could also argue that giving too much information about a problem is too much. Like in my example, my boss is not the expert. He hired me to become that expert. I could tell him a great deal of issues we need to address, but the amount of information I could share would cause him to get confused and forget the point(s) I'm trying to communicate. So, filtering information, which is often times being intentionally vague, to give the high-level is often a better approach.
I think withholding major information is a bit hard to justify though.
Total agreement that we have to clear communications.
If we're currently experiencing pain saying something along the lines of "Something is going on, not sure what, I'm looking into it" is plenty acceptable, if anything at all needs to be communicated. Let's add on to that a bit and now, we're not just experiencing pain, but the system is offline. We'd need to modify our stance "System is offline. I'm not sure what is going on and I'm actively looking into it." I'm not saying we have to trot out every little oopsie ever experienced, "We had a 50ms higher than normal blocked process yesterday, no one except me noticed. Thought you ought to know." Clear and open communications are a vital part of our job, not trying to hide stuff.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 26, 2016 at 8:13 am
The end of your editorial reminded me of the PSA's on the Armed Forces Network talking about the obnoxious drinkers (male or female).
Don't be that guy!
September 26, 2016 at 8:17 am
Ed Wagner (9/26/2016)
That's the direction I was thinking. It isn't really hiding, but filtering. If I inundated my boss with every little detail of everything that ever happened, he's want to shoot me because I'd drive him crazy. Think along the lines of "Hey, an implicit cast was performed overnight on a 30-row table...we have to find the code, find the developer and have a meeting. Not only would that be getting him involved in things he doesn't want to be involved in or care about, but it's also a gross over-reaction to an event that could be handled with a simple conversation among two people. I wouldn't call this hiding, but rather filtering it appropriately, so I don't know that it meets your standard of hiding information.
I could shorten that one a bunch. To my boss: Off to beat a developer with this chair. Be right back.
That's all they would need to know.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 26, 2016 at 8:25 am
Grant Fritchey (9/26/2016)
Thanks everyone for the feedback. I was hoping someone would come in and argue in favor of hiding information since it sometimes seems to be considered a valid position.
As a manager I want the relevant facts that you need me to act upon. There is no point giving me a stack dump to read.
I don't expect you to hide stuff but neither do I want you to swamp me with stuff that really is your responsibility. This isn't "Yes Minister".
If you have a blocker then I want to know. If you need a new resource then I need to determine how that will fit in my budget or how we can put a business case together to support it. Sometimes the business case might not stack up but if you don't ask you won't get.
September 26, 2016 at 8:27 am
In all fairness to the DBA, this situation might be a reacton to the IT environment; for example office politics, the incentive program, or micromanagement on the part of upper level executive managment. What this means is that issues which impact business operations or issues that are initially reported by external users will get entered into the tracking system and are visible at all management levels. However, things the DBA team discovers, things like automated processes requiring occasional manual intervention or scheduled processes that go bump in the night due to blocking, this type of thing may get fixed off the books to create the illusion of a well oiled machine.
I'm not saying this is the right thing to do; I'm just saying it's common and not necessarily confined to the worst staff membes or teams. Management and IT need to work together to foster an environment of openness, understanding, and support.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 26, 2016 at 8:32 am
Grant Fritchey (9/26/2016)
Ed Wagner (9/26/2016)
That's the direction I was thinking. It isn't really hiding, but filtering. If I inundated my boss with every little detail of everything that ever happened, he's want to shoot me because I'd drive him crazy. Think along the lines of "Hey, an implicit cast was performed overnight on a 30-row table...we have to find the code, find the developer and have a meeting. Not only would that be getting him involved in things he doesn't want to be involved in or care about, but it's also a gross over-reaction to an event that could be handled with a simple conversation among two people. I wouldn't call this hiding, but rather filtering it appropriately, so I don't know that it meets your standard of hiding information.I could shorten that one a bunch. To my boss: Off to beat a developer with this chair. Be right back.
That's all they would need to know.
Exactly my point, but the chair is unnecessary. The image of you with the bat comes to mind. 😛
September 26, 2016 at 8:36 am
Ed Wagner (9/26/2016)
Exactly my point, but the chair is unnecessary. The image of you with the bat comes to mind. 😛
They won't let me bring the bat to work any more.
Not sure why.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 26, 2016 at 8:39 am
Grant Fritchey (9/26/2016)
Ed Wagner (9/26/2016)
Exactly my point, but the chair is unnecessary. The image of you with the bat comes to mind. 😛They won't let me bring the bat to work any more.
Not sure why.
I think the T-shirt and the expression on your face gets the point across. If they've put a moratorium on bats, switch to an escrima stick.
September 26, 2016 at 11:08 am
call.copse (9/26/2016)
"If you really can't fix the problem then,"Can't fix the problem? Does this situation really occur? Everything is fixable one way or another...
Yes, it happens. I've had a couple of systems in the last two years that I've done performance-related audits for that, after sufficient analysis my report essentially read 'unfixable'. Fundamental architectural flaws meant that fixing the system required at least a partial re-architect.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
September 27, 2016 at 2:41 am
GilaMonster (9/26/2016)
call.copse (9/26/2016)
"If you really can't fix the problem then,"Can't fix the problem? Does this situation really occur? Everything is fixable one way or another...
Yes, it happens. I've had a couple of systems in the last two years that I've done performance-related audits for that, after sufficient analysis my report essentially read 'unfixable'. Fundamental architectural flaws meant that fixing the system required at least a partial re-architect.
A partial re-architect is still a (hard-to-swallow) fix. I guess I was being a little facetious, but it is always possible with time, money and will power - it's like a car though, sometimes it is an economically non-viable write off.
Re: hiding things from the boss, my boss has not discussed almost anything work related apart from pointing me at projects for all of 6 years - so not much hiding needed! What I do normally hide, quite effectively after all these years, is the dread that I feel when I get assigned a monster project and think - how on Earth will I ever work out how to do all that! Partly because past experience shows that when you break it down and get on with it, it's never as bad as it feels at first.
September 27, 2016 at 3:40 am
Gary Varga (9/26/2016) ... he believed that the contractor wouldn't provide any form of hand over if he was leaving as he refused to document what he was doing when he staying ...
I'm pretty sure I'm not the only one on here who can't understand why he wasn't escorted off the premises at this point. This to me, and I've been a contractor and made damned sure my clients got proper documentation, shows a lack of ethics and professionalism that renders him unfit for purpose and a significant risk. I really have to question any manager who accepts such behavior as well.
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
September 27, 2016 at 8:23 am
As I read through the notes, I would like to voice an unspoken but assumed point underlying the discussion: technical staff must know how to communicate with non-technical staff -- managers, business users, CEOs. It's not always easy to find that middle ground of providing enough information without providing David Poole with a stack dump. Not easy, but vital.
That's part of the job. Yes, we're hired to maintain, secure, and tune databases. But the purpose of those databases is to run the business, and part of running any business is communication. Several small-medium privately owned businesses I worked for insisted on quarterly or monthly staff meetings with a review of company financials for everyone to see: cash flow, receivables, proposal pipeline, revenue, expenses. I consider this to be essentially the same thing, b/c when everyone has information, everyone understands the business better.
I imagine nearly anyone on SSC reading this is the choir to whom I'm preaching. I liked xsevensinzx's point about telling the "if you fixed it, why are you telling me?" boss!
But. If I worked for Grant, I'd be terrified of telling him anything in the way of bad news. Who's gonna volunteer to inform "The Scary DBA" of anything but rainbows??
Rich
September 27, 2016 at 8:33 am
Rich Mechaber (9/27/2016)
But. If I worked for Grant, I'd be terrified of telling him anything in the way of bad news. Who's gonna volunteer to inform "The Scary DBA" of anything but rainbows??Rich
Are you kidding? My favorite part of the job is emergencies.
Server is down? WHOOOP! Let's go fix it!
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 15 posts - 16 through 30 (of 35 total)
You must be logged in to reply to this topic. Login to reply