How do I cope with a manager who’s always interfering in what I do, but doesn’t really understand it?

Question

We've all had them, managers who have either come from sales or last looked at code 10 or more years ago but think they know how to write code.

What can I do to give the impression that I'm grateful for their intervention, but keep it as short as possible so I can get on with my work?

Or, should I be engaging more with the manager to educate them with modern coding techniques and practices? After all, a manager who understands these will be able to talk sensibly to clients and more senior management when discussing the project and its timescales.

Answer 1

I say, go ahead and try to engage and educate.

If they're honestly trying to help you, the chance to learn something could be valuable to them. If they're just shoving their nose in for ego or political reasons ("See, I'm helping, I'm helping!"), they'll likely get the notion you'll embarrass them if they keep this nonsense up -- or bore them to death with a wall of jargon they're only pretending to understand.

And if you've got the dreaded egomaniac who truly thinks they're an expert at your job no matter what evidence you can bring to the contrary, then smile, nod, and make whatever trivial cosmetic changes will make them go the hell away. And update your resume.

Answer 2

I usually just listen everything such person has to say. I agree to almost anything and I do it my way anyhow. Usually he never bothers to check.

Answer 3

Group code reviews. Public embarrassment is always good for curbing those sorts of habits. :)

Answer 4

It can be very difficult, especially if the manager thinks they're a l33t h@x0r but hasn't coded anything in the last 10 years.

Start by using active listening. Make sure you understand exactly what point they're trying to get across. Rephrase it and shoot it back to them so that they know you understood them. Sometimes this is all they really care about.

If they insist on some implementation, ask yourself why you're refusing them. There has to be a reason. It probably breaks some fundamental software design principle... usually separation of concerns. Know your principles, and know why they're better than the alternative. Then quote the principles and explain why they should be followed in this case. That makes the discussion academic.

If you can't figure out why you don't like what they're saying, it's a good opportunity to question your assumptions.

Answer 5

I'd not educate if there has been a code history for him / her. The knowledge of development issues should have stuck in the mind.

Politely ask him/her whether you could discuss whatever he has in mind over lunch.

Answer 6

Sometimes one just has to sit down and listen, even when we don't want to.

One can only hurt the dignity of a person by not paying them attention.

Your manager is a person. Treat him like one. Look at him as if he were some guy in the street. No titles.

Doesn't that make him someone that may need a friend, someone who may feel lonely?

Have you thought about it from an emotional point of view?

Is he trying to convey an implicit message?

Talk to him. Just not about the problem. Ask him how is life going. He may feel appreciated and thus provide you with less work anxiety.

Have you considered or done this already?

If not, then why?

Answer 7

Do the same thing to him. Every time you see him, immediately start talking about his stuff regardless of whether or not you understand it or not ... "Hey, I think that marketing campaign should go like foo!" "Hey, I think our sales team should do bar!" "Hey, next time you talk to your manager, you should tell him quox!" He'll start avoiding you like the plague.

Answer 8

The problem here is that your manager obviously feels COMPETENT, when he IS NOT.

I've had such experience before and for me it worked if I subtly showed the guy that programming wasn't his domain.

For example, I might go at great lengths to explain a specific piece of code, descending all the way into talking about hash tables and linked lists, big O notation etc., until his face shows that he really feels unable to follow any more of your discussion.

So if you can pull this off you will most likely get rid of the silly questions and micromanagement.