
Product Managers, Stop Pissing Off The Engineers - bdehaaff
http://blog.aha.io/index.php/hey-product-managers-stop-pissing-off-the-engineers/#more-444
======
fredsanford
You know... This brings a part of my life back to mind that I hoped to
forget... FS, if you're reading and recognize this, I still respect the hell
out of you and wish you well. I can't go into too much depth here without
revealing more than allowed. I am purposely vague and I apologize if that
bothers or offends you but I don't want to see any litigation in my future.

I don't know how to take this article. I wish some of the insight had been
around when it mattered to me (working 60 - 80 hour weeks because of
management over-promising because they wouldn't take the time to understand
the scope because the PM was sure it was "trivial") but some of it also smacks
of the PM thinking of her/himself as some kind of deity whose wishes would
make the work happen magically. Me, personally, I like my deities to be left
in church where I can ignore them as I deem necessary...

Anyway, the best PM like being I ever had contact with was a QA department
head who had been in the line of business his whole life and knew _exactly_
what something needed to do to succeed in that business. He had a second in
command that was also a lifer. Between those 2 guys, when they got interested
in something, that something did some smooth sailing. If they were
disinterested or too busy with a fire, all hell would break loose.

Well, at this particular company, every time all hell would break loose, they
would, instead of fixing the original software, buy something similar and try
to massage it into the product. During the ~19 months or so I was there, they
bought, had been in talks to buy or were suing the seller over the bought
product not working for _4_ different products. The funny thing was, all of
these products were based on disparate technology... The original software was
built in a combination of Delphi, Borland C++ and the Borland DB engine. Of
the bought software, One was Java based, it wouldn't run for 12 or more hours
at a time. One was based on .Net and it crashed more than it worked. 2 were
based on popular C++ App Frameworks. Those 2 kinda worked, sometimes, if you
held your mouth right and kept your support contracts up to date.

Now, we have a company with at least 4 different technologies with maybe 2 of
the original developers of any of the software left. The only guy that remains
with any sense and sanity is the QA guy because his family is tied to the
company. And all along he's been yelling/screaming/cajoling/nurturing,
whatever he can do to get the management to leave the programmers alone and so
they can get the work done.

~~~
jmspring
A bad PM can be countered with good engineering management. That said, I've
been at a place that had both. Weekends were planned into the schedule and
they thought that was the norm. At a certain point, the brain drain was pretty
serious (myself included). Not meeting deadlines isn't always an engineering
issue it is a management and planning issue.

Another more recent example, boot strapped startup. General engineering goal
with a high level of what pieces are needed. Most of those working on it are
contractors not always onsight. Functionality decisions are made between a
couple of parties, but not communicated down resulting in added effort. In
this case, there isn't a lot of engineering pushback, but the PM should be
aware of the need to communicate more directly, yet doesn't. When pressed for
specs, a blank face. An example, for me, of a bad PM.

~~~
bdehaaff
Agreed. Thanks for the comments. We actually wrote recently about a "goal
first" approach where you start with the strategy and why you are doing
something and then clearly articulate the features in a collaborative way.
Consider checking it out here - [http://blog.aha.io/index.php/goal-first-a-
product-roadmappin...](http://blog.aha.io/index.php/goal-first-a-product-
roadmapping-how-to/)

------
danso
Being an engineer (by schooling) myself...I've always found it confounding how
non-technical product managers do what they do...I've seen plenty of "shut up
non-techie" posts (including this OP) but are there any really great non-
techie product manager musings on this topic, explaining how they are able to
reliably judge timeframes and output without having hands-on experience?

I do think producers are valuable...in the art/entertainment world, for
example...you don't have to be an actor/model/writer to be vital to a
production's success. However, in software, it just seems that the
implementation of the process is so vital in fully realizing the gains that
code can bring you, that if you have a product manager who doesn't understand
that, than the PM can do as much harm as good.

~~~
bdehaaff
I am the author and I built my career as a "non tech background" PM before I
became a CEO. My super secret to success (not really that secret). Be great at
explaining the "whys" and "whats" and work closely with engineering on the
"hows." Understand what it will take to build something before agreeing on the
roadmap. Building great product requires awesome PM and engineering.

------
austenallred
I hate articles like this more than anything. If you really want to help
product managers, do you have to spend the first half of the article telling
them that you're so much more important than them? It takes two hands to clap.

~~~
marshray
I see one paragraph that might fit that description. The one that starts with

> However, the reality is that you need engineering more than they need you.

And it's basically true. But I thought the line

> You are overhead.

Was too harsh and a slam.

If the author really feels that's a notable point to make, it deserves _a lot_
more explanation.

~~~
bdehaaff
I have been a PM for most of my career. Lose engineering and you have no
ongoing product, sales and you can not sell it, support and you can not
service it. You get the picture. PM is not required for the basic operations
of the business. Great PM is fundamental to success, but not to the day-to-day
management of the business.

