Part III — Cultivating Organizational Flow · Chapter 50 · 5 min read · First Public Draft
Artificial Intelligence
Owning What AI Can't
Execution can be handed to a system. The part that can't is the part worth being deliberate about now.
Jump to a chapter
Narrated with Microsoft's neural voice, not me — a recording.
What AI Lands In described the same pilot in three organizations with three different outcomes, none of which the technology explained. This is the chapter about being on the good end of that, and almost all of it turns out to be about ownership — the same argument as the rest of the paper, made more urgent rather than different by how quickly software can now be produced.
What changes
AI stops being a procurement question and becomes an architectural one. The decision is not which tools to buy. It is whether the organization has anything coherent for them to amplify, and that question is answerable before anyone signs anything.
Check the ownership before the capability
Take three things AI would plausibly accelerate here. For each, ask who owns the outcome — not who runs the process, who is answerable for whether the result was any good.
Where that returns a name, acceleration is a straightforwardly good idea.
Where it returns a committee, the situation is more interesting than it first looks. A committee is an owner — it is simply a slower one, and one where the accountability is shared out until it is nobody’s in particular. That can be entirely correct: some decisions genuinely should be made by several people who each see a different part of it, and the slowness is the cost of getting it right.
What it cannot do is answer at the speed the acceleration will demand of it. Make the work ten times faster and a monthly forum becomes the whole system’s clock. So the question is not whether the committee counts as an owner. It is whether it can answer as often as it will now be asked, and whether anybody in it will stand behind the answer afterwards.
None of which is an argument for waiting. It is an argument for spending two weeks on that question first, which is cheaper than the pilot and considerably cheaper than the eighteen-month conversation.
Assume the building gets distributed
More people are going to create more software, in more corners of the organization, sooner than most plans assume. Some of it will be very good. Some of it will be a spreadsheet’s worth of business logic living on somebody’s laptop, which is not new — it is just faster now.
The useful question is not whether to allow it. It is which guardrails and interfaces make it safe enough to be a good thing, and those take longer to establish than the tools take to arrive. That gap is the whole planning problem, and it is the one part of this worth being early on.
What the technology function is for once translation is cheap
For a long time a large part of what technology functions did was translate: turning what the business wanted into something a system could do. That was scarce, valuable, and is becoming much less scarce.
This is not a defensive question, and the good answers are more interesting than the queue ever was — stewardship of the parts that are genuinely hard, guardrails, interfaces, and the capabilities where being wrong is expensive. They are worth deciding deliberately rather than discovering by attrition when the queue empties on its own.
Keep the harness thin
People and agents need the same things from the organization to act: an outcome, context, boundaries, decision rights, tools, and feedback. The temptation, once agents arrive, is to build that harness for them — more rules to check, more context to load, more steps before anything is allowed to happen.
The purpose of the harness is the opposite: to reduce the cost of navigating the organization, for people and agents alike. So the useful question is not how much context an agent can be given, but how little anyone needs to make a good decision. Each rule that is there only because an ownership question was never settled is a cost both of them pay on every task. Settle the question and the rule can go; the harness gets thinner, and so does the bill.
Keep a human on every outcome
Execution can be delegated to a system. Ownership cannot. The moment it is assumed rather than assigned, it is gone, and the failure mode is specific: everybody believed somebody else was checking.
This is the one line in the chapter I would defend without qualification, and it applies at every scale — a generated report, a decision support tool, an agent doing something on its own. Not because the technology cannot be trusted, but because accountability is a relationship between people, and there is nobody on the other end of it to be in that relationship with.
The half that points outward
Everything above is about not making things worse quickly. Here is the other half, and it is the more hopeful one.
Speed of production is now, for the first time in my career, not the scarce thing. What remains scarce is knowing what is worth producing, and finding out whether it landed — both of which are human, both of which are slow, and neither of which gets faster because the building got faster.
Which means the organizations that will get the most out of any of this are the ones that already have a short distance between the people doing the work and the people affected by it. That distance was always worth shortening. It is now the constraint.
As technical friction keeps falling away, what is left is the organizational kind. That is the argument the whole paper rests on, and AI is simply the clearest demonstration of it any of us have been handed.
This cultivates: What AI Lands In, in Part II.