Introduction

Imagine you’re building a task management app. Your goal: make it fast and user-friendly. Users spend a lot of time updating task statuses, so your team focuses on speeding up the process. Weeks of work pay off as the status updates are now twice as fast. Success, right? Not quite. The real question is, should users be updating statuses at all? Could that step be automated or removed entirely?

This small shift in perspective reveals a bigger problem in software development: We often chase optimization when elimination is the real win. This isn’t just true for task apps. It applies to any system, from SaaS platforms to complex RAG pipelines. And it also applies to the process of building the software itself and even to building startups [1].

To address this we can look at old, proven concepts of factory optimization. Lean production offers a simple yet powerful tool: the Three Types of Work framework. By understanding what truly creates value, you’ll learn to spot inefficiencies that optimization alone can’t fix.

In this post, I’ll introduce the framework, show you how to identify the three types of work, and walk you through a real-world example. By the end, you’ll have a sharper eye for waste and a method to build smarter, leaner software.

Do we really need this?

Before I became a software engineer, I studied mechanical engineering, where I encountered a concept that fundamentally changed how I approach problem-solving: the Three Types of Work framework from lean production [2]. I saw its power firsthand during an internship at Mercedes-Benz, where I was tasked with optimizing assembly workstations.

Each workstation had a carefully planned sequence of tasks designed by process planners. But when I spoke with operators and observed them in action, I noticed something surprising: they sometimes found better, more efficient ways to work than the optimal plan. For instance, one operator moved a box of screws closer to his workstation rather than keeping it on the shelf, as originally planned. The design team had seen the shelf placement as ideal, but reality proved otherwise.

This experience taught me two critical lessons:

1. Planned efficiency isn’t always real efficiency.
2. Every step in a process or system should be questioned.

In short, if a task doesn’t contribute to the result the customer values, it could be waste. This mindset followed me into software engineering. Now, whenever I design a new feature or workflow, I ask, Is this part really necessary?

This question lies at the heart of the Three Types of Work framework. In any process, be it on a production line or in a software application, every task falls into one of three categories:

1. Value-adding: Activities that directly contribute to the end goal (like writing code that users interact with).

2. Non-value-adding but necessary: Tasks that don’t create value for the end-user but are essential (like testing or logging).

3. Waste: Steps that create no value and aren’t necessary, often caused by poor design, misunderstanding, or outdated assumptions (like redundant form fields or unnecessary confirmation clicks).

In the earlier Mercedes-Benz example, the operators reduced waste by adapting how they worked, bypassing steps that added no real value. This same approach applies to software development: how much of your process or app is built on outdated assumptions?

The 8 Types of Waste

Lean production doesn’t just help us classify work, it also highlights specific kinds of waste. Here are the 8 types of waste from lean production. I've added examples from the process of building software.

1. Overproduction: Building features users don’t need.
2. Waiting: Delays from approvals, builds, or blockers.
3. Unnecessary transport: Moving data or tasks between systems without reason.
4. Over-processing: Reworking features due to unclear requirements.
5. Excess inventory: Too much work in progress (WIP) or feature bloat.
6. Unnecessary movement: Switching between tools or environments too frequently.
7. Defects: Bugs that create rework.
8. Unused employee creativity: Team members’ ideas and improvements go unheard. I would argue, failure of collecting and using customer feedback falls into this type as well.

While not every type of waste fits perfectly, the perspective shift is valuable. If you’d like a deeper dive into how these wastes map to software, leave a comment, I might cover it in a future post.

By learning to recognize and categorize work this way, we can streamline processes, reduce waste, and focus energy on what truly matters to the customer. In software development, this approach leads to simpler, more effective products and smoother workflows.

In the next section, I’ll break down the three types of work in more detail and offer practical tips for eliminating waste while enhancing value.

Are we solving the right problem?

Imagine you have a digital assistant configured to answer questions about financial reports. When you ask, “What was Company X’s revenue in 2023?”, it doesn’t scan the entire report word-by-word. Instead, it quickly finds the most relevant paragraph (like an analyst pulling a key chapter from a book) and then rewrites it into a simple, clear answer for you. This is essentially what a Retrieval-Augmented Generation system (RAG) does, and it relies on three core components:

