Engineer Respect

Is this what the engineers you work with think about marketing?



If it is, it is almost guaranteed they feel similarly about product management.

I've experienced this attitude from three different perspectives: as an engineer giving it, as a functional manager trying to get engineers over it, and as a product manager receiving it. Few things will derail product development as badly as this attitude. Complete with this attitude comes the corollaries, "I know the product better than you" and "your opinion doesn't really matter."

If you want to succeed with your product, you must address this, and addressing it takes leadership, not confrontation. No matter how important you say you are, engineers aren't going to change their beliefs until they see how important you are.

Here are some steps you can take to address this attitude. It is not always fast. However, unless you are stuck with the perpetually egotistical engineer (and at most 1 in a 100 are that way), you can prevail!

Your opinion doesn't matter

Acknowledge to yourself that they are right, your opinion doesn't really matter. Engineers are analytical. You need to have real data to be taken seriously. If you don't have real data, get to work.

Know your product

Know your product. Nothing will kill credibility like not knowing your product inside and out. Seems obvious, but I've worked with product managers who didn't and I've seen the problems it caused as they tried to work with engineering.

Each product gaffe that you make (like calling to ask how to use that widget that's been in the product for years) does serious damage.

Avoid business jargon like the plague

The video mocks the term "marketecture" and other business jargon for a reason. If you do have to slip into jargon, make sure it is understood. Never, ever use the word, "synergy".

If you are trying to achieve a result that is greater than the sum of the inputs (e.g. "synergy"), explain it in detail. What is the effect you are looking to achieve and why do you think what you are attempting with achieve it.

Keep the engineers informed on what you are doing and why

Visiting a customer? Let them know what you are trying to accomplish. Asking for A/B testing functionality? Let them know what macro indicators you are trying to learn.

This helps engineers know that you aren't just jaunting around for fun and has the side benefit that you might get very useful feedback that can make your job easier. That is a real win-win.

Get engineers into the wild

The more isolated your development process and organization keeps engineers, the more entrenched the anti-marketing sentiment can become. It can become bad enough that the engineers truly believe that the business exists solely because of them.

Combat this by getting engineers in front of customers with you. This builds empathy for the customer, and, indirectly, for you as the voice of the customer.

Solicit feedback from engineering

Any time you can, solicit feedback from engineering and incorporate that feedback into your product. Engineers do know the product best and may have insights that neither you nor your customers have had. More importantly, this builds trust (really listening to somebody always does), which helps cement the results of the other steps.

Paul Graham contends that it is easier to teach an engineer the business ropes than to teach a business guy to be an engineer. While probably true in general (there are some specific examples of engineers I'd never put in front of a customer), it also propagates the ego-driven belief that engineers have the only hard job in the company and, consequently, the only important job.

You need to help them understand that in most software companies, the primary risk to success for most companies is not technological risk but, instead, is market risk. It is unlikely you will hit a technology hurdle that cannot be cleared, so the product dies (unlike, say, pharmaceuticals, where a drug that doesn't work won't sell). More likely is that you will create a product that nobody cares about, so the product will die, regardless of how awesome the code is. That is the value you are providing.

It doesn't take much to successfully change attitudes: just time and consistency. Good luck!