The timeline reality check

Somebody has already put a date on this. A board, a CEO, an investor update with "AI-native" in a bullet point. The date was almost certainly set before anyone counted reviewers, named owners or checked which functions review their intent quarterly.

The date is not your problem. Dates are how companies make ambition concrete, and a CTO who resents them is in the wrong job. Your problem is the version of you who accepts the date without a counter-offer, works hard for most of the window, and discovers in the last month what the first week could have told you.

This chapter won't tell you how long any of it takes. Nobody honest can. It gives you the rules, runs them against your own numbers, and hands you a verdict you can take into the room before the date hardens into a promise.

Rules, never durations

The guide publishes rules, never durations. That is a deliberate refusal, and it is the most useful thing in this chapter.

A published duration is a guess about somebody else's company dressed up as a fact. It would ignore your review capacity, your owners, your regulators and the calendar your intent reviews run on. It would be wrong for you. And you would quote it to your board anyway, because a number from an outside source feels safer than a number you have to defend. I've argued that plans are for alignment, not prediction, and that estimates are the first thing to break when the tools change under them. A timeline guide that printed durations would be the worst estimate in your plan, delivered with the most confidence.

So every verdict comes from your inputs: the deadline and who set it, your engineer count, the rung each function sits on, the owner for each function, and which functions are in scope. The output is one of three words, fits, tight or won't hold, plus what the deadline can hold and what to cut or re-sequence. Change an input and the check re-runs. It never prints a number of weeks.

1. 1One rung at a time.A function can't skip a rung.
2. 2Engineering goes first.A business function with a willing owner can start once engineering reaches rung 3. Nobody waits for engineering to reach rung 5.
3. 3Rung 5 needs one full drift cycle.A function's intent must survive at least one scheduled review (monthly for operational functions, quarterly for strategic ones) before that function counts as AI-native.
4. 4Review capacity is the ceiling.How fast humans can review sets the pace, not how fast machines can generate.
5. 5Run functions side by side only if they have separate owners.One leader can't write intent for two functions in the same stretch.

Each rule is short because each one is a hard edge. None of them bends for effort.

One rung at a time. Skipping rung 4 means skipping the evals the team trusts enough to stop checking everything. You can't buy your way past that with a bigger model or a longer week. The rung is the evidence.

Engineering goes first. Engineering already runs on pipelines, so it is where the model gets proven. But the gate for everyone else is engineering at rung 3, not rung 5. A willing business function starts as soon as engineering proves it far enough, and the first export runs alongside engineering's own climb. Nobody sits in a queue waiting for perfection.

Rung 5 needs one full drift cycle. Intent that has never survived a scheduled review is a draft. Operational functions review monthly, strategic ones quarterly. This is the rule that ends most arguments, because it is a calendar, not an effort estimate. If a strategic function's first quarterly review can't happen before your deadline, that function can't count as AI-native by then, however good its people are.

Review capacity is the ceiling. How fast humans can review sets the pace. How fast machines generate does not. Faros AI, which sells engineering analytics, reports from its own customer telemetry across more than 10,000 developers that high-adoption teams merged 98% more PRs while review time rose 91%. It is a vendor's data and correlational, but it matches the review-capacity story in Phase 1. Generation is not your bottleneck. Review capacity is, and the timeline respects it even when your plan doesn't.

Separate owners, or no side by side. Writing intent takes a person's judgment, and judgment is the scarce resource. One leader can't write real intent for two functions in the same stretch. When two functions share an owner, the check runs them one after the other, or asks you for a second name.

The three verdicts mean exactly what they say. Fits means there is room to spare. Won't hold means the list is bigger than the window, and the verdict tells you which items the deadline can hold and which to cut. Tight is the one people misread. Tight is not a green light with a footnote. It means the slack is already spent and one slip breaks it. Plan a tight verdict the way you would plan a won't-hold, and treat anything left over as a gift.

The guide publishes rules, not durations. Your deadline gets a verdict, not a number.

One example

Two hundred engineers. SOX. A board mandate that reads "AI-native in 90 days". The verdict is won't hold for the whole company, and you can see why without a spreadsheet.

AI-native means every function in scope at rung 5, with every core workflow there, and with intent that has survived a scheduled review. Strategic functions, which by default include legal, people and product, review their intent quarterly. Before that review can count, the function has to climb there, one rung at a time, behind an engineering function that has to reach rung 3 first. That sequence does not fit inside a single quarter. No amount of commitment changes the order of events on a calendar.

Then there is the ceiling. Two hundred engineers produce a great deal of agent output very quickly. The number of people who can review it did not grow with the mandate, and in a SOX environment review is not optional. That caps how many functions can move at once, and the check moves them in waves, one owner each.

What the deadline can hold is still real work: engineering at rung 3, and one intent document in each function that faces the audit. That second item is not a consolation prize. When auditors ask what the machines were told to do, why, and who owns the answer, an intent document is the answer. A company that ends the quarter with engineering at rung 3 and audit-facing intent written, owned and on a review cadence is further along than one that spent the same quarter spreading chat licences across every department and calling the usage chart progress.

What to say to the board

A verdict is useless until it leaves your laptop. Here is how to carry it.

What a deadline can hold

When a deadline can't hold everything, the check fills it from the top of a fixed order. Engineering at rung 3. One intent document in each function that faces the audit. The second function at rung 3. Every other function at rung 3. Every function at rung 5, with intent that has survived a review.

The order is not a ranking of importance. It is a chain of gates. Nothing starts until engineering reaches rung 3. The audit-facing intent protects you from the one failure a board can't forgive, which is a regulator finding out before they do. The second function proves the pattern travels outside engineering. Everything after that is spread, and spread is sized by review capacity and owners, not by ambition.

What to cut

Cut from the bottom. Always.

The tempting move is the opposite. Every function at rung 2 looks broader on a slide than engineering at rung 3, and it is worth less. Rung 2 is people prompting and pasting. It shows up as usage, and adoption isn't a result. Never trade the top of the list for a wider-looking bottom.

Re-sequencing is the other lever. Two functions with one owner become two waves. A function without an owner comes out of scope until it has one. And when you push back, push back on scope rather than the date. "That date is unrealistic" starts an argument about your team's speed. "Here is what that date holds" starts a trade, and trades are how the rest of the exec team already works.

Tell the board about the dip, too. DORA's 2026 report on the ROI of AI-assisted development describes a J-curve: a temporary drop from the learning curve and the cost of verification, and an explicit warning against cutting funding early. A board that hears about the dip in advance reads it as the plan working. A board that discovers it reads it as the plan failing.

When to say it

Week one, not week eleven.

It's how I run a board relationship anyway: monthly, written, no surprises. The first month of a mandate is the only window where the commitment is still soft. After that it hardens into a company promise, and unwinding it costs somebody's credibility. Usually yours.

Say it in writing, in one paragraph. The verdict. What the deadline holds. What you are cutting. What you need from them. And say what you are working against, whether that's review capacity, the audit, or a function nobody has agreed to own. Share the pressure, not just the outcome, because a board that knows the constraint can reason with you, and a board handed only a revised plan can only accept it or distrust it.

Say it in week one. In week eleven it's no longer a plan. It's an excuse.

The last word

This is the last chapter. You have the definition, the ladder, the phases, the Court and now the clock. There is nothing left in this guide that you need before you start.

So here is the dare. Nobody is coming to make your company AI-native. Not a vendor, not a new hire, not a better model. The Court has already ruled on waiting to hire and waiting for models, and both were false. What none of them can replace is you, going first, in the open, while people can watch you get it wrong and fix it.

The company will change as far as its CTO is willing to go first. Go.