The Autonomy Paradox
Why service-oriented orgs ask teams to own what they can't deliver
The Paradox
Team Topologies promised us faster flow, stronger ownership, and autonomous delivery. Many companies have embraced it: small, cross-functional teams led by a PM and an EM, each owning a slice of the domain. It sounds clean and modern. But in a distributed architecture, this structure breaks down fast, and the paradox underneath becomes hard to ignore.
Where the Model Breaks
A service-oriented architecture promises modularity. Systems are broken down into smaller, independently deployable services, each owned by a team. The benefits are well-understood: teams can move faster, scale more predictably, and make decisions locally. From a platform and infra perspective, it makes sense. From an engineering perspective, it lets teams limit their cognitive load. But here’s where the first crack shows. A feature, especially a user-facing one, doesn’t care about team boundaries.
Most features a PM is tasked with delivering will span multiple domains and touch multiple systems. That’s the nature of any non-trivial product in this architecture. A simple tax-filing flow? That’s not just a UI. It’s customer data, service eligibility, authentication, document storage, invoicing, reconciliation, tax logic, submission APIs, and the list goes on. And each of those pieces? Owned by a different team.
But PMs don’t own systems. PMs own problems and outcomes. The moment we expect a PM embedded in a single team to “own” the delivery of a feature that relies on many systems outside that team’s scope, we’re setting up a contradiction. We tell the PM they have autonomy. We tell the team they are autonomous. But to deliver the thing, they are not autonomous. They depend on systems, and therefore on teams, outside their control.
The org might try to resolve this by encouraging “strong ownership” or “full accountability” within the team. But that creates another tension. For a team to own something end to end, it would have to take responsibility for systems it does not own, understand codebases it doesn’t touch daily, and coordinate work with people who don’t report into their EM or PM structure. That isn’t autonomy, that’s orchestration. We’re just not acknowledging it for what it is.
So we end up in this in-between state. The PM is measured on outcomes that require multi-team execution. The team is staffed and planned as if it can deliver independently. But reality doesn’t comply. The work needs cross-team coordination, dependency management, and shared priorities. And the way we’ve structured teams and leadership models assumes the opposite.
This is the autonomy paradox.
We want teams to own their domain, but we also want them to deliver outcomes that span many domains. We want PMs to drive features, but we anchor them in teams that only own fragments of the necessary scope. We say we value speed and flow, but the moment a feature crosses a team boundary, and most do, we hit coordination overhead, roadmaps misaligned by quarters, and duplicated discovery efforts. We push for “ownership,” but the things we’re asking people to own don’t match the boundaries we’ve drawn.
Local Optimization and the Legacy Trap
Engineering teams try to collaborate, but they don’t have time, because they also have a full roadmap. The team is still expected to deliver in the original timeframe. So they optimize for what they were assembled around: autonomy. They build their own solution, promise to migrate later, and ship it. Now there are duplicated systems to maintain. Migrations that need to be planned and prioritized never get prioritized. The new system becomes legacy from day one.
Conway’s Law in Action
It’s a textbook example of Conway’s Law in action: teams are structured to be autonomous, so they build autonomous systems, even when those systems duplicate logic or drift from shared architectural principles. The shape of the org leaks into the shape of the software.
Conway’s Law: “Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” — Melvin Conway, 1968
It’s a structural tension between the way we define ownership and how systems are architected, not just a planning issue. The more we insist on holding both ends of the rope, “teams should be autonomous” and “PMs should deliver outcomes end to end,” the more strained it becomes.
At some point, we have to acknowledge this for what it is. A paradox born not out of bad intentions or poor planning, but out of the friction between product thinking and distributed systems design. Until then, we keep seeing teams caught in the gap: accountable for things they don’t control, delivering features that always seem harder than they should be, and wondering why autonomy feels so elusive.
Systems as Products, EMs as Owners
If we expect EMs to own the technical strategy for the systems they’re responsible for, and we should, then we also have to treat those systems as more than back-end infrastructure. They are products. Internal products, sure, but products nonetheless. Systems that map to specific business domains, evolve over time, and offer value to other teams through clear APIs. When these systems are built and maintained thoughtfully, they reduce what other teams need to build and own to deliver their own outcomes. They make everything faster and cheaper. They shrink the cost of change.
So if we’re already asking EMs to think this way, what’s the role of the PM? Do we need to pair every team with one? Can’t we expect EMs to weigh bugs, tech debt, and system improvements against the new features required for upcoming initiatives? And if so, why do we still treat PMs as the ones responsible for prioritizing every team’s backlog?
In many setups, PMs spend more time project-managing engineers than solving customer problems. Their calendar is filled with sprint planning, backlog grooming, and chasing alignment across three other PMs. Their role becomes more about coordination than clarity. That’s a poor use of a product function. We don’t need PMs babysitting engineers, we need them driving product thinking, working with design, research, analytics, and other disciplines to shape and refine real solutions. They should consult engineering on feasibility and iteration planning, yes. But once the initiative is shaped and prioritized, that work should be handed over to the teams whose systems are impacted.
The expectation, then, is that the business defines and prioritizes the initiatives. The PMs responsible for each initiative bring that list to the EMs, who assess which of their teams should contribute based on system ownership and available capacity. If something doesn’t align with their system, they shouldn’t be forced to own it. If it does, they step in. The negotiation happens at the boundaries. Questions get clarified between EMs and PMs. Tradeoffs are made. Once the picture is clear, the EMs commit to delivering the necessary changes in their systems. They own that delivery.
A given team might work across multiple initiatives at once. That’s fine. That’s how distributed systems work. Each team contributes to the pieces that intersect with the systems they own. EMs are the ones accountable for defining these collaborations and aligning with other EMs to make sure delivery happens. It’s honest, even when it’s neither clean nor neat. And it gives engineering leaders real responsibility, instead of pretending that every team is autonomous and every PM is the CEO of their own mini-startup.
This model acknowledges that systems are long-lived, and that the cost of building new features should decrease over time as systems evolve and become more reusable. It creates incentives to build the right abstractions, not just ship local solutions. It encourages teams to treat their systems like products. And it gives EMs the space to run their teams while holding them, and the engineers in them, accountable.
What the Business Must Provide
This setup also assumes something critical from the business: clarity of priorities. If we expect EMs to decide where their teams contribute, there needs to be a ranked, non-negotiable list of what matters most to the company at any given time. That list needs to be maintained, communicated, and respected.
This shouldn’t be controversial. Someone in leadership, the CEO or the CPO or a cross-functional exec group, should be able to say: “These are the most important problems we need to solve this quarter.” Without that, planning devolves into lobbying, local prioritization, and disconnected bets. You get misaligned teams, partially built features, and a lot of time spent doing work that doesn’t compound.
In a service-oriented setup, that kind of clarity matters even more. If initiatives are going to be staffed across multiple teams, each contributing just a piece, then everyone needs to be solving for the same goal. Otherwise, the architecture takes the blame for a prioritization failure.
Structure is only half the question. The other half is what teams are empowered to focus on, and who gets to decide what matters. If we want engineering teams to behave like owners, we need to give them clear signals, not vague mandates. We need to stop confusing autonomy with isolation, and stop pretending that PMs embedded in every team are the only way to deliver product value.
Decoupling Teams and Initiatives
The traditional PM–EM pairing tightly couples initiatives to teams. As the number of initiatives grows, the model pressures organizations to scale headcount, replicate roles, and anchor new PMs to new teams, even when the underlying systems don’t require that scale. But initiatives and teams don’t need to grow in lockstep. In fact, they shouldn’t. This model breaks that dependency. It lets initiatives scale independently, spanning systems and domains as needed, while the engineering organization stays focused. Engineering only scales when the domain grows in complexity, not when coordination grows in volume.
It’s Conway’s Law again, but in reverse. We’ve let organizational structure dictate not just the shape of systems, but the flow of initiatives. When every PM is tied to a specific team, we force initiatives to mirror that structure, splitting work across systems that don’t naturally align, or bloating teams just to reflect growing scope.
A Better Operating Model
This model is about product management as much as engineering, and about making sure they focus where it matters most. It pulls them out of backlog mechanics and into the harder work: problem discovery, customer understanding, cross-cutting initiative leadership. When both disciplines are trusted to operate at their highest level, we stop wasting cycles on ownership theater and start building systems and products that move together.
The Velocity Trap
If anything, AI sharpens this paradox. When a team can spin up its own version of an existing system in days instead of months, the duplication trap closes faster. The friction that used to slow a team down long enough to ask “wait, doesn’t another team already own this?” has gotten cheap to ignore. Without the discipline of treating systems as products and decoupling initiatives from teams, we get the same paradox at higher velocity, with more autonomy theater and faster legacy.
Author Notes
I’ve led engineering teams across more than 15 years and several companies, and I’ve seen both models in action. The teams operating under the second one were consistently the healthier ones — better architecture, stronger engagement, real ownership, engineers proud of what they shipped. They aligned with other teams without being told to. They had real technical discussions. They were proud of how they shipped, not just that they shipped.
What I keep coming back to is why the first model became so dominant, and why it’s so hard to challenge. The second one asks product to operate without a dedicated delivery team for every initiative, and shifts more responsibility onto engineering. Both costs feel real to the people paying them. Neither, in my experience, is bigger than what the first model quietly costs everyone else.
Next week’s piece picks this up with the AI lens turned on directly: what team boundaries, ownership, and coordination cost look like when so much of the work runs through models.