Fifteen Years of Fog

Knowing exactly what to build isn't the same as building it.

I carried the same vision for fifteen years before I put it in the world.

Not a vague one. The idea was sharp early and it stayed sharp. The fog was never in the idea. It sat in the distance between having the idea and handing it to someone, and covering that distance taught me something I'd have argued with at the time. Knowing exactly what to build isn't the constraint. It's barely half of it. A vision also needs a mandate that makes it non-optional and a vehicle that carries it, and for fifteen years I was short one or the other. Mine got its mandate in a single meeting that felt like the end of something.

The Loop That Worked on Everything Else

I grew up blue collar in a small Midwest town. The view was small. The optimism wasn't.

I genuinely believed I could do anything I put my mind to. Not as a slogan on a poster. As a working assumption I acted on. When nobody has told you which doors are supposed to be closed to you, you try them all.

An Air Force ROTC scholarship paid for college, and I paid it back in uniform. I was a manpower officer. The version I told at Thanksgiving is that we worked with the spaces, not the faces: how many people the force would need, what kinds, when, and where, projected five years out against a live geopolitical picture. Get that answer wrong and somebody deploys short-handed, and the cost isn't a missed quarter. Downstream of short-handed is whether people came home. That was the condition of the work, not a distinction. It's the standard I learned to work to before I was twenty-five, and I've never unlearned it.

What the Air Force gave me was the reps. Years of forcing an answer out of a question that never had clean data, and teams of people who had to act on that answer under pressure. In my first year out of college I built decision support systems that rolled out across multiple bases.

Then I had a daughter, and the math changed. I left the Air Force for PwC, doing SAS 70 work, which is what the industry called SOC 2 before 2011.

Getting in wasn't the hard part. That practice hires plenty of people who aren't accountants, and being ex-military with a systems background was a fit, not an exception. The hard part was that almost everyone around me had a map I didn't. Their parents had lived in corporate America and handed them the route in three steps: accounting degree into a Big Four firm, then a top full-time MBA, then the CFO track. Nobody in my town could have told me those steps existed, because nobody in my town had ever needed to know them. So I watched the people a little bit ahead of me and copied what they did. That works. It's just slower than being handed the map, and you never quite know how far back you started.

So I trusted the loop. Effort creates opportunity, opportunity creates the chance for more effort, and it compounds. PwC to Conagra. Conagra to Nike. Every rung confirmed it. And that loop never moved the one thing I most wanted to move. It's very good at getting you to the next rung. It has nothing at all to say about what you're carrying up the ladder.

What I Was Carrying

Somewhere inside the transformation work at Conagra, I started seeing the same thing over and over, and I started writing it down.

The first version was a monster. Every feature, every consideration, every edge case, every stakeholder type, every failure mode I'd witnessed. It was comprehensive and it was useless, because a model nobody can hold in their head doesn't get used.

Over the next several years it kept boiling down. Not because I was trying to simplify it for an audience. Because I kept testing it against real transformations, and the parts that didn't do any work fell off. What was left was three moves. Think, Plan, Do. And the order matters.

When a transformation went well, the pattern held. All three, in order, done honestly. When one failed, I could put my finger on the exact place in the model where it broke. Every time. At every scale. A two-person process fix and an eighty-site rollout failed in exactly the same way, and if you handed me the story I could tell you which move got skipped.

The order is the part people skip past, and it's the part that does the work. In everything I've watched, most stalls get treated as Do failures, because Do is the visible part. A team that skipped Think responds to a stall by adding effort, since effort is the thing they know how to add. They reach the same wall faster. The order isn't a preference about sequence. It's a diagnostic about where to look first.

The six-phase Execution Cycle I write about now is the expanded version of those same three moves, built out for teams that need more resolution. Here's how that cycle shows up in something as ordinary as planning a family road trip.

Once you can predict the failure before it happens, you're no longer carrying an opinion about how transformations work. You're carrying something you owe people. I had no idea what to do with that yet. But I stopped treating it as a hobby.

The Break

The work I did at Nike was the best work of my career, and it ended in a break. I already wrote that day in detail, as The Day I Got Broken at a Fortune 500.

I was inside a low-trust environment and I didn't have the language for that at the time. I've written since about what culture actually is, and it isn't the free bagels or the appreciation days. It's whether a person can say a true thing and survive saying it. In a high-trust room, a gap in your methodology is information somebody hands you so you can close it. In a low-trust room, that same gap is ammunition somebody saves.

For years I read that day as a diagnosis problem. I took a political defeat and filed it as a competence failure, then spent a long time solving the wrong equation, shrinking my work to fit a conclusion that was never true. That reading holds up, and it's the one that matters if you're sitting in the aftermath of your own ambush.

Here's what else was true in that room. The work was the best I'd ever done and the environment couldn't hold it. That's not a better exit than anyone else's, and plenty of capable people get pushed out of good work with no say in it at all. But it settled one question for me. I wasn't out of capability. The room couldn't hold the work, and the thing I'd been carrying needed a room of its own.

After that, I asked myself the question I'd been too busy climbing to ask. What's my purpose? I didn't have the words for what I'd eventually build. No product name, no company, no plan. What I had was closer to a compulsion: I know what I know, I know it's right, I've tested it against twenty years of transformations and it holds, so how do I get it out into the world? A break doesn't hand you a strategy. It hands you a question that used to be optional and isn't.

Fifteen Years in the Notebook

So I tried. Across those fifteen years, before the break and harder after it, I tried to get the vision out of my head using every medium I could find.

I learned Rails. I learned enough web coding to be dangerous and not enough to be useful. I tried to build apps. I tried to build courses. I bought the tools, the hosting, the templates, the frameworks. Thousands of dollars and hundreds of hours went into attempts that all died in roughly the same place.

