When you become a leader, the nature of your work changes in a way nobody quite prepares you for. You stop executing and start owning: outcomes, the growth of the people around you, the decisions that others will carry out. It's a different kind of accountability: broader, slower to resolve, harder to point to.
For some people that shift happens with the first direct report. For others it's the first time they're the person in the room whose job is to ask the question rather than answer it. For me it was the second kind. For a long time, I wasn't sure asking questions counted as doing anything.
I built on weekends to compensate. Side projects, personal tools, anything with a clear output I could hold at the end of it. It was my way of getting that feeling back: making something you know you made.
What I didn't see until much later was that the leadership work was the building. I just couldn't feel it the same way.
What Leadership Actually Produces
The output of a leader isn't code or features. It's decisions: made at speed, across people and projects, with incomplete information. Every decision carries the same question underneath it, even when you don't name it: does this match what we're actually trying to do?
That question is judgment. Applied consistently, at scale, it shapes everything downstream: a wrong decision uncaught compounds; the right question asked early enough redirects weeks of work. That's where the output lives. That's the leverage point.
The problem was the lag. When someone ships a feature, you can point to the feature that day. When a leader makes the call that shapes the next quarter, the signal arrives months later, diluted across a dozen other decisions. There's no artifact you can hold. The output exists: it shows up in numbers, in team trajectory, in what gets built and what doesn't. But it arrives slowly, and it never quite feels like yours.
I spent years with that gap between what I did and what I could feel good about having done.
What AI Changed
AI didn't validate my judgment. It compressed the loop.
Before, the real work wasn't just writing a brief and assigning it. It was trying to transfer a way of thinking. Getting someone to see the problem the way I saw it, reason through the tradeoffs the way I would, catch the thing I would have caught. That's what took the time. The communication overhead was real, but the harder thing was the reasoning overhead: trying to scale judgment across people who weren't yet seeing what I was seeing.
Now that loop is tight. I can see something wrong, articulate the fix, generate an alternative, review it, and ship it in one session. The gap between decision and output has collapsed. The execution side of the loop is no longer the constraint.
What hasn't changed is the checkpoint. Someone still has to decide what to build, whether the output matches the intent, what assumption snuck through uninvited. The stop before you ship is still entirely human. AI accelerates everything around it. The checkpoint itself remains.
The Validation Loop
The discipline I've built around this is what I call the Validation Loop. Not a checklist — a habit of mind that runs before, during, and after any build.
Three questions, in order.
01 — What problem am I actually solving? The original one, not the adjacent problem the work drifted toward.
02 — Does this output match that problem? Good output is easy to produce now. Correct output is harder. The question isn't quality, it's alignment. An AI can generate something technically excellent that's completely misaligned with what you needed — and so can a team, and so can you.
03 — What assumption did I not question? Every build embeds assumptions that nobody approved. You make them to keep moving. Catching them before they compound is the job.
These questions don't change based on what stage you're in. Zero-to-one, you're asking them about usability and relevance. At scale, you're asking them about architecture and leverage. The stakes shift; the questions don't.
The New Problem
AI has its own version of the coaching problem.
As a leader, I spent years trying to get people to think this way: asking why before how, reading their own output as a user would, noticing when the work started drifting from the original intent. Some people got it quickly. Others never quite did. That translation was hard in a way I couldn't shortcut. From how I saw problems to how someone else could learn to see them: it never fully worked at scale.
The models are capable builders. They produce, iterate, and refactor faster than any team I've led. What they don't do, by default, is question the brief. They optimise for what you asked. They don't notice when the work is technically correct but directionally wrong, or surface the assumption that nobody approved.
The challenge has shifted. It used to be: how do I coach humans to think the way I think? Now it's: how do I encode the judgment into the system itself (the critical lens, the questions, the instinct for what's off) so that the loop runs without me having to manually invoke it every time?
That's the problem the next layer is trying to solve.
Coaching the Loop to Run Itself
So here's what I've built so far: two layers.
The first is a SKILL.md file: a plain Markdown document that encodes the Validation Loop as a structured prompt Claude reads before responding.
# Validation Loop
Before completing any output, run these three checks:
1. What problem am I actually solving?
Restate it in one sentence before answering.
2. Does this output match that problem?
If it drifts, solves an adjacent problem, adds unrequested
scope, or optimises for the wrong thing, flag it before delivering.
3. What assumption did I make that nobody approved?
Name at least one. If none exist, say so explicitly.
Claude reads this file at session start. The three questions become part of how it evaluates its own output, not as an afterthought but as a gate before delivery.
The second layer is where I'm still working. The idea is a Claude Code Hook on the Stop event, which fires every time Claude finishes a response. A Stop hook configured with a prompt type can read the SKILL.md file and pass the Validation Loop questions to a Claude evaluation call. That call then decides whether to surface a misalignment or allow the response through. The encoding is done. The automated checkpoint is what I'm building toward.
What I'm trying to get to is the stop a leader always had to make, running automatically before every output without me having to invoke it. The checkpoint, encoded.
I'm still refining it. The assumption detection is imperfect. Claude sometimes names the obvious ones rather than the ones that matter. But that's exactly the kind of problem I know how to work on. It's the same problem I spent years trying to solve with people.
It turns out the skill I spent years feeling guilty about is exactly the one I need to solve it.
What This Means for Judgment
Judgment was always the output. A leader's decisions, applied consistently over time, are what shape whether a team builds the right things. That hasn't changed. What's changed is that the same person can now also execute on what their judgment finds. The gap between spotting something wrong and shipping the fix has collapsed. The checkpoint remains, but everything around it moves faster.
What AI didn't change is what was always scarce: the ability to hold the original intent in mind, ask whether the output matches it, and catch the assumption that nobody approved. That's not a task you can generate. It's a habit of mind. And it compounds the same way bad decisions do: quietly, over time, in the quality of everything downstream.
Judgment is the output. It always was. The difference now is that you don't have to wait months to see it land.
It took me a long time to feel good about that. I'm glad I finally do.