A navigation app saves you three minutes on the drive home. The first week, you still know the route; the app simply avoids traffic.

A year later, you use it for familiar trips because it is easier than checking road conditions yourself. Five years later, a road closes, your phone loses signal, and you realise you are not entirely sure how the pieces of your own city fit together.

No single day turned a useful tool into a dependency. The change arrived through a series of sensible choices.

That is what makes convenience interesting. It rarely asks us to surrender a capability. It offers to carry a small burden. If the offer is good enough, we accept it again, and the surrounding world may eventually reorganise around the new arrangement.

Then the tool fails, the company changes its rules, or we try to do the old task without it. Only then do we discover what disappeared while everything was working.

When does a tool stop saving effort and start becoming something we cannot easily function without?

The Hidden Assumption

We often imagine convenience as an extra layer placed on top of an unchanged life. The route still exists; GPS simply tells us where to turn. The document still exists; the cloud simply keeps it available everywhere. The calculation is still possible; software simply does it faster.

But a convenient tool can change the person using it, the market around it, and the infrastructure beneath it. We may practise a skill less often. Companies may stop supporting older alternatives. Workflows may grow around one provider. Other people may begin assuming that everyone uses the same system.

A useful distinction follows. Reliance means that a tool improves performance. Dependence begins when losing the tool produces a large cost because substitutes, skills, or recovery paths are weak.

That does not automatically make dependence bad. Modern life is built from dependencies. Electricity, sanitation, logistics, telecommunications, and specialist knowledge let people do more precisely because nobody has to recreate everything alone.

The more useful question is not whether we depend. It is what kind of dependence we are building.

Follow the Question: Cognitive Science

Offloading is often rational

Human beings have always moved work outside the mind: lists, calendars, maps, records, reminders. Cognitive scientists call one part of this cognitive offloading — using external actions or tools to reduce a task's internal processing demands.

A 2025 meta-analysis by Lois Burnett and Lauren Richmond, published in the January 2026 issue of Memory & Cognition, combined 75 effect sizes from 65 independent experiments. Across the included memory tasks, offloading improved average performance and reduced differences in performance between people.

That is why convenience spreads. It works. A reminder can prevent a missed appointment. A calculator can reduce arithmetic errors. A checklist can protect attention for harder decisions.

If we begin with the assumption that doing everything internally is inherently superior, we miss the trade. Convenience buys capacity. The question is what happens to the capability we stop using.

Burnett, L. K., & Richmond, L. L. (2026). Meta-analytic investigations of the effect of cognitive offloading on memory-based task performance and interindividual variability.

Risko, E. F., & Gilbert, S. J. (2016). Cognitive Offloading.

Better with the tool can mean worse without it

Suppose a tool helps you complete a task more accurately today. That does not tell us whether you will become better or worse at performing the same task unaided tomorrow.

In experiments published in 2021, Sandra Grinschgl and colleagues found that participants who offloaded information during a pattern-copy task performed better on the immediate task but later remembered less of the offloaded material under several conditions. When participants knew memory would later be tested, the cost could be greatly reduced.

Navigation offers a more familiar example. Louisa Dahmani and Véronique Bohbot found that greater habitual GPS use was associated with poorer spatial memory during later self-guided navigation. Their three-year follow-up involved only 13 participants, so the longitudinal evidence deserves caution, but the broader pattern in their study pointed in the same direction.

These findings do not show that technology causes general cognitive decline. They show something narrower and more useful: performance with an aid and capability without the aid are different measurements.

A tool can be excellent at getting us somewhere and still change what we learn along the way.

Grinschgl, S., Papenmeier, F., & Meyerhoff, H. S. (2021). Consequences of cognitive offloading: Boosting performance but diminishing memory.

Dahmani, L., & Bohbot, V. D. (2020). Habitual use of GPS negatively impacts spatial memory during self-guided navigation.

Follow the Question: Human Factors

The dangerous moment may be the handoff

Dependence becomes more serious when a human is expected to resume control after automation has been doing the work.

In a 1995 experiment, Mica Endsley and Esin Kiris examined an automated navigation task. Higher automation reduced situation awareness and was associated with slower decision performance after the automation failed. This belongs to a family of problems often described as being out of the loop.

While the system works, the human does less. Because the human does less, they may have a weaker model of what the system is doing. When failure finally requires intervention, the person is asked to perform at the moment they have the least recent practice and the poorest situational context.

Automation can therefore reduce ordinary workload while increasing the difficulty of a rare emergency. The design question is not whether automation is good or bad. It is whether the human role remains meaningful enough that recovery is realistic.

If the backup operator has become ceremonial, calling them the backup does not make the system resilient.

