3 ms·

an organization where devs are apparently autonomous, so they're responsible for failures, but still need to go in the direction set by someone else. I've jus

an organization where devs are apparently autonomous, so they're responsible for failures, but still need to go in the direction set by someone else. I've just left a place like this, largely for this reason. Someone with impressive credentials was hired by the senior leadership and given project ownership. The problem is that neither this person's education, nor their work experience, had anything to do with software; they'd never worked on a software project before. Relatively quickly, I started noticing exactly the dynamic you've described. If the backlog was growing (which it always is), engineering would get reprimanded and have the whip cracked on us. But when we'd reach objectives, we'd get no recognition or even acknowledgement, while the "product owner" would get showered in praise. After passing our first major feature milestone, the "product owner" was literally greeted with a bottle of champagne on their desk. It took me a few weeks (read: too long) to trust my perception that most of the "delays" came from how terribly the requirements were written, and how often they changed for arbitrary reasons that created no value. Choice example: does a time period "from January 2019 to January 2020" include two Januaries? The answer to this question would change, sometimes twice a week, when asked of the "product owner". In retrospect, I was in the exact no-win scenario you described, in which my team owned every failure but no successes.

qw 6y ago
> Choice example: does a time period "from January 2019 to January 2020" include two Januaries? The answer to this question would change, sometimes twice a week, when asked of the "product owner". Unfortunately, the only way you can protect yourself is to have a paper trail. If the PO says something, write it down in your tracker (Jira, Trello etc.), or at least an email. If the PO is unclear, write the answer according to how you understand it and ask directly ("Is my understanding correct"). If the PO changes its mind, document that as well. It shouldn't be necessary, and in many companies it is not, but some environments are toxic.
- JoshuaDavid 6y ago
  Though even in a non toxic environment you should document any product decisions and why they were made. Your PM now could be the most amazing and helpful person in the world, but in 3 years it may be important to know if there is an important reason a time period from January to January includes both Januaries (and thus something important will stop working if you change it) or whether that was an arbitrary decision because the question had to be answered one way or the other, so they flipped a coin (and thus there is no special reason to believe changing it is dangerous). Always document product decisions. "Documenting" doesn't have to be a big process, and you don't really need to make polished documentation, but at the very least dump your notes from when decisions are made somewhere permanent and searchable (github comments / jira comments / even slack messages in a non-dm channel count). Your future self will thank you.
  - routerl 6y ago
    This is good advice, but in my case the "product owner" was too invested in seeming competent (by, e.g., over-confidently and over-emphatically making decisions that turned out to be coin-flips). Finally, there was no accountability for product ownership; other than the engineers, no one at the company was positioned, or willing, to notice/address the delays in the project that were caused by the product owner changing their mind arbitrarily. So, while I did spend a few months documenting all these issues, the company itself had not made room for engineering-led process improvements. Noticing that, I started spending political capital on trying to fix it, which is incredibly stressful, slow, and unrewarding work. After a few months of this, I finally came to my senses and realized that, this not being my company, I would not accrue any of the benefits of improving their processes. Time to leave. The lesson, for me, has been to avoid working at companies that are either not product-focused (in which case engineering is just a cost-centre, having extremely low status within the organization), and to avoid stubbornly non-technical founders (i.e. any founder/owner who refuses to care about their engineering department beyond asking "is it done yet?").
- deleted 6y ago
  [deleted]

qw 6y ago

> Choice example: does a time period "from January 2019 to January 2020" include two Januaries? The answer to this question would change, sometimes twice a week, when asked of the "product owner". Unfortunately, the only way you can protect yourself is to have a paper trail. If the PO says something, write it down in your tracker (Jira, Trello etc.), or at least an email. If the PO is unclear, write the answer according to how you understand it and ask directly ("Is my understanding correct"). If the PO changes its mind, document that as well. It shouldn't be necessary, and in many companies it is not, but some environments are toxic.

JoshuaDavid 6y ago
Though even in a non toxic environment you should document any product decisions and why they were made. Your PM now could be the most amazing and helpful person in the world, but in 3 years it may be important to know if there is an important reason a time period from January to January includes both Januaries (and thus something important will stop working if you change it) or whether that was an arbitrary decision because the question had to be answered one way or the other, so they flipped a coin (and thus there is no special reason to believe changing it is dangerous). Always document product decisions. "Documenting" doesn't have to be a big process, and you don't really need to make polished documentation, but at the very least dump your notes from when decisions are made somewhere permanent and searchable (github comments / jira comments / even slack messages in a non-dm channel count). Your future self will thank you.
- routerl 6y ago
  This is good advice, but in my case the "product owner" was too invested in seeming competent (by, e.g., over-confidently and over-emphatically making decisions that turned out to be coin-flips). Finally, there was no accountability for product ownership; other than the engineers, no one at the company was positioned, or willing, to notice/address the delays in the project that were caused by the product owner changing their mind arbitrarily. So, while I did spend a few months documenting all these issues, the company itself had not made room for engineering-led process improvements. Noticing that, I started spending political capital on trying to fix it, which is incredibly stressful, slow, and unrewarding work. After a few months of this, I finally came to my senses and realized that, this not being my company, I would not accrue any of the benefits of improving their processes. Time to leave. The lesson, for me, has been to avoid working at companies that are either not product-focused (in which case engineering is just a cost-centre, having extremely low status within the organization), and to avoid stubbornly non-technical founders (i.e. any founder/owner who refuses to care about their engineering department beyond asking "is it done yet?").
deleted 6y ago
[deleted]