Team Autonomy and AI

I’ve been working on the longer-term implications of generative AI on product teams, and especially since I published A Vision for Product Teams, I’ve had many good conversations with people exploring different consequences and second-order effects of generative AI.

Through these discussions, one thing I’ve learned is that when it comes to product teams, there’s considerable confusion between the two related, but distinct, concepts of empowerment and autonomy.

In this article, I’d like to clarify these two concepts, and then discuss some of the less obvious implications of AI when it comes to team autonomy, and why I think this is very profound, yet does not seem to be discussed much.

For those of us interested in product development, we’ve all been pretty excited about the new tools for prototyping and code generation, and the implications on how we discover and deliver products.

But there’s plenty of other areas that are being impacted.

But before we get to that, let’s clarify the two concepts:

Many people tend to conflate empowerment and autonomy, or even use the terms interchangeably.

But when it comes to team topology, these are each important to consider separately.

Empowerment refers to the ability of the product team to discover the best solution to the problem they’ve been asked to solve.  

If you’re coming from a feature team where you were handed a roadmap of prioritized features and projects to build, then this represents a very big step in increased responsibility.  

The team can explore the different ways of solving the problem, and select the approach they believe can best deliver the desired outcome.  Since the product team is closest to the technology and customers, this generally yields much better results, and also provides a real sense of ownership and agency.

In contrast, autonomy refers to the ability of the product team to build, test and deploy this solution without depending on other product teams or other entities.  This means the team has the necessary skills, tools, data, and access.

In most companies beyond very small startups, a product team may have empowerment, but they don’t have full autonomy.  This is because they very often depend on other product teams to make the necessary changes they depend on.  

The result is that while the team may be empowered, they still feel frustrated by the lack of autonomy.

Legacy systems, older team topologies, the limitations of cognitive load, and specialized languages or technologies that not all the engineers have been trained on, contribute to the lack of autonomy.

It’s very common for product teams to complain that getting something built takes weeks longer than it would otherwise because of these dependencies and impediments.

There are ways to mitigate and manage some of these issues, but this has been a very long-standing problem.

While lots of attention has been on the new generation of tools to generate code, there are also major implications to understanding and managing very large code bases.  

Imagine being able to quickly and safely make necessary changes to code located virtually anywhere in your code base.  Even if that code is buried deep in a legacy system, with no useful documentation.  Where there may not even be people left in your company that understand that code.

More generally, let’s say you’re an engineer on call during the weekend and there’s a serious issue, and you’re able to use these tools to quickly diagnose and safely correct the issue no matter what product team might be officially responsible for that particular code.

Or, maybe you’ve been struggling under the weight of significant technical debt, but you simply can’t wait the months – or even years – it would take to reverse engineer, port, and rebuild what’s really going on in these old systems.

The point is that these new tools hold the promise not just of speeding up discovery and delivery, and increasing our level of autonomy, and reducing frustration, but also of dramatically improving the quality and maintainability of our products.

Special thanks to Mike Fisher for his feedback on a draft of this article.