How to Think Like an Engineer: Define, Measure, Solve

Engineers are not smarter than everyone else. They are just trained to think in a particular sequence, and that sequence is teachable. The core of engineering thinking is a simple loop: define the problem precisely, measure what matters, and solve the smallest thing that changes the outcome. Most people skip the first two steps and wonder why their solutions do not stick.

The good news is that you do not need a degree to use the method. You need discipline, and a willingness to be boring. Here is how the loop works in practice.

1. Define the Problem Before You Touch the Solution

The most expensive mistake in any project is solving the wrong problem. A team will happily spend a month building a beautiful solution to a question nobody asked. Engineering thinking starts by resisting that instinct.

A well-defined problem is specific, bounded, and testable. "Sales are down" is not a problem, it is a mood. "Orders in the London region dropped 12% over the last two quarters while every other region stayed flat" is a problem. It names the thing, the place, the size, and the time window. Once you have that sentence, you can work on it. Before that, any work is guesswork.

The classic trick is to write the problem statement down and read it back. If it could describe a dozen different situations, it is too vague. Rewrite it until it could only describe this one.

2. Ask "Why" Five Times, Then Stop

Behind every visible problem is a chain of causes. The visible problem is usually a symptom. Asking why repeatedly, each time on the previous answer, walks you down the chain.

Why are orders down in London? Because the top two salespeople left. Why did they leave? Because commission targets changed. Why did the targets change? Because a new manager wanted to cut costs. Why did they cut costs there? Because the regional budget was squeezed. By the fifth why, you are looking at a budgeting decision, not a sales problem.

The discipline matters: stop at five, or when the answers stop being actionable. Endless why-chasing turns into philosophy. The goal is to reach the level where you can actually change something.

3. Measure What Matters, Not What Is Easy

Engineers are allergic to opinions dressed up as facts. "The system feels slow" is an opinion. "The checkout takes 41 seconds on average" is a measurement. The second one is useful because it can be compared, tracked, and improved.

The trap is measuring what is easy instead of what matters. Website visits are easy to count and mostly useless. Conversion rate is harder to get and infinitely more valuable. When you are choosing what to measure, ask: if this number moves, will I know whether the problem is fixed?

Measure a baseline before you change anything. Without a baseline, you cannot know if your fix worked or if you just got lucky. The baseline does not need to be fancy. A week of data, a simple average, and a note about the outliers is enough.

4. Solve the Smallest Thing That Could Work

Once the problem is defined and measured, the temptation is to build the grand solution. Resist it. The engineering instinct is to find the smallest change that produces a measurable improvement, ship it, and measure again.

Small solutions fail cheaply and teach quickly. A one-week experiment with a new pricing page tells you more than a six-month redesign project. If the small solution works, you scale it. If it does not, you have lost a week instead of a year, and you learned exactly why.

This is why engineers refactor code in small steps and test after each one. The same logic applies to business: change one variable, observe the effect, then change the next. The people who fix everything at once never know which change did the work.

5. Verify With Data, Not With Feelings

A fix that feels right but does not move the numbers is not a fix. The final step of the loop is verification: compare the after measurement to the baseline, and be honest about the result.

This is harder than it sounds, because people get attached to their solutions. The engineer's defence is a pre-committed success criterion. Before you make the change, write down what number has to move, and by how much, for the change to count as a win. Then the verdict is the data's job, not your ego's.

If the number did not move, the experiment worked even though the solution failed. You now know something you did not know before, and that knowledge is the raw material of the next attempt.

6. The Loop, Applied to Anything

This sequence is not limited to machines and code. It works on a leaking roof (define: which corner, when it rains; measure: how much water; solve: patch the smallest crack first). It works on a stalled project (define: what deliverable is late, by how long; measure: the actual bottleneck; solve: remove one blocker this week). It works on a bad habit (define the trigger precisely, count the occurrences, change one small cue).

The power is not in any single step. It is in the refusal to skip steps. Most people jump straight to solutions because solutions feel productive. Defining and measuring feel like delay. They are not delay. They are the difference between activity and progress.

7. What It Looks Like From the Outside

A person who thinks like an engineer asks questions other people find annoying. "What exactly are we trying to fix?" "What number will tell us it worked?" "What is the smallest version of this we can try this week?" The questions feel slow in a meeting and fast in the results.

Over time, the loop becomes automatic. You stop proposing solutions before you understand problems. You stop trusting feelings you could measure. You stop building grand things you could test small. And you start being right more often, which is the only metric that matters.

Tags

#engineering #productivity