Decision Autonomy

I read Shape Up as soon as it was released in 2019. It was the perfect anecdote to every frustration I was experiencing in the process of building software. I aggressively nodded my head while reading it. Twice. I felt like I was inching my way in the same direction, but then someone handed me a map.

I was tired of sprints and estimates and endless ceremony to work on anything.

So I went all in. I adopted six-week cycles, two-week cool-downs, pitches, hill charts, the betting table. I rolled it out across different teams and projects. I captured feedback, learned, and iterated as I melded the process with my own thinking.

The process felt right.

I spent six years adopting and refining my expression of the Shape Up process.

But now I don’t even use it.

The evolution helped me see the philosophy and principles beneath the process.

That’s something most people miss. They get too hung up on the specifics without learning the transferable current of knowledge flowing through the process. They memorize the recipe without understanding the flavor profiles. So what happens when something doesn’t taste right? You can’t adapt.

A process is the practical expression of principles rooted in a philosophy.

Philosophy → Principles → Process

• Philosophy defines how you see and think about the work.
• Principles establish the enduring truths that guide decisions.
• Process translates those principles into action.

How you think, how you decide, how you learn.

Sadly, product work and building software is projected through the lens of process. It’s all about following a playbook, detailing the steps to achieve success. If only you read this book or watch this conference talk or gain this process certification—then you will create effective, high-output product teams.

The real shift is ignoring the process and focusing on the philosophy and principles.

Processes should expire when their governing constraints change, like leaves regrowing from stable branches and the roots of a tree.

Shape Up’s philosophy is applying intentional constraints to prepare for the unknowns.

If I had to distill Shape Up into one principle:

Fixed time, variable scope.

Set constraints before the work, but allow changes when the work meets reality.

There are two sides to this:

Intentional Constraints + Local Decisions

What Shape Up calls “shaping” work into a “pitch” isn’t for requirements. You set a clear intention in the form of a problem, and then you simulate a possible solution based on a collective understanding of design, engineering, and strategy. That usually requires bringing in multiple people to represent each discipline. The goal is to bring a shared understanding into the build. But the team building the work is often separate from the team involved in shaping the work.

The Shapers vs. The Builders

The Shapers translate understanding to The Builders with intentional constraints. They bring The Builders into the shaping process to address experience and feasibility.

The Builders leverage their understanding to make local decisions. Yet they almost always need The Shapers input once they meet reality and discover the work.

Work is delegated. And with every delegation, there’s a potential for coherence drift.

That’s why I jump in with engineers to help make local decisions. I hold the context about why we’re doing the work, so it’s easy to navigate the trade-offs downstream.

But I don’t like it. That doesn’t scale. So I merge The Shapers and The Builders into a single role I call the Product Builder.

Product Builders bring holistic understanding to the work so they can make sound local product decisions without waiting for every discipline to provide an answer. They understand design, engineering, and strategy.

Execution is democratized now, but judgement isn’t.

More execution means more decisions.

Work is delegated from a product leader to an engineer to an AI agent to more AI subagents to more engineers and more AI agents to review before shipping. That doesn’t include the sales and marketing functions attempting to sell and market the work. The potential for lost intention is high. Endless local decisions happen throughout this chain of events.

The question is no longer whether the work is fully shaped. It is whether the person doing it has enough context and judgment to shape it while building. Give Product Builders enough understanding and clear enough boundaries so they can discover the solution during the work.

Do not shape the solution. Shape the conditions for sound decisions.

Decision Autonomy is the ability to make sound local decisions in reality without losing the original intent of the work.

The three pillars are:

1. Intent Transfer: Does the builder understand the problem, outcome, and rationale?
2. Decision Range: Does the builder understand what they can decide, what can change, and what requires another perspective?
3. Reality Feedback: Can the builder rapidly put something real in front of others, receive feedback, and adjust?

Intent Transfer

Does the builder understand the problem, outcome, and rationale?

We’re working on a new feature to improve the feed, which helps researches keep up with the topics they’re interested in.

Before we could improve the experience, we needed to fix the infrastructure. Alerts weren’t delivered reliably, so I had one engineer focus on improving the delivery.

All work is assigned to a single actor. I say “actor” to represent a designer or engineer or AI agent—anyone handling the completion of a unit of work.

Each item of work is defined as a single issue, a batch of issues, or a project. A single issue is the atomic unit. A batch is a related a set of issues, like targeted fixes and improvements to a specific product area. And a project is for known problems and outcomes that require progressive discovery of a solution. An issue has a known solution. A batch has a known direction. A project has a known outcome.

I call these Work Shapes.

Once the infrastructure was fixed and the alerts were flowing, we turned our attention to the new experience. I worked with design to create Figma mockups. It required visual design direction, so I let them explore new ways to present the feed. I left comments and called out areas where scope could be cut. It happens in Figma Land because it’s easy to draw shapes when you’re not required to make them work in live code. Scope sprawls when you live in the simulation too long. You don’t have the same constraints of code. The design work was necessary for visual direction, not pixel-perfect representations of the expected output. Typically, there’s enough existing design in the live product to build from, but some work requires more visual detail.

Since this work had a known outcome, I created a project in Linear. I recorded a Loom walking through the problem, outcome, and rationale behind the work. I wrote a short overview and put the Loom in a Linear issue on the project for them to review and ask questions. We went back and forth and they quickly created a working prototype.

