3 Reasons Your Productivity Improvements Don’t Work

Unpacking productivity

Productivity is the key to improve your quality of life. When you are more productive, you have more time to do the things you really want to be doing. The things that make you happy. The things that make the grind-work bearable.

In business, for example, higher productivity means more sales which ultimately results in higher profits. Higher profits mean you can pay higher salaries, get more customers, and make more products to sell. Additional to the obvious benefits though, there’s also the added benefit of freeing up your most under-utilized, as well as most expensive resource – namely human resources – to explore ways to make your organization even more profitable. Many of Google's most loved apps, including Gmail and Google Maps, for example, were born from Google’s 20% innovation time where employees are allowed 20% time to work on a project of their choice, as long as it benefits the company.

However, when a business is struggling to deliver on their brand promise, 20% innovation time can be a bad idea to start off your productivity improvement drive. So what can you do right now to improve your productivity?

Here are the top 3 reasons your productivity improvements don’t work, and when you now what doesn't work, it's easy to adapt your strategy to find ways that do work:

1. You’re measuring the thing wrong

One of the most popular methods to improve your productivity is by improving the efficiency of parts of the system. For example, in software development, productivity is often measured by the number of features delivered in a specific time.

In Scrum, velocity is a measure of productivity. The velocity is an indication of how many features (or stories) were delivered in a specific time-box (or sprint). The higher the velocity, the more features are delivered, the more productive the system. Or is it?

What if these features contain a lot of errors requiring the support team to handle a higher number of issues reported by customers and require rework and bugfixes in a susequent iteration? Or what if these features sit in a queue waiting to be deployed in the quarterly release? Or what if what you delivered isn't what the customer wanted?

Are you really being more productive?

The missing link

There’s one critical flaw in the calculation to determine productivity improvement when you look at efficiency of a part. It doesn’t compare apples with apples. A 10% improvement in the development process alone does not necessarily result in an overall 10% productivity improvement.

Without developed features deployed and used you might have increased the efficiency of a part, but the productivity of the whole is still exactly the same, in some cases even worse as a result of the increased speed or increased waiting time between two different departments/business units.

To truly measure an improvement in productivity, you have to look at the whole system within context of value produced. To understand the improvement you need to obtain a baseline lead time from idea to delivered. Only when the lead time reduces can you say that your productivity have increased.

As you can see in the diagram below, by improving the parts you don’t necessarily improve the whole, and without improving the whole, you’re not improving. Although all the different parts increased their efficiency, the customer doesn't get value delivered to them any earlier.

You’re as weak as your weakest link. To be able to say you improved productivity, an increase in efficiency in one area is not enough. You also need to improve the interaction or handover between the different parts each time you improve one part of the process to truly be more productive.

Process improvement can only be truly measured from the point of view of the customer. If the product or service doesn’t result in delivering value faster to the customer, you’re not truly improving your productivity.

2. You’re measuring the wrong thing

As soon as you set a target, people will try their best to meet that target. Most people want to please their managers and they respect them enough not to question their motivations for setting specific targets. Often, it looks like the right measure when looking at a part in isolation, however, when looking at the whole it becomes clear that you’re measuring the wrong thing.

The perfect example of this false sense of productivity improvement by measuring the wrong thing is often observed in call centres. Productivity is usually measured by decreasing the duration of each support call and increasing the number of calls handled by each support call agent. The more calls and the shorter the duration of each call, the better the efficiency. Or is it?

Is it really more productive when the same customer calls multiple times because the call centre agent cut off the call as quickly as possible to meet their targets? Is handling more support calls really indicative of higher productivity? Or is it may be a symptom of lower quality products?

By its very nature, a call centre is designed to handle non-standard calls. Those calls that are outliers. The corner cases. The use cases used by only a select few and very unlikely users. If it was possible to answer the questions easily and quickly, chances are it could have been included as a software change in the next release. If it could be automated to be handled by a chat-bot, there would be no reason for a customer to need to phone a call centre in the first place.

