Learning Curve Theory is an important concept in business. In fact, it may be a management consulting framework that can help you in very practical ways in your work. Learning Curve Calculations are a critical part of managing an operation. This article will explore both.
I hear business jargon all the time. Most people generally understand what they are saying, but some business jargon have technical definitions that are not understood very well — especially by the person(s) using it.
Here are a few recent examples of jargon I’ve heard:
- “How many items are in your queue?”
- “That is an effective process.”
- “That product has too many features.”
- “That group isn’t utilized very well.”
- “We need to be more productive.”
- “We need to see things through the eyes of the customer.”
- “There’s too much variation in this process.”
- “Where’s my stuff?”
- “You’re not meeting your metrics!”
- “This business is way too complex.”
- “It was an average experience.”
- “That group is the bottleneck in the process.”
- “Things are out of control.”
- “We need to come to a concensus on things.”
- “Too much travel time in my job.”
One of the items not listed above is the phrase “Learning Curve.”
The Learning Curve
In General, Learning Curve Theory or Experience Curve Theory is defined as the following:
A learning curve is a graphical representation of the changing rate of learning (in the average person) for a given activity or tool. Typically, the increase in retention of information is sharpest after the initial attempts, and then gradually evens out, meaning that less and less new information is retained after each repetition.
The learning curve can also represent at a glance the initial difficulty of learning something and, to an extent, how much there is to learn after initial familiarity. For example, the Windows program Notepad is extremely simple to learn, but offers little after this. On the other extreme is the UNIX terminal editor vi, which is difficult to learn, but offers a wide array of features to master after the user has figured out how to work it. It is possible for something to be easy to learn, but difficult to master or hard to learn with little beyond this.
The concept of the Learning Curve basically states that there is less and less learning as more repetitive steps are taken. The Boston Consulting Group conducted some empirical studies and below are the conculsions from that study:
- The time required to perform a task decreases as the task is repeated,
- The amount of improvement decreases as more units are produced, and
- The rate of improvement has sufficient consistency to allow its use as a prediction tool.
Consistency in improvement has been found to exist in the form of a constant percentage reduction in time required over successively doubled quantities of units produced. The constant percentage by which the costs of doubled quantities decrease is called the rate of learning. The slope of the learning curve is 100 minus the rate of learning. For example, if the hours between doubled quantities are reduced by 20% (rate of learning), it would be described as a curve with an 80% slope. Below is a picture of what that curve might look like:
In other words, over time, it will take less and less effort and time to produce the same amount of output.
The concept of the learning curve is a powerful one and is applicable to all learning processes. It’s easy to see how to apply The Learning Curve to areas such as manufacturing where your outputs are physical products. It’s more difficult to apply The Learning Curve, however, in areas such as services or software.
For services, the easiest way to apply it is to measure the time it takes for someone to do something. Over time — the theory goes — that it should take less and less time for a thing to be accomplished.
For software, it’s difficult to apply the learning curve. It’s not good, nor is it prudent to argue that “over time, an engineer should be able to produce more and more code.” That statement reminds me of my former professor who created an entire neural net that was effective in predicting word-sense and he did it in just 2,000 lines of code. Something like that would have taken me 3x more lines of code. So, the statement doesn’t apply.
Kevlin Henney argues that software development is fundamentally a design-based education. In his words,
The acquisition and presentation of knowledge is all part of the established topic of learning. Learning involves accumulation, consolidation, exploration, articulation and feedback, all of which can be seen in effective software development processes. The emphasis on an iterative and incremental approach is something that distinguishes agile development processes from more bureaucratic and master-planned processes. A cyclic and cumulative approach reflects a learning process. When learning is normally mentioned in the context of software development, it is assumed to refer to development skills. This is the gap filled and fulfilled by books, training courses and so on. But more generally learning and the expression of the knowledge acquired defines the axis along which software development runs: what we learn is embodied and revealed in the code behind the software
For example, there is learning about the domain in which a piece of software runs or is to run, and the specific needs that define the scope and purpose of the software and any changes to it. This responsibility is not only restricted to someone with the title analyst; it applies to all those who are involved in formulating the software, including the party for whom the software is intended. A common criticism of software customers is that they do not know what they want even though they know they want it; it is easier to reason about this perception from the perspective of learning. Unless there is a process that encourages learning on all sides, how else is the knowledge going to emerge clearly? Miracles and master plans? Feedback obviously plays a significant role in all this, and shortening long feedback loops is one of the optimisations that can make any approach more effective.
Henney is especially a big proponent of the concepts of “feed-forward” and “feedback”:
Design is both a feedforward and a feedback process, which makes it a dialogue: between people; between people and the design; between people and the results of the design. This is where learning fits in. So there is a need to shorten long feedback loops, but there is also a need to increase signal to noise ratio by reducing interference continuous unregulated feedback is noisy rather than helpful.
So, in software, Learning takes place not just for the language used, but for the entire development process and lifecycle — including learning that occurs at feed-forward and feedback loops. The goal is to make these loops less noisy.
Impediments to Learning
There are impediments to learning. I can think of two that are important to discuss: Motivation and Boredom.
No matter how repetitive a task is, if there is little motivation or a high amount of boredom for the actor, then there will most likely be very little happening. I know this concept is true for me. When I’ve been involved in jobs that I have found no satisfaction in or have been incredibly bored at, then there is little learning, because there is little caring. This isn’t always true, but it is a factor. I learned this lesson sometime ago.
I once managed a intern from the top research university in the country, based in Boston. This intern had an incredible education and experience coming into the program. This intern began in the Operations side of things, which is where I was. After some time, the intern wasn’t performing well and, in fact, was below aveage for my expectations. After some time of open discussion, we decided to move the intern to a different part of the company. In that area, the intern flourished and performed incredibly well.
The lessons-learned here? The intern didn’t like Operations, but did very well in another part of the business. Because of a lack of motivation, the intern didn’t care about learning or doing well. As the intern’s manager, it would not have been prudent or fair to terminate the intern. But, it was fair and smart to discuss the reasons why and then to act upon those reasons. People need to be motivated and interested in what they are doing. If motivation and interest are absent, then learning and performance will be compromised.
Learning From The Customer
Organizations undertake several methods to learn from the customer. Below is an example of an innovative way that Toyota learns from the customer through the active use of Genchi Genbutsu:
When Yuji Yokoya received the assignment to serve as chief engineer for the second-generation Toyota Sienna, he decided to drive across North America in order to experience the highways his minivan would be driven on. Like his colleagues, Yokoya is a believer in the Toyota engineering tenet: “genchi-genbutsu,” which means: “go, see and confirm.” Yokoya drove a current Sienna more than 53,000 miles, crossing the continent from Anchorage to the Mexican border, south Florida to Southern California and all points in between.
Crossing the Mississippi River by bridge, he noted that the Sienna’s crosswind stability needed improvement. He observed excessive steering drift while traversing gravel roads in Alaska, and the need for a tighter turning radius along the crowded streets in Santa Fe. Driving through Glacier National Park, he decided the handling needed to be crisper. He also made an all-wheel-drive option a priority, along with more interior space and cargo flexibility.
Finally, he decided that the new Sienna would have to be a minivan that families, and especially kids, could live in for extended periods of time. Upgrading seat quality became a priority, along with “kid friendly” features such as a roll down window for second-row passengers, an optional DVD entertainment center and a conversation mirror so parents could monitor what was going on in the back seat.
“The parents and grandparents may own the minivan,” Yokoya said, “but it’s the kids who rule it. It’s the kids who occupy the rear two-thirds of the vehicle, and are the most appreciative of their environment.”
Learning from your customer means that it should take less and less time to develop a product that will suit the customer’s needs. Looking for those unarticulated customer needs is what Genchi Genbutsu is about and then acting on that customer knowledge in product development. Genchi Genbutsu is also known as ethnography, which is a branch of anthropology — or the science of watching people do stuff. It’s a fascinating field of study.
Learning Curve theory argues that it takes less and less effort and time for a thing done in repitition. For optimal learning to take place, make sure there is interest and motivation in the thing beign learned. Otherwise, learning and performance will be compromised. Learning Curve theory can be applied to every aspect of business and life — from software, to learning about your customer’s needs.
Become a Lean Six Sigma professional today!
Start your learning journey with Lean Six Sigma White Belt at NO COST
I’ve been a avid reader of your blog since a month ago when I discovered it. I like the way you are presenting things, connecting the dots and therefore making parallel that are not always seen at first glance.
Thanks for your valuable insight.
I have used learning curve management techniques extensively, but fail to see most of these concepts in learning curve discussions or texts. The result is a great paper plan inadequately implemented due to a lack of vision and understanding of the environment.
1. Maintain documented standards, internal and process controls.
2. Maintain operating procedures and update at least annually.
3. Continually evaluate tooling, equipment, facility, supplies, and training.
4. Include monitoring environmental factors (industry organizations, legal, technological and cultural) in everyone’s performance goals.
5. Consider cross pollination between workgroups, industries, technologies, organization and cultures.
6. Maintain surveillance on technological innovations.
7. Resist technology (any) changes for the sake of change. Verify cost benefit analysis. But always document ideas and concepts for future use. Good ideas do not always have good timing.
8. Develop open culture to receive and distribute best practices between work groups and locations. Cherry picking ideas is OK.
9. Continuous improvement, there is always a better way, limited only by technology, budget and schedule.
10. Maintain flexibility and establish action levels for process changes.
11. Develop a change management culture. (Open communication channels.)
12. Resist hire and forget for new employees. Don’t assume all employees were cut from the same mold. Follow up to ensure employees adapt to the organization’s nomenclature, processes and culture.
13. Encourage fresh eyes to question every aspect of your organization. Some question may have been asked before, but check the current environment to determine if now adoption in part or whole is possible.
14. Have freewheeling discussions and debates/ brain storming sessions.
15. Analytics do not make decisions, management must consider environmental factors outside the numbers and understand the variability of data and hazards of projecting blindly based on an analytical model.
For a learning curve to actually work, management must be actively engaged to ensure goals are met. Expecting a learning curve effect without active management often le4ads to undesirable outcomes.