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:
- The “rational” engineering organization does not exist because it is made of people, and people are inherently irrational.
- 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.
- 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.
- 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.
{ 9 comments… read them below or add one }
If only developers–and husbands–could learn to say “You’re right, dear. I’m sorry.” 60% of the time it works all the time.
Hopefully I read the original article and comments thoroughly enough and I’m not repeating an idea here, and I’m sorry if I am, but I think there is another huge benefit to having these smaller meetings ahead of time.
I think the idea was hinted at when CPM said that meeting with people ahead of time allows the PM to hear unforeseen objections. It also gives engineers time to digest the problem.
There are many reasons why this helps. It gives people time to get past any emotion flare ups that even the most rational of engineers have from time to time. Perhaps they can think of better solutions and compromises while not in the heat of an argument. Maybe a good night’s sleep just changes their perspective on things.
As for the idea that there are two types of environments, rational and irrational, I just don’t buy that at all. First off, this is the real world. Every person has different capacities for logic and emotion. There are many people that have more of both characteristics than others. And it is hard to know what will set off different people.
I concede that having rational, cooler heads involved in a discussion makes meetings go better. But if your engineers are always so rational that you can drop bombs on them and they never let their emotions affect them, I question whether you really have the best workers.
I want people that care working on my projects; they do a better job.
Caring is an emotion. Emotions are unpredictable at times. Yes, sometimes those emotions can cause problems. If you do have continual problems with an individual, mayhaps they don’t belong at your company. But giving most real people warning when contentious decisions are about to be made gives them time to get their emotions in check and think about things rationally.
Absolutely right! I think the key bit to what you write is this: Note, though, that if you frequently meet and socialize with individual developers, you can expect less and less contentious meetings over time.
If somebody is too busy to actually spend time with all of the team members, that’s not unreasonable. But their opinions will be treated as those of an outsider. If you want people to take your ideas seriously, you have to take them seriously. As people.
One good reason to talk to other people about potentially contentious ideas: maybe you don’t know everything even though you think you do.
As far as the Asian thing, having worked with Asian businessmen a lot (large companies) the “big meetings” are usually a rubber stamp. Consensus building, face saving etc happens first. Initially I thought it a very frustrating and slow approach. It is slow, and I don’t like it, but I hate it less now that I’m older.
Well the famous “pre-meeting”. Now I do understand why, specially if you are working in USA. Even more so if you have Asian influence and losing face is problematic for you. If you are Scandinavian, this may be insulting and if you are German it is a sure sign of weakness.
There are other ways to handle this. Do more than one big meeting. Why are meetings so big? Allow engineers to do what they do, engineer things. Recommend things to them, explain etc.
The problem with pre-meetings is when you manage to get too many of the weak minded fools on your side when you are wrong. Embrace the contentious meetings. Feel good about losing every now and then.
Oh and if you have not gathered… I have been on both sides of the table, in engineering (not software) and product management. I am wrong a lot :-) and I hate the political bs of pre-meeting. And yes I am from Finland.
Of course the Cranky PM is right; close communication is key to removing contentious issues.
Could you please provide some additional insights? How do you accomplish this with remote teams, which may have a 12 hour time shift from your normal office hours? Late night conference calls help but the communication remains strained. What frequency do you suggest for face to face meetings, which are more helpful than voice or video calling.
Please enlighten more, there may be some sushi in it for you :)
Zoe, the Cranky Product Manager has worked with many a Finn and Swede and Norwegian and found that the pre-meeting is even MORE important with them because of the strong (inflexible!) opinions they often have and put forth in meetings – often before hearing all the information – plus their unwillingness to change their minds. Things are different if you discuss things in a social context ahead of time.
Oh, and by “big” meeting the CPM does not necessarily mean large, but important.
Too often, the meetings that you recommend the CPM embrace degrade into male pissing contests. The various men in the room do the equivalent of “whipping it out” and try to show how frakin’ smart they are, all while putting down the others. The loudest and most obnoxious often win. But I guess you’d categorize the ones who don’t partake in this type of verbal contest as “weak-minded fools”. Well, the Cranky Product Manager disagrees. Some of the best ideas and most important points come from the people who are quiet in meetings.
Perhaps because the CPM is female she is especially annoyed by this type of thing. Premeetings work lots better.
Chuck, thanks for this. You’ve summed up what the Cranky Product Manager wanted to say in a much clearer and complete way.
On Engineering Meetings (redux) – http://t.co/by0RrAP
{ 2 trackbacks }