Endsley, M. R., & Kiris, E. O. (1995). The Out-of-the-Loop Performance Problem and Level of Control in Automation.

Follow the Question: Economics

Dependence can be created outside the user

Consider a service that stores years of documents. At first it is merely convenient. Then colleagues join. Clients expect its links. Workflows use its integrations. Old files, permissions, templates, and training accumulate.

When a better competitor appears, the price of switching is no longer the price of learning a new interface. It includes converting files, rebuilding integrations, retraining people, moving data, and coordinating everyone who depends on the old system.

Economists Joseph Farrell and Paul Klemperer described how switching costs and network effects can bind customers to vendors when products are incompatible. A product can become harder to leave not because its intrinsic quality improved, but because the surrounding relationships make departure expensive.

This is a different dependency from forgetting how to navigate. Nothing inside your brain needs to weaken. The exit itself becomes costly.

That distinction matters because personal discipline cannot solve a structural lock-in problem.

Farrell, J., & Klemperer, P. (2007). Coordination and Lock-In: Competition with Switching Costs and Network Effects.

Follow the Question: Law

Exit is part of the product

Services are usually judged while we are using them: speed, price, features, time saved. Dependence suggests another measure: how difficult is it to leave?

The European Union's Data Act has applied since 12 September 2025. Among other provisions, it requires providers of data-processing services to remove contractual, commercial, technical, and organisational obstacles that inhibit customers from switching providers or, where relevant, using several providers at once.

The regulation also phases out switching charges. As of October 2026, reduced switching charges may still be imposed when they reflect directly related switching costs. From 12 January 2027, providers covered by Article 29 may no longer impose switching charges for the switching process.

The law does not eliminate every form of lock-in. Migration can remain technically difficult. Applications can depend on provider-specific features.

But the principle matters. Portability, interoperability, and exit are not administrative details after the product is designed. They influence how much power a dependency creates.

European Union. Regulation (EU) 2023/2854 (Data Act), Chapter VI and Article 29.

European Commission. Data Act explained — switching between data-processing services.

The alternative can disappear even when you keep the skill

Suppose you know how to pay with cash. That knowledge is useless at a shop that no longer accepts it. Suppose you know how to work offline. Your organisation may still stop if authentication, files, communication, and approvals all depend on one external service.

This reveals three layers of dependence. A person can lose a capability. Switching can become expensive. And the surrounding environment can remove the alternative.

At that point, individual competence is not enough. A society can become dependent on a technology even while many individuals remember the older way, because the old way may no longer have the suppliers, interfaces, institutions, or scale required to function.

This is why nostalgia is a poor resilience strategy. The question is not whether somebody remembers how things used to work. It is whether a viable fallback still exists.

Follow the Question: Systems Engineering

Efficiency and resilience are different objectives

Convenience often rewards concentration. One account is easier than five. One supplier is easier than three. One automated workflow is easier than maintaining a manual parallel process. Redundancy can look wasteful on an ordinary day.

Then the ordinary day ends.

NIST's cyber-resiliency guidance describes resilient systems as systems able to anticipate, withstand, recover from, and adapt to adverse conditions, stresses, attacks, or compromises. The publication explicitly frames cyber resiliency as a way to reduce risks arising from dependence on cyber resources.

That changes the question from 'Can this fail?' to 'What happens next?' Can essential functions continue in a degraded mode? Is there another path? Can data be recovered? Do people know what to do when automation disappears?

Dependence becomes dangerous when the cost of failure grows faster than the system's ability to recover.

NIST SP 800-160 Vol. 2 Rev. 1 (2021). Developing Cyber-Resilient Systems: A Systems Security Engineering Approach.

Convenience can become mandatory without anyone voting for it

A tool begins as an option. Early users save time. Organisations redesign processes around it. The slower path receives less support because fewer people use it. Eventually the convenient method becomes the normal method, and the normal method becomes the required method.

No single decision created the dependency. Each local decision made sense.

This does not mean every old process should be preserved forever. Parallel systems cost money and attention, and some obsolete methods should disappear.

It means the transition deserves notice. Once the alternative is gone, the convenience has changed categories. It has become infrastructure.

Dependence is not the same as addiction

Technology debates often collapse several ideas into one. A person may use something frequently because it is useful, rely on it because it performs a task better, or be structurally dependent because work and institutions assume access to it. None of those facts, by itself, establishes addiction.

Keeping the terms separate improves the analysis. Losing navigation skill is a capability problem. Being unable to leave a cloud provider can be a switching-cost problem. A workplace that stops when one identity service fails has an architectural concentration problem.

Calling all of these addiction makes the word dramatic and the diagnosis useless.

The goal cannot be independence from everything

