If the only reason people pay attention to you is that you have the ability to fire them, you aren't much of a manager. I worked for years as a team lead. I had no authority to fire anyone, or dock their pay, the most I could do was to say nasty things about them like "They have their own independent ideas about how to get things done instead of genuflecting to me."
If he was a good program manager, people would have respected what he did, which was to understand the market for the product so well that he could inspire and lead the team to build the right thing at the right time.
Depends on the company. Since a Program Manager sits above multiple projects, some companies think of them as just a coordination role -- a little more than a PM but not yet a director. But other companies think of them more like super-PMs, parachuting into their poorer-performing projects and taking over until the PM and the team can get their act together. In these tougher Program Manager roles, they're responsible for the day-to-day life-or-death of the project.
Sadly, more companies are leaning to the idea that the Program Manager is more like a fancy clerk. They end up pretty stressed out and under-appreciated.
This gets to the central question: How do you create, run, and release a huge effort that might take hundreds of man-years, like Office 2012? Something like that covers a lot more ground than simply kicking out some code. There are all sorts of things that need to be coordinated.
Companies are still sorting through how to set up and run programs, in my opinion. There is a LOT of room for screwing things up between 5 guys and 150 guys. There are a lot of tricks to use, but many times people want simple answers and the simple answers are not forthcoming.
A lot of time employees just go to their PM and then go around the Program Manager directly to the higher-ups in the organization. Makes the whole thing quickly devolve into a Charlie Foxtrot.
(Disclaimer: I've done quite a bit of setting up programs and helping companies manage them)
EDIT: I've describe a Program Manager as being "over" the entire effort. Some companies just kick them out to the side of the whole thing. This is an even worse setup, because the business drivers aren't directly connected to the work.
"How do you create, run, and release a huge effort that might take hundreds of man-years, like Office 2012?"
I think that more and more, companies are realizing that the answer to this is "You don't."
Google Chrome is a good example. Instead of trying to figure out exactly what needed to be in the product, they built a kick-ass updater (which is now open-source). One that let them transparently and efficiently download and install updates whenever necessary, so they could treat desktop software like a webapp.
And then instead of having to coordinate hundreds of man-years of work, they can have small independent teams that crank out a feature, release it, see if the feature works well, and back it out if necessary.
The best way to deal with an O(N!) problem is to keep N small.
Their worlds apart though, enterprise would be bringing in a lot of the money on Office, they'd want something they can roll out and only periodically patch, they want something they can rely upon from day one.
Chrome is a free product that already achieves it's main aims, if chrome was a $200 browser or something I'd imagine it would have to conform to the big release idea to.
Chrome got out of beta before GMail because Chrome has a bunch of OEM deals. I don't know the terms of those deals, but I imagine there's money changing hands, and that they are of strategic importance both for the OEMs and for Google:
There's some resistance to using auto-updating software in enterprises simply because it's not the way things have traditionally been done, but IT departments are warming up to it. The huge pain of doing a major upgrade and the constant security fiascos that come from using software that's 5 years out of date are a major incentive for departments to switch to a model where individual changes can be canaried and tested in isolation before bringing down the whole enterprise. Google Docs is certainly having some measure of success in the enterprise arena, despite being a webapp with this development model. And outside of Google, Salesforce.com has revolutionized their market with a webservice-based enterprise app.
The resistance to auto updating software is the amount of risk involved.
If say Chrome was your sole web browser and an update broke compatibility with a business process, who is responsible?
It's a constant struggle to balance the business needs of predictable use and the need to stay competitive with up to date products. Mainframes and WinXP's default browser will continue to stay until the benefits can be clearly shown to out weigh the risks.
Can't employees just ignore what he/she says?