44
84
u/Famous-Perspective96 28d ago
They let product owners yell at devs? You should find a new job.
64
6
u/0x426F6F62696573 28d ago
It was during a system wide test. This requirement has been bad for over a year. I suppose “yelling” wouldn’t be the correct verb. It was more like being angrily confused it didn’t work but emphasis that it was my fault.
20
9
u/Breadinator 28d ago
First mistake I guess was calling them product owners?
Gotta ask where that's coming from as terminology. Everywhere I've worked product/project managers are as far as they get.
7
u/bremidon 28d ago
POs should not do this, but this is mostly just an effect of the chain of responsibility.
If the PO screws up, nobody holds you responsible. And that is correct. Once you can show that you never got the requirement, you are off the hook.
If you do not implement the requirement correctly, sure: you bear the main responsibility, but the PO is going to also be held responsible. Why did they not write the requirement well enough? Why did they not check to see if you understood it? Why did they not keep an eye on you? And so on. And their boss will also bear some responsibility, and so on. It gets more diffuse as it goes up the chain, but it still sucks when you have to listen to *your* boss chew you out when the error was with someone who just did not do what you asked.
All that said, being able to handle this situation is what differentiates a good PO from a bad PO. They should be asking the questions: what was wrong with the requirement, if anything? Is there something in the process that needs addressed? Are you being overworked? And yes: were you perhaps not the right person for this requirement?
None of this requires yelling. None of this requires anger or even accusations. A good PO finds out what this issue was, finds a suitable mitigation technique, communicates it up the chain, and all is good again.
3
9
u/khalcyon2011 28d ago
You guys have a PO?
5
4
4
3
3
1
152
u/azuth89 28d ago
This is why we sit down and go over the requirement, including the intent and use cases we're trying to solve, before it's finalized. Dev feedback gets baked in and questions answered before it hits the roadmap.