Why Do We Keep Adding Steps to Things That Already Work?

You begin with a simple system. Perhaps you keep a short list of what needs to be done that day. It works. Then you decide it could be better. You divide the list into categories. Later, you add priorities, deadlines, labels, recurring tasks, a weekly overview, and another place for ideas that are not yet tasks. Eventually, maintaining the system itself becomes one of the things you have to do. Nothing went dramatically wrong. In fact, almost every addition seemed reasonable when you made it. Yet somewhere between the useful beginning and the improved version, the system became harder to use than the problem it was supposed to solve.

This pattern appears in more places than productivity systems. A simple morning routine gains so many recommended steps that missing one makes the entire routine feel incomplete. A small project begins with a clear purpose and gradually accumulates features nobody originally requested. A straightforward household rule develops exceptions, reminders, and procedures. A spreadsheet designed to answer one question grows until understanding the spreadsheet requires its own explanation.

The interesting question is not why people deliberately make life complicated. Usually, we do not. Complexity often arrives one reasonable addition at a time. Each new step solves a small problem, protects against a possible mistake, adds useful information, or promises a slight improvement. The individual decisions can make sense while the accumulated result becomes unnecessarily difficult.

Complexity Often Arrives Gradually Enough That We Do Not Notice It

If someone presented us with an unnecessarily complicated system on the first day, we might reject it immediately. Twenty categories, several forms, multiple approval steps, and a long set of instructions would make the burden obvious. But when those elements appear separately over months or years, each one is easier to accept.

First, a new category is created because one type of task does not fit neatly into the existing ones. Then an additional field is added because occasionally someone needs that information. Later, a confirmation step is introduced after one mistake causes a problem. None of these changes necessarily seems excessive by itself. The complexity becomes visible only when someone tries to use the entire system from beginning to end.

This is one reason accumulated complexity can survive for so long. We remember the reason each piece was added, but we do not always reconsider whether all the pieces are still necessary together.

Adding Something Is Easier to Notice Than Removing Something

Improvement is often imagined as addition. If a method is not working perfectly, we ask what else it needs. Another reminder? Another feature? Another check? Another category? Another tool? Adding creates a visible change, so it feels as though something has been done about the problem.

Removal is less obvious. Deleting a step, shortening a form, reducing the number of choices, or deciding that some information no longer needs to be collected can look like doing less. Yet subtraction can sometimes improve a system more than another addition would.

The difficulty is that removing something requires us to question an existing part of the system. Someone originally had a reason for putting it there. Even when that reason is no longer relevant, deletion can feel riskier than addition because it creates the possibility that we will later discover we needed what we removed.

Every Extra Step Can Have a Reason and Still Be Unnecessary Overall

Imagine a process containing twelve steps. Ask why each step exists, and you may receive twelve sensible explanations. This one prevents a rare error. That one creates a record. Another makes the process easier for one particular situation. Another was introduced because of something that happened two years ago.

The existence of a reason, however, is not the same as evidence that the step still provides enough value to justify its cost. A precaution that prevents one minor problem but adds work to thousands of ordinary cases may deserve reconsideration. A category that was once useful may now duplicate information stored somewhere else. A rule designed around an unusual exception may have become a burden for every normal case.

This distinction matters because “Why was this added?” and “Should we keep this?” are different questions. Historical explanation can tell us how complexity arrived without telling us whether it remains useful.

Rare Problems Can Create Permanent Procedures

One memorable mistake can have a surprisingly long influence on a system. Something goes wrong once, so a new check is introduced to make sure it never happens again. The check remains after the circumstances that produced the mistake have changed. Years later, people may still perform it without knowing what problem it was originally designed to prevent.

Sometimes this is entirely appropriate. A rare error can have serious enough consequences to justify permanent prevention. Safety procedures, for example, should not be dismissed merely because the event they prevent is uncommon. But in ordinary low-stakes situations, the cost of preventing every conceivable error can eventually exceed the cost of occasionally correcting one.

The useful question is therefore not simply whether a step prevents something. Almost any additional check can prevent something. We also need to consider how likely the problem is, how serious it would be, how costly the prevention is, and whether a simpler safeguard could accomplish the same purpose.

