[2/2] Developer Productivity for Humans, Part 6: Measuring Flow, Focus, and Friction for Developers (Category Management)

In the second part of the article, which I began to consider in past postThe authors discuss the friction metric.

1. They decided to start building friction again from the perception of engineers, and not from data from tools like builds, autotests and the like. As a result, the authors constructed a metric using A number of components that include key engineering activities Aggregate these components by engineer and calculate the average for each engineer Further, for each of the engineers, the resulting average was compared with some threshold value calculated in the context of the perception of engineers, and not just a conditional one. 90 pencentil If the threshold was broken, it was believed that the engineer experienced friction on that day.
2. Google used to have friction metrics, but they were designed to demonstrate how infra or tools can help reduce friction, or to understand what’s keeping engineers from being more productive. These metrics were based on the number or percentage of “bad events” relative to a large number, such as Google’s flaky tests. These metrics made sense in team infra scenarios, but didn’t match the experience of specific developers.
3. But it turned out that if you count friction based on the experience of developers, you get all the same reasons: test latency, flaky tests, issues with code changes being blocked due to CI failures. This shows that the old metrics matched the new ones, but the new approach gave more confidence that it reflected the developers’ own view of what was stopping them from working.
4. Interestingly, the developers noted that to some extent these problems are not the cause of friction, but are part of the work. But if you exceed a certain threshold, such as flaky tests, this becomes a problem and they classify it as friction.
5. As a result, the metric of friction became Data from latencies logs for local builds and tests, latencies for change lists, problems with unstable tests, problems with blocked submission attempts. I also had to play with the thresholds. Data from quarterly surveys about whether they experienced friction and how satisfied they were with code complexity and development speed

As a result, the approach of the children allows you to create a basis for answers to questions of the type Can focus and flow be improved by reducing corporate meetings? Is it possible to improve focus and flow by making days or weeks without meetings?

• Is it possible to achieve better focus and flow by reducing the duration and slots for focused work? How can you use the friction metric to determine which processes to improve first?
• And so on.

But the researchers themselves are at the beginning of the journey. I hope they will share with us the results of the next steps in the next whitepapers.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes