Hacker News Reader

My team was product managed by a gutless PM who essentially made senior devs & tech leads do all the legwork.

Requirements gathering, mean user upset about a bug, weekly status call, need to break some bad news re: priorities? - send a senior dev or tech lead. Skipped most of the agile ceremonies too, busy guy. Never wrote or edited a JIRA ticket, that was for tech org to manage. He PMd 2 other tech teams the same way.

Tech leads/senior devs knew our PM was bad news from his first week but he outlived all of us until finally getting hit with a RIF after 4 years.

Management worshipping at the throne of agile become really enthralled with these guys and can derail an org for years. In theory a PMs stakeholders are the users, but in practice it is buffing the egos of the senior management that hired them. Can become a self reinforcing closed loop between senior management / agile consultants / PMs.

> Management worshipping at the throne of agile become really enthralled with these guys and can derail an org for years. In theory a PMs stakeholders are the users, but in practice it is buffing the egos of the senior management that hired them. Can become a self reinforcing closed loop between senior management / agile consultants / PMs.

Beautifully put!

This was the way in almost every place I've worked. If you did a good job at managing upward and schmoozing and stroking the senior management's ego, and had those smooth "ivy leaguer" mannerisms, then it didn't even matter if you did your job. You were the Golden Boy and destined for greatness. But if you were too busy actually doing your job and didn't properly pet your management chain, you were setting yourself up to be the scapegoat.

This is exactly the problem. If you do your job as a PM, you get pushed out because doing your job means you'll be ruffling feathers in senior management. So to stick around, you schmooze instead of doing your job because doing your job properly invariably pisses off management at some point

> He PMd 2 other tech teams the same way.

I'm with you that all of this is bad PM work, but this seems to be the root cause. I've been at a startup like this where there weren't enough PMs to start and then a couple left, which just led to the rest being stretched across more teams.

You just can't do much of anything useful in this situation - your existence consists of preparing for and attending stakeholder meetings. I guess some people thrive on the pseudo-glorified existence of "managing" a bunch of different teams, but I found it to be as miserable as you seem to have found it from the eng side. I was there to spend time with customers and designers and engineers, and after a few months of doing none of those things, I quit without a job lined up.

Once you get to that point, it can become even worse because you end up in this doom loop of management realizing that the core PM work is getting delegated to eng, thinking that this means they don't need as many PMs and then delegating more work to eng.

> Once you get to that point, it can become even worse because you end up in this doom loop of management realizing that the core PM work is getting delegated to eng, thinking that this means they don't need as many PMs and then delegating more work to eng.

At least that is better than eng doing the PM work and the PM getting all the credit for it.

Exactly. "Oh no, the team doing all the work and covering for the other team is going to get the incremental resource increases".

Yes. If a team is incapable of either doing their job or in advocating for needing more resources to do their job, then they do not get to have more resources. Particularly when another team is covering for this gap, typically, engineering.

It never goes the other way right? How many times are PMs picking up JIRA tickets, handling bug fixes, joining on-call rotas, etc type tasks that engineering does?

If non-engineering roles/orgs are created to take load of engineering, and are incapable of doing so, then they need not exist. This goes for DevOps/CloudOps/SRE/Support/QA/Product/Project Mgmt/etc.

You can run a lean startup consisting entirely of 3 engineers. But you can't run a lean startup consisting entirely of 3 SRE/QA/Product/whathaveyou.

This is not a knock on these other orgs/roles. In a well functioning shop, they are essential. But when orgs like Product forget that the tail doesn't wag the dog.. bad things follow for everyone.

>But most of them seem to think they can operate entirely in document-land and just crank out roadmap docs and keep stakeholder alignment via endless check-ins and nagging. They are doing a "project manager" job instead.

Ok, maybe I came to the wrong place to say what I'm gonna say because I guess that a sizable part of the demographics here works in hot, meaningful projects, but as a corp worker for the last 8+ years, it has been my experience that a lot of companies have products that are used either internally by their own employees or by another corporate client that still pays for them out of inertia or because there is just too much custom business logic that now it's too costly to replace them.

In both of these cases we're talking about uncompetitive products that are probably going to remain so before being discontinued. And in both of these cases companies will try nonetheless to create a SCRUM-like arrangement with PMs and POs and behave like they are building a revolutionary product, urgent taks and pressure for results included.

It has also been my experience that in this kind of environment normally PMs and POs will be fully invested in doing politics to try to climb up the corporate ladder without much concern about what makes a good or usable product. They will steer the project in whatever direction makes them look good to the administration or the client at the cost of creating a fragmented product that many times looks like it's doing a random walk in terms of functionality and improvements.

I'm not old enough to know how things were built in the 60's/70's/80's(no SCRUM/PM's/PO's I guess) but the catastrophist discourse that there's a deep slowdown in productivity compared to the previous decades and that today we're mostly relying on things we already did in the past maps pretty well with my perception.

>but the catastrophist discourse that there's a deep slowdown in productivity compared to the previous decades and that today we're mostly relying on things we already did in the past maps pretty well with my perception.

Mine too. Any ideas why productivity has slowed down so much? Is this a software online observation, or more of a wider pattern

With software I guess part of the problem is that there's a lot of diminishing returns, with it being much easier to just crank out some initial prototype that does a lot, then it is to adjust some spaghetti mess that users deeply rely on. But that should only really affect individual projects, not necessarily the industry as a whole

>Mine too. Any ideas why productivity has slowed down so much? Is this a software online observation, or more of a wider pattern

It's a wider pattern in fact:

"The productivity paradox, also referred to as the Solow paradox, could refer either to the slowdown in productivity growth in the United States in the 1970s and 1980s despite rapid development in the field of information technology (IT) over the same period, or to the slowdown in productivity growth in the United States and developed countries from the 2000s to 2020s; sometimes the newer slowdown is referred to as the productivity slowdown, the productivity puzzle, or the productivity paradox 2.0."

