[HN Gopher] Velocity vs. Impact ___________________________________________________________________ Velocity vs. Impact Author : kiyanwang Score : 20 points Date : 2023-02-17 09:31 UTC (13 hours ago) (HTM) web link (itamargilad.com) (TXT) w3m dump (itamargilad.com) | maximilianroos wrote: | This makes a strawman of "Velocity" | | The purpose of Velocity is not to ship mediocre things quickly. | It's to figure out if you're building something people want, by | showing it to them and seeing if they use it. | | Maybe you can introspect what will have impact? Great if you can! | But generally folks are overconfident in their beliefs & | underconfident in their actions, and so ship far too slowly. | vlovich123 wrote: | One limitation of this is when you do "no impact" work in year 1 | and 2 that's high value impact work in year 3. Sure, if | everything is low hanging fruit go for it. But sometimes it can | take longer to build something that has 10x impact. eg teams A, | B, and C hit a wall because all their time is spent fighting | fires because they didn't invest in getting ahead of tech debt / | product growth. Of course, it's hard to make the case that that's | the case and you can be very wrong in which case you waste a lot | of time. But making sure that you are managing smoldering fires | and preventing them from becoming infernos is high impact | "invisible" work - did you prevent the inferno or was it unlikely | to ever catch in the first place". The usual approach is to let | things start tipping and hope you have enough lead time between | "this is starting to become a problem" and "product growth has to | cease and we have to start shedding customers" | Jtsummers wrote: | What a long article to ultimately get to the realization (but | fail to state it): If you pick a quantitative measure and | optimize for it as a target, that's what you get. | | If you optimize for "velocity" (# of changes, here) then you get | velocity, a lot of changes. If you optimize for "high impact" | changes then you get high impact changes. This is not shocking. | What also shouldn't be shocking is that if the two are only | poorly correlated then you'll end up not getting meaningful | improvements in the other measure, and may in fact reduce the | other if there is a conflict between them. | | The bigger problem is that most organizations don't know what | they want to optimize or how to measure the things they want to | optimize. So they find proxies like "velocity" or "impact" and | end up optimizing for them instead of what they actually want. | | In other words, Goodhart's Law. ___________________________________________________________________ (page generated 2023-02-17 23:00 UTC)