The Toyota Production System is arguably the most important invention in operations since Henry Ford’s Model T began rolling off the production line. It has spawned numerous approaches to improving operations, all based on the same principles: relentless attention to detail, commitment to data-driven experimentation, and charging workers with the ongoing task of increasing efficiency and eliminating waste in their jobs. This collection of ideas is often termed “lean.” Today most manufacturing companies and some service firms reap its rewards.
But attempts to apply lean approaches to knowledge work have proved frustratingly difficult. Most in the business world believe that knowledge work does not lend itself to lean principles, because, unlike car assembly, it is not repetitive and can’t be unambiguously defined. Consider a bank officer deciding whether to make a loan, an engineer developing a new product, and a social worker ruling on whether a child’s environment is safe: In each instance the work involves expertise and judgment that depend heavily on tacit knowledge—knowledge locked inside the worker’s head.
However, our research in IT, financial, engineering, and legal services reveals that such work can in fact benefit from the principles of the Toyota Production System. For one thing, a substantial amount of knowledge assumed to be tacit doesn’t have to be; it can be articulated and captured in writing if the organization makes the effort to pull it out of people’s heads. For another, all knowledge work includes some activities that have nothing to do with applying judgment and can be streamlined by training employees to continually find and root out waste. Even when knowledge is genuinely tacit, creating systems and rules to guide workers’ interactions can lead to more-effective collaboration.
In manufacturing, there is a common understanding of how to make an operation lean, and many of the same techniques can be employed in different organizations. This is not the case in knowledge work. Nonetheless, we’ve found that lean principles can be applied in some form to almost all kinds of knowledge work and can generate significant benefits: faster response time, higher quality and creativity, lower costs, reduced drudgery and frustration, and greater job satisfaction.
Wipro’s Lean Journey
Our most extensive study of the application of lean principles to knowledge work involves an ambitious initiative at Wipro Technologies. Based in Bangalore, India, Wipro is one of the largest IT services and product engineering companies in the world. It has more than 100,000 employees and 72 delivery centers in 55 countries.
The operations we’ve been studying build complex custom software. They look nothing like an assembly line. Projects are assigned to teams whose members are chosen on the basis of the skills needed to address the tasks, which range from designing software that controls a digital set-top box to creating new e‑commerce platforms. Just as a team of lawyers working on a major case typically includes members with a wide range of expertise, a Wipro software team consists of people with highly varied experience. Some are quite seasoned, others are just starting out; some have specialized skills, others are generalists; some provide broad oversight and support, others do the actual work. By bouncing ideas off one another and trying things out, they come up with solutions.
Several challenges prompted Wipro to embark upon its lean journey, in 2004. Its need for highly skilled employees was increasing just as turnover was rising because of strong industry demand. The days when the company could compete on the basis of low labor costs were over. Nor could it continue to compete on superior quality; its main rivals had caught up. In search of a sustainable advantage, Wipro’s leaders decided to build a lean system. Although they recognized that this approach was unproven in knowledge work and would require a profound transformation of the company, they believed that the potential payoff—the ability to improve faster than their competitors—was worth the risk.
Wipro’s managers were unable to find companies that had used lean techniques to produce custom software on a vast scale. And they discovered that even leading strategy consultancies lacked relevant experience. So Sambuddha Deb, the senior manager in charge of operations, assembled nine other Wipro managers. The group gathered around a conference table and asked a simple question: “How do we do it?” Their answer: “We’ll educate ourselves. We’ll come up with our own ideas for adapting lean to a large-scale software operation, and then we’ll try them out.”
The managers began studying how the lean approach had been applied in manufacturing. They pored over all the written material they could find, toured lean factories, and conferred with a former Toyota guru. Then they brainstormed about how to use what they had learned; each picked an existing project to test their ideas on. Gradually they identified practices that worked.
We’ve been studying this effort from the start. We analyzed the results of 1,883 Wipro projects that involved complex product engineering or the delivery of IT solutions. Of those projects, 772 used a lean approach, and 1,111 did not. We also observed many of them as they were being carried out.
Making an operation lean is a journey of many years, not a big-bang endeavor. Still, we discovered that the lean approach is already having a significant impact. The lean projects we studied performed no better than others on measures of quality (defects and mistakes), perhaps because standards were already high. But they produced superior results in terms of time and cost. On average, the lean projects were completed in 5% less time than had been anticipated; the other projects typically finished at the forecasted time. And the lean projects came in 9% under budget; the others were 2% under budget. (For more details on the results, see “Lean Principles, Learning, and Knowledge Work: Evidence from a Software Services Provider,” by Bradley R. Staats, David James Brunner, and David M. Upton, Journal of Operations Management, July 2011.)
Drawing on our research at Wipro, we drafted some principles for making knowledge operations lean. We refined our ideas after reviewing the literature on lean manufacturing (for a particularly useful article, see “Decoding the DNA of the Toyota Production System,” by Steven J. Spear and H. Kent Bowen, HBR September–October 1999) and studying lean efforts in other knowledge work settings. In the end we came up with six principles, which we’ll describe in detail below. By using them, managers can create the customized lean approaches best suited to their organizations.
Eliminate Waste
Taiichi Ohno, the principal architect of the Toyota system, said there were “seven wastes” that everyone in a manufacturing operation should strive to eliminate: overproduction; unnecessary transportation, inventory, and worker motion; defects; overprocessing; and waiting. Typical knowledge work sites are loaded with these wastes. Indeed, knowledge work includes many routine activities that don’t involve judgment or expertise and can eat up huge amounts of time: printing documents, requesting information needed to make a decision, and setting up meetings, to name just a few.
We’ve found that knowledge workers tend to grossly underestimate the amount of inefficiency that could be eradicated from their jobs. The key is to get everyone in the organization to systematically make waste visible and do something about it. Here’s how to enlist people in the cause:
Teach everyone to ask “the five whys.”
Waste may be obvious once it has been pointed out—but finding it in the first place is not always easy, because it has generally been part of the landscape for a long time. The remedy: Instead of assuming that the approach used for a process is right, assume that it’s wrong. To this end, managers at Toyota devised “the five whys”—a process of continually asking questions until you get to the root cause of every activity performed. Why am I attending this meeting? Why am I filling out this report? Why am I standing at the printer?
When a Wipro team whose project was falling behind schedule went through this exercise, it discovered, first, that its members were solving the same problems over and over. Further questions revealed a bigger issue: The team was so busy trying to keep up with its work that it was neglecting to create standard solutions and train people. This meant that few members had the expertise to handle a variety of problems. In response, the team restructured the project along functional lines, assigned individuals to be primary and backup leaders of each function, and made them responsible for creating standard solutions and training the other team members. People rotated into a different function each quarter to further ensure that everyone acquired broad skills. Although these measures initially added to the time needed to perform work, soon the team was able to speed up, and it delivered its project on schedule.
Encourage everyone to look for small forms of waste, not just big ones.
Most successful companies have already eliminated large, obvious forms of waste, but the floors of knowledge operations are typically littered with nickels that no one has bothered to pick up. Think about your own workplace. How many e‑mails clutter your in-box because someone cc’d you unnecessarily? How long did you have to wait to start a regularly scheduled meeting because attendees slowly trickled in? How many reports are created that nobody reads?
To continually identify and root out waste, an organization must learn to care about the small stuff. This means helping people see how much waste surrounds them and recognize that eliminating it will free them up to do more-valuable (and more-rewarding) work. It means applying the five whys to everything. And it means devoting time and other resources to eliminating waste.
One project team we observed early in Wipro’s lean journey knew that it needed to identify small sources of waste but wasn’t sure how. It decided to use a value-stream map to jump-start the process. A value-stream map not only captures the detailed, individual stages of a project in progress but also identifies value added and waste. A team must track each step it takes and ask, “Why did we do that?” This allows it to create a prioritized list of elements that can be eliminated.
The team we studied was developing printer drivers—software that controls printers. As the members wrote code, they needed to test the code on a printer. Value-stream mapping highlighted several forms of waste. For example, four people who used the same printer often found themselves standing around the machine while the others’ jobs were printing. The frequent switching among users also meant that they spent a lot of time adjusting the printer settings for their particular needs. And because the printer was on a different floor, they were constantly running up and down the stairs—a round trip of five to 10 minutes.
Having pinpointed these forms of waste, the team found space for the printer on its own floor and designated time slots for each user. These and many other small changes enabled it to devote much more time to real work.
Periodically review the structure and content of every job.
Many knowledge jobs are unstructured and broad. They tend to expand gradually as one activity after another is added. People can end up with too much on their plates and too much time devoted to low-value tasks.
Managers should regularly assess their employees’ tasks, including how much time is spent on each. One product development organization that undertook such a review found that task creep, inadequate prioritization of assignments, and a lack of understanding of what made up a full workload had created a situation in which its engineers typically had twice as much work as they could realistically perform. This was causing significant bottlenecks, excessive switching between tasks, missed deadlines, and employee burnout. So the company reduced engineers’ workloads so nobody’s commitment exceeded 100% of his or her capacity. This meant that not all the work that had been planned could be scheduled, and managers had to make hard choices. However, employees’ productivity and satisfaction increased.
Specify the Work
The practice of writing down exactly how to perform a task—clearly defining the substance, order, timing, and desired result—has delivered significant value to manufacturers. It allows the actual and expected outputs to be compared. If the two don’t match, the organization knows there’s a problem with adherence to the process or the process itself and can take action to fix it.
At first glance, this approach may not appear relevant to knowledge operations. Many of the processes in knowledge operations are worked out inside an employee’s head; they may be invisible to others and hard to articulate into concrete, replicable steps. An investment banker, for instance, may not be able to easily explain how he persuaded someone to accept a deal.
In addition, the work in a knowledge operation may change rapidly, and on any given day people may do a mix of tasks—some that require judgment or intuition, and some that could be reduced to a protocol because the problem and the best ways to address it are well understood. Precisely because people typically perform both kinds of work, they and their organizations assume that many tasks that could be standardized can’t be.
Despite the challenges, a surprisingly large amount of knowledge work can be specified. And once it has been, it can be continually improved. The key is to challenge the assumption that all knowledge is inherently tacit. One manufacturing company we know of had an experienced scheduler who assigned the work throughout the factory. The company’s leaders, wanting to improve the scheduling process, asked a senior manager to interview him. Initially he answered the manager’s questions with vague generalities. But when the manager persisted, asking him to explain why he made one decision rather than another, he began giving concrete, detailed answers. The manager gradually uncovered the implicit rules the scheduler was using. The company then adjusted the rules, and performance climbed.
Specifying knowledge work involves four steps:
Look for repeatable parts of the process and codify them.
Almost all areas of knowledge work have more commonality than meets the naked eye. At Wipro, teams found it difficult to specify the overall code-writing process, because it often involved onetime novel solutions. But when they reframed the question to ask “What do we do repeatedly?” they realized that many aspects of the process, including peer review, daily builds (integrating all the pieces of code written that day into the program), testing, and customer reviews all occurred frequently within a project and across projects and could be standardized.
Don’t try to specify everything initially, if ever.
Some tasks occur so rarely that the investment needed to specify them is not worthwhile. And sometimes a problem is so poorly understood that an expert must advise about how best to address it. However, even in these instances parts of the process can be specified.
A Japanese bank that wanted to grow its home mortgage business found that hiring expert credit analysts to support the desired growth would be costly and difficut. But managers recognized that by carefully studying past lending decisions, they could derive the rules used to make them and embed those rules in an IT system. The system didn’t completely eliminate the need for experts, who had to make judgment calls in cases that were unusually complex or involved special factors. However, the vast majority of cases could be handled automatically, allowing the company to rapidly and safely grow its mortgage business.
Use data to get buy-in.
A major benefit of specifying repeatable processes is that knowledge workers are then freed up to focus on the parts of the job where they can create the most value. But many highly trained professionals don’t believe that their work can be made explicit. For example, although specifying work can improve outcomes in medicine, doctors often vigorously resist, arguing that their judgment and expertise cannot be reduced to a set of rules. (See the sidebar “Further Reading from HBR” for articles on this topic by Richard Bohmer and Steven Spear.)
Because successful specification of work often depends on workers’ involvement, overcoming such resistance is crucial. Proving the effectiveness of the process is key to overcoming such resistance. Wipro recognized this early on and began tracking where and how the specification of tasks was boosting performance. It quickly saw that specification was particularly beneficial to projects running behind schedule. Managers were then able to use the data on these projects’ improvements to win over other parts of the organization.
Keep studying the work that has been designated as tacit.
Even if work isn’t specified today, that doesn’t mean that it can’t be tomorrow. What is currently an uncommon event may happen frequently in the future. And the understanding of complicated problems can grow over time. In “Fixing Health Care on the Front Lines” (HBR April 2010), Richard M.J. Bohmer describes how Intermountain Healthcare, a company operating in Utah and Idaho, excels at regularly improving protocols for treating diseases. One approach it employs is allowing physicians to override protocols in ambiguous situations. It collects and analyzes the data from overrides and uses the knowledge from successful ones to improve the protocol. If an override produces bad results, the company uses the data to persuade doctors to stick with the routine more often. Intermountain has even created a unit to test clinicians’ ideas and hunches. One test led to better criteria for transferring patients from wards to intensive care.
Specifying work in the systematic manner we’ve described enables a knowledge organization to continually engage in disciplined learning. Waging such an effort often demands dedicated resources. Wipro created a productivity office to track best practices, investigate new ideas, aid education efforts, and help devise practical standard procedures that could be used across different teams.
Structure Communications
Recognizing that many problems are too big or complex for one person to tackle, organizations are increasingly using teams to do knowledge work. However, once multiple people are involved in a process, effective communication becomes imperative—especially because teams may have members all over the world. A lean system can promote good communication by articulating the ways in which it should be carried out. Here’s how:
Define who should be communicating, how often, and what.
Knowledge workers need to understand who will use their output. When the supplier of the work is in direct contact with the “customer” (typically someone on the same team), the two can collaborate to ensure that the output performs as expected. If frequent communication generates a rich flow of information, problems can be spotted and fixed early on. And when the desired content of communication is spelled out, people get the information they need and don’t have to waste time trying to figure out what others are saying.
One tool Wipro adopted to aid communications was the design structure matrix. In a DSM, a project’s tasks are listed along the rows and columns of a matrix, and the team marks whether each item is related to the others, designating each relationship as either a direct dependency or a feedback loop. Matrix algebra can then create a recommended order for the tasks. (For more on the DSM, see “Are Your Engineers Talking to One Another When They Should?” by Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, HBR November 2007.) The math is somewhat complicated, but Wipro used a simplified spreadsheet version that any team could understand. With one push of a button, the program ranked the tasks and identified which team members needed to interact about each one and when.
Create a shared understanding.
Members of knowledge teams increasingly work across geographic, cultural, linguistic, and functional boundaries. This means they may not have the same take on what is being communicated; the same words may have different meanings to different people. Consider the interactions between people from a U.S. company and its Indian provider of IT services. One exchange we documented involved a seemingly simple question: “Can you get the work done by a certain deadline?” To the people from the U.S. company, yes meant yes and no meant no—and if anything went wrong, they might shout and pound the table. By contrast, the Indians often conveyed no so indirectly that their U.S. counterparts heard yes. And when the Indians raised problems, they framed them as softly worded questions, which were largely ignored by the U.S workers, who were unaccustomed to such subtleties. Even though communication between the two groups was structured—there were regular updates between designated parties, focused on set discussion points—the messages weren’t getting across. The U.S. company learned that whenever it entered into a new supplier relationship, it needed to specify exactly how the supplier should communicate.
The need to structure communications and build a shared understanding was also evident at a magazine we know. One editor might acquire a long article from an outside author and hand it off to a colleague to edit. The task of turning such contributions into high-quality articles on time was often challenging and stressful. Management recognized the dilemma but thought it was inescapable: It believed that handoffs were inherently difficult because editing involves tacit knowledge of the subject matter and how to express the ideas, and no two editors approach a piece in the same way.
These things were true—but part of the problem was that there was no specified process for the two editors to communicate about the purpose of the article and how to achieve it. Often they failed to talk at all. Even when they did confer, the conversations weren’t structured. The two might have wildly different ideas about the draft and the work needed before it could be published, and there was no formal means of reconciling clashing points of view.
The magazine had a specified process for submitting proposals for articles: Each was supposed to include a written description of the piece’s value and an editing plan. But often the proposal was based on the author’s description of an envisioned article, and the draft that ultimately arrived might depart significantly from the proposal. And sometimes an acquiring editor would bypass the process by presenting a proposal to the chief editor in an oral pitch.
A more effective approach would have stipulated, first, that every editor submit a written proposal, so that the reasons for publishing the article—the value it would deliver to readers—would be on the record. Once a full draft of the article had been received, both the acquirer and the assigned editor would have to write a detailed critique and editing plan. (The latter might include the structure and length, the need for additional content, the use of examples, and an estimate of the time needed to complete the job.) The final step would be a structured conversation facilitated by a top editor, during which all three would reach agreement on these issues.
With well-specified communications, individuals understand the work they are taking on. This allows them to spend time solving problems rather than trying to figure out the job at hand.
Resolve disagreements with facts, not opinions.
A long line of research highlights the ways in which emotions and irrationality can distort the decision-making process. This can be an especially big problem when the work involves tacit knowledge, because it’s often not at all clear how an expert arrived at a particular decision and to what degree that decision was based on intuition or emotion versus facts.
One of Wipro’s lean projects illustrates the challenge and benefit of unambiguous communication within a team. The team in question had implemented a system of regularly scheduled reviews in which more-experienced members evaluated software code written by their less-experienced colleagues. The reviewer for each junior member was different each time. The purpose was to excel at finding and fixing different types of mistakes, help less-experienced people improve, and allow team members to get to know one another. Unfortunately, the senior reviewers used different standards and communicated assessments differently. What was good code writing to one might be an error to another. Even when reviewers agreed on what constituted an error, they often called it different things. The lack of common standards and communication hurt junior employees’ morale.
One of the reviewers spotted the problem and called the team together to discuss it. The group recognized that it had an opportunity to standardize communications as well as the primary work. Some of the senior members put together a list of common errors and their definitions, for all the reviewers to use. The exercise led the team to realize that many mistakes they had considered to be fuzzy errors—issues involving such things as how variables were defined and how explanations were embedded into code—were actually quite concrete. And once these things were spelled out, the errors could be systematically fixed.
The team’s language soon became so precise that even a machine could understand it: The code-writing program could automatically evaluate whether members had followed the guidelines and would raise a red flag if they had not.
In the end the team found itself spending less time fighting over what was an error and more time working on preventing errors in the first place. The incidence of errors dropped dramatically as a result.
Address Problems Quickly and Directly
One of the fundamental goals of the Toyota Production System is to turn an operation into a problem-solving engine. The core of that engine is the scientific method: articulating an explicit and measurable hypothesis about how some aspect of work could be improved, conducting an objective test of the hypothesis, and, if the data support the hypothesis, making the approach the standard. But there’s much more to it than that. Here’s how to adapt the scientific method in a knowledge setting:
If a problem arises, ideally the person who created it should fix it.
Problems can crop up because the work process is flawed or because the worker has made a mistake. In either case, involving the worker in solving the problem usually results in a quicker solution, because the people closest to a problem typically know the most about it. If this isn’t feasible, the worker should participate in applying the fix. Recall that at Wipro, the senior members of a software team would check the code written by novices. If an error was found, the novices, not the experts, were responsible for fixing it, with help from their senior colleagues when needed. This ensured that the novices knew when they had made a mistake and understood what had gone wrong, reducing the likelihood of their making similar mistakes in the future.
Problems should be solved where they occur.
Location provides important contextual information. Without that information, those trying to solve a problem can’t reproduce exactly what happened and are much less likely to succeed.
In an era when team members are often spread throughout the world, the lean idea that everyone trying to solve a problem should be able to see it firsthand might seem unfeasible. But modern technology makes it eminently possible. For example, some members of one Wipro team we observed were responsible for testing software at a U.S. customer’s site; other members, based in India, were responsible for fixing any bugs that emerged. In this case the team members weren’t just in different locations—they were in different time zones. One group was typically sleeping while the other worked. Sometimes the engineers in India couldn’t replicate the errors that their colleagues in the U.S. had found and therefore couldn’t fix them. Ultimately, the team decided to have the U.S. group use web-video tools to record the steps they took and the system configurations that had produced an error; this made it much easier for the engineers in India to identify the causes and fix the problem.
Solve problems as soon as possible after they emerge.
The fresher the information about a problem, the less subject it is to distortion, and the easier it becomes to find the cause. Attacking a problem early on also helps you make the most of the incident as a learning opportunity. This is why Toyota has employees pull andon cords to sound the alarm when a problem occurs. Even if installing similar alarm systems in, say, a law firm or pharmaceutical lab isn’t feasible, applying the principle behind them is. With this in mind, one Wipro team that had been checking its newly written code weekly switched to having frontline engineers check one another’s work daily, while team leaders reviewed the group’s work every two or three days. The incidence of errors dropped.
By using the scientific method and having whoever caused an error fix it where and when it occurred, a knowledge organization can build a problem-solving engine that drives continual improvement.
Plan for an Incremental Journey
Applying lean principles to knowledge work is not simply a matter of copying tools that have been successful in manufacturing. Instead, you must use the contents of the toolbox to invent something new. You probably won’t get it right on the first try, but over time you can put together a system of continual improvement by doing the following:
Start small.
Wipro launched 10 pilot projects to explore whether a lean approach was a viable option. When eight showed promising results, it tasked the productivity office with leading an enterprise-wide effort. Bit by bit, the company learned which ideas worked, which ones needed refinement, and which should be discarded.
Codify the lessons learned.
It’s important that someone in the organization have an overall view of the initiative; otherwise valuable learning could easily be lost. Wipro’s productivity office filled this role, reviewing every lean project, leading education efforts, and helping standardize practices.
Keep looking for new ways to work.
Although progress at Wipro was steady in terms of the number of lean projects undertaken, senior managers recognized that widespread adoption was only one measure of success and that implementation also needed to be deep.
Three years into the lean initiative, all the outward signs were promising. Employees were broadly engaged, customers were expressing interest in applying Wipro’s new methods to their own IT operations, and the growth in the number of lean projects was enormous. However, during their ongoing review of the effort, the initiative’s leaders saw that some teams were applying lean approaches just to certain parts of their projects. Worried that teams might adopt only a few of the most superficially appealing tools and not fundamentally change how they worked, the leaders stopped adding projects to the effort and made time to reexamine experiences to date. They created detailed, stage-specific recommendations that could be applied to various types of projects. Finally, recognizing that they lacked the resources to support lean efforts across the board, they decided to focus on larger projects, where the potential gains were greatest. When this groundwork had been completed—a matter of three or four months—they relaunched the effort, and the benefits increased.
Remember that the lean approach is not useful everywhere.
If the work at hand is visionary and experimental and requires inventing new ways to perform tasks, don’t try to apply lean principles everywhere. Repetitive tasks within the work can and should be addressed with lean ideas. But innovation will suffer if the time needed to come up with and test wild ideas is classified as waste and eliminated.
Engage Your Managers
In the long run, lean principles result in bottom-up improvement: Frontline people generate and implement new ideas, while managers play a supporting role. But this is the end state; an organization rarely, if ever, starts there. Middle and senior managers are critical in launching the process.
Project managers and other midlevel leaders must train and motivate their teams.
This requires a significant investment of management time. During our research, we found that teams that had leaders who were heavily engaged in the lean initiative—who educated their teams and persuaded them that lean efforts would improve performance—were more successful than teams whose leaders were not. At Wipro, either the project manager or a certified lean instructor conducted the initial training. Then it was up to the project manager to push the team to use the ideas.
Senior leaders must be long-term champions.
Many organizations suffer from process improvementitis. Their leaders pay lip service to the initiative of the month—and, not surprisingly, people don’t take the initiatives very seriously.
Turning an organization into a lean system requires a grassroots reinvention of how work is performed. That’s as true in knowledge work as in manufacturing. The transformation demands sustained investment, a huge amount of training, a new culture, and new processes. Senior leadership must treat it as a long-term change program.
Azim Premji, Wipro’s chairman, understood this well; he was deeply involved with his company’s initiative from the start. He personally reviewed lean projects, consistently met with the leaders of the initiative, and spoke about it to the outside world. His public commitment made clear to employees that the program was there to stay.
Turning a manufacturing plant into a lean system requires enormous, relentless effort. Persistence, not genius, is the key.
Turning a knowledge operation, which has far fewer repetitive, codifiable processes, into a lean system is harder still. But as we have witnessed, it can be done. And the very difficulty means the system will be tough for a competitor to replicate. This is its power.
1. Continually rooting out waste should be an integral part of every knowledge worker’s job.
2. Strive to make tacit knowledge explicit.
3. Specify how workers should communicate with one another.
4. Use the scientific method to solve problems as soon as possible. The people who created the problem should fix it.
5. Remember, a lean system takes years to build.
6. Leaders must blaze the trail.
0 comments:
Post a Comment