For a long time I thought I was failing at execution, which was a particularly cruel thing to believe about myself given what I do for a living. That wasn't it. The real problem was a shape problem. The vision is radically simple at the top and extremely deep underneath. Think, Plan, Do fits on an index card. But underneath it sit the questions that actually matter to someone trying to run a transformation on Monday morning. How do you make a plan clear enough that people can act on it without asking you three follow-up questions? How do you get thirty people genuinely aligned instead of publicly agreeable? How do you restart momentum after something stalls, when the stall itself has become the story everyone tells?

A course could carry the top layer and none of the depth. A document could carry the depth and lose everyone before page four. Software could carry both, and I couldn't build software. So it stayed foggy.

My own framework says a vision can't live in a notebook. Action-Based Leadership means the vision has to happen out where actual people are changed by it, or it isn't leadership at all. It's just a well-organized private opinion.

Mine lived in a notebook for fifteen years. I had an excellent reason, which is exactly what every exception has. The break is what forced me to apply my own standard to myself. If a vision only counts when it reaches people, then mine didn't count yet, and no amount of certainty about it was going to change that.

November 2025

The fog lifted in November 2025. Claude Opus 4.5 landed, and running it inside Claude Code changed how far I got in a single sitting. I sat down one evening to test something small and got up hours later with code that ran and did what I meant it to do.

AI didn't turn me into a person who can build anything. That's the version everybody tells, and it isn't what happened to me.

What changed was narrower. The constraint was never knowing what to build. I knew that better than I've ever known anything, down to individual decisions I'd already made in my head years earlier. The constraint was the distance between the what and something that runs, and that distance used to be spanned by years of craft I was never going to acquire while also being a father and running a career.

All those failed attempts turned out to matter. Rails, React, GitHub, databases, the command line. I never got good at any of them. But I picked up the vocabulary. I knew what a database was for, what a repository does, what it means when something fails to build. When the tools finally arrived, vocabulary was the toll, and I'd been paying it for fifteen years without knowing what I was buying.

What I Actually Built

It's called the Execution Index. XI. A person answers twenty-five questions in about ten minutes, and it reads how they move through the six phases of an execution cycle, then shows them where their capability is strong and where it's exposed. Consultants use it with the leaders and teams they serve. That's the thing that finally came out of the notebook.

The months after that first evening weren't one clean build, and the biggest thing I got wrong is the thing I should have seen coming. I showed the first real version to my first potential client and walked them through all thirty-six cells of the matrix underneath it. Comprehensive. Rigorous. Completely wrong for that conversation. I've written about what that told me about my own gaps.

I had built the deep layer beautifully and forgotten my own sentence about the monster first draft: a model nobody can hold in their head doesn't get used. Fifteen years earlier I wrote that about the vision. Then I did it again in software, and led with all thirty-six cells. So I stripped it back. What people see now opens with the three or four things that matter to them, and the depth waits underneath until somebody needs it. The rest of that story takes months to tell and belongs somewhere else. The decision took one night.

The Ordering

My purpose is to be a great husband and a great father. That's the whole thing. Everything else sits underneath it.

And part of being those two things is creating real value for the world, because that's how I have value to bring home. Not money, though money is part of it. Capability. Standing. The thing my kids see when they watch how I spend my hours. A person who has nothing to give the world eventually has less to give the people in his house.

I spent a long time thinking those two were competing. Career on one side, family on the other, every hour I gave to one stolen from the other. That's the framing that makes corporate life feel like a trade you keep losing, and most of us inherit it without ever examining it.

The reordering is what actually changed. Value for the world isn't the thing competing with the family purpose. It's part of the family purpose. Putting it in that order didn't make the risk calculation go away, and anyone who tells you it does is selling something. The numbers were the same numbers. What changed was the question those numbers were answering. So I built a different vehicle.

Fifteen years of fog, one break, and a tool that showed up at exactly the right moment. I go back and forth on whether those fifteen years were necessary or just slow. Some days the break reads as the thing that made the mandate real, and the waiting reads as the price of a tool that hadn't been invented yet. Other days it reads as fifteen years I could have compressed into five if I'd been willing to apply my own standard to myself earlier. I honestly don't know which is true, and I've stopped expecting to find out.

The vision was already correct in year one. It just hadn't earned anything yet. If you're carrying something that hasn't left your notebook, the question isn't whether the idea is good. You probably already know it's good. The question is what would have to happen for you to stop treating yourself as the exception to your own standard. And if what you're carrying is a practice rather than a product, if the thing you know how to do is the thing you're trying to sell, that's a different problem with a different shape, and it's the one I spend most of my time on now.

For me, it took getting broken. I hope it takes less for you.

---

FAQ

What does it mean for a vision to "earn its mandate"? A mandate is the difference between believing an idea and being unable to leave it alone. Ideas can sit comfortably in a notebook for years. A mandate shows up when the cost of not acting becomes higher than the cost of acting, and that usually happens at a breaking point rather than in a planning session. The idea can be fully formed long before the mandate exists.

Why did AI tools make the difference when fifteen years of effort didn't? Because the constraint was never knowing what to build. It was the distance between knowing what to build and having something that runs. Learning Rails, web coding, and half a dozen other tools never closed that distance, but it did build the technical vocabulary needed to direct a tool that closed it. The failed attempts weren't wasted. They were the prerequisite.

Should I leave my job to build the thing I've been carrying? I can't answer that for anyone else, and I'd be suspicious of anybody who says they can. What I'd offer instead is the ordering question. Name your actual top-level purpose, then ask whether the work you're doing feeds it or competes with it. If the honest answer is that your best hours are going into a vehicle that can't carry what you're built to create, that's real information. Act on it when you can, and build the vocabulary in the meantime.