• Document Store: The container of reports where all the information is stored.
• Retriever: The analyst who finds the most useful passages.
• Generator: The summarizer who rephrases the passages into an answer.

For a more technical, in-depth explanation of RAG see the first section of my post.

At a glance, a specific implementation might seem pretty efficient. But when we apply the Three Types of Work framework, a deeper analysis can reveal hidden inefficiencies. By categorizing each step into one of the three types of work, we can see which activities are truly necessary and which are wasting time and resources.

1. Value-Adding Work (VA)

This is the core of the RAG system, the part that directly delivers what the user wants. For example, when a user asks, “What is Company X’s revenue in 2023?”, the system retrieves and presents the exact figure from the financial report. This is the only part of the process that users truly care about. If it’s slow, incomplete, or inaccurate, the user experience suffers.

2. Essential Non-Value-Adding Work (ENVA)

These tasks are necessary for the system to function but don’t directly deliver value to the user. Examples include:

• Embedding financial reports into vector representations (so the system can “understand” them).
• Re-indexing documents when new files are added (to ensure search results stay up to date).
• Model warm-up times (to ensure fast responses).

While these tasks are essential, they can often be optimized or reduced. For instance, re-embedding all files after every change is wasteful if only one document was added. Similarly, model warm-up times can be reduced by preloading the model in memory.

3. Waste (W)

Waste refers to unnecessary work that adds no value to the user and should be eliminated. In a RAG system, common examples of waste include:

• Over-retrieving irrelevant documents: If the retriever grabs 50 document fragments when only 3 are useful, you’re wasting computational resources and slowing down response times.
• Re-embedding static files repeatedly: If files haven’t changed, there’s no reason to reprocess them. Yet, many systems do this by default, wasting compute time and costs.
• Overloading the document index with unnecessary metadata: Too much metadata increases storage and retrieval times, and often, much of it isn’t even used in queries. These processes increase computational costs and slow down system performance. In a real-world deployment, this means higher cloud bills and slower responses for users. Eliminating these inefficiencies can significantly reduce operating costs and improve the user experience.

The Lesson

The obvious goal when building a system like RAG (or any software) is to focus on the user-facing results, and that’s absolutely the right thing to do. But here’s the catch: waste often hides in the background, in places you don’t think to look.

When every step of your process is questioned with, Does this directly help the user? you’ll often spot hidden inefficiencies. Some processes will clearly add value (like retrieving the most relevant document), while others might seem necessary but aren’t (like reprocessing unchanged data). These moments of discovery are where real efficiency gains are made.

For a RAG system, ask yourself:

• Are we retrieving too many documents?
• Are we reprocessing unchanged data?
• Are we doing work that the user never sees or benefits from?

By addressing these inefficiencies, you’ll reduce costs and deliver faster, more responsive user experiences. It’s not about shifting focus away from the user. It’s about making sure every step in the system is justified by its impact on the user.

Conclusion and Summary

Lean production isn’t just for factories, its principles are just as powerful in software development. As outlined in The Lean Startup, applying lean thinking can help optimize entire organizational processes, from product development to market fit, driving both innovation and efficiency [1]. By using the Three Types of Work framework, we can classify every task or process step as value-adding, essential-but-non-value-adding, or pure waste. This mindset shift allows us to see inefficiencies that would otherwise remain hidden.

Throughout this post, we’ve explored how lean thinking applies on two levels:

• The development process itself: Streamlining the way we build software, from planning to deployment.
• The software product: Designing systems that work smarter, not harder, for users.

We saw this in action with the RAG pipeline example. At first glance, everything in the pipeline might seem essential, but a closer look revealed wasteful steps like over-retrieving documents and re-embedding unchanged files. By focusing on what truly creates value for the user, we identified clear opportunities for simplification.

This approach extends far beyond RAG systems. Any software, from task management tools to large enterprise platforms, can be analyzed using this framework. If you’re willing to ask, Does this step really add value for the user? you’re already on the path to better design.

If you’d like help identifying inefficiencies or optimizing your software, feel free to reach out for a free consultation. Let’s see how we can improve your product together.

References

[1] Eric Ries. 2011. The Lean Startup

[2] Jeffrey K. Liker. 2004. The Toyota Way: 14 Managment Principles from the World's Greatest Manufacturer