Outcome Over Activity

Outcomes override tasks, roles, and responsibilities.

That is the whole argument of this article. Everything else is what follows from it.

Most organizations still describe work by activity. Who owns which task. Which role is responsible for which step. Which team sits in which lane. That made sense when people did all the executing, and the hard part was dividing the work so nobody collided.

Agents change the cost of execution. When an agent can do the task in minutes, the structure we built to divide tasks between people stops being the help and starts being the friction.

In The Human Should Not Be the Integration Layer, I wrote about harnesses and loops: putting intelligence where the work happens and letting it carry bounded work forward. This article is about what that intelligence should be organized around.

My answer is outcomes.

Who sets up the meeting

Here is a small example.

A team needs a meeting. There is an engineering manager, a product manager, and a program manager. Whose job is it to set up the meeting?

In a role-based organization, this is a real question. Each role has a description. Each person can point at the line that says it is, or is not, theirs. The meeting waits while that gets sorted out.

It does not matter who sets up the meeting.

What matters is the expected outcome of the meeting. What decision should exist afterward? What should be unblocked? If the person who owns that outcome needs the meeting, the meeting is theirs to set up.

Roles answer "whose task is this?" Outcomes answer "what has to be true when we are done?" Only the second question moves the work.

Owning an outcome means owning its dependencies

When you own an outcome, the downstream dependencies become yours.

That is the part people resist. A role lets you stop at the edge of your responsibilities. An outcome does not. If the result depends on something another team was supposed to deliver, and it has not arrived, you cannot say your part is done. The outcome is not done, so you are not done.

That sounds heavy. In practice it is clarifying. You no longer have to ask whether something is in your job description. You ask whether it stands between you and the outcome.

Outcomes have to be measurable

An outcome only works as an organizing unit if you can tell when it is done.

"Client happiness" is not an outcome you can own. It is vague. Nobody can say when it has been achieved, so nobody can be accountable for achieving it.

"The initiative is done and signed off" is an outcome. It is binary. Either the client signed off or they did not.

The test is simple: could an agent, or a person, look at the state of the world and say yes or no? If the answer is "it depends how you feel about it," the outcome is not ready to delegate.

Outcome agents

This is how I think about agents now.

An outcome agent owns an outcome. It does not own a function, a tool, or a role. It owns a result.

Take client delivery. Delivering for a client touches program work, product work, and engineering work. In a role-based model, those become three lanes with three owners and handoffs between them.

An outcome agent for client delivery does not focus on any one of those aspects. It focuses on the client outcome. Program, product, and engineering are all things it may need to pull on to get there.

Outcome agents sit at the top level. They are the agents that interface most with people and with the physical world: clients, stakeholders, sign-offs, the reality the work has to land in. Below them is the machinery that executes.

Empowerment comes before skills

It is tempting to think the way to make an agent effective is to give it more skills and more standard operating procedures.

Skills and SOPs matter. They are secondary to empowerment.

An outcome agent that is allowed to do what the outcome requires will find its way to the result. It will try something, see where it stands, and try again. It hill-climbs until the outcome is achieved.

An agent with a library of excellent procedures that is only allowed to stay in its lane will stop at the edge of its lane, no matter how good the procedures are.

Swim lanes, before and after

The classic way to organize work is swim lanes.

Before: clear lanes

Program      ──[task]──────────[task]────────────▶ handoff
Product      ─────────[task]──────────[task]─────▶ handoff
Engineering  ───────────────[task]────────[task]─▶ handoff

The outcome lives in the gaps between lanes.
Nobody is allowed to cross them.

Clear lanes look organized. They fail anyway, and they tie people's hands. When something falls between two lanes, the people who could fix it are not allowed to, and the people who are allowed to do not see it.

After: outcome ownership

Outcome A (owner A) ──▶ done and signed off
   may cross: program · product · engineering

Outcome B (owner B) ──▶ done and signed off
   may cross: program · product · engineering

Outcomes are mutually exclusive and collectively exhaustive.

Outcome ownership, with permission to cross lanes, is faster. The owner does whatever the outcome needs, wherever it needs to be done.

The discipline moves to how you draw the outcomes. They should be mutually exclusive, so two owners are not fighting over the same result. They should be collectively exhaustive, so nothing the organization needs is left without an owner.

Here is what that looks like across three familiar roles:

• Product management owns the value of what is created.
• Engineering management owns the maintainability and scalability of the solution.
• Program management owns the timeline and budget.

Three very clear outcomes, and none of them overlap. To achieve them, those three people crisscross like crazy. That is fine. The outcomes stay separate even when the work does not.

Accountability rolls up

Owning an outcome also means owning its failure.

If the outcome fails, that failure rolls up. To your boss. To the CEO. To the funders. That is how accountability already works in any organization. Outcome ownership just stops pretending otherwise.

Delegation does not change this. If you delegate an outcome you cannot own directly, to a person or to an agent, the failure is on whoever empowered them. You chose the owner. You defined the outcome. You granted, or withheld, the permission to cross lanes.

This is why the human part of the work gets more important, not less. Agents can carry an outcome a long way. People still decide which outcomes matter, how they are measured, who owns them, and what that owner is allowed to do.

Try it on one piece of work

Pick one piece of work you currently describe as a task or a role responsibility.

1. Rewrite it as an outcome. What has to be true when it is done?
2. Make it binary. Could someone look at the result and say yes or no?
3. Name one owner. Person or agent, one owner.
4. List the downstream dependencies. Those now belong to the owner.
5. Grant permission to cross the lanes the outcome touches.
6. Check its neighbors. Does it overlap another outcome? Is anything left without an owner?

If you cannot get past step two, the work is not ready to delegate yet, to anyone.

Where this goes

Tasks and roles were how we divided work when people did all the executing. When agents execute fast, that division becomes the slow part.

AI-native work is organized around outcomes: measurable, owned, mutually exclusive, collectively exhaustive, with owners empowered to cross whatever lanes stand in the way.

Outcomes override tasks, roles, and responsibilities.

If you want guidance on getting started, email me at rick@datasaa.com. I would also be glad to compare notes on engineering agents, the SDLC, and the end-to-end product lifecycle.