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


Don't Explain Too Much


Don't Explain Too Much

Author
Message
jay-h
jay-h
SSC Eights!
SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)

Group: General Forum Members
Points: 931 Visits: 2222
"don't explain too much" is an excellent bit of advice for any technical discussion.

Of course it goes without saying that you don't misrepresent the situation, talk down or over simplify, but excess explanation so often moves the discussion away from the critical point at hand. If your listener wants more info, by all means provide it freely, but don't unnecessarily muddy the water.

Part of the job of a skilled tech person is to strip away (through intelligent analysis) all the complex detail and reduce a messy problem to its critical aspects. It's the inept technician who can't reduce the problem to core principles.

...

-- FORTRAN manual for Xerox Computers --
TravisDBA
TravisDBA
UDP Broadcaster
UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)

Group: General Forum Members
Points: 1480 Visits: 3069
Krowley, i actually did for awhile. i worked at the Cape on the Shuttle program back in the early 90's.:-D

"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
TravisDBA
TravisDBA
UDP Broadcaster
UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)

Group: General Forum Members
Points: 1480 Visits: 3069
jay-h (11/29/2012)
"don't explain too much" is an excellent bit of advice for any technical discussion.

Of course it goes without saying that you don't misrepresent the situation, talk down or over simplify, but excess explanation so often moves the discussion away from the critical point at hand. If your listener wants more info, by all means provide it freely, but don't unnecessarily muddy the water.

Part of the job of a skilled tech person is to strip away (through intelligent analysis) all the complex detail and reduce a messy problem to its critical aspects. It's the inept technician who can't reduce the problem to core principles.



I agree Jay, you should not explain too much. Get your point across and end it there. If they need more then give it as needed. That said, you should also not just assume your manager is technically ignorant either. Many of them came through the ranks and know very well what you are talking about. Don't just assume because they are a manager that they only understand widgets and bean counts. Like I said before, it pays to know your audience.:-D

"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
Andrew Kernodle
Andrew Kernodle
SSChasing Mays
SSChasing Mays (614 reputation)SSChasing Mays (614 reputation)SSChasing Mays (614 reputation)SSChasing Mays (614 reputation)SSChasing Mays (614 reputation)SSChasing Mays (614 reputation)SSChasing Mays (614 reputation)SSChasing Mays (614 reputation)

Group: General Forum Members
Points: 614 Visits: 8135
Haha, as much as I'd wish I could explain less at my current employer, it's usually not possible to do so Hehe. The main database system here used to be Access, before I migrated the system to SQL Server at their request. It was commonplace for the users to write their own Access queries for various tasks, some of which needed a lot of cleaning up and remodeling to avoid issues (unrestricted UPDATEs, ack!). As a result, management believes that they're just as much into the technical field as I am, which is... Mildly untrue at times, to put it one way.

I remember when I had to program in a means of calculating whether packages would fit into shipping boxes, to replace an old system for doing the same thing that was inaccurate and sometimes unable to properly match items to boxes. Thanks to some awesome help from these forums, I got a routine procedure established that would accurately take our products and match them to boxes, as long as it was supplied with updated information whenever we got new boxes.

Management inquired about how the procedure worked, and I just explained, "It'll look at the information on all the boxes we have, make comparisons with our products, find the best fit, and store the fit in a table for review as needed." Management wanted a better explanation, and I told them that calculatiions are made with the product data in the database. They wanted to know where the calculations were; naturally, the calculations were in a query in the procedure. They looked horrified. The boss proclaimed that I'd created a coding monster, and this would lead to nothing but trouble. I was puzzled.

Apparently, they felt that the calculation formulas themselves should be stored somewhere in the database, too, so they could check the formulas in case they ever needed to know why something went in a certain box. If they didn't know the query formula, how could they ever know it was right? Besides trying to put the item in the box, anyhow? :-P

