Readiness Is the Work

Earlier this week in “The Bottleneck Was Never the Code,” I made one argument: AI has made the build fast and abundant, and the organizations adopting it ship no faster than before. Every leader who has invested knows the gap. Output climbs while the throughput the business measures sits still. The work did not disappear when the speed arrived, it moved upstream to the act of deciding what the business wants and saying it precisely.

Step back, and the larger point comes into focus. We took the constraint to be the velocity of development. We spent accordingly, on tools, agents, and speed. The constraint that actually bound us was something else: the readiness of the business to absorb that speed. Deciding and specifying, the subject of that first piece, is only where it starts. Business readiness comes down to five conditions about how your organization is wired. Every one of them is a decision only you can make. This piece answers the question the first one left open. What does that readiness require of you, once the work moves at the speed the tools allow? Readiness is not the thing you arrange before the work, readiness is the work.

Know the life cycle you are adopting

You cannot get ready for a destination you have not named. The agentic development life cycle is a different shape from the one most organizations still run. The unit of work stops being the task and becomes the specification. Agents generate against that specification in parallel, not one ticket at a time. The steps that limit throughput are no longer writing the code; they are deciding, reviewing, and integrating what the agents produce. Quality stops being an inspection at the end and becomes a property built into the process. The center of gravity for your people moves upstream, away from hands on keyboards and toward specifying, deciding, steering, and governing. The five conditions that follow are not a wish list; they are what an organization needs in place to run that life cycle at all.

Readiness is a capability, not a checklist

The instinct is to treat readiness as a gate to clear once, a box ticked before the real work starts. These five conditions are not boxes, they are capabilities your company either has or has to build. They are exactly the capabilities a company built for human-speed shipping never needed. When the build collapses from months to days, the gaps disappear. Every process that used to hide in them now sets the pace. Readiness is the capability to operate at the speed the tools assume, you cannot buy it. It is a property of how your organization decides, grants access, governs, provisions, and holds rhythm. Those are leadership decisions, not vendor deliverables. And readiness is never finished; you maintain it as the organization and the tools keep changing.

Someone has to be able to decide at the speed the work now moves

Agentic delivery produces in hours what used to take days, but that speed is worth nothing if the output then waits a week to be accepted. The largest source of lost time on these programs is not the work, it is the wait for a decision. The leadership act is concrete: name one accountable person for each class of decision, give them a deputy for the days they are unreachable, and then set a service level on decisions, the way you always have on systems. A specification earns a decision within a day. A finished increment earns acceptance within two. The uncomfortable part is what this exposes: whether your decision rights are real. An approver who has to convene a committee is not an approver, they are a queue with a title.

You cannot specify what your people cannot see

An agent executes against the specification, not against your intent. So before anyone can write a specification worth executing, the team has to see the work as it really runs. That means the process, the systems it touches, and the people who hold the work in their heads, along with sight of the data it runs against. In regulated and data-sensitive businesses, that access is the slowest thing to arrange. It is also the most underestimated. It crosses departments that do not report to whoever owns the delivery. Opening it quickly is a leadership act, not an administrative one. Stage it as an entry gate before kickoff, with a named owner for each system and data source, the way you clear a security review. Every day a team spends guessing is a day it produces confident, wrong work at machine speed.

Answer the governance questions before the build, not during it

Three questions decide whether AI-generated work can ship and they cannot be compressed once the work is moving. That is why they belong at the front.

1. Is AI-generated work permitted in this system at all? Some regulated environments forbid it outright, and you need that answer before a line is written.
2. Who owns the intellectual property it carries, and what open-source obligations ride along with it? Generated code can carry licensing terms you never agreed to, and they surface during financing, acquisition, or audit.
3. How is the data classified, and what may an autonomous process do with it: read, retain, move, or send it beyond your boundary? An agent will touch whatever you let it reach, so set those limits before it runs, not after.

These are legal, security, and compliance questions. They carry the longest lead time of anything in the engagement. This year, regulators are moving from policy to enforcement. Governance now often decides whether a program is buildable at all. Get those three answers in writing, signed by whoever owns the risk, before the first increment is generated. Treat it as paperwork for later, and you discover halfway in that you were never allowed to ship.

Accepted work that cannot ship is not delivery, it is inventory

This is the least glamorous condition, and the one that quietly kills the most programs. Every operator has seen the version of it: a build is accepted, even celebrated. Then it sits for a quarter because the environment to run it in does not exist. The work that was supposedly done ships nothing. Accepted work that cannot be deployed has not been delivered; it is inventory. Build, test, and staging environments have to be provisioned through the same infrastructure-as-code path as production, reachable from CI/CD, and matched to it in data, configuration, and identity controls. Without them, the speed of generation means nothing downstream. It stalls so often because provisioning crosses boundaries no single team controls. That makes it a leadership problem wearing a technical costume. Someone with authority across those boundaries has to clear the path before the fast part begins.

The rhythm is what keeps the other four honest

The first four hold only if there is an operating rhythm underneath them. That requires a cadence, the forums where decisions get made, the escalation paths, and a shared definition of done. Without it, the other four decay the moment the first deadline applies weight. The approver goes quiet, access slows, governance gets waved through, and the environment is promised for next week. The rhythm turns five separate conditions into something that can sustain a pace. Setting it is work. Defending it when the pressure arrives is the part of the job that does not delegate.

You earn readiness on a small surface

None of this is built by writing a large readiness plan and approving it in a steering committee. The industry already named that failure, it is the heavy up-front plan and the big-bang release that buckles under its own weight. Readiness is a capability, and capabilities are earned small and then extended. Take one real piece of work, deliberately narrow, and run it through all five conditions. The narrow slice tells you which condition is actually weakest. It tells you in weeks rather than quarters. And it tells you before the cost of being wrong has scaled. Then change what you measure, tracking decision latency and acceptance cycle time rather than raw output, because those are the constraints now. You do not assess readiness; you practice it.

The owner has not changed

The earlier argument put the bottleneck on you. The judgment about what the business wants, and the willingness to put it on the record, is yours. These five conditions are what that requires, once the work moves at full speed. They are the standing capability that decides whether the speed you paid for ever reaches a customer. The tools will keep getting faster. The speed was never the hard part to buy. The readiness was always the hard part to build and it has only ever had one owner.