> And every two weeks during my 1:1 discussions with each engineer, I would also pull up that individual’s personal velocity chart (...) And if their chart is on a downward trend or significantly lagging behind their teammates, I would ask them what I can do to unblock them and help them achieve their full potential
> In fact, when discussing velocity metrics in 1:1 conversations, you should explicitly avoid comparing them against one another
These sentences are in 2 subsequent paragraphs. Compare people against each other, but you should explicitly avoid comparing them against one another. Sure thing.
> Ultimately, using lines of code, commit counts, or pull requests, to quantify engineering performance is a fool’s errand. All it does is create a culture where dishonest people write bad code to get ahead, and those with integrity are penalized and eventually quit in frustration.
But somehow velocity, which is an abstract, imprecise, and very error-prone measurement should be used as a primary metric for both team- and individual-based performance?
This article is such a mixed bag. There are great points like "don't estimate time", but then the author throws things like the quotes above. It feels like one of these "you're so close to getting it right" situations.
Also, as another commenter here mentioned – this can be gamified, because 5-point complex new feature is surely more time consuming and difficult than 5x1-point cosmetic changes. Hence, everyone should aim to take as many small tasks as possible in order to have higher individual velocity than other team members.
> In fact, when discussing velocity metrics in 1:1 conversations, you should explicitly avoid comparing them against one another
These sentences are in 2 subsequent paragraphs. Compare people against each other, but you should explicitly avoid comparing them against one another. Sure thing.
> Ultimately, using lines of code, commit counts, or pull requests, to quantify engineering performance is a fool’s errand. All it does is create a culture where dishonest people write bad code to get ahead, and those with integrity are penalized and eventually quit in frustration.
But somehow velocity, which is an abstract, imprecise, and very error-prone measurement should be used as a primary metric for both team- and individual-based performance?
This article is such a mixed bag. There are great points like "don't estimate time", but then the author throws things like the quotes above. It feels like one of these "you're so close to getting it right" situations.
Also, as another commenter here mentioned – this can be gamified, because 5-point complex new feature is surely more time consuming and difficult than 5x1-point cosmetic changes. Hence, everyone should aim to take as many small tasks as possible in order to have higher individual velocity than other team members.