Taking a thousand small steps, and nothing else

The human brain loves shortcuts.

Its natural tendency is to bucket things and cut corners as a survival strategy. Shortcuts reduce cognitive load. They help us save time and energy when resources are short.

And in certain situations, that’s a good thing. If you’re on deadline and everyone on your team is slammed, then using a shortcut might save you an order of magnitude of labor and stress.

For example, many of the top presentation software products can also be used to execute tasks like photo editing, interactive prototyping, graphic design and video production. Their final output might not be as beautiful as using a traditional design application with more technical muscle, but that shortcut still gets the job done quickly.

And with a high enough quality that most people won’t even know the difference.

I’ve gotten myself out of hundreds of design jams using this very strategy. The hacks work. In that situation, my brain uses the shortcut for good. It finds more efficient ways to complete the tasks and improve my livelihood when resources are scarce.

But in other situations, shortcuts do us more harm than good. Particularly when it comes to bigger, longer range, more strategic project based stuff.

Because when our goal is to generate meaningful change with our work, then you don’t want to take a shortcut on it, you want to do it right. Crossing that finish line is only going to be the result of taking a thousand small steps, and nothing else.

Masters writes about this process in his phenomenal book on spiritual bypassing:

No longer desperate to have a shortcut because we are so grateful to be on our way, and we smile with easy compassion at what we have done with our time, including our various detours.

His words resonate with me, as someone who spent six months launching a software platform. Talk about no shortcuts. The binary, black and white world of code is unforgiving as hell. It’s all just one big experiment. As my developer told me, sometimes you have to build a version of your product that’s completely wrong, only to scrap it and iterate your way to a solution that works.

Really? You mean all that work we put in now means bupkis?

Well, not exactly. That work is still what brought us where we are today. We needed it to fail forward.

Yes, it’s frustrating and exhausting, but there’s no other way. You can’t shortcut ones and zeroes. There’s no fast forward button. All you can do is accept the inevitable delays and trust that the next iteration will be better. Which it almost always is.

If you’re willing to hang in there and slog your way through the first version that sucks eventually you’ll stumble into the second version that rocks.

Do you know how to balance your brain’s need for speed with your project’s need for patience? It’s an important distinction.

We can’t be so naive as to believe either speed or stillness is always the answer.

Like most good things in life, it’s a matter of degree.

Do you need a shortcut right now, or do you need to take a thousand more steps?