As a PM, I believe what you're describing is the torrent of people who used to work as "project managers" and "business analysts" who've transitioned into Product for the higher pay, without appreciating any of the differences between the roles.

IMO, the fundamental role of a PM is to make the decisions nobody else wants to (and own the consequences of them). If my team is making progress and decisions are being made, I get the fuck out of the way.

I jokingly refer to myself as the "designated scapegoat", basically meaning it's my job to tank the risk for situations where everyone is nominally in agreement about something, but nobody wants to be the person to put their hand up and own the decision because of the risk if it backfires.

When I started my first PM role, I was lucky enough to work for a boss/mentor who had the same mindset. As a dev for most of my career before moving into PM, it made sense to me:

“If things go well, dev team gets the credit. If things go poorly, PM takes the blame”.

This is fundamental to building trust with the dev team and gaining the respect of leadership.

This made it possible to guide the product in directions the dev team wasn’t immediately comfortable with, because they knew it was my ass on the line. And when those decisions led to good outcomes, it further reinforced the trust relationship.

I haven’t countered many PMs who live by this, but it sure makes a big difference.

Damn I wish any PM I had ever worked with had this attitude. Honestly I don’t recognize any of this ownership in the last few companies I’ve worked with. PMs are just people that don’t talk with customers, review a product backlog, and cover their eyes and point at the Feature du jour. I wish more PMs had your ownership approach.

To jump in front of a bullet that no one wants to be struck by? As a PM, I want my eng team to be courageous and stand by their decisions rather than respecting me only once I offer my self in a sacrificial ritual.

Are they technical decisions? Yeah, sure, that's on them.

But a LOT of decisions in reality are ones where there is no clear "organic" owner. In that scenario, assuming nobody else is putting their hand up to own it, that's the PM's responsibility.

Nobody will ever tell you this in interviews, it's never part of the job description, but it is one of the most important parts of being an effective PM.

Hard agree with this take. Also, a good PM should be technical enough to really understand not just how customers use the product but how the product works. you should be able to be the designated person to answer a question from customers when nobody else knows the answer. In my role as a PM, I'm usually the person the buck stops with for Sales, Support, Solutions Engineering, et al. You can't do that if you don't actually know how anything works, which I see way too much with other PMs in this industry.

As a PM, you unlock a lot of value by getting engineers out of a lot of these meetings, by being technically competent enough (for these contexts) to not need them 99% of the time. It isn't even just about the devs' time either. It is about their focus and reducing context switching too.

100% agree. This is the biggest debate I have with other PM's who say "you don't need to be technical"... Total bullshit.

You're expecting to be able to engage with your engineering team around the relative effort and complexities of different technical solutions... You're gonna need to have an understanding of the underlying technical details.

The way I see it, I don't necessarily need to know how to build the thing (as in, all the implementation details). But I absolutely need to know how the thing we're building works, what all the key moving parts are, and how they relate to each other.

Without that, there's no way I can develop any kind of intuition as to what is and isn't possible, which is CRITICAL when managing expections with customers or internal stakeholders.

Mismanagement leads to failure. Failure leads to layoffs.

We’ve hit industry maturity with ever slimming margins but with management still operating like costs don’t mean anything. If management was doing their jobs they would discover the cost of meetings and ultimately the cost of indecision!

PMs shouldn't have to fix organization dysfunction while operating in Hero Mode.

I'm not a PM, but you are exactly the kind of PM I love to work for.

So many PMs are either over bearing or scared to make decisions; or, the worst, that do both, over bearing and micromanaging all the time and then blames the team when their decisions back fire.

Interesting that you mentioned working “for” a PM. I do believe a healthier relationship is driven by working “with”.

If a PM has time to micromanage the engineers, something has gone seriously wrong in that organisation haha

As someone who studied film/arts I always thought the art world was a disorganized mess. That was, until I worked at some corporate places and realized that in the art/film world you have at least the artist/director with a clear stance towards the project.

A good film set runs like a well oiled machine with an extremely clear division of responsibilities. Decisions can be made fast, because time is of the essence (the sun only shines so long). This is cool, because if I do the camera I usually don't need to worry about anything else. But usually I also don't have to do anything else: For the duration of the shooting, the film becomes all I need to worry about. I get food, I get a place to stay and most importantly: I chose to be there.

