Software Teams Move Beyond Autonomy

Woman organizing art supplies in a creative workspace focused on calligraphy and lettering. Photo: Antoni Shkraba/Pexels

Simon Rohrer challenged a prevailing assumption at the Craft conference: the idea that software teams should be fully autonomous is no longer sufficient. He argued that the shape of the value a team delivers dictates its necessary trade-offs between agency and coherence. This shift moves thinking from product focus to “value center” thinking. Rohrer argued that in a vaguely complicated organization, the thing that your individual team delivers is not a product. Instead, everything functions as part of a larger value stream.

“If you work in a vaguely complicated organization, the thing that your individual team delivers is not a product,” Rohrer stated. He noted that value streams change constantly, affecting every project and initiative. This variability led him to propose the concept of the value center. A team exists because it is valuable to the organization. Talking about products is the wrong language for these interactions. You deliver value in fairly complex ways to customers.

The Shape of Value and Organizational Constraints

The web of dependencies defines the shape of this value. These shapes differ for every team. Some dependencies are essential, while others are accidental. Rohrer argued that value designs the organization. The specific shape of a team’s value constrains what the organization can look like. It also limits how you can balance autonomy and coherence.

To handle this, Rohrer provided five questions for every value center at every level. These questions are based on the Viable Systems Model, a management cybernetics concept invented by Stafford Beer in the 1960s. A system’s purpose is defined by what it actually does, not what it intends to do. “We’re not what we ought to do, not what we think we might do, but we are what we do,” Rohrer explained. That is the purpose today.

Managers often feel more comfortable dealing with order than disorder, but the modern world is a paradox of intertwined order and disorder. Rohrer quoted Ralph Stacey, who noted that managers face a world characterized by both stability and instability. He mentioned preferring coherence because there is currently more disorder than order. This reality requires moving from autonomous product teams to a nested and networked organization. Networking is important; you don’t need to traverse the hierarchy in order to deliver value at all.

Visualizing Complexity with Molecular Metaphors

In a follow-up interview, Rohrer explained how to visualize these value shapes using the metaphor of simple and complex molecules. A global public cloud operator, like Amazon Web Services or Microsoft Azure, might have a large selection of simple molecules. These include standalone products like a file service or a compute service. They have minimal dependencies, perhaps relying only on the identity and access management team. These are like simple molecules: metals or water.

At the other end of the spectrum is a trading platform, which Rohrer described as his current area of work. This product is made up of multiple dependent elements of value. Pricing, risk analytics, and trading capabilities only make sense to customers when linked together. These are like complex organic molecules, such as proteins or DNA. You can decouple how you develop and deploy these elements technically, but you can’t decouple their value.

This distinction matters because it changes how teams approach their work. Treating a complex trading platform as a collection of independent, autonomous units ignores the interdependence of its components. The value emerges from the integration, not the isolation. This perspective aligns with the broader shift away from siloed product teams toward a more interconnected view of organizational output. It forces teams to look beyond their immediate codebase to the broader system they support.

Five Questions for Effective Coordination

Rohrer detailed how the five questions help explore value by combining individual contribution with the larger whole. The first question asks, “What value am I delivering?” This helps individuals understand why they are contributing and what they are delivering, such as specific user stories in a sprint, but with a focus on the underlying reason.

The second question is, “How do we coordinate?” As a team, you need to understand this to avoid treading on each other’s toes. In Scrum, this involves the backlog and sprint plan. This is something you have to do together, not apart. The third question asks, “How do we fit together?” This is about integrating work so it isn’t just one ticket after another. It involves looking at the sprint goal and how it contributes to the conceptual integrity of the system. It also asks why resources are assigned to certain areas over others.

The fourth question focuses on what cybernetics people call “there and then.” “What’s out there for us?” This looks at what the team hasn’t been focusing on. It considers what could come in the future that requires planning, or what is currently outside scope but might make sense to bring in. The final question is existential: “Who are we?” This is one existential but important question which asks more – what’s our purpose? We’re “the pricing infrastructure team” – but what does that mean? What’s our responsibility? How does that impact how we balance today’s work from planning for the future, and how we focus on all the other questions?

These questions apply at all levels: team, team-of-teams, department, and the whole organization. The goal is to maintain effective organizations by balancing the individual within the larger whole. It’s a practical way to manage complexity without losing sight of the actual value being delivered to customers.