Autonomy lets you move without needing every move spelled out. It is built from a goal, some bearings, and people you can ask for help. It can cover a small task before it extends to a wider problem.
You help a community group prepare a workshop. You are asked to update the invitation. Reading it, you notice the venue is given but not how to get there. You can propose an addition to the organiser without taking over the whole event. You then check whether the information lets participants actually turn up.
In an experienced team, the same move might be about an incident, a sales request, or a product decision. Understanding the expected result helps you choose what deserves an investigation, what can be done inside the remit, and what has to be ruled on.
Instructions and procedures stay useful. They carry experience, they protect certain operations, and they can help you start. Autonomy also means knowing when to follow them, when to ask for an explanation, and how to propose an improvement. It is not measured by the number of rules bypassed or problems solved alone.
The conditions count: access to information, time, skills, mandate, support. A person blocked by a missing authorisation does not become more autonomous by acting without agreement. They can make the blockage visible, look for the right help, and get what comes next clarified.
If you are growing a team, say which decisions are theirs and which need a ruling. If you are supporting a builder, help them find a bearing, feedback, or the right person. Handing over an enormous problem with no backing is not the only way to show trust.
A sign of progress: you can explain the intended result, propose a next action, and name what you are missing to carry it out. You can also recognise a situation where asking for help, or waiting, is still the right choice.
The understanding cards can round this out when a constraint from another craft, or a use, is still poorly known. You do not need to have mastered everything here to read them.
The cards in this capability
- 3.01 Do not bring the task. Bring the problem
- 3.02 The ticket is not the work
- 3.03 If you don’t understand why, you are not ready to build it
- 3.04 Being stuck is a decision
- 3.05 Deciding and being right are two different jobs
- 3.06 Product is not the person who writes the tickets
- 3.07 ⇄ A roadmap nobody may refuse is a queue
- 3.08 ⇄ You cannot ask for candor and keep the last word