Built to Revert

“I am all about empowering the team to make decisions, but when the decisions result in a pile of sh$t that I don’t know what to do with, next time I need to control the decision so that doesn’t happen again.“

A leader said this to me recently. That leader is not wrong. They experienced a real consequence of giving the team space, and it didn’t work out as hoped. The instinct to pull back control is completely rational.

Everyone talks about empowered teams. But empowerment is a leadership behavior, not a system property. Hire the right people, coach them, lead with strategic context. When that leader leaves, the system doesn’t carry it forward.

A while back, I ran a product mindset workshop with a large team. Two days of deep discussions on what it means to be a product team for product and engineering. On the last afternoon, an engineer told me, “No one has explained it this way before”. People were nodding. I left thinking things were about to shift. Perhaps it was my hubris.

It felt good for about a month.

Then, people returned to doing things as they had been doing them. PI planning pressure returned. Backlog grooming consumed the calendar. Feature factory resumed. Nothing seemed to have changed.

System: 1, Anu: 0.

In my last post, I wrote about why training doesn’t stick. Hint: the environment doesn’t support it. You give people the skills, but the system they return to makes those skills irrelevant. The training fades.

So if training isn’t the whole answer, what is? I’ve started calling it operational autonomy.

What Operational Autonomy Actually Looks Like

Permission Mode vs. Inform Mode

Here’s the sharpest way I can describe it:
Permission mode: Nothing happens unless someone (usually senior or a stakeholder) says yes. The default is inactivity.

Inform mode: Action happens unless someone stops you. The default is movement.

This is a structural shift. In permission mode, you wait. The leader holds the default. In inform mode, the team decides and acts.

Permission mode is the organizational default. It is often not designed intentionally. Inform mode requires redesigning the default, like switching from opt-in to opt-out. And behavioral psychology tells us that we rarely ever change the defaults. Teams revert because defaults are gravitational. The moment someone stops actively overriding the default, it snaps back.

We run in permission mode without even realizing it. It doesn’t show up as a policy. It shows up as behavior. Waiting for sign-off on decisions that shouldn’t need sign-off. Escalating because “I want to make sure leadership is aligned.” Accepting features like “add a button here” without asking why. Running things up the chain “just to be safe.”

Claire Hughes Johnson, former COO of Stripe, put it simply, if you’re not sure who the decision maker is, it’s probably you. Act that way rather than slowing the whole company down. That’s inform mode.

Two Teams, Same Environment

I work alongside a team that operates in inform mode. Here’s what’s different:

The team has clarity on their outcomes. Their goals don’t shift every sprint. They have shared ownership instead of rigid swim lanes where people only touch “their” work. When they meet stakeholders, they are ready with recommendations, not a blank sheet of paper. Their conversations are frank. No sugar-coating, no “managing up.” And when a process isn’t serving the outcome, they bend the process.

This is one of the strongest teams I’ve seen. They’re not ignoring the system. They’ve just figured out how to operate within it without asking permission for every decision along the way. “Here’s what we’re doing and why” instead of “can we try this?”

Now contrast that with permission mode. Every decision needs alignment across multiple layers. Engineers wait for the PO to write the story before they think about the problem. Recommendations get watered down to “options” by the time they reach leadership. Nobody makes a move until the next planning ceremony gives them cover to act.

Why This Is Structural, Not Motivational

You can’t motivate your way to operational autonomy; you have to redesign the default.

David Marquet took command of the USS Santa Fe, the worst-performing submarine in the Navy. Classic command-and-control: captain gives orders, crew executes. Marquet realized this produced passive obedience, not active thinking. So he stopped giving orders.

Instead of crew members saying “requesting permission to submerge,” they started saying “I intend to submerge.” That single change, from permission to intent, flipped the default. With permission, nothing happens unless the captain approves. With intent, action happens unless the captain vetoes. The Santa Fe went from worst to first.

Most retellings of this story focus on the empowerment. The deeper part is that Marquet didn’t just hand over authority and hope for the best. He built two things first:

• Competence. Instead of briefing the crew (here’s what we’re doing), he had the crew certify to him that they knew what they were doing. The burden of proof flipped — from “I told you” to “show me you know.”

• Clarity. The crew understood the mission well enough to make decisions aligned with it without asking.

Only after competence and clarity were in place did he push decisions down.

Competence plus clarity, not training and control. Without competence, you get bad outcomes. Without clarity, you get competent people optimizing for the wrong thing. Without control pushed down, you get competent, clear people still waiting for permission.

And here’s the cycle we’re stuck in: We invest in training and building competencies. But we don’t give people clarity on the purpose or the environment in which to apply it. And, when decisions go wrong, we pull control back. Which makes the training useless. Which confirms “we can’t trust them to decide.” And the cycle repeats.

---

After the workshop, I started to build operational autonomy on my team (although I didn’t call it that at the time). Clear product strategy, stakeholder-aligned objectives, continuous planning instead of PI planning, lightweight intake instead of the system’s default elaborate process, a space to think about problems, not just execute tickets. One-on-one coaching. Practices like pre-mortems and demo days.

It seemed to work — the team operated differently. They came with recommendations, questioned assumptions, and bent the process toward outcomes.

Then I moved to a new role. Within weeks, the team reverted. Output-based thinking. No strategic clarity. Reactive to whoever was loudest. The default game reasserted itself.

Here’s the admission that’s hard to write: I didn’t build operational autonomy. I was the operational autonomy. The system was tethered to my energy and my insistence on doing things differently. I didn’t encode it structurally. When I left, it left with me.

System: 2, Anu: 0.

The artifacts, documents, and rituals stay. But the behaviors conform to whoever holds the environment now.

So What’s Now?

The question I’ve been researching: how do you make operational autonomy survive without you?

I have some ideas. That’s next week.

The score isn’t final. I’m still in the game.