Intent Lead Time

The time before lead time for changes

For fifteen years, the answer to that question only moved one direction. CI/CD compressed deploys from weeks to minutes. Trunk-based development collapsed merge cycles. Feature flags untangled release from deploy. By 2024, elite teams shipped to production hourly without ceremony.

Coding agents collapsed implementation from days to hours. CI/CD had already collapsed deploys to minutes. The intent-capture phase didn’t collapse at all. Meetings, decision documents, ticket triage, alignment threads: all still on the same clock as ten years ago.

DORA can’t see it. By design.

Yesterday’s assembly line

Software shipped through a human-mediated assembly line. Each handoff was a translation. The PRD imperfectly captured the meeting. The ticket imperfectly captured the PRD. The commit imperfectly captured the ticket. By the time code reached review, the original intent had been refracted through five formats and three job functions, and the engineer who finally implemented it was guessing how the call had actually been made two weeks earlier.

The losses were enormous. The workflow was justified by where the bottleneck lived: in writing the code. Implementation was the long pole. Everything else was overhead in service of getting to a clean commit.

When coding was expensive⁴, the upstream handoff (the ideation, prioritization, and decision-making) was free. Nobody kept receipts.

Today’s agent-augmented workflow

Then prototyping became a prompt.

Lovable, v0, Cursor, Claude Code, Codex, GitHub Copilot. All of them collapsed implementation from days to minutes. The “AI prototype” lets a team start from working code instead of a blank page.

But the workflow shape is unchanged. Tickets, branches, PRs², QA gates. The pipeline is still shackled to scaffolding designed for a slower implementation phase that no longer exists.

Worse: the speedup made the upstream loss bigger. Agents execute without context or memory of why. When they ship faster, they ship faster on the wrong intent. The engineering leader’s nightmare has shifted from “we’re shipping too slowly” to “we’re shipping the wrong thing too quickly.”

What DORA measures, and what it doesn’t

DORA is precise about what it measures and where its clock starts.

Lead Time for Changes is defined as the elapsed time from a code change being committed to the repository to the same change running in production. The clock starts at commit. It does not start at decision, at PRD, at ticket, or at “let’s do this.”

This is not an oversight. DORA measures the deployment pipeline because the deployment pipeline is what CI/CD, infrastructure, release engineering, and operational practice can directly improve. Naming the upstream pipeline as DORA’s responsibility would have made the metric unmeasurable for most teams in 2014, when the framework was published.

The asymmetry today is that DORA’s clock starts where the hardest work used to begin. It now starts where that work ends.

Coding is no longer the long pole. The long pole is everything that happens before a single line of code gets written. That is where the next metric lives.

Introducing Intent Lead Time

DORA defines Lead Time for Changes as the time from code commit to code running in production. Intent Lead Time (ILT) is the time from a product decision being made to the first commit implementing it.

ILT ends exactly where DORA’s clock starts. The two metrics dovetail at the commit. Together, they measure the full change pipeline, from the moment a decision is made to the moment it ships.

No overlap. No gap.

Four sub-components

ILT is a single number, but it’s composed of four observable handoffs. Profiling each segment shows where time actually lives.

A healthy ILT compresses all four segments from weeks to hours. A broken ILT is the pipeline everyone has but no one measures.

Three of these are vestigial

Honest version: only one of the four sub-components is load-bearing in an intent-driven workflow. The other three are scaffolding from the assembly-line era.

Tickets are a project-management technology designed for queueing work to humans. The picker needed to be told which one was theirs, when it was their turn, and what state to move it to when they were done. Sequencing, pickup, and activation latencies exist because routing-to-a-person-via-Jira is the only way the old world knew to assign work.

When the picker is an agent, the spec is the assignment. A markdown PRD with acceptance criteria, a design card, an RFC: picked up directly. Nothing to queue, nothing to route, no card to drag across a board.

In a truly intent-driven workflow, sequencing, pickup, and activation will collapse to zero.

That is the provocation, and it is also the prediction. The teams that figure this out first will spend the next decade explaining to everyone else why their tickets-per-engineer counts are dropping while their throughput is climbing.

Proposed bands

How ILT relates to DORA

DORA’s four keys remain correct for what they measure. Intent Lead TimeIntent Lead TimeThe elapsed time from a product decision to the first commit implementing it. The metric DORA doesn’t measure. Companion to Lead Time for Changes. is a companion metric, not a replacement. It measures what happens before DORA’s clock starts.

Said the other way: DORA compressed deployment from days to minutes. Agents compressed coding from days to hours. Neither moved the clock on intent capture. That is the window ILT opens, and the one where most teams are losing their agentic productivity gains.

Why you probably can’t measure it today

The reason no one tracks Intent Lead TimeIntent Lead TimeThe elapsed time from a product decision to the first commit implementing it. The metric DORA doesn’t measure. Companion to Lead Time for Changes. is not that no one wants to. It’s that the upstream side of the equation has no timestamp.

DORA is measurable because both endpoints are timestamped events in systems engineering teams already use. The commit timestamp lives in git. The deploy timestamp lives in CI/CD. Plumb the two together and the clock writes itself.

The decision timestamp doesn’t exist anywhere structured. It lives in:

• A meeting nobody recorded.
• A Slack thread that scrolled off three days later.
• A PRD written days after the call it captures.
• A whiteboard photo nobody re-types.
• An RFC that landed approved without a clear “this is the moment we agreed” event.

Without a structured decision timestamp, ILT is a number you can argue about but not measure. The teams who do feel like they ship fast usually have a strong written culture that implicitly timestamps decisions: a habit of “decisions go in #decisions on the day they’re made,” or a lightweight RFC process. These are workarounds, not infrastructure.

The metric is unmeasurable until the intent shaping a product decision becomes a first-class object with a clock attached to it.

The intent-driven workflow

Tomorrow’s pipeline doesn’t look like an assembly line. It looks like a continuous human-driven conversation that produces artifacts.

That conversation needs infrastructure: a place for it to happen, a way to timestamp what gets decided, and a handoff-free path from decision to code. This is what Stoa is.

How Stoa makes it concrete

Every abstract piece of the intent-driven workflow maps to a specific product surface in Stoa.

The shape of work changes

The shape of work changes from a relay race to a continuous conversation. Specs become self-documenting because they were captured at the source. The handoff disappears because there is nothing to hand off. The intent behind decisions is already structured, attributable, and machine-readable when the agent picks it up.

This is the workflow that makes Intent Lead Time go from weeks to hours. It is also the workflow that makes ILT measurable. For the first time, the decision event has a timestamp.

DORA gave us the metrics for the DevOps era. Intent Lead Time is the metric for the agentic era.

The clock starts the moment your team agrees.