Complex societies create capability through cooperation. A surgeon depends on electricity, sterilisation systems, pharmaceuticals, trained colleagues, supply chains, records, and specialised equipment. A city depends on water treatment, communications, logistics, power, and maintenance.

Dependence can be evidence of successful cooperation.

The problem appears when dependency is invisible, concentrated, irreversible, or impossible to recover from.

So the opposite of dangerous dependence is not total independence. It is resilient dependence.

A strong system is not one that needs nothing. It is one that understands what it needs and can survive when one need is interrupted.

A practical test: remove the convenience

Remove the service for one hour. Then one day. Then one month. What fails?

At one hour, perhaps nothing important happens. At one day, you may discover that nobody knows the manual workaround. At one month, you may discover that the workaround is not really a workaround because suppliers, files, credentials, customers, and institutions depend on the missing system too.

Then ask: Can I substitute another tool? Can I export what I need? Can the core task continue at a lower level? Who controls restoration? Does failure harm everyone equally, or mostly people with fewer alternatives?

These questions do not produce a universal threshold. They reveal the shape of the dependence.

A convenience with easy exit, preserved skills, multiple suppliers, and graceful failure is different from a convenience that saves five minutes every day while quietly creating a single point of failure.

Where the Fields Collide

Cognitive science shows why offloading is attractive: external tools can improve immediate performance and reduce mental demand. Memory and navigation research shows that unaided capability can change when tasks are repeatedly offloaded, although the evidence does not justify sweeping claims about intelligence.

Human factors shows that automation can create a difficult handoff when people must suddenly resume control. Economics shows that switching costs and network effects can create dependency without any personal skill loss. Law can protect portability and exit. Systems engineering asks whether the larger system can continue after a dependency fails.

Together, the fields suggest a useful definition:

Convenience becomes dependence when losing the convenience removes realistic choices faster than the user or system can replace them.

What We Know — and What We Don't

We know cognitive offloading can improve performance on memory-based tasks when external aids remain available. We also know that offloading can reduce later unaided memory in some experimental settings, and that habitual GPS use has been associated with weaker spatial-memory performance.

We know automation can reduce situation awareness in some tasks and make manual recovery harder after failure. We know switching costs and incompatible systems can create economic lock-in, and current regulation such as the EU Data Act explicitly tries to reduce barriers to switching in data-processing services.

We do not know that every convenient technology causes deskilling. We do not know that preserving every manual skill is worth the cost. We do not know that dependence on a technology is inherently unhealthy or fragile.

The harder question is which changes matter enough that we should deliberately preserve an exit.

Back to the Route

Return to the driver whose phone lost signal. Perhaps they reconstruct the route and arrive ten minutes late. Perhaps they stop and ask someone. Perhaps the car has an offline map. Or perhaps every passenger has learned the city through the same glowing arrow.

The difference is not whether the navigation app was convenient. It was.

The difference is what remained after the convenience disappeared.

If an absence takes the task, the skill, the substitute, and the recovery path with it, we are no longer describing a shortcut.

We are describing an infrastructure we forgot to name.

The Next Question

Dependence connects parts that once looked separate. A payment system depends on identity. Identity depends on networks. Networks depend on power. Organisations depend on software that depends on other software maintained by people who may never meet.

Each component can work exactly as designed and still contribute to a failure nobody intended.

Why do complex systems fail even when every part seems to work?

Sources & Further Reading

  1. Burnett, L. K., & Richmond, L. L. (2026). Meta-analytic investigations of the effect of cognitive offloading on memory-based task performance and interindividual variability.
  2. Risko, E. F., & Gilbert, S. J. (2016). Cognitive Offloading.
  3. Grinschgl, S., Papenmeier, F., & Meyerhoff, H. S. (2021). Consequences of cognitive offloading: Boosting performance but diminishing memory.
  4. Dahmani, L., & Bohbot, V. D. (2020). Habitual use of GPS negatively impacts spatial memory during self-guided navigation.
  5. Endsley, M. R., & Kiris, E. O. (1995). The Out-of-the-Loop Performance Problem and Level of Control in Automation.
  6. Farrell, J., & Klemperer, P. (2007). Coordination and Lock-In: Competition with Switching Costs and Network Effects.
  7. European Union. Regulation (EU) 2023/2854 (Data Act), Chapter VI and Article 29.
  8. European Commission. Data Act explained — switching between data-processing services.
  9. NIST SP 800-160 Vol. 2 Rev. 1 (2021). Developing Cyber-Resilient Systems: A Systems Security Engineering Approach.

Beyond the Question is an interdisciplinary series by Arin Vale.

Read the editorial approach

THE NEXT QUESTION

Why do complex systems fail even when every part seems to work?

Continue to No. 014