10 things I've learned from 10 years of studying lean manufacturing

Lateral thinking has proven to be one of the most effective habits I've developed in my career. Over the last 10 years, learning about lean manufacturing has benefited my work in software more than any other topic.

10 years ago, I stumbled across the topic of lean manufacturing. I had recently shifted my career into web design and engineering and was underwhelmed by Scrum and other permutations of Agile. The original intent of Agile seemed clear and focused, but the day-to-day reality of how teams were managing projects and their overall process seemed over-engineered, heavy, and exhausting.

Then I discovered modern lean manufacturing and was drawn to the simplicity and lightness, along with the deep commitment to quality and continuous improvement.

For the last decade, I've independently studied all aspects of lean manufacturing, including the history of the Toyota Production System, the emergence of 2 Second Lean, and all the recent transformations companies have undergone.

There's something so concrete about observing physical processes moving through a factory, learning to identify and address waste, and clearly recognize improvements in quality, efficiency, and most importantly, the happiness of the teams and customers. These learnings have allowed me to spot and correct the much more abstract wastes found in digital work, and address areas of need that no software development methodology even considers.

I want to cover 10 things I've learned that have most impacted my work. I'm going to avoid technical terms, concepts, and theories wherever possible, but would be happy to expand on anything in future posts.

1. Everything is a process

The first mistake many individuals and teams make is to think lessons from another industries or types of companies don't apply. How can learning about physical production lines in a factory help with software development?

The truth is, the industry, product, production steps, etc. are all arbitrary.

What unites all forms of work is: everything is a process.

This realization is critical to understanding that everything, from welding an aluminum frame, to reviewing scientific findings, to designing and engineering a dropdown menu in a web app, is a process that creates or destroys value.

In fact, our job titles are misleading. A designer's job isn't to design user interfaces. Their job is to continuously improve the process of designing user interfaces. Any role should basically be considered to that of a "process engineer."

So, the lessons learned by other industries, even with wildly different contexts and approaches, have underlying, universal truths to learn.

2. There's always a customer

In addition to everything being a process, we need to realize every process has a downstream customer.

Of course, a business serves customers who buy a product. And of course, we want to serve them and produce the best quality and value for our customers.

But, we need to recognize that everything we do always has a customer. Within a team, that customer is usually internal. The customer might be someone in a different role or layer of the organization, and sometimes is yourself, present or future.

If we ask "who is the customer?" with any project or decision, we can be clear on who we're serving and creating value for. This practice completely inverts an org chart. The CEO's customers include everyone in the company. A manager's customers include everyone on the team. An engineer's customers include a pairing partner, a designer, or customer advocate.

And of course, everyone in the company is there to serve the actual customers, first and foremost. But, this is usually top of mind already, and sometimes is used as an excuse for not serving or even sacrificing internal customers, which ironically will also destroy values for external customers.

3. Blame the process, not the person

With processes behind everything we do in service of a customer, how should we respond when someone makes a mistake or we discover waste?

We should blame the process, not the person.

This inverts the typical reflex of assuming a mistake is an individual failing, shortcoming, or skill issue.

Instead, we need to realize that the vast majority of people really just want a challenging, interesting, and rewarding career. We're all just hoping to do a good job, contribute meaningfully, and benefit from the shared success of our work.

Next, we need to recognize that, outside of rare cases of actual sabotage, mistakes are the result of some upstream process, decision, or even standard. Everything from a complete lack of process to a very considered and detailed process has waste and risk of mistakes.

With this in mind, our first thought when something goes wrong is to blame the process. This engages everyone, including the person who made a mistake, in making things better.

Issues no longer become a point of individual blame and shame. They become an opportunity for improvement. The individual who made the mistake is no longer the wrongdoer. It shouldn't reflect on their personal performance. They become the most recent expert in what went wrong, what caused the issue, and how we might prevent it in the future. Their experience is the most valuable information to understand, and their ideas and creative solutions are key to improving. They should be evaluated on their contributions to the improvement.

4. Learn to identify and not tolerate waste

The default mode for many teams is performing routine work without question or reflection. Because everything is a process, and every process has waste, it's critical to learn to identify waste.

The best way to do this is to be sensitive to anything that creates friction, frustration, or struggle, no matter how small. As you work, continuously ask if there's a better way.

In learn manufacturing, there are 8 types of waste:

Transportation: unnecessary movements of products or materials
Inventory: excess raw materials, work in progress (batch processing), or finished goods. Often the root cause of other wastes.
Motion: unnecessary movements of people
Waiting
Overproduction: making more than the next process needs
Overprocessing: unnecessary steps or processing that often lead to transportation waste
Defects: efforts caused by reject, rework, returns
Skills: wasted human genius and potential. The worst of the 8 wastes.

Although these originated from physical manufacturing, they easily map to software development:

