Executing at the Speed of Strategy

AI promises to move as fast as your strategy changes. For that to work, you have to know what your strategy actually is.

I gave my own system, Lily OS, a decision I was stuck on this week, and it pushed back with the tradeoff I would have raised myself. It cited a principle I’d written down a few weeks earlier and forgotten I had. It wasn’t telling me what to do. It was thinking alongside me, using my own reasoning, faster than I could reconstruct it from memory.

That system is something I’ve been spending time on lately, and it doesn’t do any of my actual work. It captures how I make decisions. Building my own operating system is shaping how I think we could leverage AI at this stage.

The promise of AI

The promise everyone is selling right now is speed and capability. AI that lets you execute at the speed of your decisions. I think that’s the right goal, and I can see a path to getting there. But most companies, especially enterprises, can’t move that way, because when strategy changes, the workflows and infrastructure underneath it take time to catch up.

And there’s a prerequisite to all of it. You can only execute at the speed of your strategy if you actually know what your strategy is. In a lot of teams, the real strategy may not live in a form a system can run on. It lives in a few people’s heads, and it can be subjective. Ask a few strong people how they target an account or position against a competitor and you might get different answers, all reasonable, but none of them written down.

This is a deeper version of something I’ve written about before: your moat isn’t the model. What grounds the output is your strategy and judgment, and you can’t ground something in a strategy that isn’t documented.

AI as a forcing function

What I’m finding as I build my own operating system is that it’s forcing me to articulate my strategy in the first place.

My Lily OS captures what I learn, codifies how I decide, and runs routines on top. It’s something I’m experimenting with and prototyping to understand how this can scale. The act of codifying, of having to write down not what I decided but why, is already proving super useful, because it makes my own thinking legible. It has four main layers:

The capture layer. Everything I learn, dated and structured, in plain files. Notes per meeting, a daily journal, files for the domain I’m working in, running lists of open questions, things I’m noticing, my priorities. One file is a current state snapshot that everything else reads first.

The knowledge layer. This part captures not only what I decided, but why, the reasoning behind the call, and distills that into principles: how I make a given type of decision, the plays I reuse, my prioritization rules, what I’m good at. It’s seeded from what I’ve learned across my career, and it grows and updates as I make new decisions.

The skills. The AI routines that run on top. Some run on a schedule: a morning brief, an evening capture, a weekly pass that distills the week’s decisions into principles. The rest run on demand, when I’m preparing for something, prioritizing, or pressure-testing a decision. They read from the capture and knowledge layers, so they work from my context and my reasoning instead of generic defaults.

The hub. The output and shareable view. One data file as the single source of truth, and a build step that turns it into readable pages that I can easily pull up, reference, and update.

The tactical parts, status, action items, what changed, update on their own. But anything that’s my actual perspective, an assessment or a call, gets drafted for review and worked through. The system holds my reasoning so I can decide faster and more consistently.

Here’s an example of what a principle looks like, close to how it reads in my knowledge layer:

When someone brings me a request, I start with the goal behind it, then check whether what they’re asking for actually gets them there. When it doesn’t, it’s not because the request is wrong, but because there could be a better path to the same outcome. So my default answer isn’t “no.” It’s “no, but here’s what I think actually gets you what you’re after.” The point isn't to block requests, it's to redirect them toward the actual goal.

That’s a small thing, and it’s the kind of judgment that usually stays invisible. Nobody writes down how they say no. But it could shape many decisions a week, and once it’s on the page, the system can apply the same reasoning the next time a similar request comes up.

How to know if you’re codifying good decisions

Writing the strategy down also forces a question many teams never ask: is it any good? You can codify a bad heuristic as easily as a good one. A system that captures how you decide will happily capture the ways you decide badly.

This is where working with the LLM helps. Instead of just writing down what I think my judgment is, I have it extract patterns from a factual basis: what I actually decided, discussions, and the outcomes. Self-reported judgment is often flattering and can be wrong. Decisions paired with their results are harder to fool.

I’m using myself as a test subject, which is the practical choice, even though it’s biased, since I’m both the one codifying the judgment and the one deciding whether it was good. But the act of documenting it against real outcomes is how you find out whether you have a strategy that works or just a set of habits you run on out of routine.

One thing it surfaced wasn’t a strategy at all. It was a habit I’d been treating like one. Faced with certain challenges, my current instinct is to build it myself. It’s how I move fast, experiment, and learn, and it’s produced most of the agents and tools I’ve made. On paper it looks like a strength. But written down and measured against the goal, it doesn’t hold up as a strategy, because it doesn’t compound. It can make me the single point of failure. I wouldn’t have called that a habit until I had to write down why I keep doing it. It’s part of why I’m building this as a system in the first place, so the reasoning can live somewhere other than with me.

Where this could lead

Here’s where I think this could lead for knowledge workers. For example, when your best people have an instinct for a call they make all the time, you can write down the reasoning the same way I wrote down how to say no.

Take account prioritization. An experienced seller can look at an account and know whether it’s worth going after. They’re reading signals, drawing on pattern recognition and domain expertise built over years. It shows up as instinct. Ask them to explain it and you often get “I just know.”

The moment you try to codify that, you can find out whether you have a repeatable targeting strategy or instincts that vary by rep. Write down the signals and the way they actually weigh them, and AI could apply it across every account in the funnel continuously, and tell you not just which to prioritize but why. That’s something no one can do manually across thousands of accounts, and it’s different from a generic fit score, because it’s grounded in how your best people actually think. Layer in the real signals and data where your business is focused, and you get to an accurate, actionable list of accounts to target. Then the second half of the AI promise can kick in.

Once the strategy is explicit and grounded in outcomes, it can change at the speed of the market instead of the planning cycle. When a competitor launches, when leadership pivots, when a segment stops converting, you update the codified strategy and the execution follows that week, not next quarter. That is what executing at the speed of strategy actually requires. A strategy that’s written down, grounded, and live.

What’s next

I’m starting to document my own decisions and reasoning, and to use it. It’s helping, and I’ll keep experimenting with it as a personal project.

The question I’m working through now is how to leverage the system and point it at bigger problems at a larger scale. How do you target better, score accounts and contacts, find the gaps in the funnel and figure out how to fix them? That’s where the codified strategy becomes context that a workflow or an agent runs on.

None of that part is simple. The systems underneath, the data, the integrations, the automation, are their own hard problem, and the place where a lot of AI work stalls. I’m not solving that today, but the point is that the layer has something to run on, your actual strategy instead of generic defaults.

Getting the strategy right compounds, just like the funnel we already know in marketing. Get the top of the funnel right, the right accounts and people, and conversion compounds the whole way down. A perfect email to the wrong person at the wrong time still falls flat. The leverage is at the front, in the strategy, instead of in the execution.

If you want to build your own OS and codify your decisions, start small. Take one decision you make all the time, like how you prioritize or how you say no, and write down the reasoning behind it, not just the call you made. You’ll probably find your strategy is fuzzier than you assumed once you have to say it out loud. That makes sense. It’s the hardest part to define, and the part most worth getting right. Once you can see your own strategy clearly, you can start moving at the speed of it.

In a later post, I’ll get more into the how: the skills, what a knowledge layer file actually looks like, and how you could start building your own.