A team is discussing how to solve a problem. You have an approach in mind, probably backed by experience, but the team reaches a different conclusion.
Their approach is reasonable. You can see some risks, but there is no strong reason to override the decision.
So you let them try it.
This sounds like autonomy. The difficult part comes afterward.
How long do you let the approach run before intervening? What happens when progress is slower than you expected? At what point does giving space become waiting too long?
I ran into exactly this tension while trying to change how I lead technical discussions. I wanted to create more room for others to make decisions instead of becoming the person who provides the solution whenever I have a strong opinion.
What helped was adding one small constraint to the experiment: a time boundary.
Instead of leaving the decision open-ended, we could agree on when we would look at the result again. Until then, the team had space to execute its approach. At the review point, we could look at what actually happened rather than debating whose initial idea was better.
That distinction has become useful for me because it separates two decisions that are easy to mix together:
Who owns the approach?
and
When do we evaluate whether that approach is working?
There is more to getting this right, especially around outcomes, constraints, and what should happen at the review point. I wrote about the experience and the practical model I now use in the full article:
👉 Give Autonomy a Time Boundary
If you lead technical discussions, I am curious how you handle this moment: when the team chooses a reasonable approach that you would not have chosen yourself.
Top comments (0)