We Can Confuse More Control With More Reliability

Adding steps often gives us a sense of control. If a project feels uncertain, we create more checkpoints. If we are afraid of forgetting something, we record it in several places. If a routine feels inconsistent, we make the instructions more detailed. The system becomes more explicit, and explicitness can feel safer.

But more control points also create more places where the process can fail. A task copied between several systems can become outdated in one of them. A routine with ten required steps creates ten opportunities for interruption. A form containing information nobody uses creates extra work and another possibility for incorrect data.

Reliability does not always come from having the greatest number of safeguards. Sometimes it comes from having fewer parts that are easier to understand and maintain.

Tools Can Quietly Become Additional Work

A tool usually enters our life because it promises to reduce effort. We adopt an application to organize tasks, a template to speed up repeated work, a calendar system to remember commitments, or a spreadsheet to make information easier to find. Initially, the tool may genuinely help.

Then maintenance begins. The application needs organizing. The template needs updating. The calendar requires categories. The spreadsheet needs another column. Soon we are not only doing the original work; we are also managing the infrastructure created to support the work.

Again, this is not necessarily bad. Useful systems require some maintenance. The question is whether the maintenance remains smaller than the problem the tool solves. When the supporting system regularly demands more attention than the activity it was designed to support, its original purpose deserves another look.

Customization Can Continue Long After It Stops Helping

Many tools allow extensive customization, and customization can be genuinely useful. A system adapted to the way someone actually works may be easier to use than a generic one. But the ability to customize something can also create an endless sequence of improvements that solve increasingly minor problems.

We change the layout, rename categories, create new templates, adjust settings, reorganize folders, and search for a slightly better method. Each improvement promises to make future work smoother. Sometimes it does. At other times, the improvement process becomes a substitute for using the system.

This can be difficult to notice because organization feels related to the work. Reorganizing a writing system feels connected to writing. Rebuilding a study schedule feels connected to studying. Adjusting a project-management board feels connected to completing the project. But related activity and productive activity are not always the same.

A Better System Can Become Worse Through Too Many Exceptions

Rules are usually created for ordinary situations. Then an unusual situation appears. Instead of allowing an exception to remain an exception, we modify the entire rule to accommodate it. Another unusual case appears, so another modification follows. Eventually, the rule becomes difficult to understand because it contains the history of every unusual case that ever challenged it.

Personal routines can develop this way too. We create a simple plan, encounter one difficult day, and add a special rule. Then another situation produces another rule. Soon the plan includes instructions for what to do when we are late, tired, traveling, busy, interrupted, unmotivated, or unable to complete a particular step.

Some flexibility is useful. But a system designed to predict every possible exception can become harder to follow than a simpler system that allows us to make occasional judgments when unusual circumstances arise.

We May Keep Features Because We Already Learned How to Use Them

Once we have invested time learning a complicated system, its complexity can become less visible to us. We know where everything is. We remember what the abbreviations mean. We understand which steps can be skipped and which cannot. The process feels manageable because familiarity has reduced the effort required to navigate it.

Then someone new tries to use the same system and struggles. Their confusion can look like inexperience, and sometimes it is. But it can also reveal complexity that experienced users have simply learned to work around.

This is why a beginner’s question can occasionally be valuable: “Why do we do this step?” Experienced users may know exactly how to perform it while no longer remembering whether it still needs to exist.

Once Something Exists, Removing It Can Feel Like Losing Value

Suppose an application has twenty features and only six are regularly useful to you. Removing the other fourteen could make the interface easier to navigate, but it can also feel like losing capability. What if one of those features becomes useful later? What if a situation appears where we need exactly the option we removed?

This possibility makes addition psychologically easier than subtraction. Keeping an unused option preserves potential value, while removing it closes a possibility. Yet every preserved option also has a cost, even if the cost is small: visual clutter, additional decisions, maintenance, learning, or attention.

The challenge is that potential benefits are easy to imagine individually while accumulated costs are distributed across repeated use. A feature may save ten minutes once a year while adding a few seconds of confusion every day. Without considering the total pattern, we may overvalue the exceptional benefit and underestimate the ordinary cost.

More Choices Can Make a Simple Action Require More Decisions

