The Productivity Problem

Everyone’s been talking about productivity ever since I started my career. From managers to senior leaders , it seems like one of the biggest concerns that most organisations are grappling with. It emanated as a concept in the industrial revolution and then carried on till the wee years of the 21st century. If one reads a bit of Adam Smith then one would realise that an organisation’s success largely depends on production. More the production, more is the revenue and more is the profit(if I take into account subsistence being unimaginably low) and thus in order to become sustainable an organisation tends to scale up production as much as possible. The model of capitalism stuck to it till the information age arrived.

In this information age organisations worldwide are thinking about how productivity as an organisational goal can be optimised. But before we even go there it’s important to understand what on Earth is productivity. Google defines it as follows:-

That’s a vague definition since we are trying our best to understand productivity quite comprehensively. So let’s first understand how to define productivity. Quintessentially productivity is a function of focus, time, intent/impact curve, company profit(gross and net) over quarters, outcome, impact along with the output. That’s again quite mathematical so I am going to try my best to explain in the simplest way possible. Here at this point I would like to mention the JTD or the Jobs to be done framework enunciated by the late professor Clayton Christensen, father of modern innovation.

JTD makes it easier to understand a lot of things and hence could be applied in understanding productivity tad better. Forgive me for using an example from the technology industry but let’ say you are a software engineer. Let’s say your team follows Scrum which runs 5 days sprints with 4 sprints every month. Let’s say every sprint there is a certain backlog or work that the team is supposed to do from the bucket of overall backlog. Let’s say every sprint you are given a bunch of user stories to work on with each user story having certain hours. So even if we assume the focus factor to be 75% with 25% time allocated to various miscellaneous activities then if you are able to finish all the jobs allocated to you in a sprint faster than anybody else then you are super productive. But again there might be a situation that your work does not end which could be because the work needed more than the hours allocated in a sprint or because your velocity of execution is less than the average velocity in a team. Then in that case you might be termed unproductive or the work was more complex than earlier estimated. But to resolve this conundrum one can take into account your productivity over multiple sprints and if you cannot wrap up jobs within the sprint then most probably you are unproductive or less productive.

But is that all? Well guess not. Productivity also takes into account how focused you are toward completing a job. It also takes into account your time management skills. It takes into account not only the output you produce but the outcome of the output and it’s corresponding impact on the customer and the company. The customer outcome and impact whether it’s customer or user could be measured using frameworks like NPS(Net promoter Score), CES(Customer Effort Survey),CSAT(Customer Satisfaction) and impact on the company can be measured in terms of the gross profit and net profit. However one can also calculate the per capita productivity of an engineer by measuring the impact of the delivered job by checking product analytics to see how much is the usage of a feature and if the usage is helping generate an outcome for a customer with a certain impact where we can again use JTD framework as it’s used in product management in tech companies.

Last but not the least it’s also important to understand if the gap between the intent and the impact is zero or otherwise. Now this is a framework mostly used to check if what was intended to be built or solved is exactly as envisaged or there is some apparent gap between the envisaged product and the final product. That’s again important to understand if your code if you are an engineer not only solved the problem that you were trying to solve but also did not create regression in the code base that again broke the build thereby resulting in many errors for the consumers of the product. It’s an effective framework that tends to take into account how precisely you could solve the problem as an engineer. Now the necessary and sufficient condition for an engineer like you to be productive is when you tend to fulfil all the by conditions that comprise productivity per se. I admit this is a byzantine method of computing productivity and yet it’s more effective if we dissect productivity into it’s aforementioned components as opposed to taking it as a singular variable. Now at this juncture if you feel you have a better way of computing productivity then feel free to share it. Couple of good books that tend to take a shot at explaining productivity would be High Output Management by Andy Grove, Measure what matters by Jon Doerr, Indistractable by Nir Eyal, IkiGai by Hector Garcia and Francesc Miralles, Atomic Habits by James Clear and Maverick by Ricardo Semler. Do share any book that you have read on productivity.