Transportation: every code change has to go from commit, to pull request, go through review, get merged to staging, get validated, get rolled out to production, etc.
Inventory: concurrent projects create excessive work in progress, leading to waiting, overproduction, overprocessing, transportation, defects, and more.
Motion: documentation is hard to find. Knowledge and communication are split across many tools and locations. Code is divided across multiple codebases and services. Work is spread across multiple tools, services, and logins.
Waiting: tests, pre-commit hooks, CI/CD actions take too long run. Pull requests are waiting for review. A question or request for help goes unanswered and blocks progress.
Overproduction: ideas are easy to spin up, which exacerbates already stressed engineers. Low-value features and side projects don't have customer demand and dilute the product.
Overprocessing: upfront, high-fidelity design is often unnecessary and thrown away after a feature is built. A proposal goes through several layers of review and formalities.
Defects: bugs, typos, downtime, etc. This is one of the only wastes software teams are actually aware of and sensitive to.
Skills: wasted human genius and potential in any industry is common and equally damaging

Once you notice something wasteful, or even something that simply bugs you, don't accept it. All too often, teams can list tons of things that frustrate them or are clunky, but never get around to doing anything about it. They defer to how things have always been and assume that's how they have to be. Teams can have incredibly high tolerance for tech and process debt, where things that drag down daily work are allowed to persist for years or never get addressed.

5. Stop and fix

So, everything is a process in service of a customer, every process has waste, and we should blame the process instead of the person when finding mistakes, defects, or waste. But what do we do when we find a problem?

We should stop and fix.

Yes, we should immediately stop what we're doing and fix the problem. We should prevent it from occurring again. And, others should stop what they're doing to help.

This sounds absurd and completely inefficient to teams when they first hear it. The thought of halting all output to fix a problem seems to threaten deadlines, burn valuable time and energy, and be wildly disruptive.

The main pushback I've heard is: "we don't have time to do that. We're too busy to stop everything every time a problem comes up."

But, the truth is: you're too busy to fix your problems because you're too busy to fix your problems.

The reason why you're so busy, the reason why there's no slack in the system, the reason why stopping to fix a problem would jeopardize shipping on time, is because you never address the problems that create waste, destroy value, and eat away at your capacity.

To illustrate this, let's talk about Toyota. Toyota assembles tens of thousands of vehicles a week. And anytime a person on the assembly line encounters an issue, they pull a chord that halts production. Everyone around immediately comes to assist the person who pulled the chord to help diagnose and fix the problem.

In just one of their factories with 250 assembly line workers, they do this 16,000 times in 1 week. Each person pulls the chord more than 60 times a week. And this is a company that is world-class in quality and consistency. They got this way by stopping and fixing to ensure defects don't make it past where they originally occurred.

6. Make daily improvements

Like stopping and fixing, this next practice receives the same excuse of "we don't have time to do that." Teams dedicate the first 30 to 60 minutes of their day to fix what bugs them and make small, incremental improvements.

This practice involves something called Daily 3S. 3S stands for "Sweep, Sort, Standardize."

Sweep: clean the work area. This can be physical, digital, or both. As you clean, remove anything unnecessary, make things nice, and look for waste or signs of defects.
Sort: put things back. Reset the work area to the way it should be.
Standardize: make the improvement stick. If something doesn't have a dedicated place, make one. Organize or reorganize things to make them more readily accessible based on what you need in your work.

This practice has immediate benefits for each day of work. It's also a great warm up to get momentum for deep work and deeper problems. And, it's the best way to learn to identify way, try ideas, and engage in creative problem solving.

This daily habit also prevents massive, wasteful refactors, redesigns, etc. in favor of incremental, continual improvements. And, if there isn't time for all the improvements in one morning, then the team only needs to wait 1 day until the next opportunity.

No improvement is too small. Many improvement ideas are quick, rough experiments. But each improvement will spawn many others, including improving an improvement. If it's better than what we have now, it's worth doing.

7. Prioritize improvements

With improvements that can't be made immediately, it's important to prioritize them.

The criteria for prioritizing improvements is:

Safer
Better quality
Simpler
Faster

Most teams jump right to "faster," thinking that will correlate to efficiency. But, faster is the last layer of optimization to make. And, fixating on making something faster can result in speeding up something that shouldn't even exist.

Better quality, simpler, and faster are easy to translate to software development, but safety can be harder to grasp. Safety in software actually has many important qualities:

Security
Privacy
Psychological safety
Accessibility
Ergonomics

Ideally, an improvement benefits safety, quality, simplicity, and speed all at once. But, we should make tradeoffs based on these priorities. If something improves safety, we should be comfortable with it being more complex and slower. Over time, we can make further improvements to capture these other qualities.