~~~
coldtea
There are such things as "one developer shops".

There are no "one PM shops".

Case closed.

------
gfody
If you're having non-technical product managers owning technical products
you're asking for trouble. Since when did any non-technical product person
become the domain master go-to-guy for any technical product? I have seen
product managers provide great leadership on technical products but they have
always been supremely capable and the engineers respected them for it.

Some product person with an inflated ego spinning buzzwords is not going to be
respected by engineering and will not succeed in influencing them in any way.

 _What you may think: I have been around engineers a long time and know the
difference between NoSQL and MySQL. And there is no doubt that I would have
been a great engineer if I had lerned to program, found it rewarding, and led
a ton of open source projects._

Anyone who seriously thinks this way is most likely _hated_ by engineers and
probably gets made fun of a lot behind his back.

~~~
bdehaaff
Exactly, all of the "what you might think" points were exaggerated but not
intended to be ridiculous. Great PM works and respects the value of what
engineers can contribute during the plan AND build efforts.

~~~
gfody
I think I am responding more to the way you have set the scene where we have
non-technical product managers owning technical products. I think if this
situation exists you've actually got a fucked company or at least some serious
org-level trouble with the division of roles and responsibilities and probably
not something you could fix by head-shrinking your product people.

Actually it's funny if you think about it the only way non-technical product
managers maintain their positions owning technical products is by finding such
companies and actively partaking in all the _what you may think_ behavior.
Forgive me if this whole piece is intended as subtle irony in which case I say
well done and humbly accept my swoosh.

------
doctorpangloss
Eh—hoarding credit is sort of the M.O. of a really great product manager.

A PM has to compete with all the other PMs to get her features implemented.
And if the PM's feature gets implemented first, this PM looks super
productive.

I think if you're an product manager looking to be the best product manager,
_taking credit_ is imperative. Because at the end of the day, your feature is
just paper until it is implemented.

Not being hated, well, that's another matter... I sympathize with the enormous
friction between folks who assign work and folks who finish it.

~~~
michaelochurch
_I sympathize with the enormous friction between folks who assign work and
folks who finish it._

I don't. If you create this separation between the two categories, you'll have
a terrible organization and when it caves in on itself, I will cheer that
process on.

That's why open allocation is morally superior (in addition to working
better). People "assign" work to themselves (without noise) and then do it.
None of this parasitic high-horse management bullshit.

You know how much better the world would be if "work" was a culture of doing
things rather than delegating and taking credit? It'd be a different world.
People might actually, like, work when they go "to work".

~~~
danso
You know how much better the world would be if everyone was good at work? If
everyone had a correct estimation of his/her own ability? If everyone knew
when to defer to those with better judgement?

The world would be awesome. But that's not the way the world is. And not all
well-oiled machines will stay well-oiled...and in such a situation, sometimes
it may be worth it to have someone who manages the process and can play King
Solomon anytime two workers are fighting over a baby.

I'm not sure if the PM role does this well in practice, I'm just saying, I can
imagine such a role in an imperfect work environment paying off.

------
hammerzeit
In what world do PMs actually think the supposed thoughts in this article?
Yes, it's important to document well, focus on why not how, and be a shit
umbrella not funnel -- though these have been PM 101 everywhere I've worked.

But when PMs infringe on these issues (and yes, all PMs do) I find it's rarely
a conscious decision as much an impulsive/instinctive thing from being torn in
100 directions at once.

~~~
marshray
For example:
[https://news.ycombinator.com/item?id=5930324](https://news.ycombinator.com/item?id=5930324)

------
madkins1868
Oh great, another Product Manager/Project Manager/XYZ Manager has pissed off
the software engineering masses post again. Another "we can live without you,
but you can't live without us scribe...". Really? You mean I can't go find a
top notch, $15/hr engineer to build in Kathmandu to build the product to my
specs? Get a hold of yourself boys. You're not all that. I can (and have)
built plenty of products with a wide assortment of engineering resources
worldwide. If you're worth your salt, you recognized that it is the
relationship between disciplines that matters - nt your "Engineers will Rule
the World" mantra. Get over yourselves....

~~~
bdehaaff
I built my career as a PM before becoming a CEO, so this might not be just
another one of those posts. Are there market-leading products that have been
built with lead $15/hr engineers? Please call out a few, I would love to learn
about a few of them.

------
digisth
I'd like to add "Don't give estimates to other stakeholders (especially a
client!) without talking to engineering." Even if you have some technical
expertise, your guess may be off due to a lack of knowledge of the specifics
of the platform, framework, gotchas, other priorities the team may have and a
million other things.

The reality is that you can get yourself (and your team) into a bind if you
commit to an estimate/schedule without discussing the details of what will be
delivered with engineering. Don't do that.

------
bkilgore
What a short-sided article. I actually think it's more often the other way
around--that engineers keep pissing off product managers! ;-)