Ironically, the old method of doing this was essentially the exact same procedure, except it didn't do a data-based rotation of the items to see if they'd fit another way, and it had to be run by hand. Seemingly, that procedure was never examined by management, and they never had complaints about it until it started causing problems with us paying too much shipping. Either way, at least things are functioning far better now, even if I'm slightly worried about having to explain my coding when it's mostly unnecessary again Hehe

- :-D
Steve Jones
Steve Jones
SSC-Dedicated
SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)

Group: Administrators
Points: 36302 Visits: 18752
cfradenburg (11/29/2012)
Based on my experience I'm not sure that I agree with the, "managers shouldn't know," part of this. I fully agree that they shouldn't be the decision makers on topics like this but if they want assurances and details as to what's being done I don't think that's a bad thing. ...


There's a difference between explaining technically and details. That you run a backup every ten minutes, and you can recover to that level of granularity is a nice explanation. A look at the the nuance of log records, and tail log backups being available and the options available for the BACKUP LOG command, with scripting to move the file off the machine is a bit much.

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Steve Jones
Steve Jones
SSC-Dedicated
SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)

Group: Administrators
Points: 36302 Visits: 18752
brian.francis (11/29/2012)
I agree that the managers don't need the technical details, but a discussion of what options are available and what is most appropriate for the situation is critical. Too often I see IT folks just assume the implementation they did for project X applies for project Y and the business has no idea how their system was implemented. If you don't explain the options with the costs and benefits then they tend not to realize they're even making a choice. Usually when I see people talking very technical, it's because they don't really understand what they're doing so they try to intimidate others so they stop asking questions. This leads to poor communication and a general mess.


+1

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
TravisDBA
TravisDBA
UDP Broadcaster
UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)

Group: General Forum Members
Points: 1480 Visits: 3069
Hiza,
Just remember to not let these kinds of things get you upset. Managment many times asks dumb questions. It does not mean they are dumb. Just misinformed. There's no such thing as a stupid question, but many times they're the easiest to answer. It's all how you approach it :-D

"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
Rod
Rod
Ten Centuries
Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)

Group: General Forum Members
Points: 1133 Visits: 1932
Good admonition, Steve. I'm one who tends to give too much detail to managers. I do this for a variety of reasons, like thinking that I've got to prove to my management that what I do is complicated. And sometimes that results in situations like you've described where management is now micro-managing based upon what they think they understand of the problem. I have to work to not giving too much detail.

Kindest Regards,RodConnect with me on LinkedIn.
Andrew Kernodle
Andrew Kernodle
SSChasing Mays
SSChasing Mays (614 reputation)SSChasing Mays (614 reputation)SSChasing Mays (614 reputation)SSChasing Mays (614 reputation)SSChasing Mays (614 reputation)SSChasing Mays (614 reputation)SSChasing Mays (614 reputation)SSChasing Mays (614 reputation)

Group: General Forum Members
Points: 614 Visits: 8135
Oh, certainly. Work does frustrate me on occasion, but usually it takes something orders of magnitude greater than that to bug me :-). I was just weirded out by the situation... In my mind, if we could create a procedure that works, verify that it works, and record its results for error-checking should problems develop. that was a solid defense against trouble. The idea that it could be faulty just because the formulae weren't visible threw me for a loop!

- :-D
David.Poole
David.Poole
Hall of Fame
Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)

Group: General Forum Members
Points: 3698 Visits: 3120
Too much detail dilutes management effectiveness.

If you are a detail person and a manager then it is too easy to get sucked into detailed technical debates rather than stepping back and letting people get on with it.

If a non-technical manager gets highly technical information then they just switch off and miss the key point that you wanted them to understand. If they have a low understanding of the technical world they can get panicked by info that DBAs and other techies regard as business as usual.

Alternatively you find them strangely unavailable whenever you need to speak to them.

Let them ask for more detail if they require it but find a way of asking why without sounding defensive and patronising. "If you could let me know what your end goal is then this would help me to find the salient facts".

LinkedIn Profile

Newbie on www.simple-talk.com
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