Call-centres are intended to deal with corner cases. Their goal should be to improve the customer experience by providing information that is not available in the system. It is supposed to be a listening tool to find out what the customers need in order to deliver better quality products. A barometer to measure the external environment.

By measuring the number of calls handled per day, or the duration of each call, ultimately you are saying that it is acceptable to build bad software (or products).

Rather than compromising the quality by reducing the time spent on each support call, the goal should be to deliver value (or quality) by balancing time, cost and scope to meet the sole objective of meeting customer expectations, which is what quality essentially is about.

It’s not perceived quality when you offer a customer a more expensive solution with all the bells and whistles that he doesn’t need or want, just as it isn’t perceived quality when a car salesman offers a Ferrari because it’s the most expensive option on the floor to someone looking for cost-effective and family friendly. No one would argue that the Ferrari is a high-quality vehicle, but it doesn’t meet the needs of the customer, making it worthless. It is only quality when what you offer meets the needs and wants of the customer. That is quality.

Quality is not what’s better for you. Quality is what’s better for the customer.

Improving productivity directly relates to improving quality. Quality directly relates to the value delivered. High quality, high productivity.

Re-evaluate whether your measures support higher productivity by enabling faster delivery of value, or whether it impedes a great user experience. Just because a customer answers that their call was sufficiently dealt with by the call centre agent, doesn’t mean that they are happy with the service or product offering. The only questions that really matter are:

1. Would you use the service or product again?
2. Would you recommend the service or product to someone else?

Rather than measuring the number of calls handled per day or the time spent on each call, measure the categories of calls and the number of similar issues reported. Use it as an input into the design and development function rather than a fire fighting mechanism to shield the developers from the errors they made.

3. You’re doing too much

More is better. Right?

Well, I would argue that in most cases this is not true at all. Apple, being the perfect example to prove that it’s not about how much functionality there is, but how useful that functionality is. Good design is simple. It’s easy to understand. It doesn’t require you to read through a manual or attend a training course to use it. It doesn’t require someone constantly having to show you how to do the same thing or where to find it.

The one axis of the quality triangle is scope, yet few productivity improvement suggestions focus on this aspect. Cost and time improvements are covered in detail, yet few people realize that scope can be reduced too to improve productivity. It’s not only about doing more with fewer resources, but it is also simply about doing less.

One of the deadly wastes of lean is overproduction. Producing more functions than what is used is a waste. It is scientifically proven that the human brain can only hold 3 – 8 items in working memory. When you open up a program like Adobe Illustrator with it’s multitude functions, it can be overwhelming and daunting. Research has also proven that most users only use the same few functions, with up to 80% of software development unused. Imagine what you could have done with the time spent on these 80% unused functions if you weren’t so busy building it?

The customer isn’t always right.

There is a difference between blindly saying yes to a customer request and understanding the need behind this request. Often, you are serving the customer better by saying no. Many times customers will ask for a specific function to be built. Yet after finding out why they want this or how they intend to use it, it often becomes clear that they either don’t need it, or they want something else than what they asked for. They just don’t know the technical language you are speaking. Saying yes to every customer requirement is not adding to the value delivered and can negatively impact productivity.

Rather than measuring the number of features developed, measure how users are using it to decide whether something is actually productive or not.

Productivity improvements pay for itself

More productive teams translate to higher profit margins for the company. Investing in productivity improvement is an investment, rather than an expense.

To start your journey to more productive teams, make sure you are measuring the right thing, and that you measure it rights by comparing apples to apples and including an end-to-end view of the process. Lastly, learn to say no. Less is more. Discern between what a customer is asking for and what they actually need to achieve their goal.

Spend more time understanding the need before rushing to build it.

Originally published on People Development Magazine: https://peopledevelopmentmagazine.com/2018/12/31/3-reasons-your-productivity-improvements-dont-work/