The Secret to Navigating Uncertainty: Move Your Feet

Sometimes, the most productive thing you can do is write bad code.

About 15 years ago, I read a post by Matt Swanson called “Move Your Feet.” His advice for a runner who wanted to get faster was painfully simple: just run. That idea stuck. It’s not a revelation I have anymore; it’s a fundamental operating principle. It’s the lens through which I approach ambiguous technical problems, operating with a Staff-level mindset.

Recently, my team was tasked with a new feature that needed to be embedded across several existing pages. The easy path was duplication. The right path was a reusable component. The challenge wasn’t in recognizing the right path; it was in the execution. Specifically, how do you build a reusable component with a great local dev experience when you don’t have the backend services ready yet?

A junior engineer might see this as a blocker. A past version of me would have treated it as a research project, spinning up a Confluence doc and diagramming potential solutions before writing a line of code. It felt productive, but it was just procrastination disguised as diligence.

My approach, shaped by that “move your feet” philosophy years ago, is different. As a leader, my job isn’t just to solve the problem; it’s to de-risk the strategy for solving it. The goal isn’t to find the perfect plan. The goal is to take the first, smallest step that generates momentum and creates a “thin slice” of the system that validates the architectural approach for the entire team.

So, I didn’t start with a grand plan. I started with the most basic, tangible artifact of truth: the contract. I wrote a simple OpenAPI spec. It wasn’t complete. It was probably wrong. But it existed. That was the first step.

With that contract file, I could open Storybook and start building the UI. I didn’t wait for a sophisticated mock server. I hard-coded a JSON object in the story file. The component appeared. The feedback loop was immediate. This is the critical part of the “move your feet” mindset: you don’t build the whole system at once. You build the next, smallest piece of the loop.

Seeing the UI made the contract’s flaws obvious. I updated the spec. The component broke. I fixed the component. The loop tightened. Only then, with a working, tangible loop, did I introduce a more advanced tool like MSW to serve the contract. The tool didn’t lead the process; it served the process.

This isn’t a story about how to build a contract-driven UI—though I’ve written about that more broadly. It’s a story about how a leader de-risks ambiguity. My value here wasn’t in having the answer. It was in creating a system for finding the answer. By taking the first step, I gave the team a tangible starting point. I transformed a vague, intimidating problem into a series of small, manageable tasks.

This philosophy is the direct antidote to what I call “The Planning Delusion”: the belief that you can think your way to clarity in a vacuum. You can’t. You don’t gain clarity by drawing more diagrams or writing more specs. You gain clarity by taking a step, seeing the result, and adjusting your course. I didn’t just unblock the feature; I demonstrated a strategy for navigating uncertainty.

That post all those years ago gave me more than a productivity hack. It gave me a professional philosophy. Just move your feet.