4 ms·

So much emphasis on ROI, but we have to remember the Amazon employees who needed to skip toilet breaks to fill their quota and pee into a bottle. It doesn't hav

So much emphasis on ROI, but we have to remember the Amazon employees who needed to skip toilet breaks to fill their quota and pee into a bottle. It doesn't have to be always so narrowly focused on ROI. Maybe there is a wiggle room for human matters?

jrockway 5y ago
I think a lot of consternation comes from priority being set by the product team, and not from the engineering team. The priorities need to satisfy both parties. I'm very much a fan of roadmaps, planning, and delivering big product changes quickly, but I'm also pretty aggressive about carving out time for things that are going to improve velocity overall. As an example, right now, one of my team's highest priorities is to remove a bunch of dependencies from local deployment and CI so that a developer can run the whole stack with just "go run main.go" and so that CI tests more of our stack. (Our team runs managed Kubernetes clusters with our company's software stack installed in it, so it's very easy to get into the state where you need accounts with 3 cloud providers and 25 secrets to do anything... and it's a big productivity killer to require all of those for every change. And it means that a lot of test coverage is manual, which is an amazing velocity killer.) No product manager would rate that as the top product priority, but as the engineering TL I know it's a productivity multiplier -- reduce development cycle times and get more story points out of each sprint going forward. An engineer can test 100 of their tweaks per day, instead of 10. Another option is to schedule slack times into your sprints. Ruthlessly prioritize, figure out how many story points your team can do per sprint, and fill it up. But, if your team typically does 100 story points per week, only take on 80 story points of work, and use the other 20% for "things that come up" or "things that engineers feel like doing". I haven't actually done this, but I plan to in the future, so I don't know what the right number is. But people always feel bad when 100% of their work is chosen for them; so build in time to let people choose their own work. The business gets what they want, the team gets what they want, and everyone is happy. Finally, slightly off-topic... this is my guiding light for anything related to planning: https://apenwarr.ca/log/20171213 https://apenwarr.ca/log/20171213 I worked for the author, and our team got a lot of stuff done -- we hit our OKRs every quarter, people believed us when we said "we'll do that next quarter", and we had a lot of fun making a great product. Planning is not bad, planning is great. Don't let it scare you away; planning doesn't mean "the PMs control your life". It just means you know what goal you're working towards.
Phil-bitplex 5y ago
The way I read it, it was totally independent of human factors, not excluding them. Ruthless prioritisation in this context means to focus your decisions of what to focus on around delivery of value to customers. You definitely have wiggle room for human factors. Including those factors in your decision making is only way this can work, otherwise you will get poor quality at the end of it. At least that has been my experience in the context of software delivery.

jrockway 5y ago

I think a lot of consternation comes from priority being set by the product team, and not from the engineering team. The priorities need to satisfy both parties. I'm very much a fan of roadmaps, planning, and delivering big product changes quickly, but I'm also pretty aggressive about carving out time for things that are going to improve velocity overall. As an example, right now, one of my team's highest priorities is to remove a bunch of dependencies from local deployment and CI so that a developer can run the whole stack with just "go run main.go" and so that CI tests more of our stack. (Our team runs managed Kubernetes clusters with our company's software stack installed in it, so it's very easy to get into the state where you need accounts with 3 cloud providers and 25 secrets to do anything... and it's a big productivity killer to require all of those for every change. And it means that a lot of test coverage is manual, which is an amazing velocity killer.) No product manager would rate that as the top product priority, but as the engineering TL I know it's a productivity multiplier -- reduce development cycle times and get more story points out of each sprint going forward. An engineer can test 100 of their tweaks per day, instead of 10. Another option is to schedule slack times into your sprints. Ruthlessly prioritize, figure out how many story points your team can do per sprint, and fill it up. But, if your team typically does 100 story points per week, only take on 80 story points of work, and use the other 20% for "things that come up" or "things that engineers feel like doing". I haven't actually done this, but I plan to in the future, so I don't know what the right number is. But people always feel bad when 100% of their work is chosen for them; so build in time to let people choose their own work. The business gets what they want, the team gets what they want, and everyone is happy. Finally, slightly off-topic... this is my guiding light for anything related to planning: https://apenwarr.ca/log/20171213 https://apenwarr.ca/log/20171213 I worked for the author, and our team got a lot of stuff done -- we hit our OKRs every quarter, people believed us when we said "we'll do that next quarter", and we had a lot of fun making a great product. Planning is not bad, planning is great. Don't let it scare you away; planning doesn't mean "the PMs control your life". It just means you know what goal you're working towards.

Phil-bitplex 5y ago

The way I read it, it was totally independent of human factors, not excluding them. Ruthless prioritisation in this context means to focus your decisions of what to focus on around delivery of value to customers. You definitely have wiggle room for human factors. Including those factors in your decision making is only way this can work, otherwise you will get poor quality at the end of it. At least that has been my experience in the context of software delivery.