What you're describing is exactly the opposite of every actually successful team I've seen, and describes every mediocre team I've seen. Silos are death and not just in a code base. Good developers understand the product. Mediocre ones churn out tickets mindlessly.
I'm okay with that knowing those developers are doing two jobs for the pay of one. And most products turn into that once the original developers leave.
It's not like you can't learn the product through the PM either.
I think you're conflating "doing two jobs" with "not being allowed to just type JavaScript into a computer all day in isolation and being expected to actually communicate and think about things other than data structures and algorithms."
If you're a true senior software engineer as most of us claim to be coding is a small part of your job, not your entire job.
You should be learning the product through the PM for sure, and I don't think a senior engineer should be doing first-level support, but especially in small companies talking to customers is good and should be expected from basically everyone who is working on the product.
"the PM can't be expected to sit in meetings all day, they need to learn the coding side of it too so they know the potential limitations of the features they want to suggest"
But if a PM does have a technical question, they don't need to go google stuff and figure it out - they ask a developer.
Likewise, when a developer has a product question, why can't they rely on a PM to answer that for them? Why must we also be expected to be in customer meetings and putting in extra effort, when PMs definitely won't put in effort to learn the technical side?
Yes, it still fits when you flip it around, speaking as an engineer turned technical PM. PMs should absolutely be technical and have enough depth of understanding about the product they can figure things out for themselves, as well as write code.
That's not going to prevent the PM from asking questions to the developers though. I ask questions all the time, because I want to validate my mental model with others and verify my understanding. Asking questions is a /good/ thing.
The part where you are missing the boat is acting like customers are a distraction or an enemy. Customers are /the point/, the /only/ point, really at the end of the day. Every role in every business is customer-facing to some degree.
> But if a PM does have a technical question, they don't need to go google stuff and figure it out - they ask a developer.
In a good organization they first try to figure it out themselves versus distracting a developer (thus costing possibly hours of productivity due to breaking someone's flow). The same way a developer would first try to answer their own question before they start badgering another developer.
Giving away flexibility for free is a collectively dumb move on our part. If someone knows you can take on coding tasks and customer interviewing vs. just coding, you are more valuable to them and they should pay more for it.
They've already gotten away with adding infrastructure and architecture (aka system design) rolled into one developer position. And putting it behind long and stressful interview processes. I'm not doing PM stuff on top of all that and not getting the pay and prestige for it.
Why do you assume it's for free? The compensation of a software engineer varies widely. The same experience can get you anywhere from $100k to $1+m.
Perpetually doing less in fear of not getting paid enough for doing more is how you get paid a pittance while complaining about it constantly. Doing more and then finding a way to get paid more is how you get paid more and be happy.
In my experience, both are needed. Product owners and developers who understand the product. It's possible to have both, they're not mutually exclusive.
Yes, but it's the Product Owner's responsibility to clearly understand the requirements from both customers and the business and communicate them clearly to engineering.
Having engineers handle "support calls" doesn't make much sense, they are not equipped to manage product feedback or understand the business implications.
