Giving more requirements and context can actually increase autonomy.
Many managers think that autonomy means complete freedom to do whatever you want. They delegate a task to somebody on their team, give them full autonomy, and think they’re being a great manager because everybody wants autonomy.
But then the task comes back and it’s not right. The manager is frustrated because they didn’t get what they wanted. The team is frustrated because they were told they had autonomy and put in a lot of effort and now their work is being rejected.
Giving more constraints and context at the start necessarily means that the team will have less options on what to do. But that actually creates focus as they can quickly dismiss options that are not a fit. And it creates greater autonomy because they can trust that solutions they find within the bounded space they’ve been given will be accepted, so they can be more innovative within those constraints.
One subtlety here is that I’m talking here about specifying acceptance criteria for the work – what requirements does the resulting work have to satisfy? Great managers can specify the output without specifying how the work gets done (that can quickly become micromanagement). As an aside, vibe coding is a great way to practice setting such requirements because you don’t care about the code itself, but you do care about the result.
So when you’re trying to give someone on your team autonomy, take the time to specify what the constraints you want them to operate within. That might be design principles, that might be specific requirements for the work, that might be tradeoffs you want them to follow (user satisfaction over revenue, or “move fast and break things”). That will actually lead to greater autonomy and productivity because they will have the freedom to try things within those constraints.
P.S. This misconception is the root of the “founder’s mode” dilemma, which was articulated as that founders can’t let go of the details because then their executives don’t do the right things. But founders who think they have to choose between micromanagement of the details or complete hands-off autonomy are misguided. Good managers specify the constraints and requirements they want their teams to work under, and hold them accountable to those requirements.