This one is yours

Somebody at your company is going to own the AI transition. Maybe the CEO announces it in a memo. Maybe the CFO turns it into a cost program with a savings target and a quarterly readout. Maybe a Head of AI gets hired, a council gets formed, and a year later there is a governance deck, a usage dashboard, and every workflow that mattered is still done by hand.

Or you take it.

This guide is written for the CTO who takes it. Not the engineering part. The whole company: revenue, operations, finance, legal, product, people. Engineering goes first because that is where it can be proved. Then it goes everywhere else, because proof that stays inside engineering is one good quarter and nothing more.

That is a bigger job than the one you were hired for. Good. Nobody else in the room can do it.

Who this is for

You run technology at a company, whatever your title says, and you intend to change how the work gets done. Not sponsor it. Not approve the slides. Change it, function by function, with your name on the outcome.

That is the reader: the CTO as change agent. The guide assumes you have authority over engineering and influence everywhere else, and that influence is the part you are about to spend.

Stage matters less than you think for the destination and more than you think for the route. The ladder in this guide is the same at every size. The moves are not. When you sign in, the guide asks for headcount and adjusts, using the same stages the tinycto curriculum already filters by.

At 0 to 5 engineers, you probably still write code, and "finance" is a founder with a spreadsheet. Every function is one person. That makes the ladder brutally honest, because you can watch every workflow yourself, and it makes you the best-placed CTO in this guide: you have nothing to unlearn.

At 5 to 20 and 20 to 50, you know every workflow by name. Each function outside engineering has one owner, often a founder, and the owner is the whole conversation. Your risk is the opposite of bureaucracy: nothing is written down, so there is no intent to hand a machine.

At 50 to 150, the org chart starts to fight back. Functions have leaders with their own authority, handoffs have owners, and every step you remove belongs to somebody. This is where the transition stops being technical and turns political.

At 150 and up, you have the most to lose and the most to unlearn. Your processes are good. They earned their reputation. That is exactly the problem: the practices your best people are proudest of sit precisely where the new constraint lands, and those people will defend them hardest.

You do not need an AI background to lead this. The Court in this guide rules that "we need to hire AI engineers first" is false, and for a reason that should give you confidence: the people who can write intent for a function are the people who already know its systems and its customers. You need two other things. You need to stay close enough to the tools to judge what they can do, and you need the stomach to tell your CEO and board unwelcome things early.

If you came for a vendor shortlist or a maturity model to paste into a deck, this is the wrong guide.

Why the CTO leads it

Engineering already runs on pipelines. Years ago, long before any model could write a function, engineering made "done" explicit enough for a machine to act on. A merge to main runs the tests. A green build is a fact, not an opinion. A deploy is a command, a rollback is a button, and the history of every change sits in version control with an author and a reason. None of that was built for AI. All of it is what AI needs.

Now look across the hall. Month-end close lives partly in a spreadsheet and partly in the controller's head. In support, "done" often means the customer stopped replying. A sales stage changes when a rep remembers to change it. Those functions produce real output, and good people produce it well, but most of them have never had to define done precisely enough for something that cannot ask a follow-up question.

Engineering made "done" explicit enough for a machine to act on years ago. No other function has. That is why this is yours.

The research agrees. Google's 2025 DORA report found that AI does not fix a team, it amplifies what is already there, and the seven capabilities it names as amplifiers read like an engineering org's checklist: strong version control, small batches, a quality internal platform. Engineering has spent twenty years building the scaffolding every other function is about to need.

So engineering is the proving ground, and you are the only executive who can do three things.

You can prove it on your own function first. The feedback loops already exist in engineering. Tests fail loudly, deploys are counted, incidents are written up. You can climb the ladder there and show, with your own numbers, what it looks like when a machine does the hands-on work and a person sets intent. That is Phase 1, and the gate out of it is rung 3, not perfection.

