I have to say that I often chuckle to myself when I see people write so much about autonomous agents writing code. So many leaders are barely able to delegate and trust their senior engineers; am I supposed to believe they’ll be fine with LLMs doing it? Let’s talk about making teams more autonomous, so if AI actually allows them to move faster, you won’t be the bottleneck.
Basics of Autonomous Teams
Having worked with many teams has taught me that fixing teams that aren’t autonomous enough isn’t straightforward. Rarely does it get fixed merely by telling people to “be more independent.” Often, there are issues relating to what the engineers know to do and how management has treated them so far.
These create a Gordian knot that makes things hard to tackle. We have to address two aspects simultaneously, in a pincer movement. We tackle autonomy with the team and proper delegation with leadership.
Delegation
Your team will find it hard to take on more responsibility and execute on things if you hold them on a tight leash. Many leaders don’t recognize that they’re doing so, or at least are partly to blame for it. You might think you’re just helping them when they come up with questions, not realizing your role in making them feel they need to keep asking for permission.
When I work with executives who feel swamped, often what we need to do is to set the stage for letting their people do autonomous work and be ready for healthy delegation. That starts with putting an end to executives being answer machines. Like miserable AI chatbots, they spend their days responding to questions left and right. That’s an indication that you need to create guidelines and defaults, not supply solutions.
Second, you should work on your trust. As the micromanagement flywheel teaches us, delegation is impossible when we lack transparency and don’t trust our team. In such a scenario, not delegating is the responsible thing to do. However, you should strive to correct things so that you can trust your people. After all, would you have hired them in the first place had you known you wouldn’t end up trusting them?
The problem often is in the team per se, but in how you’ve set up the organization for effective communication, clarity, and accountability. Be clear about the expectations from seniors who take ownership of features, for example. Be clear regarding deadlines, when to escalate, and have the right safety nets in place. This will allow you to trust them, let go a bit, and give them the space they need to gain their autonomy.
Autonomy
The second half of our pincer movement is to ensure that the team is capable of operating in autonomy. Otherwise, you’ll be working on delegating to people who don’t know how to do the actual work. That’s not exactly an improvement.
I’m going to assume that the tech skills aren’t an issue (and if they are, these are the things that are often easy to tackle). Then, the key parts are context, objectives, and borders.
Context is about ensuring that the team understands the general direction, the product, the market, etc. This is what I often call Product Mastery. This is the difference between having people go from point A to point B, then to C, waiting for instructions after each leg of the trip, and those who have enough context to be able to spot a shortcut.
Objectives are clear, actionable, and prioritized goals. The clarity regarding what needs to be done is crucial to have autonomy. Lacking clarity, people often get lost without even realizing they have. Making an effort to define good objectives makes a huge difference.
And lastly, borders are about defining together what the expectations are, what they are expected to tackle by themselves, as opposed to cases that need to be escalated. The clarity helps the team know when they have to stop and get permission while also making management less concerned.