Meanwhile in corpoworld there are X meetings with people who don't even know why they were invited, don't wanna be part of it, are not given the time/resources/mental headspace to be there and then corperate wonders why the project doesn't goes as swimmingly as it could. If your people already do two jobs and the project becomes a third, guess what: they are going to avoid doing too much and maybe if you are lucky some poor sap carries that thing over the finishing line alone. But if that is the outcome, wouldn't it have been better to free that person from their daily duties and put them in charge of the project and whom to talk to? The resoueces of the company would have been better spent, the result would have been better, the thing would get done quicker etc.

If you want to take two things away from this post:

- put someone in charge of the project, make sure they want to do it

- Daily cruft is the enemy of projects. Free people from the rest of their duties, even if it is just a day of the week, e.g. "on Fridays Frida works on project X".

How do you evaluate whether someone wants to do a project? If a boss asks, "Do you want to do this project", seems like another way to ask "Do you want to remain employed?"

It’s important for your boss to frame that differently if it’s truly optional.

They can’t leave it at “do you want to do this project?” They need to follow up with, “It really is optional, I won’t be hurt if you say no.”

They also can’t do it with a big decision first. They have to frame small decisions that way sometimes, to build trust that when they say you have the ability to decline, they mean it. Then, they can ask that way on big decisions.

If a decision isn’t optional, they should phrase it a different way. I use something like - “I need you to do this project - how does that make you feel?” I want them to tell me if it’s a hardship, but I don’t want to imply that I’m leaving the door open to a different outcome necessarily.

Establishing a culture where that assumption is not the case and engineers can say “no I’m not very interested in that”. Also a boss that can actually read people (correctly).

After the roadmap is finalized, as the manager I ask every one on my team to stack rank at least N preferred projects from the roadmap. I map preferences to projects with some optimizations (e.g. career progression, avoiding knowledge silos), review it with everyone, and then commit for the roadmap.

If there's grunt work that no one wants to do, I distribute it fairly among the team. Fairly can be splitting it up evenly among the team (everyone refactors _n_ files) and sometimes it means we round-robin the responsibility (e.g. quarterly compliance reviews with auditors). Obviously this depends on the team size and role in the company, but I think it's only come up a few times over ~4 years.

I mean, there is many ways to do that, but one way is to instead of asking a single person you let people apply. For projects that are not as attractive you up the compensation/bonuses till someone is interested.

Then they made the choice themselves and even if the project sucks in the same way, they made the choice themselves.

An important rule of low/no budget film-making is: no mattee who is in your crew/cast, know why they agreed. For an established actor that might be trying out a new or different acting style, a different role, whatever. For the sound guy it might be learning the tools, or going to a certain landscape or some compensation. Know what motivates your people besides the salary and treat that motivation like the most valuable secret intel tou could have ever aquired.

In my experience this is usually a result of misapplying the idea of "consensus". The best formulation I've seen work is "nobody is vetoing". It doesn't mean that everyone agrees, just that nobody disagrees strongly enough to block progress.

I would go even a bit further. For a good consensus to be had, everyone that cares to should have the opportunity to share their opinion and defend it, to provide stakeholders all the viable options. The "consensus" then isn't that we all agree on the "right" option, but that we all agree that the person in charge, after evaluating the options, makes the final decision and we all move forward with that plan without taking any disagreements personally or getting angry if your option wasn't selected.

I'm lucky enough to work in such a team, and it's been fantastic.

A good way to approach this is to think like a military: there might be a staff, but there is only one commander in the unit. Their whole job is making the right decision as quickly as possible and assuming responsibility for it.

If the manager keeps avoiding making decisions and diluting responsibility, they aren't fit to be a manager.

I’ve used this analogy before but people hate it. on internal projects at my firm everyone wants everyone else to have an equal voice out of guilt. The meetings and navel gazing never stop and the work becomes working on the process and never actually delivering on the need.

With client projects it’s different, you have a budget and deadline. Miss it or screw up on the way and the client fires you and hires your competitor. My client delivery teams are a much harsher environment but roles and responsibility for decisions are very clear and everyone’s job is at stake so it gets taken pretty seriously. There’s no room or time for consensus building, the flip side being owning a bad decision means working somewhere else.

Oh, it's important that everybody has a voice. But it should never be equal, making it equal almost guarantees the project will stop.

Making sure everybody has a voice is a task for the people that actually have power there. The other part of that task is cutting those people down and overruling them when needed.