You can calibrate. A designer on my team rebuilt two pages carrying ninety percent of platform traffic in three days with an agent, against a two-month estimate. Nobody had been careless. The estimate came from experienced people whose instincts were tuned to tools that no longer described the work. Every other exec is about to bring you estimates like that for their own function, and a leader who has not built with the tools cannot tell a wildly wrong number from a sound one. You can, if you keep your hands on the work.

You can carry the pattern out. This is the part nobody warns you about. The org chart is the bottleneck, not the tooling. Every handoff you remove in finance or support belongs to a person whose authority depends on it. Removing it costs a role, a meeting someone chairs, a sign-off that made someone relevant. You will walk into those functions as a guest, and the pattern has to be retold in their language, not engineering's. Phase 2 is built around exactly that.

The objections you will hear

"Isn't this the CEO's job?" The CEO owns the outcome and the deadline, and should keep owning both. But the CEO cannot tell you whether an eval suite is trustworthy enough to drop from reviewing everything to reviewing a sample. You can. Lead the work and let the CEO own the stakes.

"Shouldn't we hire a Head of AI?" Ask what that person would have caught last quarter. A standing AI body built before any named failure invents review that everyone routes around, and it moves the decision away from the people who own the systems. Agent governance is the same decision you already make about any author touching code, made about a new kind of author.

"Engineering isn't there yet either." Correct, and it does not need to be. A willing business function can start once engineering reaches rung 3. Nobody waits for engineering to reach rung 5.

What happens if you don't

The transition gets owned by whoever finds it easiest to measure. That usually means adoption: seats bought, weekly active users, the share of code a model wrote. Adoption isn't a result. It tells you where you are stuck when it is low and nothing at all when it is high. Duolingo, which said in 2025 it would weigh AI use in performance reviews, dropped it as a review metric in April 2026 and went back to judging whether people did their jobs well.

Left to a cost program, it becomes the substitution trap: the same work, in the same order, a little cheaper, with a ceiling set at a fraction of your labour cost. Left to a council, it becomes a queue.

One more thing, so you hear it now and not later. This job changes yours. By the last phase, the leader's work in every function is writing intent and handling escalations. That includes you.

How this guide works

The guide has two layers.

The first is this essay. It is public, and anyone can read it. It defines AI-native in a way you can observe rather than argue about, gives you a five-rung ladder to place each function on, and walks five phases in order, with a gate between each that no function can skip. Read it straight through once. Every claim in it is one you can check.

The second layer is personal, and it is the reason the guide exists. Sign in, do the intake, and the guide builds a profile of your company: your stage, the functions in scope, where each one sits on the ladder, your deadline and who set it, and every constraint you believe is holding you back. From then on, every chapter carries "For your org" callouts built from that profile, so the essay you read is about your company, not an average one.

It also argues back.

Every constraint you state goes to Constraint Court and gets a verdict: real, negotiable or false. The hearing asks who owns the constraint (a name, not a team), what would have to be true for it to disappear, and what removing it costs. Then it rules, and every ruling ends in a first move with an owner and a date. The pushback is blunt. There is no toughness setting, because a softer version would be less useful and you would know it.

The timeline check takes your deadline, your headcount and your rungs, and returns one of three verdicts: fits, tight, or won't hold. It publishes rules, never durations. No chapter here will tell you how long something takes, because a number printed in an essay is somebody else's number. Every verdict is computed from your own inputs, and it re-runs whenever they change.

Then the guide keeps you honest. You pick a check-in cadence. At each check-in, it holds you to the rulings you accepted, flags intent documents that have gone stale, and names the single next move for the week. The same profile is available in Claude through the tinycto MCP server, so a ruling you argue out in a chat shows up on the site, and the other way round.

What you walk away with is concrete: a one-page board summary with each function's rung, the timeline verdict and the asks; an intent document template for each function, pre-filled from your profile; and the Court transcript, every ruling with its owner and date, ready to share with your exec team. They live in your takeaways.

The guide links into the curriculum wherever a lesson goes deeper, especially the Agentic Engineering track, but it stands on its own. You do not need to have read anything else first.