Clarity Before Autonomy

There is a balance I keep coming back to when working with a team:

How much direction should I give, and how much should I leave to the person doing the work?

Too little direction creates confusion.

Too much direction creates dependency.

The useful middle ground seems to be:

High clarity, high autonomy.

But what does clarity actually mean?

Before handing over a problem, I think there are a few things worth making clear:

• Context: Why are we doing this?
• Outcome: What are we trying to achieve?
• Constraints: What limitations or decisions already exist?
• Definition of good: What does a good result look like?
• Ownership: Who is responsible for getting it there?

Once these are clear, the how can usually belong to the person doing the work.

For example, instead of:

“Build this using X, Y and Z.”

it can be:

“We need to solve X because of Y. These are the constraints. A successful solution should achieve Z. You own figuring out the approach.”

That creates room for someone to think, make decisions, and learn.

There is also an important distinction between autonomy and abandonment.

Giving someone ownership doesn’t mean disappearing. Checkpoints and feedback are still necessary, especially when someone is new or the problem is unfamiliar.

So perhaps the simple model is:

Clarity → Autonomy → Checkpoints → Feedback

Give enough clarity to start.

Give enough autonomy to think.

Use checkpoints to catch problems early.

Use feedback to help the person improve.

The goal isn’t to tell people what to do. It’s to give them enough clarity that they can figure out what to do next.