3 ms·

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 yo

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 13y ago
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 13y ago
  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-roadmapping-how-to/ http://blog.aha.io/index.php/goal-first-a-product-roadmappin...
bdehaaff 13y ago
Thanks for the thoughts. I wish we had started Aha! (www.aha.io) earlier and were writing on PM topics like this when it would have been useful to you.

jmspring 13y ago

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 13y ago
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-roadmapping-how-to/ http://blog.aha.io/index.php/goal-first-a-product-roadmappin...

bdehaaff 13y ago

Thanks for the thoughts. I wish we had started Aha! (www.aha.io) earlier and were writing on PM topics like this when it would have been useful to you.