<a href="http://g.adspeed.net/ad.php?do=clk&zid=15220&wd=468&ht=60&pair=as" target="_blank"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15220&wd=468&ht=60&pair=as" alt="i" width="468" height="60"/></a>
Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
<a href="http://g.adspeed.net/ad.php?do=clk&zid=15491&wd=120&ht=300&pair=as" target="_top"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15491&wd=120&ht=300&pair=as" alt="i" width="120" height="300"/></a>
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
SQLServerCentral.com
»
Editorials
»
Don't Explain Too Much
22 posts, Page 1 of 3
1
2
3
»
»»
Don't Explain Too Much
Rate Topic
Display Mode
Topic Options
Author
Message
Steve Jones - SSC Editor
Steve Jones - SSC Editor
Posted Thursday, November 29, 2012 12:05 AM
SSC-Dedicated
Group: Administrators
Last Login: Yesterday @ 3:26 PM
Points: 31,425,
Visits: 13,738
Comments posted to this topic are about the item
Don't Explain Too Much
Follow me on Twitter:
@way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
Post #1390306
s_osborne2
s_osborne2
Posted Thursday, November 29, 2012 1:10 AM
SSChasing Mays
Group: General Forum Members
Last Login: Today @ 1:10 AM
Points: 612,
Visits: 1,869
Nice article Steve. I simply couldn't agree more with this. Managers should have faith in their staff and trust that they know what they're doing.
I have sometimes found that if managers spent more time managing, and less time trying to understand the technical details of *everything* then team morale would be better.
Thankfully these days i'm in a place where this isn't a problem.
Follow me on Twitter:
@WazzTheBadger
LinkedIn Profile:
Simon Osborne
Post #1390329
Dalkeith
Dalkeith
Posted Thursday, November 29, 2012 1:46 AM
SSC Rookie
Group: General Forum Members
Last Login: Today @ 5:58 AM
Points: 41,
Visits: 310
I would slightly alter that to
Have clear lines of responsibilty and let the best people have full control of their areas. That means at some point management or anyone else relinquishes decisions on certain aspects to those that know.
This tends to happen naturally in small organisations but gets worse as the organisation increases in size.
Post #1390344
bobfeldsien 7099
bobfeldsien 7099
Posted Thursday, November 29, 2012 5:35 AM
Forum Newbie
Group: General Forum Members
Last Login: Tuesday, December 18, 2012 2:01 PM
Points: 1,
Visits: 5
I certainly agree with your point. Managers who insist on making technical decisions better left to developers are a real problem and even more so in larger organizations.
As a consultant to large government and financial organizations, I run across this very often. I usually respond with a detailed and written technical explanation of what the industry standard best practices are and why they are applicable to the client's specific circumstances. With a smaller client, that is often enough to change their minds. With a large organization, sometimes you just have to do it their way and wait for it to fail. When that happens, you have already documented that you know what the problem is and how to fix it. And if it doesn't fail, then at the very least you have strengthened your image as a "team player". And on rare occasions, you will find that the client was actually correct for their particular situation.
Bob Feldsien
Post #1390454
cfradenburg
cfradenburg
Posted Thursday, November 29, 2012 6:18 AM
SSCommitted
Group: General Forum Members
Last Login: Thursday, May 16, 2013 7:44 AM
Points: 1,555,
Visits: 1,925
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. If someone asks me how they can know that I can recover data to within 10 minutes in the case of an outage I have no problem explaining the basics of transaction log restores, where we store them, and what alerting we use so we know if they fail. However, if they then turn around and say that it's too complicated and that I need to change it then we'll have a problem. They need to accept that they're getting the basics that a manager needs to know what's happening and that knowing how to pull it off is the job of the DBA team.
Post #1390490
brian.francis
brian.francis
Posted Thursday, November 29, 2012 6:19 AM
Forum Newbie
Group: General Forum Members
Last Login: Thursday, December 06, 2012 7:04 AM
Points: 5,
Visits: 183
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.
Post #1390492
Dizzy Desi
Dizzy Desi
Posted Thursday, November 29, 2012 6:56 AM
Valued Member
Group: General Forum Members
Last Login: Thursday, April 11, 2013 10:27 AM
Points: 70,
Visits: 656
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.
Totally agree - customers/managers need to have some information in order to feel confident in the solution you are providing. I find that people who
do
understand what they're doing are also able to speak in simple language (aka non-technical) to help the others understand.
Post #1390511
krowley
krowley
Posted Thursday, November 29, 2012 7:18 AM
SSC Journeyman
Group: General Forum Members
Last Login: Wednesday, May 15, 2013 9:16 AM
Points: 89,
Visits: 341
I am not sure I agree about explaining. This assumes that managers have no technical abilities and couldn't really understand the explanation. This also assumes that every developer is going to use best practices.
If I am a manager and we have a situation where we need to restore data from a back up and my developer can't do this in a timely manner or forbid can't actually do it at all, then my head will be on the chopping block, not just my developers. So I want to be darn sure I trust them with something as critical as backups, and that means I want to understand the decisions they are making and why they are making them.
Post #1390530
TravisDBA
TravisDBA
Posted Thursday, November 29, 2012 7:22 AM
Ten Centuries
Group: General Forum Members
Last Login: Thursday, May 09, 2013 9:23 AM
Points: 1,288,
Visits: 2,996
I also agree Dizzy and krowley. There are ways to communicate/explain this to a manager without getting too technical and still get the basic point across. However, after explaining in layman's terms (using the backup/restore scenario as an example), they still don't understand the concept of what I am talking about (some are just clueless), then they should go sell flowers for a living. They should not be managing an IT shop. That said, I also should not have to explain what VLF's are to them to get my point across of how much of the data i can get back for them. Its all how you communicate it that makes all the difference. Always try to know your audience at any given time. This is not rocket science people..
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...
"
Post #1390532
krowley
krowley
Posted Thursday, November 29, 2012 7:55 AM
SSC Journeyman
Group: General Forum Members
Last Login: Wednesday, May 15, 2013 9:16 AM
Points: 89,
Visits: 341
TravisDBA (11/29/2012)
I also agree Dizzy and krowley. There are ways to communicate/explain this to a manager without getting too technical and still get the basic point across. However, after explaining in layman's terms (using the backup/restore scenario as an example), they still don't understand the concept of what I am talking about (some are just clueless), then they should go sell flowers for a living. They should not be managing an IT shop. That said, I also should not have to explain what VLF's are to them to get my point across of how much of the data i can get back for them. Its all how you communicate it that makes all the difference. Always try to know your audience at any given time. This is not rocket science people..
Unless you are doing IT for a rocket company. Then it is rocket science.
Post #1390562
« Prev Topic
|
Next Topic »
22 posts, Page 1 of 3
1
2
3
»
»»
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.
