3 Reasons your productivity improvements don’t work

Image of productivity
Karin Dames

Karin Dames

Productivity coach at funficient
With 20 years experience in the software development industry, Karin specializes in helping teams get unstuck, innovate, communicate and ultimately be more productive. She believes in efficiency through fun implementing lean, agile and gamestorming as tools for process improvement. Her goal is to create more happy, healthy and whole workplaces where each person thrives and productivity soars.
Karin Dames

@funficient

A cup of fresh ideas for old problems. Making happy workplaces with technology, gamification, yoga and anything agile.
RT @ajbkr: “How to tell if a company is really agile” by @funficient https://t.co/KLpON20cwa - 1 year ago
Karin Dames

Unpacking productivity

Productivity is the key to improving your quality of living. When you are more productive, you ultimately have more time to do the things you really want to be doing. The things that make you happy. In fact, it doesn’t only make you happy, it is beneficial to everyone involved.

In business, for example, higher productivity means more sales and ultimately higher profits, which in turn contributes to possibly higher salaries. Additional to the obvious benefits, there’s also the added benefit that your most under-utilized resource, and also most expensive resource – human resources – is freed up to explore more ways to make your organization more profitable. Many of the most loved Google 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 the 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:

1. You’re measuring the thing wrong

One of the most popular methods to improve 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, for example, 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 contains a lot of errors requiring the support team to handle a higher number of issues reported by customers? Or what if these features sit in a queue waiting to be deployed in the unchanged quarterly release. Are you really being more productive?

The missing link

There’s one critical flaw in the calculation to determine the productivity improvement. It doesn’t compare apples with apples. A 10% improvement in the development process alone does not necessarily (or probably even) 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 productivity improvement, a baseline lead time from idea to delivered product needs to be measured. 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.

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 centers. 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 center agent cut off the call as quick as possible to meet their targets? Is handling more support calls really indicative of higher productivity? Or is it maybe a symptom of lower quality products?

By its very nature, a call center 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 center in the first place.

Call-centers 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 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 less resources, it is also simply about doing less.

One of the deadly wastes of lean is over production. 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.


Photo by Maciej Serafinowicz on Unsplash