Four Lenses of Productivity
Individuals, teams, organizations, and markets need different productivity metrics.
This is the latest issue of my newsletter. Each week I cover the latest research and perspectives on developer productivity.
This week I read Individual, Team, Organization, and Market: Four Lenses of Productivity, an essay by Amy J. Ko for the book Rethinking Productivity in Software Engineering. This essay provides a helpful model for thinking about the different types of metrics that can be used to understand engineering productivity.
My summary of the paper
When researchers have previously investigated developer productivity, they’ve surfaced some surprising nuances about what software engineering “work” actually is and at what level this work should be considered. For example, one study found that developers have differing views on what it means to be productive, while another found that developers find it difficult to gauge the productivity of their teams.
This piece proposes four lenses through which to think about productivity:
Individual
Individual is the most obvious lens for thinking about productivity, relating to developers’ progress on tasks, learning new skills, and the quality of their work. Factors such as tools and documentation also strongly influence how efficiently developers can complete work.
Team
When we think about team productivity, we think about how efficiently the team can meet requirements. This is impacted by factors such as how quickly developers can get information from their teammates, the quality and efficiency of decisions made within a team, and how efficiently new hires are onboarded to the team.
The team lens is sometimes in tension with individual productivity: for example, interruptions can be a nuisance for individual developers, but they may improve team productivity overall. However, research has found that team productivity is bounded more by communication and coordination overhead than by how efficiently individual developers work. Finding ways to streamline communication, coordination, and decision-making is therefore key and perhaps more impactful than making individual developers faster.
Organization
Viewing productivity through an organizational lens is even more broad. The author of this paper mainly focuses on this lens as it relates to the influence of the company’s policies, norms, and processes on how efficiently work can move at the team and individual levels. These may include the company’s policies around remote work or work-life balance, which may impact individual and team productivity differently. The organization’s investment in infrastructure, or norms around meetings, also impact team and individual productivity.
Market
Viewing productivity from a market lens acknowledges that the whole purpose of an organization that creates software is to provide value to customers and other stakeholders. To measure productivity in terms of value, a company has to define how its products deliver value. These understandings then influence organization and team-level strategies for improving this top-level notion of productivity.
In conclusion, the author points out that each of these lenses are often in tension, therefore leaders should consider using metrics from each dimension. Additionally, the author suggests that individuals, teams, organizations, and markets all need their own metrics, stating that “each of these has different implications for what actions one might take to increase productivity in a company.”
Final thoughts
This paper gives us an easy way to talk about different types of metrics. If we want to improve productivity at the team level, we should measure the factors that relate to that level, such as those relating to communication and coordination. Additionally, we should consider using counter-measures where the different lenses are in tension with each other.
That’s it for this week! Share your thoughts and feedback anytime by replying to this email.
If this email was forwarded to you, subscribe here so you don’t miss any future posts:
-Abi
As to what constitutes the “work” of software engineering, I’ve been leaning heavily on:
“Software engineering is the application of an empirical, scientific approach to finding efficient, economic solutions to practical problems in software.”
— Modern Software Engineering: Doing What Works to Build Better Software Faster by David Farley
https://a.co/4Y6PS14