In 1971, introductory psychology students were separated into two groups and asked to complete the same task—solve a puzzle created by a board game company. In the first session, both groups were asked to come up with as many solutions to the puzzle as they could. During the second session, one group was given $1 for each successful configuration of the puzzle they could come up with. The other group was not paid. Finally, in the third session, both groups were once again not paid.

In that third session, the group that was never paid performed better and was less distracted. This revealed an important psychological factor when it comes to accomplishing tasks. The reward is in the activity itself. This was the fundamental discovery made in a groundbreaking study by Edward L. Deci in 1971. Autonomy gives way to productivity.

We've all probably experienced the opposite of autonomy. A boss breathing down our necks. Check-ins every hour or every day. Suggestions that were actually directives. In those situations, we shrink. We crave the freedom to make our own decisions and to deliver results for the simple intrinsic value of doing the work. Fortunately for many, businesses around the world have recognized the value of autonomy. Job descriptions now tout autonomy as a job perk.

But too much autonomy can be as bad, or worse, than too little. As a manager or a founder, it's hard to walk the line of providing autonomy balanced with coaching and avoiding micromanagement. Let's consider a scenario.

Julia is a product manager at a small startup. She has been given full trust. The company's policy is that you don't have to earn trust, but you can lose it. In Julia's first three months, she conducts research and scopes out a feature to bring to market based on that research. The autonomy is refreshing. Her boss, the Head of Product, has told her to own whatever process and decisions she makes.

At the end of those first three months, the engineering team is ready to begin work but they have run into a problem. Julia's project scope doesn't make any sense. Much of the functionality already exists and anything new would take the product in a completely different direction than it has been going. The engineering team wonders if Julia even knows the product at all. They do their best to work on small tasks tangentially associated with the project and they even ask Julia questions about how the larger work fits in with the vision for the product and the company.

The Head of Product starts to wonder why the project is taking so long. She hears whispers that engineering is frustrated. But, she's not a micromanager, so she encourages the team to talk with Julia, and she asks Julia if there's anything Julia needs from her. Julia tells her she's got it under control—Julia doesn't want to lose her autonomy, after all.

Julia goes back to the drawing board while the engineering team works on bugs and cleanup tasks. She's convinced that her research is spot on, so she tries to find another angle. After two months of customer calls, she has a new proposal for the team. She decides this time to show it to the Head of Product. The Head of Product listens and then tells Julia that the decision is Julia's to make.

Julia is a little more hesitant this time around, but she presents the project to the engineering team, and they tell her it's better. It won't fundamentally change the app like the last proposal would. It introduces new functionality, but it fits in with the app. They start work but soon come up against a new set of problems.

How will developers interact with this new feature, they ask. Julia hadn't considered the public API. She wasn't sure how the public API was used. If the engineering team built the new feature without public API support, another public GET endpoint would return data that didn't make any sense. At this point, the engineering team was halfway through the feature, and they were more frustrated than when they read the first proposal.

The Head of Product is getting frustrated. It's been five months and the team still hasn't shipped anything. She asks Julia for a status update. Julia says she's having trouble getting the work over the finish line because she needs to understand how it plays into the public API. She tells the Head of Product she'll just need to do some additional research with developers. The Head of Product nods and tells Julia it's her call. Julia needs to own the decision-making process and the outcomes.

The engineering team lets the work sit and goes back to bugs. Julia hits the phones. She talks to developers around the world to better understand how they interact with APIs and how they expect new features to be incorporated into public APIs. It takes a month, but Julia is feeling much better.

She returns to the engineering team and tells them we should add a public POST endpoint that will allow developers to enable this new feature and use it. Then, the GET endpoint data will make sense. The team asks her if it should be part of the GraphQL API or the REST API and how she thinks developers should authenticate. Should permissions be extended across existing API keys or should developers have to generate new keys for these new features?

Julia's head is spinning. The Head of Product is angry. The engineering team is frustrated and bored of working on bugs. And everyone's to blame.

In this very exaggerated scenario, the Head of Product was completely hands-off to the point of not managing at all. The opposite of micromanagement is no management. And that's just as harmful. What teams need in highly autonomous organizations is macro-management. A holistic picture of the entire organization and its status is required. Understanding the underlying issues that may be bubbling up is key. These things can only happen if you, as a leader, are coaching. Autonomy does not mean coaching goes out the window.

In our example scenario, the Head of Product could have coached Julia on the steps she might need to take to better understand the product. The Head of Product could have coached the engineering team on how to be more involved in the product ideation process. Macro management considers the larger picture and uses that picture to provide feedback and coaching.

Without coaching and feedback, our scenario has turned into a 6-month waste of time with the possibility of Julia losing her job. All of it was avoidable without having to step in and micromanage the entire process. Just because you get feedback and coaching doesn't mean you lost the ability to make decisions. As a leader fearful of overstepping into the micromanagement realm, remember that for most people the reward is in the activity. In the study cited at the beginning of this article, all of the students were given instructions and guidance in the form of papers documenting the puzzle they were working on.

Autonomy only works if there is a feedback loop. With no loop, you get autonomous failure.