Better Communication with Non-Technical People?
tinpan asks: "I've got a communication problem. When non-technical managers ask me to explain technical choices, they often make choices I recommend against and they later regret. I can tell that they do not understand their choice because of how they are explaining things to each other, but they usually refuse further explanation. So, it's time for some education. I want to get better at communicating technical subjects to non-technical people. More accurately, I want to get better at helping non-technical people make better technical decisions and I'm willing to accept it may include some understanding of 'selling your idea.' What advice do my fellow readers have in accomplishing this? What books, online courses and/or seminars do you recommend and why?"
I'm not aware of any training or education specifically designed to help technical people communicate more effectively with non-technical people. You are more specifically interested in communicating with decision makers, which is far more specific than say talking to your family or non-technical friends. Being more specific in some ways makes it easier. I'm guessing that your difficulty lies not so much in not communicating technical details or ideas adequately, but not understanding the decision making process being used. One of my primary job functions is being a liaison between the technical and non-technical sides of the company, and I even talk to customers/partners who know nothing about technology. Point being, I am good at it now--I am complimented on this often--but this was not always so. Meaning that yes, it's something you can get better at.
... enterprise ... leveraging" in (b), or the particulars about what enterprise-class means and mentioning competitors in (c)?
Given that, here's what I can tell you:
1) Detail is enemy #1. Technical work has lots and lots of details to it, and we often get absorbed in them and like to talk about them. This will ruin your efforts again and again, you *must* train yourself to hold back details unless specifically asked. For example, if somebody asks what an acronym means, you probably shouldn't tell them what it stands for. Also, when pressed for details, try and give only the details relevant to your audience. For example, if somebody asks you what "WebSphere" is, do you tell them:
a) "WebSphere is a proprietary J2EE server. I recommend we go with JBoss instead since it is open source and does everything we need. It's cheaper and easier too."
b) "WebSphere is an IBM product designed for an enterprise computing environment leveraging Java technology. You might use it for serving web pages."
c) "WebSphere is one of many enterprise level, server-side Java solutions. It's a complete J2EE server, supporting all server-side Java standards, like servlets, JSPs, and enterprise java beans. It is intended to provide scalability, robustness, clustering, fail-over, up-time guarantees, and other things expected from an enterprise class product. You might choose it for the same reasons you would choose Oracle over other databases. BEA, Oracle, Sun and JBoss all provide competing products providing almost identical functionality at different price points and service levels."
All three are reasonable answers depending on the context. Does your audience want to hear "cheaper and easier" in (a), "IBM product
2) Decision makers often have to make decisions regarding things they do not personally know. As you have observed, this often leads to making sub-optimal decisions. In debate class, relying on an authority rather than having a good argument might get you marked down. In the real world, quoting an authority is often (maybe even usually) more important, as the decision maker might not understand the actual argument. I experienced this repeatedly and to great frustration earlier in my career, where a manager would pretend to listen to me, only to do what a more senior, trusted person recommended. In some cases there will be other hidden agendas, and often times you won't know what the decision makers parameters are. For example, you might recommend Vendor A for price/performance reasons, and the manager chooses Vendor B because B is a "safe" choice and the decision maker is in a difficult position with his or her boss.
3) This leads to: you'll need to understand the chain of command. Often times, the person that you get to talk to does not have the final say. Instead, that person has to sell the decision to other business people and the people who control the purse strings. So in some cases you are educating someone who is really just a champion, not a final decision maker. In this case, you must prep them to d