https://en.wikipedia.org/wiki/Productivity_paradox

this compares apples to vitamins in a way -- what is possible and what is expected have changed so much in thirty years for office and information work, that reducing it to a pair of numbers seems ridiculous

> Mine too. Any ideas why productivity has slowed down so much?

It's not exactly a new idea:

> The term "software crisis" was coined by some attendees at the first NATO Software Engineering Conference in 1968 at Garmisch, Germany. [1]

As you can see, people have had the perception that it's harder to crank out software than before for a long time now. The reality is that we're collectively vastly better at it than we used to be, and that what we're trying to do gets harder and harder. No one is paying for the kind of productivity software dev had in the 2000's, and no one will be paying us 20 years from now for doing what we do now. Except if maintaining older software that yields value - in which case, well, maintaining and expanding a brownfield is always harder than greenfield.

[1]: https://en.wikipedia.org/wiki/Software_crisis

I'm a PM (I now exclusively look for the 'technical' qualifier before any role I consider) -- I could not agree more with what you wrote. The last paragraph particularly.

Lately, I've been responsible for mentoring other PM's. Sure there's the widely shared roadmap, but also -- I can't tell you how many documents and sheets are created that are literally never seen again by anyone other than me, and I get the feeling were created to demonstrate that they are working. It's a habit I try to break.

The reason I advocate for technical product management so strongly is I've (over)simplified the problem in my head to be that some PM's are stuck at that high level of abstraction because they're unable to communicate with their teams on the detailed technical matters on a daily basis. So they end up in a weird grey area of project/product management.

> documents and sheets are created

That sounds terrible and predictable. Data managed by a PM should be managed and presented in the same product dashboard used by everyone else.

When they can't use git and find project tracking software too complex to understand, this is what regularly happens. Either this or charts and tables in Miro/Figma boards.

This is too cynical IMO. Documents are actually the correct tool for some kinds of thought and communication. Issues are different, Miro/Figma boards are different.

> Issues are different, Miro/Figma boards are different.

In practice over the last year, I've seen product managers make Gantt charts in Miro as the source of truth for a project and run backend engineering retros in Figma. These were done redundantly with our issue tracking system; my cross-functional team had to create issues in our tracker based on the Miro and Figma boards to actually manage our own work, then duplicate the updates on those boards to communicate them up to product.

> they're unable to communicate with their teams on the detailed technical matters on a daily basis

Yeah, I've had PMs who've ground backlog grooming sessions to a halt so engineers can explain in detail what each one is, or shared incorrect information about a bug fix or new feature to a technical writer for release notes because they were so confidently incorrect.

The PMs with enough aptitude to understand and explain what the engineers are doing, even if they're not actively participating in implementation because they're applying that knowledge to broader strategic/roadmap decisions and cross-team coordination, are the best to work with.

That’s what happens when you hire a full time person to do what should amount to 8 hours a week. They go looking for ways to show value, and often that just causes everyone else to have more work too.

Usually it’s places where the projects are plenty small enough for the normal manager to handle it but they’re lazy and want the TPM/PM to be their secretary.

Having been a PM (now developer) the problem I faced was half the time I was having to provide documentation, communications and evidence for my managers. Which is of course fine but when you have HIPPO syndrome (HIghest Paid Person in the Office) who likes to make product decisions then you have to spend most of your time covering your back and managing up

PMs get a lot of stick, sometimes justified, but they're just having to play office politics in order to get stuff done

Yep. And then you leave and the engineers start complaining they have to play office politics to get things done. :)

PM->Dev is not the typical trajectory, although it's one I'm considering.

How do you feel about the transition?

My experience (FAANG) has been the opposite. PMs want to dream up features and put together a roadmap and then they think their work is done. A great PM is both creating a vision or plan and guiding the execution and iteration. The plan is the 20%.

> But most of them seem to think they can operate entirely in document-land and just crank out roadmap docs and keep stakeholder alignment via endless check-ins and nagging. They are doing a "project manager" job instead.

They are not managing product, they are managing stakeholders

Mainly internal stakeholders, I take it. Isn't all that entirely big-company politics?

Whereas a PM in a small company can devote more attention to the product, customers, market, metrics.

What's a good question to ask to find out which sort of animal you're dealing with?

A great way to solve for this in B2B, is to hire a customer and train them as PM. They will hit the ground running much faster to bridge the gap.

Just so I understand, the best way to hire a product manager in B2B is to poach the employees of your customers?

A more charitable interpretation is poaching ONE such employee out of all your customers. It's not a criminal act, IMHO.

Managers of any company that think they can't afford to lose a single employee are doing something wrong and should google "key man risk"

My org tried this, but being in financial services no one thought through this problem - our customers are much better paid than any PM we could hire.

That is to say, the only customer we could convert to a PM was one who was fundamentally bad enough at his existing client side job that he was OK capping his income at 25-50% of his potential.

Doesn't it go in the other direction too? Any PM you can hire can probably make more in finance?

Well yes but that's why I think "we'll just hire a typical user as a PM" isn't really a solution.

It also doesn't give them any training in how to PM.

They should just be someone technical enough with enough people skills and familiarity with user use cases to bridge the gap.

That's why the best PMs have some kind of engineering background or are former eng. As small as it may be it is a requirement nowadays.

I've always found PM's that come from a UX/Design background to be more willing to engage with the actual people we are building software for. IME, it's always been BA/MBA types that want to draw up documentation and then chuck it over a wall (development) and call it a day.

I've worked with dozens and dozens of PMs over the years and almost zero of them do this. Most of this is always done by product designers.