November 29, 2012 at 12:05 am
Comments posted to this topic are about the item Don't Explain Too Much
November 29, 2012 at 1:10 am
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.
November 29, 2012 at 1:46 am
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.
cloudydatablog.net
November 29, 2012 at 5:35 am
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
November 29, 2012 at 6:18 am
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.
November 29, 2012 at 6:19 am
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.
November 29, 2012 at 6:56 am
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.
November 29, 2012 at 7:18 am
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.
November 29, 2012 at 7:22 am
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..:-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"
November 29, 2012 at 7:55 am
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..:-D
Unless you are doing IT for a rocket company. Then it is rocket science. 😀
November 29, 2012 at 8:20 am
"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 --
November 29, 2012 at 8:35 am
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"
November 29, 2012 at 8:41 am
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"
November 29, 2012 at 8:47 am
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? 😛
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:
- 😀
November 29, 2012 at 8:52 am
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.
Viewing 15 posts - 1 through 15 (of 21 total)
You must be logged in to reply to this topic. Login to reply