Product Pushback: "Making Teams Autonomous is Too Hard and Expensive!"

Achieving autonomy is essential if you want to hold teams accountable for outcomes rather than just outputs. Without autonomy, teams fall into what I call cover-your-ass development—an environment where people prioritise documentation, handovers, and sign-offs to protect themselves from blame when something inevitably goes wrong. This stifles creativity and slows delivery.

Making teams autonomous is not easy though. Achieving meaningful autonomy requires two key elements:

1. Clear scope separation between teams

2. Independent codebases for each team

Which brings us back to the feedback from the workshop. Designing and implementing scope and code autonomy between teams is a very time-consuming and expensive exercise. Is it realistic?

Is code separation realistic?

At Amazon, autonomy was non-negotiable for their “two-pizza teams.” In the book Working Backwards, the authors reflected on how successful teams spent up to nine months separating their code and implementing the necessary instrumentation for monitoring before they delivered any features. While this may seem excessive, it paid off. Once those teams achieved autonomy, they were able to deliver rapidly without waiting on others. In contrast, teams that tried to achieve “quick wins” early, without achieving true autonomy, were bogged down by dependencies, ultimately limiting their speed.

Jeff Bezos famously said, “Communication between teams is a bug, not a feature.” Independent teams succeeded by minimising the need for inter-team communication, leading to greater speed and agility.

However, the success of isolating code has led to an over-correction with the shift from monoliths to microservices. There are real performance overheads with microservices, as well as the added complexity associated with managing and debugging distributed systems. A more balanced approach is “team-sized services,” as coined by Team Topologies. This means dividing code between teams while avoiding unnecessary fragmentation within a team.

The key is to find the right balance. For startups with a handful of product teams, the overhead of code separation may not be justified. But as an organisation scales, delivery speed often drops dramatically, making the investment in autonomy worth it.

Can you achieve scope separation?

Verizon is a massive company with over 300 separate product teams. They have a mix of customer value-stream aligned teams and shared capability teams. The value-stream teams are organised around the customer journey (Learn→Buy→Get→Pay→Manage→Support), product offerings (Mobile, Home, Services, Devices) and channels (Digital, In-Store, Retail Ecosystem).

When Verizon wants to launch a new product, it often impacts multiple journey stages, channels, and shared capabilities like analytics and profiles. As Richard Dalton, Verizon’s Head of Design, shared, a single product initiative could require changes across 42 teams—all of which were already at capacity. Balancing competing priorities and delivery schedules among all these teams was a huge challenge, with significant overhead and cost. And given changes keep arising, the organisation ends up in a perpetual state of expensive replanning.

Richard also shared an example of wanting to ensure that the in-store and digital experiences were coherent. This meant that the two separate channel teams needed to work closely together. When two teams need to collaborate closely, you don’t have two teams anymore; you have one large team.

To resolve this problem, Verizon faced three choices, each with trade-offs:

1. Prioritise channel coherence: Teams would own multiple channels, but given the increase in responsibility they would need to reduce their customer journey scope.

2. Prioritise journey coherence: Allow channels to have differences.

3. Prioritise both: Accept slower speeds and higher costs.

Product strategy isn’t just about where to focus—it’s about where you’re willing to accept trade-offs. Designing the boundaries between teams is about explicitly defining where you are willing to make trade-offs. Without these painful decisions, delivery speeds will suffer as dependencies increase exponentially.

The Path to Removing Dependencies

For companies transitioning from a project delivery structure with a monolithic codebase, creating autonomous teams isn’t an overnight endeavor. At Amazon, they identified and separated teams one at a time, gradually achieving autonomy over a period.

At ZeroBlockers, we advocate for having a Process Vision—a long-term goal for autonomy, much like a product vision. It’s about defining the future state we want to reach, but recognising that we won’t achieve it immediately.

Toyota revolutionised the auto industry with its approach to small, continuous improvements. We should take the same approach in our transition to autonomous, empowered product teams.