{"id":1956,"date":"2024-09-23T10:49:33","date_gmt":"2024-09-23T10:49:33","guid":{"rendered":"https:\/\/janbosch.com\/blog\/?p=1956"},"modified":"2024-09-23T10:49:33","modified_gmt":"2024-09-23T10:49:33","slug":"from-agile-to-radical-measuring-team-performance","status":"publish","type":"post","link":"https:\/\/janbosch.com\/blog\/index.php\/2024\/09\/23\/from-agile-to-radical-measuring-team-performance\/","title":{"rendered":"From Agile to Radical: measuring team performance"},"content":{"rendered":"\n
\"Image
Image by Gert Altmann from Pixabay<\/figcaption><\/figure>\n\n\n\n

In his book \u201cSlow productivity\u201d, the author, Cal Newport, provides an analysis of the history of performance management. He starts in the manufacturing era where productivity was easy to measure: in practice, it was the number of widgets per hour a factory worker could produce, using all the equipment available.<\/p>\n\n\n\n

When knowledge work became the primary occupation, things changed quite significantly as measuring the productivity of a knowledge worker is a very difficult proposition. In many contexts, it\u2019s virtually impossible to do in any actionable fashion. Of course, after some time, sometimes years, we can point back and identify breakthrough contributions, but this doesn\u2019t make it actionable. All indicators are lagging ones.<\/p>\n\n\n\n

The answer to measuring the productivity of knowledge workers became using a pseudo metric: perceived busyness. For a manager, the idea was that if your people run around as if they\u2019re really squeezing the last out of every minute of their day, you were confident that your team was productive.<\/p>\n\n\n\n

In my view, this analysis is spot on; many of the organizations I work with worship busyness. When I was in industry, some of my colleagues would joke that they would sleep when they were dead, but clearly, they didn\u2019t have the time now. They were working as hard as they could, even if I couldn\u2019t help but suspect that they created an illusion of busyness rather than accomplishing tangible and significant outcomes.<\/p>\n\n\n\n

The challenge with knowledge work is that activities that can be automated often already are and we need the knowledge workers for the tasks that are, by definition, non-repeatable and often \u201cwicked problems.\u201d In these situations, the breakthroughs are hard, or rather impossible, to plan. Over the years, in my research, I\u2019ve noticed several times that there are ideas that simply need time to germinate and that I need to noodle on for a long time before I have an insight that allows me to write a paper around it. And we all know the situation where you suddenly have a new insight or solution to a problem popping into your head while you\u2019re doing something completely different, like taking a shower.<\/p>\n\n\n\n

When assessing team performance, we have a choice. Either we accept that knowledge work is unmeasurable or we determine that it\u2019s possible to measure the impact after some period of time. I\u2019m firmly in the latter camp as in my research, I can also see the impact of my efforts, even if it sometimes takes years.<\/p>\n\n\n\n

All organizations I work with have top-level KPIs that they\u2019re pursuing such as revenue, margin, number of customers, recurring revenue, net promoter score, and so on. At the team level, many software teams track a number of feature-level metrics that allow them to understand how their component or subsystem is performing in the field. Often, these are quality related such as defect density, number of defects slipping to the field, test coverage and the like.<\/p>\n\n\n\n

The challenge is that the team-level metrics and the top-level business KPIs aren\u2019t connected in any way. Consequently, a team may really move the needle on their metrics, but the impact on the business is simply unknown. The team metrics move, the business KPIs move, but the connection between the two isn\u2019t known and is impossible to determine due to all the confounding factors.<\/p>\n\n\n\n

In the SaaS world, many companies build a hierarchical value model where the top-level business KPIs are connected to team-level metrics by an intermediate product KPI layer. To ensure the correct dependencies between the team, the product and the business levels, these companies continuously experiment and measure to collect quantitatively validated relationships between metrics and KPIs at all levels.<\/p>\n\n\n\n

For example, one company periodically intentionally slowed down their solution for a small slice of their customer base to measure how customers experiencing a slower product behave differently than customers who experience normal performance. That allows them to connect team-level metrics, such as system performance, to business-level KPIs, such as revenue and customer satisfaction.<\/p>\n\n\n\n

Once a company has a quantitatively established relationship between the business level and teams, it becomes feasible to start to measure team performance quantitatively and regularly. For one of the companies I worked with, every team knew at the end of each sprint exactly how much money they made for the company. Using A\/B testing, the teams were able to move the conversion KPI with small amounts and any promille of conversion improvement directly translated into a positive revenue impact.<\/p>\n\n\n\n

In this situation, if a team hasn\u2019t moved the needle for several sprints, as a leader, you have a clear case to discuss team performance with the members and work on mitigation actions to address the lack of performance. Please note that these teams will tend to be very busy. However, as one of my managers often said, activity isn\u2019t the same as progress.<\/p>\n\n\n\n

A second approach is to organize teams around business KPIs. So, one team owns one of the top-level KPIs and has as its sole responsibility to move the needle on their KPI without or with minimal detrimental impact on the other top-level KPIs. In this case, it also is quite feasible to measure team performance as they either move the needle on their KPI or they don\u2019t.<\/p>\n\n\n\n

A remaining question is whether a team that moves the needle for their KPI does so sufficiently to warrant a high performance rating. This often requires an analysis of the KPI\u2019s revenue impact in relation to the cost of the team. Each team has to contribute such that their cost is justifiable in terms of the benefits they bring to the company. For instance, even the net promoter score has a clear revenue impact as a higher score leads to lower cost of customer acquisition and lower attrition, increasing the total lifetime value of customers.<\/p>\n\n\n\n

As most teams these days consist of knowledge workers, it\u2019s often difficult to measure the performance of individuals and teams. For a long time, managers have addressed this by focusing on a pseudo metric: perceived busyness. With the growing availability of data and our ability to process larger and larger volumes, it\u2019s increasingly feasible to create hierarchical value models where team-level metrics can be connected to business-level KPIs. Alternatively, we can organize teams around these business KPIs and measure their impact in that way. To end with a quote from Thomas Edison: \u201cBeing busy doesn\u2019t always mean real work.\u201d<\/p>\n\n\n\n

Want to read more like this? Sign up for my newsletter at\u00a0jan@janbosch.com<\/a>\u00a0or follow me on\u00a0janbosch.com\/blog<\/a>, LinkedIn (linkedin.com\/in\/janbosch<\/a>) or Twitter (@JanBosch<\/a>).<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

In his book \u201cSlow productivity\u201d, the author, Cal Newport, provides an analysis of the history of performance management. He starts in the manufacturing era where productivity was easy to measure: in practice, it was the number of widgets per hour a factory worker could produce, using all the equipment available. When knowledge work became the … Read more<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"generate_page_header":"","footnotes":""},"categories":[8,10],"tags":[],"_links":{"self":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1956"}],"collection":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=1956"}],"version-history":[{"count":1,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1956\/revisions"}],"predecessor-version":[{"id":1957,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1956\/revisions\/1957"}],"wp:attachment":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1956"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1956"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1956"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}