The Illusion of Movement

Jun 23, 2026

“Never mistake activity for achievement.” - John Wooden

Speed and velocity get used as if they mean the same thing. In physics they do not, and the difference is worth borrowing.

Speed is how fast something moves. It is a scalar, pure magnitude, with no direction attached. Velocity is a vector: it carries both the speed and the direction of the motion. It is not just how fast you are going, but where you are headed. The distance we cover, the paths we choose, and the destinations we arrive at are dictated by these two.

You can have a great deal of speed and almost no velocity, running flat out and ending the day exactly where you started. Much of our hard work is just speed, and it is usually the velocity in it, the part that has a direction, that carries us anywhere.

Take this blog. It is the clearest example I have.

I bought the domain. I chose the stack, then changed it. I filled a list with sixty article ideas, still have it, some half-written, some with just outlines, and, until now, none published. I built a template, set up a project, read about how other people write. The setup kept getting better. The number of published articles stayed at zero.

Every one of those steps was real work but none of it was progress. I was polishing the setup while the only thing that mattered, shipping an article, never moved. For too long.

I call this gap the Illusion of Movement: spending real energy on motion that looks like progress, while nothing that mattered moved at all.

Building the wrong thing

“There is nothing so useless as doing efficiently that which should not be done at all.” - Peter Drucker

The most expensive version of this is not laziness. It is effort, careful and sustained, aimed at the wrong thing. We’ve all been there and we recognize the shapes. The feature shipped on time and to spec that nobody opens. The dashboard with a dozen numbers climbing, none of them the one the business actually turns on. The refactor that runs for a quarter and leaves the product exactly where it began. The dive straight into building on a problem that a little discovery would have shown was already solved. Every hour was real work, and none of it moved the goal, because the goal was never the thing being measured.

This is one of the oldest lessons in building products. Marty Cagan, who has spent a career studying why products fail, puts the blame in one place: most failures are not teams failing to build what they set out to build, they are teams building the wrong thing. The hard part is not always the construction. It is knowing what is worth building, and that question lives upstream of the first line of code.

A civil engineer would not start a bridge without knowing whether it carries cars, trains, or people. Software lets us build first and find the purpose later, because software is soft, and we underestimate the cost of that. Changing direction after you have built is slow and expensive, and sometimes worse than starting over. This is why understanding the problem before committing to a solution is cheap insurance against an expensive mistake.

Getting out

“It is not enough to be busy. So are the ants. The question is: what are we busy about?” - Henry David Thoreau

We do not get out of this by working harder, because more effort can just be more speed without a clear direction, and speed is rarely the problem. We escape it by deciding where we are going, and then constraining the motion and pointing it there.

Name the destination. Before we can point the work, we have to know where we are going, and most teams rush past this because naming it feels slower than starting. It is not a slogan on a wall. It is a handful of concrete answers that anyone on the team could write down. What problem are we actually solving, and for whom. How will they use this in the middle of a real day, not in the demo. What do we expect it to change for them, the outcome we would point to and call the work a win. And what are we trading off to get there, because choosing a direction is also choosing what we will not do, and a direction that costs nothing usually decides nothing. A destination we cannot put in a few plain sentences is not a destination yet, it is a wish. Name it early, keep it small enough to be wrong without losing too much, but name it before we start to move.

Limiting the work in progress also helps. A team caught in the trap usually has too many things moving at once, all pushed hard, none finished. Borrow the discipline from Kanban and cap how much can be in progress at any time. Fewer starts, more finishes. And because every slot is now scarce, starting becomes a deliberate choice instead of a reflex.

Make the goal visible. Pick the one outcome that defines the cycle, the thing that, if it moves, means you won, and put it where everyone can see it. Once the goal is singular and visible, motion can no longer pose as progress, because anyone can look up and check whether it actually moved. Watch for the opposite tell as well: a dashboard where everything climbs, features shipped, pull requests merged, tickets closed, while the one that matters sits still. That kind of activity is not the goal moving, and a wall of green can be the most convincing disguise the illusion wears.

The other side

“Even if you’re on the right track, you’ll get run over if you just sit there.” - Will Rogers

Sometimes we only find the direction by moving. Early in a project the path is not knowable from a desk, a startup has a goal and no map to it, and the motion is the research. Think of exploring a new city without a map: rather than deciding the route in advance, we try a street, see where it leads, drop it, and try another, experimenting with tools and methods without growing attached to any of them.

Sometimes the destination is the learning itself. We build a small thing we already know we will throw away, not to ship it but to understand a tool, a model, a problem we cannot see from the outside. That is not the illusion, as long as we are honest about what it is really for. The trap is not the throwaway, it is telling ourselves we are going to launch it. Name the real goal, learning, and the same motion that would have been waste becomes the straightest line to it. Pretend the goal is shipping, and we will keep polishing something that was never meant to ship, and call it progress.

The difference is intent: keep the experiments short, check often whether they are still useful, and stay ready to drop what fails. By moving fast first, a clear direction often emerges, and only then is it worth measuring progress against it.

Wrap-up

“If one does not know to which port one is sailing, no wind is favorable.” - Seneca

Speed and direction are intertwined, and both matter. Speed makes progress possible, but without direction it wastes the very energy it spends. Like a ship sailing with no port in mind, you might reach somewhere eventually, but slowly, and into every obstacle along the way.

This is not only a team problem. It is how a career drifts, how a side project quietly dies, how years go by full of effort with nothing you can point to. The cure is the same at every scale: name the port, point the work at it, and check often that the two still agree.

So before the next stretch of hard work, we should spend the few minutes that feel like a waste and put into one sentence where it is all pointed. When we cannot draw that line, we have found the illusion. Velocity, in the end, is just speed that knows where it is going.