I work as web developer for a big retail company, which sells goods to smaller retails through its e-commerce web site, developing both for the e-commerce and intranet.
The main source of profits is made through the sales through the e-commerce, followed by the ad-hoc customer management by the marketing department.
Our department (web development) report directly to the top managment (AD, CEO, etc).
Even though my direct manager is an ex developer who understands the various programming issues, the department head is a marketroid who doesn't understand a thing about programming.
He thinks that everything that doesn't yield benefits in a short span is a waste of time and not worthy, and his behaviour is hurting us developers.
The main problem is I'm unable to explain technical concepts or issues to non technical people, so I fail to persuade him about what I should do or not do or what would make my work easier and more efficient.
Reading the similar questions I understood that I should
Not make him feel stupid.
Not look like I'm insubordinating.
Not look like I'm trying to skip my work.
But how the hell can I do that?
How can I cross this "cultural" gap?
How can I speak his language?
What's the best way to convey him that thing X should be done Y way, that thing W is not a good idea and that tool Z is something really useful for us?
Is there any good material on how to deal with non technical managers?
Some of the answers around are suggesting examples he can understand, but I find these answers a little vague, I fail to come up with anything decent.
Lately I'm starting to think that maybe we should take marketing classes or buy Mitnick's social engineering book... :\
Let me stop those who are starting to scream "let your manager handle him".
When my manager fails to handle him, the ones who will pay the consequences are us, the developers.
So, helping my boss getting the point through is helping myself keeping my sanity around, and certainly something worth the trouble.
Both the password for the intranet user and the e-commerce customers are saved in clear text in the database and must be changed every sixty days.
This is a nonsense to me: aside from all the implications of not encrypting passwords before saving them, forcing the user to change their password every two month is begging them for using weak passwords. (He thinks the first is not an issue and that changing password frequently is more secure.)
When a customer log in, all the user informations are saved into a cookie and using HTTPS everywhere is only a burden.
This too doesn't make sense to me: we're bouncing arounk 75 KiB of cookies with every request instead of looking up user details from database, and by sniffing the cookie (e.g. unprotected WiFi) you can impersonate the user and buy stuff (even really expensive things) under his name yet only the login process is encrypted. (The former is not worth refactoring, and the latter is a non issue to him.)
A colleague handles trouble tickets quickly because he's been working for the company for twelve years, many of the tools he's been "entrusted" have been developed by him and tells the user "don't do X" instead of fixing the problem in the code, and we who have been working here for one or two years, are managing tools written by former employees and go digging through the code to fix the problem get chewed for out higher mean resolution times. (He tells us we should be quicker, like him, because the time spent dealing with trouble tickets is not profitable, yet he won't allow the rebuild of the most crappy tools which would save time in the long run.)
An issue tracking a la Redmine is seen only as a time sink because it does not "produce" any tangible benefit, yet we're stuck on taking note of to dos and problems on paper or .txts and keeping spreadsheets of the modifications as reference.