> and suddenly nobody can even identify who is the decision maker.

For management more interested in playing politics, this kind of ambiguity is a feature, not a bug. This is how you take credit for successes, and shift blame for failures.

I think weak leadership is the default, with a micromanager trying to own everything as an over-correction coming in as the runner up.

I've worked across 18 companies, and about 2-3 times I've been given a person to onboard me, once we had a decent central wiki, and the rest of the times I've basically been left figure it out.

I don't even think these things are overly hard to figure out, but very few people in tech straddle the lines between tech and org, and when they do, they're usually kept at bay by the non-technical tech roles ( deliver manager, etc ).

This is a great take.

In my limited experience, you have a real problem if the dev team hijacks what will be done and how it will be done. There is a good chance your product is going to be over-engineered, difficult to steer and all the minor but important details will never get done/corrected because hey, lets build another mammoth worthless (in business terms) functionality.

I also saw powerful product managers get support from higher-ups and then shovel their ideas down the throat of engineering orgs. A PM in Uber's Marketplace org used to create and present a brand new architecture for the entire Uber's marketplace. It was not concrete enough. It didn't really convince people of what problems to solve. It was not even a good architecture (maybe it was, but at least few people got convinced). In fact, the presentation didn't even get many questions but hundreds of blank stares. Needless to say, the architecture was not implemented. It was nevertheless quite a humiliation to the marketplace's eng org.

Saw this firsthand when I worked at Nokia. It was consensus building taken to extreme levels, resulting in having 7 different UI toolkits and 4 developer platforms. Absolute hell, but very polite and conflict-free.

I don't think consensus-building is necessarily bad on it's own. Depending on the environment, when people don't feel like they have an opportunity contribute, it can potentially lead to other issues.

To your point, I think a lack of leadership can kill a consensus-building process. Whoever is coordinating needs the authority and will to end the discussion when the time is right (among other things.) Otherwise, it really can become endless debate and drawn out attempts to get some unwilling party onboard.

> I don't think consensus-building is necessarily bad on it's own.

Making decisions based on consensus is just often not the right choice in this context. If used for the wrong type of decision, it will lead to a "design by committee" type of process and result, driving a lot of people mad along the way.

A better way to make decisions in a software project is to consult with stakeholders (if necessary), identify the appropriate decision maker based on competence and then let that person make a decision.

> A better way to make decisions in a software project is to consult with stakeholders (if necessary), identify the appropriate decision maker based on competence and then let that person make a decision.

Holy shit. This is one of the most profound things I've read about management in a long, long time.

> I’ve worked with some product managers who produced prodigious amounts of meetings and slide decks and Figma charts and process documents and Notion pages and after meeting summary e-mails but can never actually conclude what we should build.

Spot on. If I could have all the years wasted through this back, I would be a young man again. In my experience, these are product managers that have never actually been involved in building anything.

Also modelable with Storming/Forming/Norming/Performing

Except every time you add someone new, it slips back to a prior state - and every time the group gets bigger, it takes longer to ‘settle’.

Eventually, roles/ownership/structure. needs to be codified, or the group never ends up actually performing - and if not done right, that won’t happen even with that.

I once as team lead had to preside over a product designer and senior dev (who used to be a CTO at a tiny startup) who never saw eye to eye, but the designer always had the final say, (unless there was a good technical reason to do something differently), because that’s what she was in charge of

I think there's a reason why historically many cultures in a time of crisis tend to choose a leader to take responsibility until the crisis is dealt with, like the dictator in republican Rome. Pirates often elected and even unelected their captains, but during any action their power was absolute. And so on.

> So we're better with benevolent dictators.

Making a decision based on input from relevant coworkers while being competent in the domain you are making the decision in isn't exactly dictatorship?

This and, especially if the decision maker made it to their level based on merrit.

> This and, especially if the decision maker made it to their level based on merrit.

Assuming a competence hierarchy, that should equal competence. Unfortunately, oftentimes it's not a competence hierarchy. In those cases, it may take some time to trust in someone's competence.

Yes, undoubtedly. Although once appointed as a dictator the benevolence part normally slides.

So what happens in the happy case is a very complex system of figuring out who should be the dictator and when they need to be moved on. If you look at successful open source projects that process is often visible - a brutal communal negotiation (of global scope!) to work out who in the world is the person with the best motivation to control a project.

In the spectrum between consensus and dictatorship, there’s also democracy.