Intent Transfer is transferring enough intent to the builder so they can begin. Work Shapes help you match the intent to the shape of work.

Transfer the intent, not the mandate.

The builder needs the mental model behind the work, not an exhaustive prescription of what to build. Give them autonomy to create.

Decision Range

Does the builder understand what they can decide, what can change, and what requires another perspective?

As we iterated on the prototype, the engineer’s confidence grew with their understanding of the work. They asked questions and made suggestions to improve it.

They used two of the three Builder Tools, a set of tools Product Builders leverage when building through uncertainty:

1. Scope Chisel: A tool for removing, simplifying, and deferring work without damaging the intended outcome.
2. Decision Compass: A tool for knowing when to proceed, consult, or escalate.

Shape Up talks about “scope hammering,” but a hammer is a blunt instrument. When you make decisions about scope, you need something more precise. The Scope Chisel is a tool for builders to remove, simplify, or defer work while maintaining the intention. But to wield the Scope Chisel, you must first learn the ropes of making local decisions. The second tool, the Decision Compass, helps you know when to make the call, gather additional perspectives, or escalate. When I work with engineers, I bring the design and strategy needs to offset any deficiencies. I focus on expanding their autonomy so they can increasingly make independent decisions.

Micro interactions matter. When they ask for feedback, reflect the question back and capture their opinion. When you don’t have a strong opinion, say it and defer to them. It helps shift the implicit power balance, making their Decision Compass stronger.

Decision Range empowers builders to make decisions in real-time. Builder Tools provide skills to focus on and improve.

Bound the space, not the solution.

Clearly define where the builder can operate while leaving room for judgment inside those boundaries. This applies just as much to AI agents as it does to humans.

Reality Feedback

Can the builder rapidly put something real in front of others, receive feedback, and adjust?

If the direction is right, you can move fast. But in the real environment. If you’re building software, write code. Use the software in production. Meet reality as quickly as you can. AI writes code with speed, but speed without quality is incoherence.

We pushed the prototype to a preview environment. I used the feature, gave feedback, and we went back and forth making iterations. We talked about what worked and what didn’t. We even uncovered things that didn’t surface in any phase before building it. Because that’s the thing: you won’t really get a feel for how something works until you meet it in reality. The sooner you do that, the better.

We even released the first part of the feature to production. We tested and I added multiple issues once it was in production with live data. Again, the push to increased reality drove higher-fidelity feedback.

The third of the Builder Tools is the Reality Ladder, a tool for moving work through progressively higher-fidelity contact with reality. The builder is responsible for adding more contact with reality in tight iterations.

Both the Scope Chisel and Decision Compass help builders navigate the feedback. You can’t resolve it all. And you need to hold the line on the intention driving the work.

Reality Feedback is when you finish the shaping process. It doesn’t happen in a mockup or a document. It happens when reality meets the work and you get feedback.

Let reality finish the shaping.

Release in small scopes to reduce the surface area and reason about the changes. Let the process improve decision-making and compound coherence in the real medium.

The Practice

Developing Decision Autonomy is a practice.

It’s continuous.

It flows through five steps:

1. Sense: What is the work, and who should own it?
2. Transfer: What must the builder understand?
3. Bound: What can they decide independently?
4. Build: What does reality reveal?
5. Reconcile: Did the decisions preserve intent?

Sense

I recognized the feed work as a project. There was a known outcome and a solution to figure out during the build. And I knew the right engineer to tackle the work.

Transfer

I recorded the Loom with the simple overview of the project. I didn’t write an exhaustive pitch that would be made obsolete as soon as the implementation starts.

Bound

I shared the core problem the feed was meant to address, along with the open questions to resolve in the process. I treat all scope as negotiable so long as it keeps the core intention and outcome. The builder needs freedoms to make local decisions.

Build

The engineer produced a working prototype on a live URL. We worked through feedback to resolve the issues in the real medium. We didn’t live in the simulation.

Reconcile

A staging environment is still not the same as a production environment. So we released a slice of the feature to production. It’s better than what we have today, even while we work through continued iterations.

The Throughline

The best engineers I’ve worked with aren’t the best because of the code they write. They’re the best because of the way they think and how they understand the codebase. It’s a deep intrinsic knowledge. They develop a feel for the work, like a chef who can make new dishes with any available ingredients. They learn to make decisions when variables change. Like a true Darwinian, they adapt to their environment to succeed and thrive.

It’s the reason I write so much about judgement and coherence. If everyone can write code with AI, then the value shifts to:

1. Making sound decisions → judgement
2. Understanding the system → coherence

Making sound decisions comes from making decisions and learning from them. You need to participate in the experience of work. If you offload critical thinking, you destroy the human experience of building intuition.

Understanding the system comes from following the flow of information and how it connects to each of the integrated parts. It’s a holistic understanding from experience.

Decision Autonomy is an important part of the story. It’s an extracted concept from a larger tapestry of thinking shrouded in a deluge of prescriptive and rigid ideologies.

If you peel away the acronyms, you can unearth timeless principles.

And once you understand the philosophy and principles, you can extend them to construct whatever process you need.

Because judgment is not renewable.