How I think about: Productivity
This is a second post in the How I think about... series in which I am sharing my current views on a range of topics related to leadership, tech, culture, ethics, and strategy. I deliberately say ‘current views’ as my thinking continues to evolve and I expect that at some point in the future I may change my view about some of the ideas mentioned in this article — as far as I am concerned that’s a feature, not a bug. If you want to read the first post in this series, have a look at How I think about: Uncertainty.
Why are we so focused on Productivity?
In various shapes and forms and to varying degrees, productivity has been a focus area for businesses, governments, and institutions for centuries. Most of the modern thinking about productivity and its measurement originated during the industrial revolution and is grounded in the ideas of Scientific Management. Overall productivity, seen through the GDP lens, after centuries of stagnation, has been rising exponentially since about mid 1800s mostly as a result of applying technology and scientific method to create more value and accelerate progress. The graphs below from Our World In Data illustrate this beautifully.
Whilst traditionally we tend to think about productivity more in terms of industries like manufacturing in the IT context, ‘engineering productivity’ has become a topic of debates at executive levels of most organisations and a major area of focus for the industry. With so much business value today being dependent partly or completely on technology, it is understandable that making IT as productive as possible is a key enabler for business success. Or is it?
What do we mean by productivity anyway?
In general terms, productivity is the efficiency of creating some valuable output. Typically, it can be expressed as the ratio between inputs (in terms of time, money and other resources) and the desired outputs.
In manufacturing and activities that are based predominantly on a repeatable process, productivity is much easier to measure as both inputs and outputs can usually be quantified well and changes in process translate to changes in output rather clearly. For example, we can easily count the number manufactured items (toothbrushes, cars, steel pipes) and measure how changes in our process, ways of working, technology, knowledge etc. influence the production numbers.
Productivity in knowledge work
In knowledge work, things are much messier. Firstly, our ‘outputs’ are often intangible and thus harder to ‘see’. That means we can’t easily measure output in a simple way without neglecting many crucial elements (more on that later). More importantly, especially in product development, we do not follow a repeatable set of steps to produce a specific number of software ‘items’. Yes, we do have and need methods, processes, and tools to help us orchestrate work especially when working at scale, but our output is always multi-faceted, has many aspects, qualities, characteristics and functions all of which determine its overall value to the business.
The work product engineering teams do is also almost always unique in nature — we rarely do the same thing more than once. We are discovering and learning as we go, we probe, sense and respond. This context is fundamentally different to a repeatable manufacturing process and as such, requires a very different mindset when it comes to thinking about, measuring and optimising productivity.
Since knowledge work and digital product development specifically is what I am most interested in, I will focus the rest of this post on productivity in the context of knowledge work, namely software engineering and digital product delivery. In software engineering and technical knowledge work in general what we understand as ‘productivity’ is indeed multi-faced and encompasses several dimensions like:
Pace: How fast work gets done
Quality: How well work gets done
Satisfaction: How satisfying the work is
Maintainability: How well are long-term considerations taken care of
Communication and collaboration: How well are information and knowledge shared and used
Given all this context, we need to recognise that there isn’t a single metric or indicator that gives us a holistic view of engineering productivity. In fact, reducing productivity to a single number tends to have very negative consequences as we shall see later.
Common anti-patterns
Assuming software engineering is like manufacturing
The biggest anti-pattern I repeatedly observe is organisations applying manufacturing mindset to knowledge work and trying to measure productivity in the same way as one would measure an output of a production line. As we saw above, knowledge work is fundamentally different from a repeatable process we tend to optimise in manufacturing. And while various lean techniques can be very useful in identifying and removing process bottlenecks and thus improving flow, productivity is software engineering takes a range of forms and needs to be thought about very differently.
Trying to measure productivity of individuals
This stems from the myth of 10x developer and the desire to maximise individual performance in hope that this will directly result in an equivalent improvement in the team and org performance. The reality, again, is much more complex and messier. It is true that people’s skills, expertise, added value and impact vary quite significantly and that organisations should always aspire to attract and retain the best talent they can. At the same time, given the nature of productivity in knowledge work, putting a lot of focus on measuring how individuals perform using specific metrics leads to poor outcomes — people feel watched, they tend to start gaming whatever metric is used to measure their performance, they over-focus on demonstrating their own contributions at the expense of the overall output/productivity of the team etc.
Looking for a simple answer
Numbers usually tell only (a small) part of the story. It’s tempting to use whatever metric we can measure as a proxy for productivity. But that is never the full story and over-indexing on any one number is highly undesirable. There are many context-/situation-specific reasons why various productivity-related metrics may go up and down for a given person/team. These need to be understood to truly determine what is happening and why. Over the years, many metrics have been proposed and used to measure productivity. Yet, in my experience, none of them does the job in practice:
Forgetting what we are actually trying to achieve
Peter Drucker and W. Edwards Deming are both credited for saying: “If you can't measure it, you can't manage it.” And as someone who is very focused on organisational performance, I sympathise with this. At the same time, measurement of anything, and productivity is no exception, needs to be seen as a means to an end, not the outcome in itself.
The ultimate outcome we are interested in is NOT how productive a person or a team is, but how much business and customer value we can create at any given time. And to maximise that, we need a good dose of systems thinking and we need to look at the organisation as a whole and examine which factors influence our ability to create value the most. Over-focusing on productivity, especially in the limited and narrow sense outlined in this section, is not going to result in the outcomes we want and will likely cause a range of local optimisations without any major improvement in the top line value creation.
When a measure becomes a target, it ceases to be a good measure - Goodhart's law
Adding people as a go-to method to increase output
Productivity does not scale linearly with the number of people — experience shows that productivity scales roughly following a square root function i.e., to get double the productivity we need to quadruple the team size. But that also means increasing hand-offs, complexity, cognitive load, and coordination. All these aspects will impact productivity in various ways, and we need to consider carefully if increasing number of people in the team or organisation is really the right answer and whether we have the basic structural conditions and technical and organisational maturity to make scaling worthwhile.
Productivity as an IT issue
Way too often I see organisations considering productivity as a challenge that needs to be addressed first and foremost by IT/Engineering as if it was only IT that participates on value creation. This effect is chiefly down to the pre-existing Taylorism-style ideas and also the fact that most IT teams, in some way, tend to measure things related to their productivity. This narrow focus on IT-only productivity inevitably results in local optimisations where a small part of the overall value stream gets all the attention despite the fact that much bigger gains can be achieved by looking at the overall end-to-end flow from idea to operations. As an additional side effect, one part of the organisation feels constantly under pressure and continues to look for more and more ways how
Utilisation = Productivity
This is one of the ideas that, whilst having been debunked a hundred times over, continues to live on and influence decisions, process and measurement of productivity. The intuitive assumption is that in order to be maximally productive, people ought to be maximally utilised. This works well in the manufacturing context where a machine ideally should be running at 100% utilisation all the time as its productive output is directly proportional to its utilisation. This however does not translate to knowledge work. People are not machines. Digital products are not toothbrushes. As shown nicely in this post by Pawel Brodzinski, the optimal utilisation point to maximise value overall is typically way less than 100%.
Should we focus on productivity at all?
In a digital product context, productivity is influenced by a range of factors such as:
the nature and the maturity of the product the person/team is working on
the processes the team and the organisation follow
the maturity of the development environments
people’s levels of clarity and understanding of the desired outcomes
individual skills, experience, and motivation
team and corporate culture and overall work environment e.g., psychological safety, dependability, structure & clarity, meaning & impact of work
In practice, there are many things we care about when it comes to ‘productivity’ as they have real-world effects on the overall performance of the team, the organisation and the amount of business and customer value that gets delivered. Here are a few 'dimensions' all of which contribute to productivity:
Levels and quality of communication within a team and across teams — this results in fewer mistakes, less rework, higher quality, fewer misunderstandings etc.
Adherence to technology principles and standards — this results in less tech debt, less rework, better alignment, better performance etc.
‘Scout mindset’ (I leave the code in a better shape than I found it) — this results in reducing tech debt, lead time getting shorter, fewer defects etc.
New ideas and contributions to team and org improvement — this results in improved team engagement, better collaboration, improved outcomes etc.
Coaching and growing others — this results in improved people retention, engagement, better collaboration, higher quality, better outcomes
Innovation and solution creativity — this results in shorter lead times, solutions fit for purpose and future-proof etc.
Ability to give and receive feedback and reflect on it — this results in better team cohesion, higher team performance and engagement etc.
Ability to learn quickly and apply learnings in practice — this results in better solutions, faster delivery, less rework, better outcomes etc.
As we now see, productivity is not one thing, and we should not fool ourselves into thinking that we can abstract it into a single metric. Instead, if we want to gain better insights about productivity to help direct our actions and team support more effectively, the mindset we need to adopt should be based on:
Focusing on Outcome (business value) as opposed to Output
Paying more attention to progress/trends over time rather than absolute values
Focusing on teams rather than individuals
Focusing team and E2E measurements on flow-based metrics and business OKRs rather than output and ‘productivity’ metrics
Focus on growing team and org maturity (from idea to production) — productivity will follow
Consider using a team-based scorecard based on a range of measures rather than a single metric and make targets team specific
Interpreting all metrics WITHIN the relevant context (i.e., in other words, numbers without context are often meaningless)
Evaluating individuals’ added value based on feedback from peers and relevant domain experts (as opposed to purely data)
With all that said, there are many things that we can and should do to help engineers and teams to become more productive, regardless of what metrics we choose to use, for instance: limiting context switching and keeping levels of work-in-progress relatively low, having a clear understanding of product roadmap, the desired outcomes and customer needs, having time to invest in addressing technical debt on an ongoing basis, managers actively removing impediments which are beyond control/influence of teams, eliminating dependencies etc.
So where does this leave us?
We need to think about productivity in knowledge work very differently and need to leave behind old paradigms which do not translate into the digital context. We need to appreciate that productivity is complex and multi-faceted and as such needs to be evaluated and considered from a range of perspectives and with a multitude of insights. We need to see productivity as a multi-dimensional phenomenon not as a two-sided coin. We must not forget that any measurement is context sensitive and that failing to understand the context will almost certainly lead us astray.
Insights and metrics pertaining to productivity are helpful to understand what is true and what and how we should change, but we must get blinded by them — instead of obsessing about individuals’ productivity, businesses should concentrate more of their energy and resources on the value-creation capabilities of the organisation as a whole.
PS: Thanks to Lewis Jardine, Sandra Atkins, Susanne Franke, Lien DePlancke and Wayne Palmer for their ideas, critique, and contributions to the original version of this post.
PPS: Found an error or a typo? Did I get something wrong? Or do you have an idea you’d like to share? Please let me know!