Just Keep Moving

Jason Warner
5 min readFeb 13, 2016

I’m not a runner. Like, at all. I'm not built like a runner, I don’t think like a runner, I don’t move like a runner. My cardio is pushing a car through the parking lot instead of jogging around it. I’m not a runner.

I still remember the last time I ran anything longer than a mile. It was mid-October 2009. Ragnar Ultra Relay. I still have the sticker on my car. Our team of 6 was completing the 200+ mile relay race from middle of nowhere Arizona to Tempe, AZ. My segments were approximately 12 miles, 13 miles, and 13 miles. Before starting Ragnar my longest run ever was 15 miles and that was the previous Saturday.

But, I made it. And I haven’t run since. My training is much different, my goals are much different. But I took something away from that race that I will never forget: It’s OK to speed up, it’s OK to slow down, it’s even OK to get very slow, but don’t stop. Don’t ever stop.

It’s OK to speed up, it’s OK to slow down, it’s even OK to get very slow, but don’t stop. Don’t ever stop.

See, the thing with stopping is you have to start again. And all the energy it took initially to start is needed all over again when you could have just as easily kept going in the first place. Don’t stop. Just move. One foot in front of the other. Make it to the lamppost, the driveway, that tree just over there. Keep going.

“Waiting for perfect is never as smart as making progress.” — Seth Godin

Software projects and ultra endurance running have quite a bit in common in this regard. And the same principle applies to software: Just keep moving. There’s too many opportunities to stop, too many distractions, too many reasons to not to make progress that we have to fight the urge.

The single most common way I’ve seen this emerge in software, and business for that matters, is the want for perfect, either in design, architecture, setting, or information before progress can be made. Perfect, however, is an illusion. Nothing, no matter how thoughtful or well put together, will be perfect. Edge cases will always exist. And because the tendency is to think about the edge cases and stop progress until they can all be accounted for, progress stops.

Fight this. It is almost always a trap. Probability wise, there is an unrealistically small chance that you and the people around you can’t make a good enough decision right now, keep momentum, make progress, get the thing shipped and validate somewhere along that path without stopping everything. That’s the nuance and trick here; keep moving while validating. Parallelize as much as possible, allow others to continue forward, try not to block, find a path or approach to move, even at a slower pace. Get creative with your paths. Perhaps it’s guarding against a decision with abstraction, perhaps it’s choosing a different architecture in case a component needs to be swapped out. There are many ways to move. One foot in front of the other.

Probability wise, there is an unrealistically small chance that you and the people around you can’t make a good enough decision right now, keep momentum going, make progress, get the thing shipped and validate somewhere along that path without stopping everything.

What’s happening is what I call The Fear of Future Context. It’s hard to make a decision if people think or fear that the information can and will be better in the future and their decision might look bad because of this. Don’t fall for this. Information in the future will always be better. If we wait a day, we know more, if we wait a week, we know even more, if we wait a year, we know so much more our entire outlook might change. And if we didn’t make progress in that time, we also wasted the only non-renewable thing in our lives: time. Leadership is making as good a quick decision in time as possible.

Leadership is making as good a quick decision in time as possible.

Further, mature leaders at all levels of an organization know this and are happy to have made progress in spite of opaque information and welcome new information to course correct. It’s never (or should never be) seen as someone made a poor decision, rather mature leaders recognize someone made a brave decision particularly because of the amount of information available. “Just Keep Moving” is actually one of the earliest markers of an emergent technical leader as I’ve been able to find. Someone who gets this aspect typically has the sophistication, breath, awareness and ability to coalesce divergence threads needed to actually achieve something, let alone lead something.

Mature leaders … know this and are happy to have made progress in spite of opaque information and welcome new information to course correct.

So is it ever appropriate to halt everything, stop the line and re-evaluate? Yes, of course. There are no absolutes. There are certainly times when it’s appropriate to pause, maybe even stop fully. The same truth, though, is those times are rare and certainly not as normal as we see them to be in software today. If we see those times are normal course and speed, they become tools we use more often. If, however, we treat them with the absolute heaviness that they in fact impart, we would use them more sparingly.

Project inertia is a real thing. Even a project with one person has some inertia element, largely dependent on that one person’s drive. Larger projects with several people, or big projects with many teams, have staggering inertia to them. The amount of energy required to keep something that is already in motion moving forward is orders of magnitude lower than the amount of energy required to start something from a stop.

Be a leader for your folks and your project. Guard against this and help them find alternate approaches that do not involve stopping. Be creative, think broad, think deep, find a way. The easy way is to stop, the prudent way is forward. Find the absolute smallest thing that keeps you going. Find the next. Keep it going. One foot in front of the other. Make it to the light pole.

The easy way is to stop, the prudent way is forward.

It’s OK to speed up, it’s OK to slow down, it’s even OK to get very slow, but don’t stop.

--

--

Jason Warner

CTO @ GitHub. Previously VP/Head of Engineering @ Heroku, Desktop Engineering @ Canonical/Ubuntu.