Part of the problem, in my opinion, is that engineering tends not to give
feedback, as much as they give derision. And product management tends to be
too timid to stand up for themselves.

In reality, we all piss off each other. We'd all be better served if egos were
checked at the door, and we could have open, collaborative conversations about
creating really great products.

------
five18pm
Let me add couple more:

(1) Asking for a feature and then never showing up once when it is being
built. "Hey, we are adding this page here. Is it okay?" <No answer>. "Hey, is
this workflow good?" <No answer>. Once implemented, come around and ask "Why
is this built this way?"

(2) Not being interested in any feature that engineering is interested in.

It is okay to talk to customers all the time, but once in a while turn around
and talk to engineering too.

~~~
bdehaaff
I totally agree. I think the best PMs actually leave at least 20% of their
roadmap for engineers to tell them what else needs to be built.

------
hamburglar
I read most of it, but you really lost me in the first sentence. If you are
_actually_ the CEO, that's one thing, but one sure fire way to piss off the
engineers is to think of yourself as "the boss" simply because your role has
"manager" in the title. Everywhere I've worked, the engineers answer to an
engineering manager, and the engineering manager is a peer to the PM.

------
vijayr
slightly off topic - anyone moved from coding to product management? I
thoroughly enjoy product management - market research, coming up with new
product ideas, feature ideas etc. No clue how to make the transition though :(

~~~
hkarthik
It's a tough transition, but I've seen it done in a few ways:

1) Internally apply for a Product Management job. Expect to have put in at
least 3 years within the company and make sure you know the business domain
better than most other engineers. Play politics successfully and hop on the
first open PM position available. You may have to pick a product in pretty bad
shape as a proving ground.

2) Build your own product either on the side or quit your day job to focus on
it. Make sure it's something a bigger company like Yahoo, Google, Facebook,
Salesforce, etc would be interested in. Make a real go at building a business,
and doing the hard PM work. Hire others to do the engineering work so you can
focus on the PM skills. This may also take 5 years before you land your dream
PM role. If you play your cards right, you may land in a PM role with a nice
exit as well.

3) Go get an MBA from a top school that Google, Facebook, and Microsoft
actively recruit from. Make sure your program has a focus area on Technical
Product Management so you can get into the right recruiting circles. This may
be a faster track, but expect to lose 2 years of income and rack up a lot of
tuition debt to make it happen.

~~~
michaelochurch
This is good advice but the reality of it is goddamn depressing. "Proving
ground"... "at least 3 years"... "MBA from a top school". We fucking lost our
industry. Because we failed, we have to deal with executives.

Product management shouldn't be a special job for high-horse do-nothings with
MBAs and connections. It should be a concern for all engineers; something
everyone should care about and be able to influence.

~~~
hkarthik
Ha! I guess my negative bent around becoming a PM bled through. I have
considered going into a PM role as a future career move but the reality of it
usually depresses me into sticking with engineering.

It is pretty depressing that in most software companies, engineering makes
little to no decisions about features, market strategy, or operational
efficiency. You really have to get out of engineering to have any influence in
those areas.

With engineering being so lucrative, you see a lot of self-selection where the
weaker engineers end up making these transitions, which only makes the whole
situation worse.

------
michaelochurch
I stopped reading here: _Involve engineering management early and often, so
everyone has a chance to contribute to the product vision and buy into where
the product is headed._

This is tailored to people in inefficient VC-istan companies where engineers
don't get to speak for themselves, hence "involve engineering _management_ ".
Ok, we're done here.

I agree that there are a lot of terrible, arrogant PM's out there. PM is the
ultimate MacLeod Clueless job in many organizations (with engineers closer to
the MacLeod Loser tier) because it involves a lot of context-switching and
annoying work, but is ultimately just as subordinate as anything else, since
the job still involves serving executives.

~~~
bdehaaff
Good point. I deleted "management" from the post. The best orgs (and also the
most successful) are those where everyone has a voice. Maybe you will keep
reading now and let me know if anything else in the post really tweaks you the
wrong way.

~~~
michaelochurch
In general, quite good and I agree with it.

Minor nit: (1) you used the term "executive team" and I hate that phrase.
Don't get me started on teamism. I hate this cargo-cult bullshit where every
group of people is called a _team_. Executives are a _court_ , in the medieval
sense.

Also, I still sense that you're writing from a closed-allocation perspective.
(I'm not even sure that proper open allocation would have a PM/engineer
distinction. Why not hire people who are willing to do both?) Closed
allocation is doomed to produce garbage and no amount about of telling other
people to be better will correct for its foundational problems.

~~~
seivan
"Closed allocation is doomed to produce garbage and no amount about of telling
other people to be better will correct for its foundational problems."

I've been thinking on this lately, it does make sense. Never been in a
position to try it until now.

~~~
michaelochurch
What is your strategy for trying it? Are you starting a company?

~~~
seivan
I quit one.