Don't get caught up in tracking improvement ideas, just use this ranking to determine which current idea is most important. Individuals can keep their own lists if they like, but maintaining improvement backlogs (like any backlog) is wasteful. People will remember good ideas as they encounter repeated frustrations. Ideas that don't come up again are almost always no longer relevant.

8. Mistake-proof

When we find the source of an issue, mistake, or defect, we should aim to prevent it in the future. This is called mistake-proofing and leads to valuable improvements.

There are lots of examples of mistake-proofing in software development, especially with tooling, validation, and automation. Test-driven development prevents failing code as soon as it arises. Linting errors give realtime feedback, and pre-commit hooks prevent issues from making it to CI/CD checks. Validation on form inputs guards submission.

Practices like code review and QA help identify and correct mistakes before they reach customers, but aren't mistake-proofing. Mistake-proofing makes the mistake impossible in the first place, or at least provides feedback as close to the mistake occurring as possible.

9. Follow one-piece flow

A central misconception many teams have is confusing activity for productivity.

This confusion leads to the wasteful and detrimental practice of having multiple projects in progress for any given team and/or individual.

Concurrent projects create waste through increased overhead, waiting, context switching, miscommunication, and exhaustion. These wastes cause more defects, lead to burnout, and harm both velocity and quality.

To address this, strive for one-piece flow, where each person, team, or even company has a single project at a time, carried through to completion, before taking on a new project.

Like stop and fix, one-piece flow gets a lot of initial pushback. It seems significantly slower than batching work and having multiple projects at once. But the chaos and motion of concurrent projects is an illusion: if you combined the cycle time of each project and summed it up, it will be longer, often significantly, compared to the total duration of completing those projects one at a time.

One-piece flow makes everything easier, especially when performed at a team level. All team members start a project at the same and build shared context as they collectively focus on a single effort. This creates pairing opportunities, eliminates waiting, handoff, and context switching, and makes work more engaging and successful. By pairing on the work together, team members offer each other continuous review, eliminating the need for PR reviews and alleviating QA significantly. This mistake-proofs much of the work, as pairing partners catch a mistake as it occurs. If a larger problem or blocker arises, everyone has shared context to help and is available to offer support.

Not only is one-piece flow faster and higher quality, it increases actual agility. By only starting and finishing one project at a time, the team has more frequent opportunities to propose and select the next project with a completely clean slate, based on the most recent context and experience. When multiple projects are in progress, there is perpetual work and overlapping timelines, which can lock teams into decisions for weeks, months, or even years at time before reflecting on what should come next.

Another way to improve one-piece flow is to work on smaller projects. Aim to reduce scope from multiple weeks, to a single week, to even a day. This increases agility further and often results in more impactful work by focusing on what's essential.

One-piece flow should also be done at each hierarchy of work: from initiative, to project, to task, to step in the process. It's crucial to maintain focus and reduce work-in-progress and context switching at every level.

10. Achieve flow

All of these practices culminate in achieving flow: the ease of work progressing smoothly, swiftly, and successfully from idea to the customer. Flow is an energizing, rewarding, and valuable state of work that leads to a happier team and more capable company.

Flow also involves identifying waste and issues at higher level. Central to this is understanding and spotting bottlenecks. Bottlenecks occur in every process. They're easy to spot with the waste of inventory: simply look for where work is waiting or work-in-progress is piling up more instead of one-piece flow.

Teams can make a damaging mistake when they become aware of bottlenecks. In attempt to get caught up, they try to push the work through the bottleneck faster, often by simply pressuring people to work harder, longer hours. This simply makes the bottleneck worse, as people are over capacity, which harms quality and can lead to complete burnout. It's disrespectful to people, blames them instead of the process, and is also the completely wrong way to resolve a bottleneck.

The first step in actually resolving a bottleneck is leveling production. This means reducing the throughput of all surrounding steps in the process to match the pace of the bottleneck.

For example, if there are a bunch of designs waiting to built, stop designing more features, and stop doing upfront design. Allow engineers to complete the work-in-progress, and when they're ready, start on a new project together with one-piece flow. This guarantees design and engineering will work at a successful pace and prevent future excess inventory.

The bottleneck has been eliminated once the production across stages is running evenly. Often, this will make it obvious that there is another bottleneck elsewhere. Repeat this process until the throughput of the whole system is even. Then, the overall throughput can be increased by making continuous improvements, such as stop and fix, daily 3S, and the other practices explained above, which improve speed and quality together.

So, as you learn to identify waste, identify what isn't flowing, adjust everything else in the process to match, and then make incremental improvements to lift up the whole process together. This will result in a calmer, happier, more efficient, engaging, and successful experience for everyone, while bringing more value than ever to customers.

Wrapping up

I could write an entire book on this, and have often considered doing so. Each of these 10 lessons deserve chapters of their own, and there are dozens of other lessons I haven't covered here. Let me know if you have any questions, what you're struggling with, and if you'd like me to write further on any of these topics.