Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Preface

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).

My problem

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.

My questions

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... :\

Beware

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.

Some examples

  • 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.

share|improve this question

closed as not constructive by Yannis Rizos Feb 25 '12 at 0:25

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

    
General workplace issues are off topic on Programmers, you might find the Workplace Area51 proposal worth committing to. Discussing the technical merits of the examples you posted would be on topic, if you have presented them in an impartial tone, but you seem to already have made up your mind. This seems more like an invitation to a discussion than a question‌​. –  Yannis Rizos Feb 25 '12 at 0:30
    
Half of your examples are implementation details. The mistake was involving the manager in such decisions in the first place. Instead of asking for permission to encrypt passwords, it's your job to know to do that, and factor it in when you give an estimate. He doesn't need to understand those details any more than he needs to be able to read your code. –  nmclean Feb 27 at 13:54
add comment

3 Answers

Are you really not a good talker, or are you just being made to feel that way?

The problems are organizational and cultural, not technical. They're not your fault and you're not going to be able to change them. Leave.

share|improve this answer
    
That's not prejudice, I really have difficulties explaining my point of view, call it a mix of shyness and lack of experience. –  Albireo Feb 25 '12 at 0:12
    
Regarding the job changing: it's not so easy, as I've got a permanent contract with a decent pay when at the moment everyone is hiring with fixed term contracts; also new employees whom I think know what they're talking about are saying this is the best company they found so far; it's still something possible, but quite hard. –  Albireo Feb 25 '12 at 0:17
add comment

• 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.

• When a customer log in, all the user informations are saved into a cookie and using HTTPS everywhere is only a burden.

• 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 <snip>

• 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.


How are any of these things your problem?

You can appeal to the marketing wonk by talking money; all of these things are going to cost a lot of money if they're not fixed. The security problems will eventually cause a hacker to crash the site and steal people's personal information; it's going to cost a lot more money to recover from this than it is to just fix the security problems.

Issue tracking is a no-brainer; there are open source systems that can be put in for pennies. Or, you can learn the in-house system. Or you can find another place to work. Those are basically your choices.

share|improve this answer
    
My problem is exactly how do I appeal to the marketing wonk by talking money in a way the can understand and approve. I have no idea on how to do that the "right" way, you can call it lack of communication skills. –  Albireo Feb 25 '12 at 0:25
    
It's not your communication skills that are the problem. It's the attitude and preconceived notions of the marketing zealot. –  Robert Harvey Feb 25 '12 at 0:26
    
@Albireo - "It seems like a security breach would be really expensive and pretty easy for someone to do, and not that hard to prevent. Would a security breach really be cheaper than I'm assuming - will we catch expensive orders before they ship, or just let them return it or something?" "O.K., I guess it's hard to know exactly how likely a breach is, but if we've decided to take our chances does that mean we won't all get fired if one happens? " –  psr Feb 25 '12 at 0:32
add comment

Build some trust first.

Start by asking your manager to invite his boss to speak with your team, say every two or three months. The main idea of this meeting is to provide an opportunity for the department head to explain the department's goals and priorities to you.

Your team should take those priorities totally seriously; work on the priority issues. This is critical; your team is a cost centre to your business. Your role is to make sure the business can function and achieve the things it needs to achieve, and to do so in a way which is financially efficient.

Makes notes at the meeting so that everybody can see how the priority of things evolves (last month's middling priority becomes this month's burning issue for example).

Once the department head sees that this works well (i.e. that the high priority issues really are working out better) you can try flagging small numbers of high-risk problems at this meeting. Use what you've learned about the business's priorities to select the issues that really do/will affect the business, not just the things that annoy you.

You'll notice that an important part of this suggestion is, listen to the department head. Take them seriously, and maybe they'll take you seriously. They're probably not stupid. It looks like you just think they are. It's pretty clear you have little respect for them - consider for example the language you use to describe them.

Yes, leaving is an option. But even all-engineering-all-the-time jobs are going to require you to explain your point of view to others. Even if you're just trying to convince someone to use Turbo Boyer-Moore rather than a Knuth-Morris-Pratt string search in their code. Building communication skills will benefit your career.

If you really feel that your communications need work, consider doing something about it. Take a course (if your company offers these courses) or join Toastmaters.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.