Product Managers, Stop Pissing Off The Engineers
blog.aha.io
blog.aha.io
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.
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.
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.
Whatever. I like the article, it makes some good points.
It's hard to write an article explaining one side of a situation like this without 'taking sides'.
I think the the PM role/title has become such a generic position that articles like this one are really taking a stab at anyone non-engineering, not that I am upset by it.
As a startup founder, meshing technical teams and non-technical teams is extremely difficult to do. The work environments, thought processes, personalities, etc. are so different.
> 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.
There are no "one PM shops".
Case closed.
Product managers are an extension of people's normal employee workflows but expanded for coordination and communication, however there's nothing preventing the PM from exercising minimal responsibility on things like product design and whatnot.
The worst ones: I wrote the specs. Instead of talking about technical stuff, I have to explain why something like "getting cache coherency right" is going to cost three or four days, and that no, I can't go to another scheduling meeting right now, didn't we have one yesterday?
The best: Shields.
The worst: "Why isn't that bug fixed? I'm going to call a meeting about that bug at 4:00, and I want it fixed by 5:00" [seriously. this happened]
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.
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.
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.
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".
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.
Other people aren't very good at estimating what something will cost in terms of time or effort.
It's actually pretty rare to find people that assign themselves tasks and follow through on them. If you have an entire organization made up of people like that, awesome; it's the ideal, not the norm.
It's important to remember that you are only a leader if people choose to follow you.
Otherwise, you are just leveraging your position, and that's probably not a good long-term strategy, nor is it the right thing to do.
Credit means much more when it is given, not taken.
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.
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.
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.
(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.
Become [executive's gender of interest] and learn how to sit on a desk.
Are you fucking kidding me? I don't have enough karma to downvote you, someone please do the honors.
That said, if you don't think 95+% of workplace favoritism is based on sexual desire, you're misled. That's especially true in the non-technical/subjective roles where ability is so hard to evaluate.
Most corporate executives did their 20s wrong and want to Feel Like A (Wo)Man now that they're older. Which means that for non-tech/subjective proteges they tap either (a) young, attractive people of the opposite sex who give them a "hip" image, or (b) unscrupulous young men ~20 years their junior through whom they live vicariously.
Yeah, that's bullshit. Maybe in certain sectors, but unless you have something to back that up, I'm calling bullshit.
Experience.
Larger companies tend not to be that way, though. I saw a ton of that stuff in VC-istan, but none at Google or in the banks.
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.
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.
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.
A good advise for one who wants to do the transition would be to just to dare to dream. Suggest products, get involved in all stages of the product's lifecycle. Be proactive, and after a while go and ask to be a PM. It's not a promotion as PM are not superior to devs (except from me). It's like a new role in your career, much different from a programmer.
In addition I would strongly suggest to build something on your own. Just do it, and you will learn a lot about specifying a product, about marketing, about managing the project of your own. If you come with this on your record, you are like 100 times in a better position.
Forget about MBA. It is useless and just dumb to do it. Go get some good books from Amazon, read 37signals series and other books which Amazon will recommend you in this area. God forbid the missed souls of the MBAs, but there is a reason Google don't hire them.
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.
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.
I've been thinking on this lately, it does make sense. Never been in a position to try it until now.