AI & Leadership · 9 min
Work IN. Work ON. Work AS.
The old leadership advice was to get out of the work. AI may be giving us a reason to get deeper into it.
There is a familiar piece of management advice: work ON the business, not IN it. The distinction comes from Michael Gerber's The E-Myth Revisited and has long since become part of the vocabulary of management. Working IN means doing the work — serving the customer, solving the problem, writing the code, making the sale. Working ON means improving the machine that produces those outcomes: systems, processes, structure, strategy.
It is a useful distinction. But something has changed. AI is creating a third mode, and it sits between the other two. Not working IN. Not working ON. Working AS.
I think it may become one of the defining skills of knowledge work in the AI era — and, less obviously, the thing that decides how well a company implements AI at all.
The problem with two modes
The old model contains a tension. Spend all your time IN the work and you become the bottleneck. You solve the problems, you answer the questions, you make the decisions, you become indispensable — and you have no time left to improve the system that produces tomorrow's outcomes.
So you are told to step back. Design the process, build the system, document the knowledge, delegate the execution. That creates leverage, and it creates a second problem: the further you move from the work, the easier it becomes to design a system based on an abstraction of the work rather than the work itself.
The spreadsheet says one thing. The process document says another. The people actually doing the work know something else. That gap — between the system as designed and the work as experienced — is where most of the valuable knowledge lives.
The knowledge we do not know we know
Expertise is not entirely explicit. Experts do not simply follow a list of instructions. They notice things. They recognise patterns. They sense when something is slightly off. They know which exception matters and which does not, and when a situation calls for judgement rather than process.
This is usually called tacit knowledge. The OECD's work onAI and the future of skills makes the point that tacit knowing is not the same as knowledge you can articulate, and that it is often difficult — sometimes impossible — to reach by introspection alone.
That matters enormously for AI, because the valuable thing is rarely “here are the twelve steps”. It is closer to: when I see this particular pattern, I become more cautious. Or: this customer is technically asking one question, but the real issue is something else. Or: the numbers look fine, but I do not trust them yet.
The expertise is not in the action. It is in the judgement behind the action.
So what is Work AS?
Work AS means doing the work while making yourself a reference model for how the work should be done. You are not only executing, and you are not designing the system from a distance. You are performing the work as a way of discovering the system inside it.
Think of it as the player becoming the coach while the game is still being played. You answer the customer while noticing what made the answer good. You review the document while noticing the criteria you are applying. You decide while noticing which signals made you trust one option over another.
Seen together, the three modes are a progression:
- Work IN asks what needs to get done. It produces the outcome.
- Work AS asks what I am doing that makes this work. It producesthe logic, the pattern, the judgement.
- Work ON asks how we make it repeatable. It produces the system.
Work IN creates experience. Work AS extracts intelligence from that experience. Work ON turns that intelligence into capability. Which is why Work AS is not another word for reflection or documentation — it sits between execution and architecture, and it is the step most organisations skip.
Why this is the real bottleneck for AI
Organisations have always tried to capture tacit knowledge through training, mentoring, SOPs and communities of practice. What is new is that AI can be an active partner in the conversion.
Instead of writing the retrospective at the end of a project, you can interrogate the work while it is happening. Instead of asking an expert to spend two days writing a manual, you can have them do the work and use AI to help surface the patterns, decisions, exceptions and assumptions inside it. Not only what happened, but: why did you do that? What would have made you choose differently? What did you notice that was not obvious? Which parts of this are rules, and which parts are judgement?
A small example. A leader answers a difficult customer email. That is Work IN. While writing, they notice that the stated problem is not the real problem, that the tone matters more than the factual complaint, that one phrase signals escalation risk, and that the normal policy should be bent here without becoming a precedent. That is Work AS — they have just exposed part of their decision model. What that logic then becomes — a coaching framework, a review rubric, a prompt, an agent's escalation rule — is Work ON.
Recent research points the same way. One 2026 study examines how generative AI canmake tacit knowledge explicit in apprenticeship systems; another sets outdesign principles for governing AI-mediated capture and transfer of expertise, including decision heuristics and risk judgement. That same work is clear about the risks: hallucination, goal drift, agreement bias, and distortion of the expert's original meaning.
So Work AS is not “let AI watch me and automate everything”. It is: use AI to help me see, articulate, test and encode what I am learning from the work. A more interesting proposition, and a considerably safer one.
The part that decides what stays human
Here is why I think this matters more than it first appears. The usual worry about AI is that it takes work away from people. The more practical risk is that companies delegate the wrong things — handing over the parts that carried the judgement, and keeping the parts that were only ever routine.
That distinction cannot be made from the conference room. It takes someone close enough to the work to say: this step is a rule, that one is a judgement call; this is the exception that reveals what we actually care about; this is where a novice would go wrong.
Work AS is how that awareness gets built, and it cuts both ways. The more precisely you can describe the routine, rule-based part of your work, the more confidently you can hand it to an agent — and the more clearly you can name the part that should stay human, and defend the time for it.
That is the actual promise. Not fewer people, but better-placed ones. Every hour of genuinely routine execution you delegate well is an hour returned to the work only a person can do: the judgement, the relationship, the responsibility, the thing that needssomeone to care about it.
But you only earn that trade by understanding the work well enough to split it correctly. Split badly, AI ends up holding the judgement while the human does the admin around it. That happens more often than anyone admits, and not because the technology failed. It happens because nobody did the Work AS.
A deliberate practice
The skill itself is simple. When you are doing something that matters, stop periodically and ask:
- What did I notice — which signals actually influenced the decision?
- What did I know without explicitly thinking about it?
- What exception did I make? Exceptions usually reveal the real rule.
- What would a less experienced person have missed?
- Could another person — or a system — reproduce this reasoning? If not, what is missing?
The last question is the hinge. Where the answer is yes, you have found something that can become part of the system. Where the answer is no, you have found something worth protecting.
Write the answer down as one sentence. Not a procedure, not a lesson for everyone. Over time those sentences become your own rosetta stone: knowledge tested in your actual work rather than borrowed from someone else's theory.
The new loop
The old model was work IN, then work ON. Do the work, step back, build the system. The AI-era model may be: work IN, work AS, work ON — and back into the work with a better system. Do it. Observe it. Extract the intelligence. Build. Return.
The boundary between doing and designing becomes more fluid. The person doing the work becomes a source of system intelligence, and the system becomes a way of amplifying it.
Knowing what is worth teaching the machine
Work AS does not replace the other two modes. It connects them. Work IN gives you ground truth. Work AS turns ground truth into transferable intelligence. Work ON turns that into organisational capability.
For a long time, leadership leverage meant getting other people to do what you used to do: delegate, standardise, document, automate. AI adds another kind — codifying how you think while you work. Which changes the question. Not “how do I get out of this work?” but: what can I learn from doing this work that would let the system carry more of it, and let me carry more of what only I can?
The danger was never working IN. The danger is working IN without learning from the work.
Because in a world where machines can increasingly execute, the scarce skill is something else: knowing what is worth teaching the machine in the first place — and what is not.