A basic system often works partly because it asks very little from us. We know what to do next. As options accumulate, the system begins asking questions before allowing action. Which category does this belong in? Which priority should it receive? Which label applies? Should it be scheduled, listed, delegated, archived, or added to another project?

Each decision may be tiny. But the original task has not disappeared. We still need to write the email, make the call, prepare the document, buy the item, or complete the work. The organizational decisions have been added on top of it.

Additional choices are valuable when they produce distinctions we actually use. If nothing meaningful changes after assigning one of five labels, however, the classification may be creating work without changing action.

Information Can Accumulate Faster Than Its Usefulness

We often collect information because it might be useful later. Notes are saved, links bookmarked, files downloaded, screenshots stored, and documents organized into folders. Each individual item has a plausible future purpose. Over time, however, the amount of saved information can become large enough that finding what matters becomes difficult.

The problem is not necessarily that we collected useless information. Much of it may be genuinely interesting. The problem is that usefulness depends partly on retrieval. Information we cannot find when we need it has less practical value than information that is easy to locate.

This creates another form of accumulated complexity: a system can contain more knowledge while becoming less usable. Improvement therefore cannot be measured only by what has been added. We also have to ask whether the additions make the important things easier or harder to reach.

We Rarely Schedule Time to Remove What Is No Longer Needed

Most systems have natural moments for addition. A new project begins, so we create a folder. A new responsibility appears, so we add it to the routine. A new problem occurs, so we create a rule. Removal has fewer obvious triggers. Old folders remain after projects end. Procedures remain after circumstances change. Categories remain even when we rarely use them.

As a result, complexity can grow through a simple imbalance: additions happen whenever something new occurs, while subtraction happens only when the accumulated burden finally becomes irritating enough to demand attention.

This is why simplifying an existing system can feel surprisingly productive. We are not necessarily discovering a better method. Sometimes we are simply removing decisions, steps, and information that belonged to an earlier version of the problem.

The Simplest Version Is Not Automatically the Best Version

None of this means that every process should be reduced to the smallest possible number of steps. Some complexity exists because reality is complex. A detailed medical procedure, legal process, engineering system, or financial control may contain many steps because important distinctions and risks genuinely need to be handled. Removing them merely to make the process look elegant could make it worse.

Even in everyday life, an extra step can be worth keeping if it reliably prevents a meaningful problem or produces information we actually use. Simplicity is not the goal by itself. A system should be simple enough to use while remaining detailed enough to do its job.

The more useful question is therefore not “How can I make this as simple as possible?” It is “Which parts are doing useful work?” That question allows complexity to remain where it earns its place.

A System Can Work Well Without Being Interesting

There is another reason we sometimes abandon simplicity: once a method becomes familiar, it can feel boring. A basic checklist that reliably works may no longer feel satisfying because there is nothing left to optimize. A new application, technique, template, or organizational method brings novelty. It gives us something to explore and improve.

There is nothing wrong with enjoying tools or experimenting with better methods. Experimentation can produce genuine improvements. But novelty and usefulness should not be confused. A new system can be more interesting to build while being less effective to live with.

Sometimes the unexciting method survives because it solved the problem well enough that there is very little left to think about. Its lack of novelty may actually be part of its success.

Before Adding Another Step, We Can Ask What It Will Change

A useful test for a new step is surprisingly concrete: what will be different because this exists? If we add another category, what decision will that category improve? If we introduce another check, what meaningful error will it prevent? If we collect another piece of information, when will we use it? If we adopt another tool, which existing task will become easier enough to justify maintaining the tool?

The question does not require every addition to produce a dramatic benefit. Small improvements can matter when they happen frequently. But it forces the benefit to become specific instead of remaining at the level of “this seems more organized” or “this might be useful someday.”

Once we can name what the addition is supposed to improve, we can later check whether it actually did.

Sometimes Improvement Means Leaving Something Alone

There is a stage in many systems where continued adjustment produces smaller and smaller benefits. The important problems have been solved. The process is understandable. The result is good enough. At that point, another improvement may technically make one detail better while making the overall system harder to maintain.

Recognizing that point can be difficult because improvement feels inherently positive. But a working system does not always need to become more sophisticated. Sometimes its greatest advantage is that we no longer need to think about it very much.

