I've been reading "Thank you for the Days" the autobiography of Mark Radcliffe, a radio presenter. His observations on being a radio producer are interesting to think about for project managers (and managers more generally). Here's what he says:
"Initially, with the native enthusiasm of relative youth by Radio 1's then standards, I did try to exert some influence on proceedings...Eventually I realized that the bands were going to do what they were going to do, and the seasoned BBC engineers were more than capable of recording it. ...As producer I wasn't responsible for the material. I was just there to make sure everyone was getting on with it, and no bits of BBC equipment got broken or stolen.... It brought home to me one of the most important lessons a producer can learn, that if everything's going smoothly, don't be tempted to stick your oar in just to satisfy your own ego".
The bit about "not being responsible for the material" reflects that the bands Mark Radcliffe was producing were being recorded to appear on the then massively influential John Peel Show - a significant marketing opportunity at the time. I suppose the point is that if the band preferred to appear drunk (or unusually sober) or to try out a new sound, then that was a risk for them and their label, not for the BBC. Also, rock musicians are not exactly a group noted for their ability to listen to business direction. There are similarities in publishing here - I've come across some authors who have rock star status and so are edited with great caution if the idea of editing them is tenable at all.
By usually, Project Managers are usually accountable to the business for the project (as in, the business expects to take it up with the PM if the material is unsatisfactory). I've seen projects where the programming team's ideas are accepted uncritically on the rock star model, but the success is mixed. Usually, it goes wrong where specialists are making decisions that are outside their specialty. This can be hard to detect - for instance a programming decision might knowingly or unknowingly assume a certain model of customer behaviour, and the programming team may not know enough about the customers to get that right. Or (in some cases) to have the humility to ask Marketing. Of course, in other cases, the exact opposite of that problem occurs.
This means the PM is always having to make a judgment - "am I forwarding an opinion in my role as the person accountable for the delivery of the project, or am I just sticking my oar in". For example, say you are at a meeting discussing the table structure of a database. It seems to me that the PM is entirely in his or her rights to hold out for a structure that will be quicker or cheaper to build but just as good, (or conversely to champion something that is harder work for the programming team to build but will deliver better business benefits). However, like Mark Radcliffe, the PM needs to remember to shut up provided it's clear that everything is going well.