Communicating Across the Techno Gap
You have probably heard people talking about "dotted lines" in organizational charts. That is when someone has partial accountability to someone other than his direct manager. An org chart notation that I would really like to see is a "flashing red" line. I would use it to show when someone reports to a manager who has no clue what he does.
Any reader of Dilbert knows that this happens all over organizations but the case that I am the most keenly aware of is when a technologist reports to a non-technologist (or, perhaps worse, a former technologist). As a consultant, this is the area where I am regularly deployed. I am often hired by the non-technical manager to help him validate and/or understand what his technical staff are doing. I am also often hired by the technical staff to validate and explain their strategy. Consultants get put into this position because this is an area where companies struggle on their own. They need an outsider to facilitate and verify because communication and trust is so compromised. While I do love this work and would be happy to perform this role at your organization, here is some free advice to get you started so you can make some progress on your own.
Communicating to a non-technologist
Your manager doesn't really understand what you do despite your best attempts to explain it. You suspect that he doesn't care. Maybe he doesn't want to understand. Maybe he can't help that his brain just locks up when you say words like "refactor." You don't feel appreciated. You are about to stop trying.
When talking to your non-technical manager, don't try to dumb down what you say but for every detail mention, make a very clear connection to something that matters to the business. That usually means cost (short term and long term), quality, and impact. By impact, I mean things that will benefit the business: time savings, competitive advantage, etc. Provide inputs for any financial analysis he wants to do.
Don't get bogged down in numbers. Instead, draw comparisons because the units are probably meaningless. At the end of the day, the non-technical manager wants to be reassured that progress is being made and nobody is making "unconventional" technology decisions. An example of the former, is saying that you are "doubling storage" rather than "adding a 500GB RAID 5 storage array." For the latter, say "companies like EBay use MySQL" rather than "MySQL is a fully ACID compliant database."
More important than anything you say is how you listen. Listen to his concerns. Figure out what kind of proof will alleviate these concerns and provide it. Prototyping is a great way to show a technology in terms that a non-technical person can relate to - much better than UML.
Communicating to a technologist
Admit it. You are a little afraid of your tech guy. He has strange working habits and speaks in a language that you only barely understand. Even though you manage him, you have very little visibility over what he does. Unlike with other people who report to you, your advice to him is pretty much worthless because you both know that you have no idea what you are talking about. Whenever you ask a question, the answer just confuses you more. You just stop asking. The scariest thing you can think of is that your tech person leaves and, after drifting helplessly for weeks, you learn that your entire infrastructure is in chaos and about to collapse. What is going on in this technical empire he has built under your nose?
If you don't know anything about technology, you should start learning. Unless you are retiring in the next couple of months, you can only expect technology to become a more important part of the business that you are supposed to run. Have your technology guy help educate you. Ask him about the technical details underneath what you see as a user. But don't just listen to your internal technology people, listen to what is happening outside of your organization. Talk to your peers at other companies and learn about what they are doing. Read stuff online. Hire a good consultant. Share what you are learning with your technical staff in a non-confrontational way. Don't go in with managerial bravado. You are the student - be humble. It is a warning sign if they get defensive when you show a genuine interest.
The best approach for making technology decisions is to describe what you need in very clear terms (your technical person will call that requirements gathering). I like usage scenarios as a way to communicate these things. Ask your technical staff to put together their best solution and schedule time to review its viability and sustainability. Have an open dialog about the implications. Meet regularly with the team - not just at the end to "sign-off."
More important than anything you say is how you listen. Treat the interaction not as manager but as a partner and teammate. You both have the same goals. When the technical discussion gets out of your depth, don't shut down! Instead, connect it to something that you do understand and that matters to your responsibilities. Share the insight that you have about the company's needs and what your boss will ask for.