A simple method that reliably helps us do the thing it was designed for may already be doing enough. The challenge is noticing when the next improvement would improve the system—and when it would merely give the system one more thing to manage.

Research Suggests That We Can Overlook Subtraction When Trying to Improve Something

The tendency to improve through addition rather than subtraction has been examined experimentally. In a 2021 study published in Nature, Gabrielle S. Adams, Benjamin A. Converse, Andrew H. Hales, and Leidy E. Klotz investigated how people changed objects, ideas, and situations when asked to make them better. Across different tasks, participants frequently overlooked opportunities to improve something by removing components and were more likely to generate additive changes.

The researchers also found evidence that subtraction may simply be less likely to come to mind during the initial search for solutions. When subtraction was made more noticeable, people became more likely to use it. The study does not mean that adding is generally irrational or that simpler solutions are always superior. Instead, it identifies a useful asymmetry: when we think about improvement, addition may receive consideration before subtraction does.

You can read an accessible explanation of the research from the University of Virginia, where members of the research team conducted the work: Why Our Brains Miss Opportunities to Improve Through Subtraction — University of Virginia.

Subtraction Becomes Easier When We Ask About It Directly

If addition is often the first category of improvement that comes to mind, one practical response is not to force ourselves to simplify everything. It is simply to make subtraction one of the possibilities we deliberately consider. After asking, “What should I add?” we can also ask, “What could I remove without making this worse?”

The wording matters because the second question searches a different part of the problem. Suppose a weekly routine feels difficult to maintain. Asking how to improve it might produce another reminder, another planning session, or a better application. Asking what could be removed might reveal that two recurring tasks are no longer necessary, that the same information is being recorded twice, or that a rule created months ago no longer serves a purpose.

Neither direction should automatically win. The point is to allow both to enter consideration before deciding what improvement requires.

Removing a Step Is Easier When We Know What the Step Is Supposed to Do

It is difficult to evaluate a system when its components have no clearly stated purpose. A step may feel important simply because it has always been there. Before removing it, we can ask what problem it prevents, what information it produces, or what decision depends on it.

If the answer is clear, we can evaluate whether the function still matters. Perhaps the step prevents an expensive mistake and should remain. Perhaps it produces information nobody has looked at for a year. Perhaps it duplicates another part of the process. Perhaps the problem it once solved disappeared after a different change was introduced.

This is more useful than simplifying according to appearance. A five-step process can contain five necessary steps, while a three-step process can contain two unnecessary ones. What matters is not how short the system looks but whether each part contributes enough to justify its presence.

Temporary Additions Have a Habit of Becoming Permanent

Many forms of complexity begin with the phrase “for now.” We create an extra spreadsheet while changing systems, add another meeting during a difficult project, keep two versions of a process during a transition, or introduce an additional check while investigating a problem. These additions may be entirely sensible because the situation temporarily requires them.

The difficulty appears when the temporary situation ends but the temporary structure remains. The additional meeting becomes part of the calendar. Both spreadsheets continue being updated. The extra check becomes standard procedure. Nobody deliberately decides that the temporary solution should become permanent; people simply stop asking when it can be removed.

One way to prevent this is to attach a review point to temporary additions. If something is being introduced specifically because of a temporary problem, deciding when it will be reconsidered can be as important as deciding to add it.

We Can Ask Whether a Rule Handles the Normal Case or the Exceptional Case

Systems become particularly complicated when ordinary behavior is designed around rare exceptions. Suppose ninety-five percent of situations can be handled with a simple process, while five percent require additional attention. One option is to build the exceptional requirements into every case. Another is to keep the ordinary process simple and create a separate response for the unusual cases.

The second approach is not always possible. Sometimes an exception is serious enough that everyone must be screened for it. But when the consequences are minor, forcing every ordinary case through procedures designed for rare situations can create substantial unnecessary work.

This question can apply to personal routines too. If something unusual happens once every few months, does the everyday routine need a permanent step for it, or can the unusual situation simply be handled when it occurs?

Removing Something Can Reveal Whether It Was Actually Useful

