Discover more from Gad’s Newsletter
Scaling (Process) Innovation: Know-How vs. Know-Why
The New York Times had an interesting article earlier this week on Amazon. The article documents several interesting stories about Amazon, such as the fact that the firm is growing at an unprecedented speed, and also describes how Amazon was less than forthcoming (definitely less than it promised) about Covid cases, both internally, to its own employees, as well as externally, to the authorities.
While reading this article, several things stood out to me. The first one was that while Amazon has many processes, including very detailed metrics to measure the performance of each employee and detailed instructions for everything operational, the processes regarding HR and people management are much less sophisticated. From promotions to grievances, to dealing with an ill employee, the firm’s processes are ad-hoc and quite chaotic. This side of the “equation” is just not as developed as the customer side, which of course, is not just an error of omission. It cannot be that someone didn't notice.
The second thing that stood out was the statements made by Jeff Bezos, which are quoted in the article by former employees:
“David Niekerk, a former Amazon vice president who built the warehouse human resources operations, said that some problems stemmed from ideas the company had developed when it was much smaller. Mr. Bezos did not want an entrenched workforce, calling it “a march to mediocrity,” Mr. Niekerk recalled, and saw low-skilled jobs as relatively short-term. As Amazon rapidly grew, Mr. Niekerk said, its policies were harder to implement with fairness and care. “It is just a numbers game in many ways,” he said. “The culture gets lost.”
In an effort to unpack this quote, I see two interesting aspects. First, it is interesting to read that this culture was there from day one. While it is well-known that Amazon aims to maintain this "Day 1" mentality, it is always interesting to see that even when it’s not intentional, early decisions may remain in power for much longer than you would have imagined, along with both their positive and negative effects.
The second thing that can be learned from this statement, and in my opinion, the more important one, is that Jeff Bezos didn't want to have a “march to mediocrity” by letting employees remain in their positions for too long.
This statement’s primary assumption is quite simple: workers (specifically front-line workers) are liabilities to the firm. We need them now, but if they stay on too long, they become less motivated, and over time, this will result in the firm’s decline.
I would like to contrast this viewpoint through the Lean Operations system or the Toyota Production System, which believes the opposite. The Lean Operations system assumes that the employees are the ones that drive continuous improvements by making small changes on the shop floor. Empowering employees to make small changes and alert the entire organization to quality issues has been the hallmark of this method.
For example, Toyota (and almost every exemplary implementation of Lean) has been using the notion of Andon:
“Toyota has used Andon cords (see below) to help workers quickly raise issues in the production line as they occurred. Pulling the cord initiated a signal sent to the supervisor to review the issue. The Andon notification is displayed using a color-coded light system (see below) that indicates the current status at each workstation. The supervisor performs genchi genbutsu by going to the area of concern and investigating the problem.”
You read it correctly. Any employee on the line can alert someone regarding any issue. If the problem is small, it will be solved by the employee and their supervisor. If not, it will escalate to the point that the entire production line may have to stop. Although this does not happen very often, it can happen, and I have seen it happen.
Nevertheless, and before we all start soapboxing, let’s take a step back and make sure that the difference between Amazon’s and Toyota’s views are clear, and while we are at it, let’s also clarify why both may have some merit.
One of the central debates in Operations is whether the best method for organizational learning is through "Learning by Doing" or "Learning Before Doing”. Where does the center of gravity of process innovation lie? Intuitively, I know that the question forming in your head is, "why not both?", but let’s wait on that for a bit.
Learning by Doing
The goal of organizational learning is to ensure that the firm is becoming more efficient and provides a better service to its customers, understanding that market conditions and technologies change. This goal is at the core of both approaches.
“Learning by doing” is where the employees on the ground, the front-line workers, improve the operations and product. For example, it can be a line worker that makes changes to how things are assembled. It can be the Careem (later acquired by Uber) country manager deciding whether to add features or not. It can be a warehouse manager for an e-grocer deciding to organize the warehouse differently. In a healthcare setting, learning by doing allows nurse practitioners to implement changes they believe will improve the safety of their patients. These process improvements can be big or small. The notion of “learning by doing” is the heart of the lean method.
It is essential to highlight the underlying assumptions of learning by doing. The first is that knowledge is local, thus proximity to the "action" and customers is essential. It assumes that the workers are a source of knowledge since they are close to the customers, and if they are empowered to do so, they can drive innovation. The final assumption is that "Know How" is crucial for success. Practical knowledge is superior to theoretical knowledge.
Learning Before Doing
On the other corner of the ring stands the "Learning Before Doing.” This is very much what we see in Amazon’s example: employees are measured tightly by KPIs dictated by HQ (or any other central administration). There are plenty of examples of “learning before doing” and they are actually more pervasive than the ones we see in "learning by doing". For instance, our freedom in choosing a video conference software is limited. The HR practices set by the organization we belong to are specific and must be followed. The power to choose what is reimbursed is not ours. These, and other processes, are dictated from above, and while Amazon may seem extreme, most of us are in a system where leadership makes decisions we cannot change, even if we find them inefficient.
The main underlying assumptions here may sound a little harsh, but they circle around the fact that workers are viewed as those who inject “noise” and underperformance into the system and thus have to be "controlled" and "monitored", rather than motivated. To illustrate, the employees of an organization, that shall not be named here, received an email stating that they will have to be in the office at least three days in July and at least eight days in August, in preparation for their return in September. Why 8? Why not 9? Why not 3? Is this attentive to the best and most efficient way to return to work? My question is obviously rhetorical.
Another underlying assumption is that knowledge is central rather than local. The central admin knows best. They know how to pick and pack in a warehouse. They know which features work best in each geographical location. They know what systems are most suitable, and thus KPI's are derived from the top to deliver what the central administration perceives as optimal.
If learning by doing prizes "know-how”, then learning before doing prizes "know why." Indeed, “know why” is much easier to aggregate centrally, and thus there is no question that "Learning Before Doing" scales better in the sense that you avoid duplicating decision making. You test what works well and then replicate it, rather than letting things brew and develop in different parts of the organization. But the critical question, of course, is whether you believe that such knowledge indeed exists centrally.
Which learning method is better? Hard to say. Different markets, different roles of operations, different roles of technology. If people are the key differentiator in your industry and business model, then the “learning by doing” method is better. If scale (and thus technology and data) are the differentiator, then you choose “learning before doing”. There are no optimal solutions. Only trade-offs.
Now, let's go back to the question of why not both. Why not mix “learning by doing” with “learning before doing”? It is possible, of course, but very hard to execute. Why? Because every time a decision is made centrally, the incentives of those on the floor to make suggestions the next time they see inefficiencies are reduced. For example, in the Toyota Production System, the most important moment is the team’s reaction to the employees’ alert. The real difference here is asking "Where is the issue?" rather than "What have you done wrong...again?". We have all worked in places where employee suggestions and suggestion boxes were just like the Never Ending servings at Olive Garden: bottomless, tasteless, and thus, useless.
There are examples of firms that have managed to achieve this mixed model. Haggy Rao and Bob Sutton describe the success of Kaiser Permanente (a healthcare service provider) in scaling the adoption of its IT system by its different units. The firm created a "guardrails system" where the local offices were allowed to build their systems with specific guides from the top: they had to have the same look and feel. The local systems had to be interoperable and have the same data structure, yet they could develop systems that fit their specific needs. It's not impossible, but such a hybrid requires a lot of coordination. It also comes from two opposing philosophies on who has the knowledge: the leadership or the worker. These cultural differences are usually harder to reconcile than the processes themselves.
Education: Which one is Better?
For the parents among us, let's try to see how we view our kids’ teachers.
This is an example where most educational leaders and politicians believe that knowledge is central. From the Common Core to the No Child Left Behind, to whichever new system is going to be proposed, they believe in “learning before doing”. The underlying assumption is that teachers are the source of the issue, and thus we need to, first and foremost, improve the quality of the teachers. They are not motivated. They are not knowledgeable. Although most of us agree that our kids have excellent teachers, overall, the belief is that teachers are the problem rather than part of the solution.
So, most educational systems are built top-down. Decisions are made at the state level, which dictates directives to the school districts, which, in turn, dictate actions to the teachers, who usually have very little freedom to make adjustments to their curriculum and methods. Is it justified?
"Combining DonorsChoose data with data on student test scores in Pennsylvania from 2012–2013 to 2017–2018, we find an increase in the number of DonorsChoose projects funded at a school leads to higher student performance, after controlling for selection biases. For a school with zero funded projects, one funded project—of about $400 in value—translates to between 2 to 9 more students scoring basic and above in all subjects in high school and science and language arts in primary and middle school. We find this effect is driven mostly by low-income schools, indicating funded projects help close the achievement gap. Our study suggests that those in the education sector can harness the wisdom of frontline workers—teachers—to improve effectiveness and equality".
The question here is not whether you like the mechanism of crowdfunding or not, but rather whether empowering frontline workers to make decisions and giving them the freedom (and the budget) to do so will result in better outcomes.
As mentioned above, this is not the case in most educational organizations, from what I hear, which makes the results of this study quite significant!
The point of this is to show that we can criticize Amazon all day, but we are all guilty of this crime. We like to be empowered by others, but the reality is that we tend to believe we have the right answer and would like to be the ones setting the processes towards the solution we have suggested.
Back to Amazon
A few years ago, in his letter to shareholders, Jeff Bezos was very proud for using the notion of the “Andon Cord”
“We build automated systems that look for occasions when we’ve provided a customer experience that isn’t up to our standards, and those systems then proactively refund customers. One industry observer recently received an automated email from us that said,
We noticed that you experienced poor video playback while watching the following rental on Amazon Video On Demand: Casablanca. We’re sorry for the inconvenience and have issued you a refund for the following amount: $2.99. We hope to see you again soon.
Surprised by the proactive refund, he ended up writing about the experience: Amazon noticed that I experienced poor video playback’ And they decided to give me a refund because of that? Wow. Talk about putting customers first.”
And here is the Ad for a related role:
But notice the subtle difference. While at Toyota, the Andon Cord was a tool for the frontline workers, at Amazon, it is a “robot” run by technology and data.
Finally, my personal angle on this issue: Over the years, I have managed different teams. Whenever I criticized a solution that was suggested (and my readers know that I can be critical at times), the common question was, "OK, so why just not tell us what you want, rather than having us guess?". My usual response has always been, "If I knew the answer, I would not need you". Over the years, I built teams where we all believe in learning by doing and value quick iterations with those closer to the “action.”
But this is also true for my long-term goals as an educator. The reason I keep on researching, teaching, and writing is that I genuinely don't know the answers.