Hacker News Reader

Comment by seivan | Hacker News Reader

The problem isn't PM's know jack about code. The problem is the set where a PM would even be required. That means there's a structural flaw in your process.

The idea of having a project manager is ridiculous. People _should_ manage themselves and take ownership of the project. Making the PM useless.

View on HN

That's probably why, when building a skyscraper, modern construction practices dictate that all the subcontractors just "do their own thing" and sort out with each other when it's OK to put in walls, pipes, wiring and structural alterations.

The N^2 communication overhead is OK, because PMs are just useless overhead anyway.

I heard sometimes building projects fail because the PM only understood what was supposed to be happening and who was responsible for what, as opposed to having advanced plumbing, HVAC, electrical and structural engineering knowledge.

</sarcasm> (I don't usually resort to it... promise...)

That would be great if software were exactly analogous to building skyscrapers, and developers were idiot construction workers who do nothing but put the sheetrock and nails where they are asked.

(Note: I am not saying that construction workers are idiots, I am saying that programmers are not idiot-construction-workers.)

There is not just one way to organize a project.

Construction workers and programmers are both tradesmen, for most values of the word. I know you added a disclaimer already but I figured I'd just emphasize the point.

PM is a team function, that of (in a nutshell) managing and tracking resources and tasks. It's also a field of study, and optionally a job title.

At the level of abstraction of PM, software is exactly analogous to building skyscrapers, building a rocket, producing a theatre production or capping deepwater horizon.

You are right that there is not just one way to organise a project. However, if the project is being organised at all, at least one person is doing project management.

It's just that the acting PM(s) may not be formally trained it in, or have "PM" as their job title. That's fine.

Code is the sheetrock and nails of software business.

Programming is a lot closer to drafting a design for a building than actually constructing it, which is more akin to compiling.

Works great on small projects, does not scale to very large projects. There is a non-zero amount of communication, scheduling and cross-team coordination that needs to happen. If you want developers to do it, that is fine, it just means less development time. If you have never met a good PM it is easy (but intellectually lazy) to write off the discipline. Once you have worked with a good PM you realize by off-loading that drudgery (well, drudgery from a dev perspective) everyone wins.

Agreed. However, I think a lot of the PM hating arises due to PMs who think that just because work flows through them to the customer, it's ok for them to take credit for it. I've dealt with inefficient PMs, and I can live with such people, but PMs who use their job as an expression of their inner narcissism are a different story. I think the latter motivates people to take up torches and pitchforks more than the former.

Speaking as a technical lead with a decade and a half of experience shipping web products solo and with small teams never exceeding 10 people, I can assure you that there very much is a place for a product manager in a great many products. In fact we just hired a product manager and it's a huge weight off my shoulders. Requiring all developers to be responsible for strategic thinking at all times is at odds with low-level focus needed to ship great software. A good PM is someone developers can trust to have the high level picture in mind at all times so the devs can focus on the necessary details.

I believe he's referring to project managers, not product managers. The latter certainly have a crucial role in understanding how the product fits into the market, and undertaking the kind of strategic thinking you're talking about. The role of the former, however, is usually to manage work scheduling and intra-team coordination, which, the OP is arguing, is something that programmers can generally handle on their own.

There's a place for PMs. If you're willing to step into shoes other than your own, start by reading PeopleWare [1]. And then dig into the origins of self-managing Scrum and have a read through Takeuchi and Nonaka's paper[2].

When you're done, I'd love to hear your thoughts on PMs, and why we're still making the same mistakes we made, and wrote books about, 30 years ago.

[1] http://www.amazon.com/dp/0932633439/

[2] http://hbr.org/product/new-new-product-development-game/an/8...

Perhaps he's referring to a product manager - who if he's doing his job right is the guy with the deep domain expertise who spends his time talking to customers instead of dealing with project-management administrivia.

I do know lots of developers who don't think there should be product managers either - but in my experience they either have incompetent product managers or are working on a developer-centric product where they themselves have the domain expertise they need.

That might work if the "project" is full spec'ed and defined as if it were the output of a Waterfall design process. I can't imagine that most projects are actually like that, though.

Having a good PM ensures that when ambiguities arise, they can be solved in a single way to allow those doing the coding to continue on unaffected.

Having 10 different people "take ownership" of a single project is itself a recipe for a different type of disaster.

How the project outputs will be produced (the supplier in PM lingo) is only one aspect of the project. Projects typically have an associated business interest, and users who will use the products produced by the product.

Certain resource roles (e.g. business analysts, UX specialists) can provide advice on the impact of decisions on the business case and the users, while others provide technical input, but project decisions typically cut across more than one of supplier / business / user interests, and it is in the interests of the business to ensure that someone can integrate the requirements of all three.

Having a project manager (or equivalent role such as an agile 'Scrum Master') is not incompatible with employees taking ownership of the project - decisions that only affect the supplier, or fall within ranges that the business / user is happy with can be taken by the suppliers. Often, the PM's role is to facilitate agreement between the different stakeholders.

It is possible for the PM role to be shared amongst the suppliers, but it is not usually a good idea for a big project, because being a PM is a specialist area in its own right hat developers have to learn separately from their specialist technical skills, and spreading the role across too many people can mean that context switch inefficiencies mean the PM role doesn't get carried out.

I used to have this attitude and then I realized that the vast majority of people cannot manage themselves.

If you have a small startup you can probably only hire people who can manage themselves. But as soon as you want to grow big, that becomes very very difficult.

Unless you're Valve, who apparently has been able to do it =)

Reply on news.ycombinator.com