The Cranky Product Manager had a religious experience recently, where the gods of enterprise software came to her in a vision and presented her with the Laws of Product Management. Being gods, they instructed her to share these sacred Laws with y’all.
The Cranky Product Manager shall post each Law in a separate post. Eventually, when several Laws are posted, you can view them all together via the Divine Rules for Product Managers category.
Law #1: On preparing for potentially contentious meetings with Engineering
If thou plans to meet with the Engineering team, where thou suspects the Engineers will disagree with the recommended priorities for product development, then thou shall endeavor to informally meet with each member of the team individually beforehand.
Over burritos or sushi, thou shall endeavor to convince each Engineer of your point of view, describing the use cases and the research thou has done to arrive at the recommendations. Thou shalt be charming and nice and personable and actually listen for a change.
If the time allotted for lunch is too short to convince the Engineer, thou shall continue the conversation over beers after work. An official “meeting” is to be avoided.
Again, it is emphasized that thou shalt meet with everyone on the team individually, from the mightiest architect to the meekest junior engineer.
If thou does this according to THE SOFTWARE LORD’S wishes, the big meeting with the Engineering team will go smoothly and everyone will leave with common agreement as to the features and priorities of the next release.
Also in Divine Rules of Product Management
- Divine Rules for Product Managers #1: Prepping for Engineering Meetings
- Divine Rules for Product Managers #2: On Dealing With Unreasonable Customer Demands
- Divine Rules for Product Managers #3: On Helping the Press with Product Reviews
{ 12 comments… read them below or add one }
Dear CPM, I admire and enjoy your blog, but this post was painful to read: there are actual grammatical rules that apply to this form of now archaic English (see the Wikipedia article on “though” for example). For some more background, the short note “Ye Olde Butcherede Englishe” kinda nails the problem.
Thou hast written a good article, but I do have one question to ask the Gods. And since it is a moral dilemma, it is of course appropriate.
“Dost thee submit an expense report for said beverages and meals with engineering staff in these convincing sessions?”
(apologies to Chris for I fear I mutilated the language more than the CPM, but couldn’t help myself the indulgence)
Cranky,
Sorry to say, but yet another violent disagreement here. :-)
There are basically two types of engineering cultures that a PM will have to work with: rational and irrational.
With a rational culture, the role of PM and Engineering is well understood and followed. There is a cooperative culture but PM is responsible for defining *what* the priorities are, and Eng on *how* to best implement them, with some cross over as needed. There is constructive discussion when issues arise and people are, for the most part, professionals. No sushi, burritos, Jolt Cola or other consumables are needed in this relationship, though providing them on occasion is usually appreciated.
The other, irrational, culture should be avoided as much as possible. Here Engineering believes they are the owners of the sacred code and have been granted divine rights to code what they please, and only see the PM’s “requirements” as loose “suggestions” on what to build. They usually have some executive supporting them and they know it and use that to unravel the work of even the best PMs.
No amount of sushi or burritos or other food will change them, as they feed on power and prestige and will never allow a lowly Product Manager to attain a level of authority over them.
While it is good, in general, to socialize ideas amongst people before the “meeting”, the approach you recommend is unnecessary with the former culture and will not work with the latter.
Saeed
Saeed,
Theoretically, you are correct; that there is no rationalizing with an irrational force and this type of engineering organization should be avoided. And it does feel a little sneaky to do this, even if you don’t submit an expense report. I’ve worked in both types of organizations (who hasn’t?) and I must say that in my experience if the personal relationships are good, then the working relationship becomes so much more efficient.
So it isn’t as much about buying people’s agreement, but by socializing the ideas with each type of organization beforehand, you get insight and the trust of the engineering team to tell you why they disagree and it gives you the opportunity to work with them and listen to come up with potential compromises and alternate courses. So much easier to do this when the need to impress peers in a meeting is not part of the equation. (I’ve even seen where only having a relationship with part of the engineering team helps enough to convince difficult irrational members to relax their push)
I think this comes down to the same conclusion that all these rules or that any product manager worth her/his salt knows: every organization is somewhat different and the cultures and personalities within differ as well. What works in some won’t work in others and it is up to us to know all the tools available and be able to figure out which screwdriver we need to drive that nail home.
Although I think the advice to meet informally with team members is absolutely right, I think this should be done a little more ad hoc. Doing it only when you want something is going to become transparent to the point that they will stop accepting your invite for a free tuna roll, and perhaps resentment for being ‘played’. But it’s never about sushi, burritos or beer. Well, ok, sometimes it’s all about beer. Informal, ad hoc meetings lets you get to know these people on a non-work basis and find out a bit more of who they are. It’s amazing what you discover. Product management involves strong negotiation skills. Negotiating methods such as those described in “Getting to Yes” openly encourage this type of socialization as an important tool. It makes a lot of sense to me. The engineers, in spite of rumors and occasional evidence to the contrary, are fellow human beings.
I bet Cranky Product Manager is Asian :)
Some great comments.
Saaed, I agree with your assessment fully, but I have never worked in a “rational” environment. Every company I have been at, there has been loathing and distrust of the product management organization (they are typically part of (gasp) Marketing after all). That said, there are shades of irrational organizations, and for me that is the crux.
Since I pulled my degree in physics, and can toss around Maxwell’s equations, as well as duel with quantum mechanics, bandgap theory, etc. I usually am effective in winning the hearts of engineers. However, it is not a trivial task, and consumes a lot of my personal bandwidth.
Oh, how I would love to work in your rational environment that you describe. Maybe one day…
This communication theme seems to be catchy as it was a recent post of pain at another PM blog group. Anyway, I have often seen our role as PM’s as that of a crafty chameleon. Consider the vast audience that we are asked to communicate with internally in our own organizations and externally to our markets. We have to posses the skill to alter our language to suit that of a very broad audience. In a singe day we will have a face-to-face with a CEO of a Fortune 500 company who wants to know why he\she should buy our product and later attempt to communicate with a developer how to use technology to solve a real business problem. And tomorrow we have to write a product data sheet that everyone understands and a press release that only the competition will read.
Heck, considering the scope of our communication responsibilities I see the engineering meetings as child’s play (although it has helped me that I have taken courses on 5 major development languages in order to better achieve engineer-speak).
Yes, I would say that we are faced with some difficult communication tasks. We are constantly “selling” (sorry) and evangelizing our cause and we have to do it with passion. It will be that passion that will go a long way in convincing even the staunchest of irrational audiences. If you can’t passionately get behind the goals for your product as you have come to envision them, find a new product.
@Bruce,
No need to apologize for using the word “selling”. Nothing wrong with it and it is very needed skill for PMs. It’s the first Product Management Axioms that I follow.
http://onproductmanagement.net/2007/07/16/product-management-axioms/
@Geoffrey
A fellow physics grad! Great to hear that. I’ve worked in a couple of VERY rational environments, and a few VERY irrational one. It comes down to company culture and the mindset of the executives. If they permit grandstanding and egotistical behaviour from Engineering, then it’s virtually impossible to change from the bottom up.
BTW, given your background, you may like this post on Frames of Reference as applied to Product Management.
http://onproductmanagement.net/2007/07/29/frames-of-reference/
@Howard and John
It is totally about the relationship that is built with engineering. They may not like you, but they should respect you. There are some personalities though that cannot be won over because for them it is a power struggle, and giving Product Management any authority is viewed as a loss of their power. I’ve unfortunately worked with (loosely speaking) a VP Eng who was backed by an EVP of Products who pushed every good PM out of the org. This was done by promoting or hiring weak (i.e. compliant) PMs and pushing aside the stronger ones. That went on for many years until a new CEO started making changes. Several years later, I hear the problems have diminished, but are have not disappeared. The real challenge now is for PM to truly step up and deliver on what is expected of them.
Saeed
Geez, I see a lot of dancing around an obvious point – engineers typically have lousy interpersonal communication skills and a less-than-competent grasp of organizational politics. Engineers tend to be absolutists and purists – what’s “right” is justified by the fact that it’s “right”. And I think that’s the point of the CPM’s post – prepping for “engineering” meetings. Not for sales meetings. Not for exec meetings. For engineering meetings, cuz dealing with engineers requires its own approach and appreciation.
Two cases in point. And they’re about IT guys. Granted, IT guys are like the poor relations of engineers; they don’t design technology, they just get stuck implementing it, but in my experiences with both, they have share many of the same personality traits.
#1. In my current-about-to-be-recent gig consulting at a big freakin’ company, I’ve been amazingly successful *pats back* in bringing all stakeholders together, getting consensus, and establishing a strategy – except with IT. They came around, but only after I spent at least 2-3 times as much face-time with IT managers and in engineering process workshops than with the business groups who actually have the problem being worked-on. And IT can decide to derail any non-IT-focused meeting by proclaiming that X, Y and Z are impossible. Don’t need to research it – just take their word for it. And that IT group wonders why they’re despised virtually throughout the rest of the company? No mystery why they’re getting downsized and outsourced either.
#2. My brother was in the Marines for several years. Being Marines, they’re all trained to be infantry riflemen, so even cooks and lawyers can strap on a weapon and charge a hill any time, any where. An unapologetically ballsy blood-and-guts culture through and through. Well, except for the IT guys. He was amazed that the Marines who were IT guys were like Jimmy Fallon’s “IT guy” skits on SNL – cocky, fast-talking, acronym-spewing, with at least 3 pieces of technology clipped to their belt. And they had that same “IT guy” attitude and talked to people, including senior officers, in ways that would get anyone else boot-stomped on the spot. Why do they get away with it? Because they’re the only ones who can fix the XO’s Blackberry, or can get the CO’s laptop to connect to the network on the ship you just deployed on, etc. My brother wanted to rip into these guys on multiple occasions, but hell, he needed them to get his iPaq to sync his email. So once again, different rules of engagement for the nerd herd.
In my view, we treat software engineers and IT engineers like people used to treat shamen and witch-doctors. They command powers that are a mystery to the rest of the tribe, they get to dress in their own weird outfits, they demand odd forms of tribute, and they frack-up discussions by announcing the cataclysmic consequences of ignoring their bizarre rantings.
Crops had a bad year? See – that’s what Mordok warned would happen if you didn’t spend the village’s money on a new altar to the monkey gods.
Product flailing in the market? See – that’s what Markus warned would happen if you didn’t spend half your engineering schedule on a Ruby on Rails refactoring project.
So like other commenters, I disagree with the “rational vs irrational” notion as I’ve seen the latter as the norm. I agree that it shouldn’t be, but it is. And so we are stuck offering sushi, sake-bombs, and burritos to curry favor.
That’s also why I believe so many successful software PMs have technical backgrounds. I saw on a TV show that even real-life witch-doctors don’t lay on the BS with other witch-doctors. It’s like they say:
Never sell to a salesman.
Don’t try to grift a grifter.
And don’t try to tell me you just pulled-out a demon out of that guy’s liver cuz I know the old chicken-blood-and-gizards-in-my-pocket trick too.
Ah well. Feels like Friday already…
I’ve tried this. It is exhausting and I’d argue a waste of time to try to hit everyone. You really only need 1-2 engineers: the lead developer and/or the chief architect. The other developers will fall in line with what they want. It’s very rare to find dev orgs that are “flat” enough that the lead dev/architect is actually influenced by what his subordinates think. “Alpha dog” developers are highly territorial and believe they are God’s gift to C++, and many see it as a sign of weakness to admit that someone else knows more than they do. That’s why they dig in their heels at the first sign of conflict.
I focus on getting my relationships with those two people solid first and the rest works itself out. Usually my battle with them is never on prioritizing features, it is on bug fixes vs. new functionality and new functionality vs. “architecture.”
New blog post: Divine Rules for Product Managers #1: Prepping for Engineering Meetings http://tinyurl.com/8zp4lk
{ 3 trackbacks }