I can feel my eyes slowly glazing over. I'm not trying to, really. I am doing my absolute best to stay focused and present. After all, technically I am facilitating the meeting, right? Want me to talk to your gorilla? Send me an email
Tuning back into the conversation… discussion… okay let's call it what it is, the knock-down, drag-out argument. I determine that, yes they are still on the exact same topic and neither side is relenting. I can almost hear the announcer's voice:
"And in this corner, weighing in with an MBA from Wharton and a BS in Computer Engineering
from UC Santa Cruz...The Product Manager!"
"In the other corner, with a Masters in Computer Engineering from CalPoly, an electrical engineering
minor, a minor in physics, and founder of two start ups...The Engineering Manager!"
I try to remember, how exactly the functional spec review devolved into 'passionate' discussion on whether one feature should be implemented with Java or .Net. The Product Manager is currently white boarding exactly how the feature would be coded in .Net. Meanwhile, the Engineering Manager is not only disagreeing with him, profusely, but is adamantly stating the feature isn't what the customer wants and trying to push his own user scenario.
At this point Hogarth leans over and quietly confides in me, "So...just so I'm clear. The Product Manager is trying to engineer the product, the Engineering Manager is writing new user scenarios oh and executive staff isn't even bought in to the whole product, because our competitor isn't doing it yet? I got that about right?"
"Shut up Hogarth…" I mutter.
"What? Okay, fine just ignore me. I'm only the gorilla in the room."
Welcome to the "too many cooks" gorilla. When everyone in the program team is part engineer, part product manager, an expert in QA, and of course a natural salesman (I mean how hard can it be to sell our awesome product, right?).
When exactly did it happen? Take the Product Manager role, for example. Today, if you want to be hired as one in Silicon Valley, you have to be an expert in business and engineering. If you don't have a double major, you can practically say good bye to the job. Okay so I exaggerate a bit, but it just underlines a trend I've watched for the last ten years.
I guess I blame the Dot.Com era. Now maybe that's using a convenient scapegoat, but it is true that the late 90's start ups required everyone to wear multiple hats. When I was a product manager, during that time, I had to be not only a product manager, but a business development manager, a salesman, a trade show AV expert, a project manager, a QA tech, a user interface expert and even desktop IT to my coworkers. We all got so used to wearing so many hats, that we started thinking we were good at everything we did. I guess we all forgot the second half of the famous saying. "I'm a jack of all trades, but a master of none."
Flash forward ten years and I'm watching the Engineering Managers trying to shape the product, while Product Managers are trying to code the product, and absolutely nothing is getting done. It's almost like we've lost the ability to trust that the other guy can do his job and we can focus on doing our jobs.
"Isn't that what I just said?" Hogarth asks in a deadpan voice.
What advice can I offer?
This is one of the biggest and most difficult gorillas that I've ever had to deal with. As a project manager, you can easily identify he's there, but talking about him is not as easy. You certainly can't tell the Product Manager to "mind your own business and let the engineer code." Sure it would feel very satisfying, but not all together productive. There are two things I've found to be helpful, in facing this gorilla.
1- Support the expert: Of course you can't come out and say "The engineer makes that decision", but you can provide support to the expert for a given task. Not only can you facilitate meetings to focus on the 'expert' for a given discussion, but make sure you have clear process documentation, with task owners (Engineering owns the functional spec, PM owns the user scenario), clear definitions of documents (what exactly should a Market Requirement Document (MRD) do, as opposed to what an Functionality Requirements Documents (FRD) should do.) It may seem subtle, but it can go a long way to clarifying roles.
2- Ask the right questions: "How does using Java change the user scenario?", "Don't you have market data on why this feature is critical?" You're not really asking questions of course. In true Socrates fashion, most of the questions you ask, you already know the answer to. You are just bringing the answer into the light. Remember though, the questions should support the expert.
And there is one more way to avoid this gorilla. That is to know what you are good at, know what your job is and put faith in your team mates to know the same. But then we are all doing that already, right?
Have any tips for dealing with the "too many cooks, not enough experts" gorilla? Share them here and bring out your inner gorilla talker.
Until next time I'm,
Joel BC
Professional Gorilla Talker
Tuning back into the conversation… discussion… okay let's call it what it is, the knock-down, drag-out argument. I determine that, yes they are still on the exact same topic and neither side is relenting. I can almost hear the announcer's voice:
"And in this corner, weighing in with an MBA from Wharton and a BS in Computer Engineering
from UC Santa Cruz...The Product Manager!"
"In the other corner, with a Masters in Computer Engineering from CalPoly, an electrical engineering
minor, a minor in physics, and founder of two start ups...The Engineering Manager!"
I try to remember, how exactly the functional spec review devolved into 'passionate' discussion on whether one feature should be implemented with Java or .Net. The Product Manager is currently white boarding exactly how the feature would be coded in .Net. Meanwhile, the Engineering Manager is not only disagreeing with him, profusely, but is adamantly stating the feature isn't what the customer wants and trying to push his own user scenario.
At this point Hogarth leans over and quietly confides in me, "So...just so I'm clear. The Product Manager is trying to engineer the product, the Engineering Manager is writing new user scenarios oh and executive staff isn't even bought in to the whole product, because our competitor isn't doing it yet? I got that about right?"
"Shut up Hogarth…" I mutter.
"What? Okay, fine just ignore me. I'm only the gorilla in the room."
Welcome to the "too many cooks" gorilla. When everyone in the program team is part engineer, part product manager, an expert in QA, and of course a natural salesman (I mean how hard can it be to sell our awesome product, right?).
When exactly did it happen? Take the Product Manager role, for example. Today, if you want to be hired as one in Silicon Valley, you have to be an expert in business and engineering. If you don't have a double major, you can practically say good bye to the job. Okay so I exaggerate a bit, but it just underlines a trend I've watched for the last ten years.
I guess I blame the Dot.Com era. Now maybe that's using a convenient scapegoat, but it is true that the late 90's start ups required everyone to wear multiple hats. When I was a product manager, during that time, I had to be not only a product manager, but a business development manager, a salesman, a trade show AV expert, a project manager, a QA tech, a user interface expert and even desktop IT to my coworkers. We all got so used to wearing so many hats, that we started thinking we were good at everything we did. I guess we all forgot the second half of the famous saying. "I'm a jack of all trades, but a master of none."
Flash forward ten years and I'm watching the Engineering Managers trying to shape the product, while Product Managers are trying to code the product, and absolutely nothing is getting done. It's almost like we've lost the ability to trust that the other guy can do his job and we can focus on doing our jobs.
"Isn't that what I just said?" Hogarth asks in a deadpan voice.
What advice can I offer?
This is one of the biggest and most difficult gorillas that I've ever had to deal with. As a project manager, you can easily identify he's there, but talking about him is not as easy. You certainly can't tell the Product Manager to "mind your own business and let the engineer code." Sure it would feel very satisfying, but not all together productive. There are two things I've found to be helpful, in facing this gorilla.
1- Support the expert: Of course you can't come out and say "The engineer makes that decision", but you can provide support to the expert for a given task. Not only can you facilitate meetings to focus on the 'expert' for a given discussion, but make sure you have clear process documentation, with task owners (Engineering owns the functional spec, PM owns the user scenario), clear definitions of documents (what exactly should a Market Requirement Document (MRD) do, as opposed to what an Functionality Requirements Documents (FRD) should do.) It may seem subtle, but it can go a long way to clarifying roles.
2- Ask the right questions: "How does using Java change the user scenario?", "Don't you have market data on why this feature is critical?" You're not really asking questions of course. In true Socrates fashion, most of the questions you ask, you already know the answer to. You are just bringing the answer into the light. Remember though, the questions should support the expert.
And there is one more way to avoid this gorilla. That is to know what you are good at, know what your job is and put faith in your team mates to know the same. But then we are all doing that already, right?
Have any tips for dealing with the "too many cooks, not enough experts" gorilla? Share them here and bring out your inner gorilla talker.
Until next time I'm,
Joel BC
Professional Gorilla Talker
Posts