One reason we hesitate to remove steps is that we cannot always predict what will happen afterward. Instead of making every subtraction permanent, we can sometimes test it. A recurring meeting can be skipped once. A category can stop being used for a few weeks. A routine can be shortened temporarily. An unused field can be hidden before being deleted.

The experiment creates information. If problems immediately appear, the removed element may have been doing useful work. If nothing meaningful changes—or if the process becomes easier—the system has provided evidence that the element may not have been necessary.

This approach is especially helpful when arguments about usefulness remain theoretical. Rather than debating endlessly about whether a small step matters, a reversible trial can show what happens when it is absent.

Some Complexity Is Hidden Because Someone Else Maintains It

A system can appear simple to the person using its final output while being complicated for everyone maintaining it behind the scenes. A manager may see a clean weekly report without realizing that several employees spend hours transferring information between systems to produce it. A customer may experience a simple service while employees perform numerous manual steps in the background.

The same thing can happen in personal life. A neatly organized planning system may look efficient while requiring substantial maintenance every weekend. A carefully arranged household process may work smoothly because one person constantly remembers and coordinates the details.

Evaluating simplicity therefore requires looking beyond the visible interface. We need to consider where the work went. Removing a step for one person is not a genuine simplification if it merely transfers the same burden invisibly to someone else.

A Useful System Should Make the Main Activity Easier to Reach

One practical way to evaluate a supporting system is to look at the distance between intention and action. If you want to write something, how many organizational decisions happen before writing begins? If you need to record an appointment, how many places must be updated? If you want to find a document, how much knowledge about the filing system is required?

A sophisticated system may still perform extremely well if those actions remain easy. Complexity becomes more concerning when using the support structure repeatedly delays the activity it was created to support.

This does not mean every task should require one click or one step. It means the supporting structure should earn the attention it demands.

We Can Separate Information We Need From Information That Is Merely Nice to Have

Information is particularly easy to add because storing another detail often seems inexpensive. Another column in a spreadsheet, another field on a form, another note in a database, or another metric in a report may take only seconds to create. But once the field exists, someone may have to complete it repeatedly.

A useful test is to ask what happens after the information is collected. Does it influence a decision? Does someone review it? Does it help identify a problem? Does it satisfy a real requirement? If the answer is consistently no, the information may be creating maintenance without producing corresponding value.

“We might need it someday” can be a reasonable reason in some contexts, especially when information would be impossible to recover later. But it should not automatically justify collecting everything that could conceivably become useful.

Removing Duplication Can Be More Valuable Than Finding a Better Tool

When a system becomes difficult, replacing the tool is an attractive solution. A new application promises cleaner organization, better automation, or easier navigation. Sometimes changing tools genuinely solves the problem. But if the underlying process contains duplication, unnecessary approvals, unclear responsibilities, or information nobody uses, a new interface may simply reproduce the same complexity in a more attractive form.

Before replacing the system, it can therefore be useful to examine the process without the tool. What actually needs to happen from beginning to end? Which information needs to move between people? Which decisions need approval? Which records genuinely need to exist?

Once those requirements are clear, choosing a tool becomes easier because the tool is supporting a defined process rather than determining the process itself.

Not Every Useful Feature Needs to Be Used Every Time

A system can contain complexity without forcing all of it into every interaction. A software application may offer dozens of advanced options while keeping the basic action straightforward. A personal planning system may include detailed project tools that are used only when a project actually requires them.

This suggests another alternative to deleting everything unnecessary: progressive complexity. The simplest path remains available for ordinary situations, while additional options appear when they are needed.

The principle can be applied without technology. A basic routine can have an optional extended version. A simple checklist can contain a separate section for unusual cases. A standard process can remain short while pointing to additional instructions when specific conditions apply.

The goal is not necessarily to eliminate capability. It is to prevent every possible capability from becoming a requirement for every ordinary action.

Simplification Can Fail When We Remove Context Instead of Friction

There is also a risk in simplifying too aggressively. Instructions can become so short that new users no longer understand them. A form can remove a field that turned out to provide important context. A routine can become so flexible that nobody knows what the essential part is. A report can remove details that were necessary for interpreting the headline number correctly.

