4 ms·

> 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

by 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]

by qw 6y ago

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]