I used to be obsessed with goals.
Annual targets. Quarterly breakdowns. Monthly milestones. I tracked everything. I reviewed everything. I reset when things didn't go to plan — which was more often than I'd like to admit. And every time I reset, I'd adjust the number, recommit with energy, and run the same cycle again.
It took me years to realise the problem wasn't my commitment. The problem was the tool.
Goals, as most people use them, are a terrible operating system for a business.
What goals are actually good for
Goals are directional tools. They're useful for deciding where to point yourself. "I want to be at X revenue in 18 months." "I want Y clients by the end of the year." That clarity of direction matters — without it, you're just busy, not strategic.
But direction is not a plan.
Knowing where you want to go tells you nothing about how to get there. It gives you no process for tomorrow morning. And it tells you nothing about what to adjust when things go sideways.
This is where most goal-driven entrepreneurs get stuck. They set the target, feel the energy of it, then have to figure out from scratch each week how to move toward it. No process. No structure. Just intention and effort — which is exhausting and wildly inconsistent.
What outcomes actually require
Every result I've produced reliably in my career came from the same place: a repeatable process I could trust, adjust, and improve over time.
Not motivation. Not a better goal. A better system.
When I ran e-commerce, I didn't "try harder to find good products." I built a sourcing system that gave me a consistent pipeline of vetted opportunities every week. I didn't "try to be more responsive to clients." I built a communication cadence with clear touchpoints so nothing fell through the cracks.
The outcomes I wanted were the outputs of processes I designed. Once I started thinking about it that way, the question changed entirely — from "am I working hard enough?" to "is this process good enough to produce what I need?"
That's engineering thinking applied to business. And it changes how you see almost every problem.
The goal trap in practice
Here's how the trap works: goals create urgency without creating capability.
You hit the end of the quarter, the number is short, and the solution everyone reaches for is to try harder next quarter. Work more hours. Push the team. Double the outreach. That might close the gap once. But it doesn't fix the system that produced the shortfall. Next quarter, same problem.
I've been in organisations where this cycle ran for years. Leadership setting increasingly ambitious targets. Teams working increasingly hard. Results staying roughly flat. Everyone frustrated. Nobody asking the question that mattered: what does the system actually produce — and is that enough?
When you start engineering outcomes instead of chasing goals, the question becomes: what needs to change in the process to change the output? That's a solvable problem. "Try harder" is not.
What the shift looks like
I still have targets. Direction matters. But I spend far more time on process design than on goal review.
For every outcome I want to produce, I work backward: what steps, in what sequence, executed how consistently, would make this result almost inevitable? Then I build that. Document it. Test it. Refine it.
The goal becomes almost secondary — a checkpoint to confirm the system is calibrated, not a motivational target to chase every week.
When the system is right, the outcomes take care of themselves. When the outcomes are off, I go back to the system, not to the goal.
That's not a mindset shift. It's a structural one. And it's the only reliable path I've found to results that compound rather than fluctuate.
Starting this week
Pick one result you keep trying to achieve by working harder.
Now ask: what process, if I executed it consistently for 90 days, would make that result almost inevitable?
Design that process. Write it down. Execute it. Measure it. Refine it.
Stop setting goals as if they're a strategy. Start engineering the process that produces the outcome you want.
One more thing worth saying: this shift is not about becoming less ambitious.
The people I know who've made this move most completely are, in my experience, more ambitious than the goal-setters they replaced. Not because they set bigger targets — because they build better machines. And a better machine, run long enough, consistently outperforms any goal you could have set for it.
The goal-setter looks at a result and wonders how to want it more strongly. The systems thinker looks at the same result and asks what change to the process would produce it reliably. One is a motivation problem. The other is an engineering problem. Engineering problems have solutions.
I made this shift gradually — not in one decision but across years of noticing the pattern. The outcomes I was most proud of weren't the ones where I'd wanted something intensely enough to grind through to it. They were the ones where I'd built something that produced the outcome as a natural consequence of running.
That's the difference. One model makes you the engine. The other makes the process the engine and you the designer.
Design beats willpower. Every time. In every sustained context.
The goal is a guess. The system is how you make it real.