How can we prevent project managers from bothering programmers

Question

Hi,

We're in a fast paced industry (communications) and we build websites and mobile app among the other departments of the company (print, ads, advertising, etc).

We are the only "non-creative" department and our methodologies often clashes with the other departments. They usually go see people directly without any sort of methodologies.

Anyways, my concern today is that our project managers in our department often bypass the tech lead or our director and go see programmers directly. Programmers now have to talk to someone with a completely different perspective than his own. It's hard for them to remain concentrated and there's confusion about the demands they receive (unfiltered, unclear or plain wrong). Sometimes they dare to tell the programmer how to do something by telling them "it's easy, just do what you did last week" or something. Plus, the tech lead/director looses track of who's doing what.

It is true that sometimes a small thing can be asked directly, we don't want to fall into bureaucracy. But where to draw the line to prevent those problems is hard to do. This problem starts with a single little demand, then another and another until it is out of control. We previously tried to do something about it but how can we make something durable?

So, what can we do to prevent this situation without sacrificing our "agility"? How is it at your place?

Thanks

Answer 1

Have your developers respond that their priorities are set by their lead/supervisor, as they would be in any other department. As such, they should take it up with the lead/supervisor.

Answer 2

I see two options:

1. Make sure your programmers are assertive enough and comfortable enough to direct project managers to the tech leads if it's not a "no brainer" type thing.
2. Strictly enforce Project Manager to Tech Lead communication. Tell your programmers to direct them to the Tech lead anytime a PM taps their shoulder.

My vote would be for option 1 and it has worked well for me in the past. When in doubt get the necessary parties involved. Option 2 can lead to too much bureaucracy as you suggest.

Answer 3

You could realize that you're part of a larger organization whose goals are not to "get the code written". The goal is to solve a problem. In that light the project manager talking to the programmers is perfectly logical. There probably should be some communication with the tech lead as well to allow him to do scheduling, but there's nothing wrong with talking directly to the developer in order to avoid the "telephone" problem.

As to your developers communicating with someone who has a different perspective than them, your developers should be seeing the problems from the perspective of business goals and not just one line of code after the other. You'll never reach the finish line if you don't know where it is.

Answer 4

Assign a "lead designer" for the software. His job is to keep a coherent software product, and to save the project managers time because they don't have to explain things down to the level of individual developers. Sell the position as something that actually helps them save time and results in better realizations of their ideas.

If you do actually save them time and effort, human selfishness will automatically cause the results you want. It's a bit like moving a crossing to where people actually cross the road. It doesn't change their behavior, but it fixes the problem.

As an aside, it's my idea that programmers should also go through the lead designer for their improvement ideas. Otherwise you just get organic feature growth, and you never get really great software designs that way. When they tell their idea, there should be a sort of "yes, but it would be even better if..." reaction.