Learn to Think One Level Up—and One Level Down
Most people are trained to solve the problem directly in front of them.
A spreadsheet needs to be cleaned, so they clean the spreadsheet.
A report needs to be made, so they make the report.
A warehouse worker needs to know where a product is, so someone builds a screen showing the product location.
A farmer needs to water a field, so someone improves the irrigation schedule.
There is nothing inherently wrong with this kind of thinking. In fact, most work gets done this way.
But some of the most valuable ideas appear when you deliberately refuse to stay at the level where the problem was presented.
Instead, you move one abstraction level up or down.
You ask:
**What larger system is this task part of?**
Or:
**What smaller mechanism actually makes this task happen?**
Then you keep moving.
This way of thinking is useful in software, business, engineering, medicine, manufacturing, logistics, agriculture, design, construction, education, and nearly every profession where systems and people interact.
It becomes even more powerful when you stop limiting the idea to the digital world.
Software can process information.
Sensors can observe reality.
Machines can change reality.
Human beings can make decisions.
The interesting systems emerge when all of those layers begin working together.
---
What Is an Abstraction?
An abstraction is simply a level at which you choose to think about something.
Consider a car.
At one level, it is:
**Transportation.**
Move down one level and it becomes:
**A vehicle.**
Move down again:
**Engine, transmission, steering, braking, electronics.**
Move farther down:
**Pistons, bearings, gears, sensors, wires and valves.**
Farther still:
**Combustion, friction, heat transfer, electrical current and mechanical forces.**
Move upward instead and the car becomes part of:
**A transportation system.**
Move higher:
**A system for moving people and goods through society.**
None of those descriptions is wrong.
They are simply different levels of abstraction.
The skill is learning to deliberately move between them.
---
Why Moving Between Abstraction Levels Matters
People often spend enormous amounts of effort solving a problem at the wrong level.
Imagine a company that spends hundreds of hours improving a monthly report.
They redesign the charts.
Automate the spreadsheet.
Improve the dashboard.
Add AI-generated summaries.
Speed up the database.
Eventually someone asks:
**Why does this report exist?**
The answer might be:
> Managers need to know when something important is going wrong.
That is a completely different problem.
Now the question becomes:
> Why generate a 40-page report at all?
Perhaps the better system monitors the underlying data continuously, detects unusual behavior and alerts the correct manager only when intervention is required.
The reporting problem disappeared.
The company did not improve the report.
It moved one abstraction level higher and questioned the reason the report existed.
This pattern appears everywhere.
---
A Simple Abstraction Ladder
A useful way to think about almost any system is through five levels.
Level 5: Purpose
Why does this exist?
Examples:
Increase crop yield.
Move people safely.
Keep patients healthy.
Deliver products quickly.
Educate students.
Reduce manufacturing defects.
---
Level 4: System
What overall system accomplishes the purpose?
Examples:
A hospital.
A transportation network.
A supply chain.
A school.
A manufacturing plant.
A distribution center.
---
Level 3: Process
What sequence of actions happens inside the system?
For an online order:
Customer orders.
Inventory is located.
Product is picked.
Product is packed.
Shipping label is created.
Carrier receives package.
Package is delivered.
---
Level 2: Mechanism
What actually performs those actions?
Workers.
Software.
Barcode scanners.
Robots.
Databases.
Motors.
Algorithms.
Conveyor belts.
Sensors.
---
Level 1: Physical Reality
What is physically happening?
Electrons move.
Motors rotate.
Light hits a camera sensor.
Heat transfers.
Pressure changes.
Chemical reactions occur.
Human muscles move objects.
Radio signals travel.
Materials deform.
At this level, every abstract system eventually becomes physics.
---
The LLM Example
Consider a common modern task.
You have a messy dataset and tell an AI system:
> Clean this data and make some useful charts.
The AI may do an excellent job.
But you stayed at the task level.
Now move one abstraction level down.
Instead of asking AI to clean the data, ask:
> Can you build a program that automatically cleans this kind of data and generates the charts every time new data arrives?
Now AI is no longer performing the task.
It is helping build the machine that repeatedly performs the task.
That distinction is important.
One approach produces an output.
The other produces a capability.
Move down another level:
What exactly does the program do?
Remove duplicates.
Normalize dates.
Validate categories.
Detect missing values.
Reject malformed records.
Calculate metrics.
Store results.
Generate visualizations.
Now you are thinking about mechanisms.
But you can also move upward.
Ask:
> Why do I need the charts?
Maybe the answer is:
> I need managers to identify problems.
Move upward again:
> Why should managers look through charts to discover problems?
Perhaps they should not.
Maybe the system should continuously monitor the data and notify managers when something meaningful changes.
You started with:
**Make a chart.**
You ended with:
**Build an organizational early-warning system.**
That is the value of changing abstraction levels.
---
The Difference Between Doing Work and Building a Machine That Does the Work
One of the most useful downward abstraction moves is this:
Instead of asking:
> How do I perform this task?
Ask:
> How would I build something that performs this task repeatedly?
That changes your thinking.
Instead of writing a weekly report, build a reporting system.
Instead of manually checking inventory, build an inventory-monitoring system.
Instead of responding to the same customer questions, build a knowledge system that answers them.
Instead of manually inspecting every product, build an inspection process.
This does not automatically mean everything should be automated.
Sometimes a human is still the best mechanism.
But separating the **task** from the **machine that performs the task** forces you to see the underlying structure.
---
Now Bring the Physical World Into It
Modern discussions about automation often stop at software.
That is too narrow.
The physical world follows a very useful loop:
Sense → Understand → Decide → Act → Verify
This pattern exists in biological organisms, machines and increasingly intelligent systems.
Sense
Something measures reality.
Examples include:
Cameras.
Microphones.
Temperature sensors.
Pressure sensors.
GPS.
Radar.
LiDAR.
RFID.
Accelerometers.
Moisture sensors.
Chemical sensors.
---
Understand
The system interprets the information.
That might involve:
Simple thresholds.
Rules.
Statistical models.
Computer vision.
Optimization algorithms.
Machine learning.
Large language models.
---
Decide
Something determines what should happen.
For example:
Reject this product.
Open this valve.
Slow the machine down.
Notify this manager.
Change this route.
Increase the temperature.
Request human review.
---
Act
Something changes the physical world.
A motor moves.
A valve opens.
A pump starts.
A robotic arm moves.
A heater turns on.
A door locks.
A vehicle changes direction.
A human receives instructions and performs an action.
---
Verify
Finally, the system asks:
**Did the action actually work?**
This step is extremely important.
A software command saying that a valve opened does not necessarily mean that water actually flowed.
You may need another sensor to verify the result.
That turns automation into a feedback loop.
---
Manufacturing: From Inspection to Prevention
Imagine a factory producing thousands of bottles.
At first, the problem might be:
> We need workers to catch defective bottles.
That is the task.
Move down.
What is the worker actually doing?
Looking at each bottle.
Comparing it with expectations.
Recognizing defects.
Removing bad bottles.
Now the task can be decomposed.
A camera observes the bottle.
Computer vision analyzes the image.
Software classifies the bottle.
A programmable controller receives a signal.
A pneumatic actuator pushes the defective bottle off the production line.
Now digital information has caused a physical object to move.
But do not stop there.
Move upward.
Why are we inspecting bottles?
Because defective bottles should not reach customers.
Now ask:
> Can we detect the cause of the defects earlier?
Perhaps the problem comes from inconsistent temperature, fill pressure, machine alignment or material quality.
Sensors could monitor those variables.
The system might notice that defects begin increasing whenever a machine drifts outside a certain operating range.
Instead of merely identifying bad products, the factory begins adjusting the process before defects occur.
The abstraction changes from:
**Detect defective products.**
to:
**Maintain a production process that produces fewer defects.**
That is a much larger improvement.
---
Agriculture: From Automatic Watering to Crop Optimization
Consider irrigation.
At the simplest level:
> The farmer waters the plants.
Move downward.
A valve controls water.
The valve is activated electrically.
A controller decides when the valve opens.
Soil sensors measure moisture.
Weather data provides additional information.
Now you can build:
**Sensor → software → decision → valve → water**
That is already useful automation.
But now move upward.
Why are we watering crops?
To maintain conditions that help plants grow.
Water is only one variable.
The real system may involve:
Water.
Temperature.
Sunlight.
Humidity.
Soil nutrients.
Pest pressure.
Plant disease.
Growth stage.
Now the question changes from:
> When should this field be watered?
to:
> What environmental conditions will maximize healthy crop production while minimizing resource use?
The irrigation system has become part of a much larger optimization system.
---
Warehouses: From Helping Workers to Rethinking Inventory
Imagine a warehouse employee walking through aisles looking for products.
A straightforward improvement might be:
> Build an app showing the employee where every product is located.
Useful.
Now move downward.
A database stores product locations.
A barcode or RFID system identifies products.
Software calculates a picking route.
A handheld device gives directions.
Move down again.
Instead of showing a human where to walk, perhaps a mobile robot receives the route.
Software sends instructions.
Motors turn.
Wheels move.
The product physically travels across the warehouse.
Now move upward.
Why are products being moved so far in the first place?
Maybe frequently ordered products are stored badly.
Perhaps products should be positioned based on demand.
Or warehouses should be closer to customers.
Or products should arrive from suppliers at different times.
You began with:
**Help workers find products.**
You eventually reached:
**Redesign inventory placement and the supply chain.**
The original problem may shrink dramatically.
---
Restaurants: Question the Workflow
Imagine a restaurant.
At the obvious level:
A waiter takes an order.
Move downward.
The customer speaks.
The waiter interprets the request.
The waiter enters information into a point-of-sale terminal.
The kitchen receives the order.
A cook prepares the meal.
The waiter delivers it.
Now individual pieces can change.
Customers might order from a tablet.
A QR system could send orders directly to the kitchen.
Voice recognition could capture orders.
Software could automatically check inventory before allowing unavailable dishes to be ordered.
Now move upward.
Why does the waiter take orders?
To communicate the customer's desired meal to the kitchen.
Once you recognize that purpose, many implementations become possible.
The waiter may still be valuable—but perhaps for hospitality rather than data entry.
A technological improvement does not always remove a profession.
Sometimes it changes where human effort is most useful.
---
Construction: Give Buildings a Nervous System
Consider concrete curing.
Traditionally, builders may inspect conditions and perform tests to determine whether concrete has reached sufficient strength.
Move downward.
Temperature affects curing.
Moisture matters.
Sensors can be embedded in the structure.
Measurements can be collected continuously.
Software can analyze them.
Now imagine connecting that information to other building systems.
Heating changes.
Cooling changes.
Water application changes.
Workers receive alerts.
Move upward.
Why are we monitoring concrete?
Because we want a safe structure.
Go higher.
What if the building continued monitoring itself for decades?
Sensors could potentially observe:
Vibration.
Strain.
Moisture.
Temperature.
Movement.
Structural changes.
Now you are no longer thinking about a construction inspection.
You are thinking about a structure with something resembling a primitive nervous system.
It senses its own condition and reports abnormalities.
---
Healthcare: From Measuring Illness to Maintaining Health
Consider a hospital patient.
At one level:
> A nurse checks the patient's vital signs.
Move downward.
Sensors measure heart rate.
Blood pressure is recorded.
Blood oxygen is measured.
Temperature is measured.
Software stores the readings.
Algorithms can identify abnormal patterns.
Now connect the chain:
**Sensor → analysis → alert → clinician → intervention**
That is a feedback system.
Now move upward.
Why monitor vital signs?
To recognize deterioration.
Move higher.
Why wait for obvious deterioration?
Perhaps patterns across many signals can reveal problems earlier.
The system might combine:
Heart rate.
Respiration.
Movement.
Medication.
Sleep.
Laboratory results.
Blood pressure.
Medical history.
The abstraction has shifted from:
**Record the patient's condition.**
to:
**Detect meaningful changes in the patient's condition early enough to act.**
Again, the original task becomes part of something larger.
---
Retail: Is the Shelf the Real Problem?
Suppose a store repeatedly runs out of products on shelves.
The obvious solution might be:
> Have employees check shelves more frequently.
Move downward.
Camera sees shelf.
Computer vision estimates remaining inventory.
Software compares shelf inventory with expected demand.
Employee receives restocking instruction.
That solves part of the problem.
Move farther down and a robotic or automated system might physically transport products.
But move upward instead.
Why does the product need to be sitting on a shelf?
Because customers need access to it.
Does access require shelves?
Not necessarily.
Perhaps products could be stored densely and retrieved automatically when requested.
Suddenly the question becomes larger:
> What should a physical retail store actually look like?
Once again, changing abstraction levels reveals possibilities hidden by the original assumption.
---
Education: Stop Assuming the Lecture Is the Product
Consider education.
A struggling student says:
> I don't understand this lecture.
A direct solution might be to improve the lecture.
But move upward.
Why does the lecture exist?
To help the student understand the concept.
Now the lecture is no longer sacred.
The learning experience might instead involve:
Interactive simulations.
Practice problems.
Visual explanations.
Discussion.
Experiments.
Games.
Tutoring.
Projects.
AI-assisted feedback.
Move downward instead.
What does "understanding" actually require?
Perhaps the student must:
Recall certain facts.
Recognize patterns.
Apply a method.
Explain the idea.
Transfer it to a new situation.
Now the educator can design around those specific mechanisms rather than simply producing more presentation slides.
---
Marketing: Move Above the Advertisement
Imagine a company saying:
> We need better advertisements.
That is the current abstraction.
Move down.
What makes an advertisement work?
Audience.
Message.
Creative.
Offer.
Placement.
Timing.
Measurement.
Landing page.
Conversion process.
Now you can improve each mechanism.
But move upward.
Why are you advertising?
To create demand?
Capture existing demand?
Build awareness?
Generate trial?
Acquire customers?
Increase retention?
Different purposes may require completely different systems.
Sometimes the real problem is not the advertisement at all.
Maybe customers try the product but do not return.
In that case, improving advertising simply sends more customers into a retention problem.
Moving upward prevents you from optimizing the wrong component.
---
Human Resources: Don't Automate a Bad Process
Imagine a company receives thousands of job applications.
Someone proposes:
> Let's use AI to rank resumes.
That might help.
But first move upward.
Why are there thousands of applications?
Perhaps the job description is too broad.
Perhaps applications are too easy to submit.
Perhaps the company does not clearly describe the required skills.
Perhaps the hiring process attracts many people who cannot possibly qualify.
Now move downward.
What is the recruiter actually looking for?
Specific experience?
Communication ability?
Technical competence?
Portfolio quality?
Reliability?
Leadership?
Those signals might be measured more directly than through a resume.
The lesson is important:
**Automation can make a bad process run faster.**
That does not make the process good.
---
One of the Best Questions: Why Does This Task Exist?
When you encounter repetitive work, do not immediately ask:
> How do we automate this?
First ask:
> Why does this work exist?
Sometimes the answer reveals an important business function.
Other times it reveals historical baggage.
Organizations accumulate tasks.
A report was created five years ago because one executive requested it.
That executive left.
The report remained.
Then someone automated the report.
Then someone built a dashboard for the report.
Then someone created an AI summary of the dashboard.
Nobody asked whether the information was still needed.
Automation without abstraction thinking can produce extremely sophisticated waste.
---
Another Powerful Question: Can I Build the Machine Instead?
There is an enormous difference between producing an output and producing a capability.
Instead of:
Write the report.
Think:
Build the reporting system.
Instead of:
Analyze this customer.
Think:
Build the decision framework that analyzes customers consistently.
Instead of:
Fix this dataset.
Think:
Build the validation pipeline that prevents dirty data from entering the system.
Instead of:
Find this problem.
Think:
Build the monitoring system that automatically notices this category of problem.
One piece of work solves one instance.
A system solves a category of instances.
---
Move Down Until You Reach Reality
Abstract thinking is powerful, but there is also danger in staying too abstract.
Eventually every real system touches reality.
A manufacturing dashboard does not manufacture anything.
An agricultural model does not water plants.
A logistics algorithm does not move boxes.
A medical alert does not treat a patient.
Somewhere, information must become action.
A useful question is:
> Where does this system cross from information into the physical world?
That boundary is often where interesting opportunities exist.
Software sends a command.
A motor rotates.
A valve opens.
A person changes behavior.
A product moves.
Energy transfers.
Material changes.
Reality becomes different.
---
Move Up Until You Reach Purpose
Moving downward shows how something works.
Moving upward reveals why it exists.
Suppose someone tells you:
> We need better truck-routing software.
Move upward.
Why?
Fuel costs are too high.
Why?
Trucks are driving too far.
Why?
Inventory is located far from customers.
Now perhaps routing is not the largest opportunity.
Maybe the organization should relocate inventory.
Or forecast demand better.
Or change delivery frequency.
Or change packaging so more products fit on each truck.
The best solution to a routing problem may sometimes exist outside the routing algorithm.
---
Think Sideways Too
Up and down are not the only useful directions.
Systems interact with neighboring systems.
Call this **lateral abstraction**.
Suppose you are improving an airport baggage system.
You could study:
Conveyor belts.
Tracking systems.
Sorting algorithms.
But sideways connections also matter:
Flight scheduling.
Security screening.
Passenger check-in.
Aircraft loading.
Weather delays.
Gate assignments.
Staffing.
A delay in one system propagates through the others.
Many real-world failures happen because teams optimize individual components while ignoring connections between them.
---
The Replacement Question
Another useful exercise is to ask:
> If we were designing this system from zero today, would this component still exist?
Be careful with this question.
Existing systems often contain valuable knowledge accumulated through decades of experience.
Old does not automatically mean bad.
But historical processes can also survive long after their original constraints disappear.
Examples:
Would paperwork exist?
Would employees manually copy numbers between systems?
Would customers stand in this particular line?
Would this department send this report?
Would this approval require five people?
Would this machine need to operate this way?
Would the warehouse have these aisles?
Would the classroom use this schedule?
The goal is not to destroy existing systems.
The goal is to identify which constraints are real and which are inherited assumptions.
---
A Practical Mental Model
Whenever you encounter an interesting problem, write down seven questions.
+2: What larger purpose does this serve?
Why does anyone care?
---
+1: What larger system is this part of?
What happens before and after it?
---
0: What am I looking at?
Describe the task exactly as it exists today.
---
-1: What mechanism makes it happen?
People?
Software?
Machines?
Rules?
Processes?
---
-2: What physically makes that mechanism work?
Signals?
Energy?
Movement?
Materials?
Chemistry?
Human behavior?
---
SIDE: What other systems touch it?
Customers?
Suppliers?
Other departments?
Regulators?
Transportation?
Infrastructure?
---
REPLACE: Would I design it this way today?
If not, what would replace it?
---
Example: The Elevator
Consider something ordinary: an elevator.
At level zero:
**An elevator moves people between floors.**
Move upward:
It is part of a building transportation system.
Move upward again:
The purpose is efficient movement through vertical structures.
Move downward:
Motor.
Controller.
Doors.
Cables or belts.
Brakes.
Sensors.
Move farther down:
Electrical energy creates electromagnetic forces.
Those forces generate mechanical torque.
Mechanical components move mass against gravity.
Now move sideways.
The elevator interacts with:
Fire safety.
Electrical systems.
Security systems.
Building access.
Emergency power.
Traffic patterns.
Maintenance systems.
Now ask the replacement question:
> If we redesigned high-rise movement from scratch, would elevators work exactly as they do today?
Maybe.
Maybe not.
The important part is not finding the answer.
The important part is learning to ask the question.
---
Beware of Local Optimization
One of the biggest advantages of abstraction thinking is that it helps prevent **local optimization**.
Local optimization means improving one part of a system while accidentally making the overall system worse.
Imagine a warehouse manager is measured only on packing speed.
The packing department becomes extremely fast.
But shipping cannot process packages quickly enough.
Now boxes pile up.
The packing department's metrics improve while the warehouse performs worse.
The same thing happens in organizations.
Sales may maximize new customers while operations becomes overwhelmed.
Manufacturing may maximize production volume while inventory piles up.
Marketing may maximize leads while sales receives poor-quality prospects.
Customer service may minimize call time while customers have to call repeatedly.
Each department can look successful individually while the system fails collectively.
Moving upward reveals the whole system.
---
The Goal Is Not Always Automation
It is tempting to assume this framework inevitably leads toward automation.
It should not.
Sometimes the better abstraction reveals that a human should remain involved.
Humans are unusually good at certain things:
Handling ambiguous situations.
Understanding social context.
Making ethical judgments.
Building relationships.
Responding creatively to unusual circumstances.
Recognizing when rules should not be applied mechanically.
Machines are often excellent at:
Repetition.
Measurement.
Monitoring.
High-speed calculation.
Consistent execution.
Large-scale pattern detection.
The question should not be:
> How do we remove the person?
A better question is:
> Which part of the system benefits most from human judgment, and which part benefits from automation?
That produces stronger systems.
---
AI Makes This Way of Thinking More Important
Artificial intelligence dramatically lowers the cost of building certain capabilities.
Software prototypes can be created faster.
Data can be analyzed more easily.
Images can be interpreted.
Text can be classified.
Natural language can become an interface to software.
This means individuals and small teams can now experiment at system levels that previously required much larger technical organizations.
But AI also creates a trap.
Because AI can perform tasks quickly, people may simply ask it to perform more tasks.
Write this.
Analyze this.
Summarize this.
Clean this.
Classify this.
Those uses are valuable.
But the larger opportunity often appears when you ask:
> Can AI help me build the system that continuously handles this category of work?
And an even larger opportunity may appear when you ask:
> Why does this category of work exist in the first place?
---
The Most Interesting Boundary: Bits to Atoms
For decades, much of computing focused on moving and transforming information.
Numbers.
Documents.
Images.
Transactions.
Messages.
Records.
Today, software increasingly connects directly to the physical world.
Cameras see.
Sensors measure.
Algorithms interpret.
Software decides.
Machines act.
Robots move.
Vehicles navigate.
Buildings respond.
Factories adjust.
This creates a useful conceptual boundary:
**Bits → decisions → atoms**
Information becomes physical action.
A database value becomes a warehouse robot moving a pallet.
A temperature reading becomes a cooling system changing output.
A camera image becomes a machine removing a defective object.
A soil measurement becomes irrigation water flowing.
A traffic sensor becomes a light changing.
That connection between intelligence and physical systems is likely to be one of the most important areas of technological development.
---
Practice This Everywhere
You do not need to be an engineer.
Practice abstraction thinking while going through normal life.
At a grocery store:
Why are checkout lines organized this way?
At a hospital:
Why does this information move from this person to that person?
At work:
Why is this report created every week?
While driving:
Why does this intersection require this traffic pattern?
At a restaurant:
Why does ordering follow this sequence?
While using software:
Why does the user need to click these five buttons?
Inside a warehouse:
Why is inventory physically arranged this way?
In your own job:
Why does this task repeatedly consume someone's time?
Then move.
Up.
Down.
Sideways.
Back to physical reality.
---
Do Not Ask Only “How Can I Improve This?”
That question often keeps you trapped inside the existing design.
Instead, rotate among several questions:
**How can I improve this?**
**What creates this?**
**What is this part of?**
**Why does it exist?**
**What happens before it?**
**What happens after it?**
**Can the cause be eliminated?**
**Could a system perform it repeatedly?**
**How does information become physical action?**
**How do we verify the action worked?**
**Would we design it this way if we started today?**
Each question moves your mind to a different level.
---
Three Types of Problem Solvers
There is a useful progression here.
The Task Solver
The task solver asks:
> How do I do this better?
This person improves execution.
Organizations need these people.
---
The System Builder
The system builder asks:
> How do I create something that handles this repeatedly?
This person creates leverage.
Instead of doing the work every time, they create processes, software, machines or organizations that repeatedly produce the result.
---
The Architecture Thinker
The architecture thinker asks:
> Why does this task exist, and should the surrounding system work differently?
This person redesigns the structure itself.
The strongest problem solvers can move among all three modes.
Sometimes the right answer is simply to perform the task.
Sometimes the right answer is automation.
Sometimes the right answer is eliminating the task.
The skill is knowing which level deserves attention.
---
A Simple Rule to Remember
Whenever a problem appears, resist the urge to immediately solve it.
First travel the ladder.
Ask:
**One level up:**
What larger outcome are we actually trying to achieve?
**One level down:**
What mechanism actually creates the result?
Then continue moving until you understand the system well enough to decide where intervention produces the greatest leverage.
Sometimes you will discover a better tool.
Sometimes you will discover a better process.
Sometimes you will build a machine.
Sometimes you will redesign the entire system.
And sometimes you will discover that the problem you were originally asked to solve should not exist at all.
That is the deeper value of abstraction thinking.
It teaches you not merely to find better answers.
It teaches you to find better questions.