This is why useful subtraction is selective. We want to remove friction that contributes little, not information or structure that makes the system understandable. The question is not simply “Can this disappear?” but “What becomes harder to understand or accomplish if it disappears?”

If the answer is significant, the apparent complexity may be carrying useful information.

We Can Distinguish Core Steps From Supporting Steps

When a process feels crowded, identifying its core can make the rest easier to evaluate. What absolutely has to happen for the outcome to exist? Everything else can then be considered in relation to that core.

For example, the core of publishing a short article might involve writing, reviewing, and publishing it. Formatting systems, organizational labels, promotional planning, analytics, image preparation, and archives may all be valuable supporting activities, but they serve different purposes. Seeing those layers separately makes it easier to ask whether each supporting activity contributes enough to remain.

This does not require stripping the process down permanently. It simply prevents supporting infrastructure from becoming indistinguishable from the thing we originally wanted to accomplish.

Maintenance Cost Matters Because It Repeats

A step that takes thirty seconds seems insignificant. But if it happens twenty times a day, every working day, its cost is very different. Repetition changes the calculation. Small inconveniences in frequently used systems can deserve more attention than large inconveniences in processes used once a year.

The opposite is also true. We sometimes spend hours optimizing a rare activity to save a few minutes the next time it occurs. The improvement is real, but the total benefit may never recover the time spent designing it.

When deciding what to simplify, frequency can therefore be as important as difficulty. Repeated friction accumulates quietly.

A System Should Occasionally Have to Justify What It Contains

Because additions accumulate naturally, an occasional review can reverse the imbalance. The purpose is not to reorganize everything again. In fact, constant reorganization would create another form of maintenance. The review can be much simpler: what are we still using, what are we maintaining without using, what is duplicated, and what exists because of a problem that no longer exists?

The same questions can be applied to a routine, folder structure, project workflow, recurring schedule, or personal organization method. The objective is not to create a new system at the end of every review. Sometimes the best result is simply deleting one unnecessary step and leaving everything else alone.

Subtraction Should Solve a Problem, Not Become Another Ideal

Once we discover the value of removing things, it is possible to become overly enthusiastic about minimalism itself. We may start deleting useful features because the smaller system feels cleaner, reducing options that genuinely serve different needs, or treating every form of complexity as evidence of poor design.

That repeats the original mistake in reverse. Addition is not inherently bad, and subtraction is not inherently wise. Both are ways of changing something. Their value depends on the problem.

A new step deserves to exist when it solves a meaningful problem at an acceptable cost. An existing step deserves removal when its cost has become greater than the value it provides. Sometimes improvement requires adding. Sometimes it requires subtracting. Sometimes the most useful decision is to change nothing.

We Can Simplify the Decision About Simplifying

There is no need to conduct a complete audit of everything we do. That would ironically turn simplification into another complicated project. We can begin wherever friction is already visible. Which process repeatedly feels more difficult than it should? Which routine requires more maintenance than the activity itself? Which tool do we spend more time organizing than using? Which step do we perform automatically even though we no longer remember why?

Those moments provide natural candidates for examination. If something works well and creates little burden, it may not deserve attention simply because it could theoretically be simpler.

If you want a quiet place to examine questions like these without building another elaborate system around them, you can also explore the Mibosma Free Tools.

Simplicity Is Most Useful When It Is the Result, Not the Rule

The original idea that simplicity can bring us back to ourselves is appealing, but simplicity does not need to become another lifestyle requirement. A simple system is useful when it removes unnecessary effort while preserving what matters. A complicated system can also be entirely appropriate when the problem genuinely contains many important parts.

The more interesting lesson is how easily complexity can accumulate without anyone deliberately choosing it. We add a feature because it helps. We create a rule after a problem. We preserve information because it might matter. We add a check because an error occurred. Each decision can be reasonable, yet the combined system can eventually become something none of those individual decisions intended to create.

That is why improvement occasionally needs a different question. Instead of always asking what else would make something better, we can ask whether anything is making it harder than it needs to be. Perhaps nothing should be removed. Perhaps one small step is doing important work. But sometimes the solution is already inside the system, hidden beneath something we no longer need.

Making something better does not always require giving it more. Sometimes improvement begins when we notice that what is already there is enough—and that the next useful change is to take something away.