351–360 of 370 posts
Earlier quoted context omitted.
Once you get to staff+ level, engineers are no longer hired mostly for writing good code.
That’s fair, but that is… what, 1% of all software engineer hires?
Earlier quoted context omitted.
Having one product owner is fine. The problem is that it should be a role someone moves into from one of the disciplines involved. Design, engineering, domain expert etc… Now we have Product Manager orgs with Associate PMs, junior PMs, senior PMs, group PMs etc… A junior PM almost by definition can’t be a product owner. They don’t have the seniority to make decisions, so what you end up with is a situation where seni…
Product Owner and Product Manager is not the same, especially in a larger organizations. Product Managers usually dont manage sprint backlogs, as its too fine grained. I often see sprint backlog that contain 20+ stories that add up to 1 customer facing capability/feature.
I mean product owner as in the person responsible for the product.
Earlier quoted context omitted.
> Very few engineers want to maintain relationships with customers That’s what CX is for. > interview users to identify potential features That’s what designers are for. > manage leadership, play politics for resource allocation That’s what your lead/people manager is for. You don’t need a PM. You need an org chart.
> That’s what designers are for. Designers interview people, and potential features may come out of that. They don't put those potential features into a roadmap and allocate resources to them. I'm a designer: if it were up to me, I'd spend 99% of my time improving the UX of the product we have, because that's what I care about most. Somebody has to own the vision for the product with respect to the company's business…
That kind of depends. The product-minded ones (who are naturally interested in the "producty" kind of work) are excellent people for that. So you may find that in some companies the people doing product work are either engineers or designers. I've often done that from the engineering side, and I've seen it done really excellently by UX designers too. In other companies you may have dedicated people.
In my experience, whether it works well or not is less a function of how the roles are divided and more a function of whether the individuals doing product work are good at product work (which is difficult to find, even when they are dedicated product specialists). I think I would probably argue that due to the nature of the job being a lot about connecting different functions of the business and synthesising into a coherent whole, product people tend (on average) to better at their job when they do also have experience with at least some of the other roles they are interacting with (although this isn't necessary to do the job well).
Principal Product Manager here. I agree... Way too many people took advantage of this role over the last 20 years, IMO, in the name of FOMO. Too many I avoided or fired because they just could never, never, understand the tech. I wont hire a PM now that isn't also a contributor during work or in their spare time. Not only should they be excellent leads, they should be able to get down and dirty actually move the need…
We frequently assume that if someone has no specialty then they must be a generalist. There is the freshly minted MBAs who did a two year consulting stint out of school who is familiar with many topics though they are clearly not an expert. There is the person with a degree in the humanities who claims that they are a generalist just because they can't do math and never tried to learn javascript. There is the engineer who is not very talented and tries to push their way into management since they are great at scheduling meetings when everyone else was too busy doing the actual work.
This is not to say that an MBA or an MFA are not great degrees. It is simply to say that they are not enough on their own. One needs to actually do things - a lot of things. Real generalists developed their skill set through their own hard work over a long period of time.
There is a function many (though not all) software teams need whereby someone understands customer needs, prioritizes them, and translates them into something that can be worked on by developers. We call that role "Product Manager". Do you strictly need an MBA who has some specific certifications to do that? No, of course not. A very strong UX researcher could potentially do it. A very strong engineering lead could potentially do it. But for many products, it requires a significant time investment in understanding the problem space, guiding a UX/UI research/design team iterating through solutions, and documenting it in such a way that a dev team could approach it.
As someone else commented, the article is just "Hiring bad leaders is bad".
Earlier quoted context omitted.
Some of what you described in the comment I replied to fits the description of complicated company-spanning project management - a valuable role I have typically seen referred to as "program management" - but some of it, the team level dealing-with-task-backlogs type stuff, are things that managers and team members can just do in the course of their work. But you're right that my comment focused only on the latter th…
There is certainly a distinction between teams just dealing with their task backlog and project management. I wouldn't waste a project manager on that. Program management is a level above project management as you say, coordinating multiple projects. But there is definitely a space for complex single projects (not programs) that still require detailed planning and coordination. It's not really about personal preferen…
(I get it, sometimes the need for a lot of planning is imposed from the top, like if you sign a contract with an immovable delivery date, but I think most organizations should do whatever they can to avoid doing that, in order to enable them to structure projects flexibly and have small mostly-autonomous teams.)
I think the personality thing is important both in terms of contentment with your work (and thus which organizations and projects you choose) and in terms of how you analyze the relative value of things when evaluating trade-offs between the different things an organization can invest its time and resources on.
Earlier quoted context omitted.
> Very few engineers want to maintain relationships with customers That’s what CX is for. > interview users to identify potential features That’s what designers are for. > manage leadership, play politics for resource allocation That’s what your lead/people manager is for. You don’t need a PM. You need an org chart.
A product manager works at a higher level than those roles. They aren't implementers - they collect information, identify needs, create plans, and get approvals. And then direct the roles you mentioned to do the work needed. A PM will say things like: "I spent 120 hours talking with our users last quarter. They want a macro language added to the product to make their work easier. Our major competitor already has this…
It sounds like this person has worked with some truly mediocre product managers. I’m a PM, from a self-taught engineering background, and I’ve worked with many mediocre folks too across all disciplines. I view my job primarily as risk management. A great team of engineers and designers will face a huge number of risks to shipping great products, like not having the right skill set to articulate their vision to get ot…
A good PM creates an environment where engineers like OP thinks the PM is not needed because “PMs do nothing” or whatever. It’s short sighted and frankly insulting
Earlier quoted context omitted.
> In my experience, the vast majority of PMs could not describe the difference between TLS 1.3 and 1.x. Does the vast majority of PMs need to tell the difference between TLS 1.3 and 1.x? I mean, is that a relevant aspect of the vast majority of products? If not, why should a PM bother about irrelevant details? One of the cardinal sins of proponents of this "engineers should rule everything" mentality is failing to te…
> If not, why should a PM bother about irrelevant details? Because engineering failed to consider these details. Now I'm the one that has to point out how amateur we look when in some areas we don't require TLS and others we're so strict, we only have 1.3. Engineers (management or rank and file) who can't understand why this is a problem is exactly the reason you need technical PMs.
I don't think you got the point. The point is that no one cares, or think it's important enough and much less critical to justify wasting time with it. Product Managers are there to create value, and spending time on things no one notices is not how you create value.
Earlier quoted context omitted.
yeah +1, I used to wear the product manager hat in an engineering role, while working with bad product managers, and so I thought the role was a grift at best. Also dealing with a herd of b2b clients sucked while trying to focus on doing the things we argued about / committed to doing. Then a good PM got hired, he actually understands what's going on / makes the effort to learn, and the life of "Engineering" roles go…
Yeah, the problem is that accountability for PMs is usually missing. No one checks whether the PM is adding or removing effectiveness, so the good PMs go unrecognized and the bad ones keep siphoning energy from the project. Second, bad PMs just create unnecessary work for everyone around them. Everyone believes they just have to do what the PM says, and then suddenly you have a whole eng team contributing nothing.
It sounds so ridiculous, and yet ... it happened.