A spec-first management system

Radical Execution

A management system for software teams in the age of AI.

Modern teams have never been better at building. They still fail in the same place: the commitment no one actually made. Radical Execution replaces projects and status with explicit objects you can point at, roles that cannot blur by accident, and signal read against what was promised.

The problem

The failure was never in the code.

Pull the thread on the slipped launch, the incident, the escalation that lands at four in the afternoon, and at the bottom you find the same thing: two teams who each thought the other one owned it. A dependency everyone referred to and no one agreed to. A plan whose owner reorganized away two quarters ago. A row that had been green for six weeks because nobody looked at it hard enough to make it anything else.

We automated the build, the test, the release, and the rollback. Nobody could automate the answer to who agreed to what, because that answer was never made explicit anywhere a system could hold it.

A commitment that lives only in the people who made it does not survive them.

Why now

Agents compressed the build. They did not compress the clarity.

For two decades the slowness of building was, by accident, a buffer. If shipping took a quarter, you had a quarter of standups to notice the missing commitment before it detonated.

Then

Slow was survivable

There was always time to reconstruct the agreement by hand before the bill came due.

Now

The buffer is gone

Work that filled a quarter arrives in an afternoon. The gap the slowness hid is open at full speed.

So

Accountability gets heavier

Agents produce motion; they cannot be answerable for a surface. As execution accelerates, the human layer becomes more load-bearing, not less.

The model

Manage through objects, not projects.

Radical Execution separates the management system into a small set of primitives, then draws hard boundaries between the things every organization blurs together. The whole model fits on one page.

The Radical Execution model map: seven layers, from objects and the SPEC through the accountability atoms, the commitment pipeline, signal, and views, to the human-agent boundary, ending in the core test.
The Radical Execution model, at a glance.

1 · Objects before process

Four primitives, one property.

An Org pursues a Goal by doing Work that changes a Product or System. Three of the four are built to change or disappear. Only one carries a standing bill, which is why it needs a standing owner.

Org

How humans structure themselves to accomplish goals. A container for people and authority, not the work or the thing it changes.

Dynamic

Goals

What success means for an org, or what done means for a body of work. A goal that is never retired was never a goal.

Ephemeral

Work

The temporary execution that changes products and systems. Work has a beginning and an end; that is the definition, not a defect.

Ephemeral

Product / System

The durable surface work affects. It accrues obligations and outlives the team that built it, so accountability anchors here.

Durable

2 · The unit

The SPEC is the thing you manage.

A SPEC is a structured statement of intended change. It connects a goal, a durable surface, the accountable people, the commitment, and the signal used to tell whether reality still matches what was promised. It is as heavy as the change requires and not one word heavier.

3 · Accountability atoms

Four functions that never blur by accident.

Ask which atom a person holds on this SPEC, and let the title fall where it falls. Anyone can specify; only an accountable owner can commit; the Pilot keeps the signal honest.

Holds intent

Specifier

Names what change should happen and why. Cannot commit, unless also holding another atom. A proposal is a petition, not a promise.

Holds belonging

Product Owner

Answers whether the change belongs on this surface and will be operated and maintained. Must be able to refuse; a yes-only owner is a rubber stamp.

Holds the work

Builder

Answers whether it can be built, accepted, and delivered at the agreed scope and timeline. Cannot decide belonging.

Holds signal

Pilot

Reads reality against the committed SPEC and routes drift to the authority that can act. Flies the plan; only the signers can change it.

4 · The commitment pipeline

One petition, two ACKs, continuous signal.

Commitment is not one act. It is four, held by four accountabilities. A request stops being able to become a promise just because the requester was senior.

Specifier

Proposal

Here is the change, why it matters, and what I bring. A petition, not an ACK.

Sponsor

Fitness ACK

This serves a sponsored goal and is worth the organization's capacity. The gate before commitment.

Owner + Builder

Dual ACK

Aligned on scope and timeline, and this belongs in our product. A single, two-sided commitment.

Pilot

Signal

Reality still matches the committed SPEC, or here is the drift. A continuous obligation.

5 · Signal, not status

Green against what?

A board or a feeling is status. The committed SPEC is signal. Signal reads reality against what was committed, not status against what someone hoped. A stale green is not green; it is unknown.

A real yellow carries three things, or it is a zombie: a path to green, an owner, and a decision date. Signal routes to authority; it does not stop at the sensor.

GreenReality matches the commitment.
YellowDrift is visible while correction is still cheap.
RedCommitment, scope, ownership, or reality has broken.

6 · Views

Portfolios are queries. Roadmaps are filtered views.

Connect the SPECs through their typed edges and you get the SPEC graph. Every portfolio and roadmap is a projection of that graph, regenerated on demand, owned by no one because it is maintained by no one. Get the graph right and the views are current by construction.

By goal

What has real work behind it

Which goals are resourced, and which are a slide with nothing committed underneath.

By surface

What is landing here

Everything changing one product or system, whatever goal it serves, and whether the surface can absorb it.

By stage & signal

Hope vs. promise

What is proposed, committed, or closed, and where reality is drifting right now. Never expose a SPEC above its commitment stage.

7 · The human-agent boundary

Agents accelerate work. Humans stay accountable.

The line is not about what agents are allowed to touch. It is about what only a human can answer for.

Agents can

  • Draft a SPEC, a scope, a first-pass definition of done
  • Produce implementation, tests, and migrations at volume
  • Compare what shipped to what was committed
  • Detect stale signal and surface drift
  • Answer “what does the record say?”

Humans must

  • Align the work to a sponsored goal
  • Accept that a change belongs on a surface
  • Bind the commitment, and own its maintenance
  • Judge which yellow has a path to green
  • Answer “who is accountable?” when reality diverges

The core test

Does reality still match what we committed to?

Can the people accountable for a change look at the SPEC and answer that question, right now? If yes, the organization is executing. If no, it is narrating motion.

Radical Execution: A Management System for Software Teams in the Age of AI. Book cover.

The book

The whole system, worked end to end.

Every object, the collapse rules, the fitness proxy, the five verbs of contribution, the failure modes, and two tests you can run on your own work this week. Radical Execution is a practitioner reference, written from every seat in the room on work large enough that failure is public.

Read Radical Execution™

Coming soon on Amazon.