responsibility+no+authority

The Cranky PM is finally getting up the energy to respond to comments on her older blog posts.  In particular, those from a certain reader who keeps inflicting violent disagreement on her.

What THE???  Who does he think he IS?  How DARE HE disagree with the Cranky Product Manager?  When is he (along with the Cranky Product Manager’s husband) going to at LAST learn that THE CRANKY PRODUCT MANAGER IS ALWAYS RIGHT. This is a fundamental LAW of the universe.  Truly.

Anyway, here is one of the violent comments that has the Cranky Product Manager’s knickers in a twist.  It is on the Divine Rules of Product Management #1: Prepping for Engineering Meetings post.

You know, the post where the Cranky Product Manager said (in a much more long-winded fashion), “If you’re going to meet with the Engineering Team and you suspect the meeting is going to be contentious because some/all will be surprised or disagree with your recommendations, then make your case with each team member individually ahead of time so that the meeting goes smoothly.”

To be perfectly clear, the Cranky Product Manager was NOT suggesting the following:

• That you BRIBE engineers using free food. Her point was that you discuss the issues with individual engineers in an INFORMAL setting. If you can do this by playing some (free) Nintendo Wii with them, then fine, do that.  (Note that the Cranky PM usually does not pay when she lunches with engineers; everyone pays for him/herself.  Of course, this only works if you mostly ask developers to agenda-free lunches. Otherwise they’ll be suspicious every time you ask them to lunch.)
• That you meet with individual engineers prior to EVERY meeting with Engineering.  It’s only mandatory before the meetings you expect will be contentious.  (Note, though, that if you frequently meet and socialize with individual developers, you can expect less and less contentious meetings over time.)

Anyway, who could have guessed anyone would disagree with the idea of meeting with engineers individually before contentious meetings?  Not the Cranky Product Manager.

During the Cranky Product Manager’s days as a hoity-toity management consultant in the McBainCG Group, this practice was called “the meetings before the meeting” and was regarded as fundamental.  The goal of Big Meetings was to get the client team officially on-board and start them moving forward with the McBainCG Group’s recommendations.  Without the “meetings before the meeting,” getting this “Let’s Go” decision was very unlikely.

Why not?

Well, first, many people — especially engineers — pride themselves on being these paragons of rational thinking (this is called self-delusion). These folks CANNOT say “let’s do it” without trying to poke holes in your arguments for a while — sometimes a LONG while, as in hours.

Second, without “meetings before the meetings,” you are leaving an awful lot — too much — to chance.  The meeting and your entire project could go to hell because someone has an objection you hadn’t anticipated and you say something stupid.  Or this common situation: an engineer is surprised by your findings and has a visceral emotional reaction against the “surprise” aspect, but instead of complaining about the surprise, s/he shoots down your findings, in public. Then, the meeting ends before you can make a proper rebuttal.  Great. Now you’ll have to work five times as hard to convert this person to your course of action.  And if this person is respected or influential, well you gotta work on other people too.

Now, as far as Saeed’s assertion that in a “rational” engineering organization, the developers will fall in line and do what PM recommends, the Cranky Product Manager says:

1. The “rational” engineering organization does not exist because it is made of people, and people are inherently irrational.
2. The so-called rational Development Team might do what you recommend even if they disagree with you. But if you want them to do a GOOD or possibly even GREAT job, if you want to keep them motivated, and if you want FUTURE projects with them to go well, then you will spend the time to convince them your recommendations are the right ones.
3. It’s much easier to be a PM if you have the loyalty and respect of the Development Team. You get that respect by giving it – by listening to others’ opinions and learning about them as people.   And don’t only talk to your developers when you want something from them.  Seriously, that makes you a user and abuser.
4. If you know the Development Team is going to fall in line with your recommendations because they are “rational” or will buy into your recommendations, the meeting won’t be contentious will it?  So, maybe this Divine Rule doesn’t apply.

Paul Young commented that these “meetings before the meetings” take a lot of time and are really only worthwhile with the lead developer/architect (not the junior developers).  Well, again, the Cranky Product Manager respectfully disagrees.  In her experience, junior developers that are not “sold” on the PM’s recommendations are often very disruptive to the actual project (even if they are quiet in the meeting) and spread all kinds of negativity.  This varies of course, but many young developers (especially those hailing from elite “Institutes of Technology”) are Hotshot types who think they are smarter than everyone else — ESPECIALLY product managers.

Solomon commented “I bet Cranky Product Manager is Asian.”  Well, maybe, but maybe not. Is this comment because the CPM’s tactics provide ways for engineers and product managers alike to avoid losing face in a public forum?  Or is it because she clearly likes sushi?  Explain?

Paco commented that the “meetings before the meetings” were important for engineers, but maybe not for other types of business professionals.  Well, the Cranky Product Manager only partially agrees.  Engineers are special because they like to think they are super-rational and analytical and love poking holes in arguments, and thus need to be given plenty of time to do this.  Further, their unique role makes it easier for them to obfuscate what they are really doing.

However, “meetings before the meetings” and getting buy-in are important for ANY meeting you think will be contentious.  NEVER surprise ANYONE – - no matter their role – at a Big Meeting where you’re seeking “Let’s Do It” approval.  Yes, this means the CEO. Find a way to give him/her a preview of what you’ll say ahead of time.

Anyway, this whole thing reminds the Cranky Product Manager of a post she wrote two years ago entitled “That All the Responsibility But No Authority” Saying.  Check it out.

{ 11 comments }