I’ve been talking to my clients about the balance required in a successful and effective team, which lies on 3 factors: Slack, Autonomy and Execution.

Recently I’ve seen several examples of Autonomy issues that could have caused a lot of failure work. Picture this: You as an executive or director delegate a new project to one of your managers to execute, start to finish. This is great, and the first step needed in balancing the Autonomy seesaw; actually delegating the work to people.

Yet the issues start when the managers don’t know how to claim that autonomy in practice, and how to use it in order to effectively execute the project. A common case is where they do not discuss priorities and requirements with other departments as their peers, instead receiving whatever they are given as facts set in stone.

While you would look at the different requirements or needs discussed and get to the root in order to understand the value to the organization, the real priorities underlying every milestone and work together to establish an optimal solution, the manager that’s missing autonomy is likely to go directly into execution mode.

Accepting requirements from other departments is not what they should be doing and “because Product says so” is the surest path for wasted work and over-engineering. When I notice requirements and tasks being laid out without the manager understanding them I know it’s likely that there’s an autonomy issue underlying.

If you can see this happening in your organization as well, you should actually work on correcting this and understanding what are the causes. Work with your team to describe the responsibility they have and what you expect them to do. You should not be needed and called for whenever a new requirement arises. Instead, they should be mentored and guided to understand what power they have and how they’re supposed to wield it.

Doing this means you get managers that are able to think outside of the box, understand the true goals of their projects, and so reduce failure work and effectively correct course when eventually requirements change.

Otherwise, you risk getting milestones that are way too big, filled with features and capabilities that will not be used for months while they are supported and maintained, instead of spending that work in delivering real value to your clients.