We used to have a QA manager to tag team with, but they got rid of QA and we happily obliged. Once in a while you could rely on the operations/IT people for this, but we are trying to get rid of them as well.

So far this is really working out well for managers.

> if they endanger the product in a way only engineers can understand

If you have critical risks that only engineers can understand, then you have extremely poor engineering leadership. I can’t think of any examples critical risks I’ve encountered that couldn’t be communicated concisely to non-technical stakeholders.

> If you have critical risks that only engineers can understand, then you have extremely poor engineering leadership.

Or extremely incompetent PMs. I've had one PM be confronted with the documentation of something where it clearly said "don't do this, it's wrong and will ruin everything" (which, totally by coincidence, is what he was told by someone on the team before). He still demanded it to be done because he had heard a talk at some conference where that was recommended. It took getting the CEO into the issue via back channels to clear that out.

Imho the percentage of PMs, POs etc that have no clue what they are doing is much, much higher than in any technical role. If they're good at bullshitting, they can usually talk their way out of being blamed for their failure and switch to a different company later.

But you’re not talking about a risk that only an engineer can understand. You’re talking about a risk that somebody else in the organisation is trying to hide from their own boss. Which is a completely different thing.

For every position, there is a chance of a bad hire. PMs are no exception. Every productive employee has a chance of losing motivation and start underperforming. Again, PMs are no exception.

You organization needs ways to detect and "fix" situations caused by a person not living up to their role.

Balance of power between product and engineering is one of such circuit breakers.

A balance of power between engineering and product ownership is a terrible idea. The role of engineer doesn’t necessarily require any understanding of the customers needs. If you have an engineering team that understands them well, it’s either because of competent product ownership, or it’s a complete coincidence. Engineering should not have control over what is built, or have the power to override product owner’s decisions. Product owners should not have control over how things are built, or the ability to override engineering leadership’s decisions. They’re simply different areas of responsibility, there is no need at all for a balance in power between the two, and creating one for the purpose of avoiding bad decisions is just as likely to be used for avoiding good decisions, or decisions that conflict with somebody’s personal taste or political objectives.

Deciding what to build, and for how long, indirectly dictates you how things are built.

Deciding which engineers should have a career advancement also influences how the product is built.

It sounds like you’re describing your own experience of office politics more than anything relating to the roles of product and technical leadership.