3 ms·
I used to work at Amazon, which is known for its draconian policies, but I was on a good team at one point. On that team, you were expected to allot no more tha
by sombremesa 8y ago
I used to work at Amazon, which is known for its draconian policies, but I was on a good team at one point. On that team, you were expected to allot no more than 4 hours a day to your tickets.
The rest of the time was for meetings, code reviews, self organization, administrative tasks, 20% time, etc.
Now that I'm in a company where everyone is always heads down and code reviews clog up the pipeline and no one is on the same page, I'm beginning to see that being less "productive" gets more done.
- gubbrora 8y agoSlow code review is really bad for productivity. Both cost of task switching as you wait, and of merging upstream changes into your branch.
- dwiel 8y agoThat's a reasonable observation, but only loosely related to the parent post. Admin, code reviews, meetings all count towards that 2-4 hour goal
- nine_k 8y agoBeing productive is getting things out the door to production. Writing code is only a part of this equation. If you don't have a process that cares well about the other required things (reviews, testing, meeting and thinking, etc), you end up with a lot of code written, and much less of it useful for business at a given moment.
- awshepard 8y ago"The Phoenix Project" references this - when a particular resource (expert) is the only person who can get some task done. Of course that means that person is at or beyond 100% utilization, which means their queue length (or wait time) goes through the roof. Paradoxically, reducing utilization increases productivity/throughput. The section about controlling WIP here [1] illustrates it quite well. [1] https://itrevolution.com/resource-guide-for-the-phoenix-project-kanbans-part-2/ https://itrevolution.com/resource-guide-for-the-phoenix-proj...