There’s no justification for it to exist. It’s like saying every bus needs a steerer and a gas pedal pusher. This is worse than a single driver, but hey it creates another job
DB specialists are make-work too, unless you are working at AWS or some other massive provider. Architect is also make-work. Someone who makes technical decisions and orders engineers around but doesn't code. LMAO.
I worked at a large telco, between prod and dev and test we had a couple of hundred oracle dbs running, plus probably that again in vendor supplied odd custom stuff.
DB Specialists were essential.
We also had an architect who was trying his best to keep track of everything, design the future and attempt to keep in all almost sane. It was a ginormous mess. Without him it would have been utter chaos.
The value of any given role depends on the org and context and situation
Yes, and i have seen teams working entirely without a formal backlog of user stories. Some use a large wall chart, some use a User Story Map without any kind of Scrum of Kanban process... in some teams this also works.
They are cheap and useful if you have sufficient time to read, especially the ones about team structures and recruiting. They contain more content about roles and structures.
It's about product management, leadership, engineering organizations, and related topics. I still consider it personal because all of the content stems from personal experience.
And yet, software product managers mostly do not have managerial authority.
They manage the product, not the people. But they need to influence the people anyway.
It could be email, but it also be Confluence, Notion, OneNote, or something like that. I understand that you think a chat solution like Slack or Teams or Mattermost is too "chatty", right?
or a dev server and you then you can deploy qa server or staging for load testing, integration testing if you have multiple sub systems. and testing for load balancing type issues.
I'm not arguing against more flexibility when your in small team /pre or early release MVP stage(s)
Also, you need a "Hot Fix" short circuit process as well. Although you need to watch it and make sure management is on board with the idea that a reliable road map is important and specific criteria for urgency or everything turns into a "hot fix".
Note: I am a product manager myself
I see the team of PM, Engineer, Design, Data, etc. as one team consisting of people with different skills.
The skillset of a PM does not include coding, but it helps to have some technical understanding to discuss on eye level. The skillset of a software developer does not include user understanding (for example), but it helps to have some idea of user situation to discuss on eye level. If all functions understand what the others do, the team will be successful.
In my opinion, your experience of product managers sounds like people with poor understanding both of the job of a dev and of the job of a PM. No blame.
