Overall Optimization

The Suboptimization Trap

In 2008, I joined Bwin in Vienna as a Scrum Master, eager to apply what I had learned about agile development. My disappointment came quickly when working with my first team. Despite everyone’s best efforts, the team never delivered what was planned by the end of each Sprint.

Management blamed the team for lacking commitment. But the real problem was different.

Each team member had received individual performance goals from their respective managers. These personal objectives pulled people in different directions. The developers optimized for their individual targets, not for the team’s shared outcome. What looked like a commitment problem was actually a suboptimization problem.

When everyone optimizes for their own goals, nobody optimizes for the whole.

This pattern repeats across enterprises of all sizes. Departments optimize their budgets. Teams optimize their velocity. Individuals optimize their performance reviews. Each local optimization makes perfect sense in isolation. Together, they create an enterprise that works against itself.

Overall Optimization means every improvement must be evaluated by its effect on the Enterprise Product, not just the unit making the change.

When the Whole Enterprise Aligned

A fortunate circumstance allowed me to experience what happens when an enterprise truly optimizes for the whole. Bwin’s board decided to launch a loyalty program called b’inside with the highest priority. This decision overrode all individual targets and departmental goals.

Team members were not assigned—they were asked if they wanted to work on this product idea. True commitment emerged because people chose to dedicate themselves to a shared Goal.

When obstacles arose, I could simply remind everyone of the overarching objective. The “Project #1” priority card cut through organizational friction. Within the first Sprint, the team delivered four complete features with automated testing—unprecedented in that organization.

True commitment arises only when people decide for themselves to pursue a shared Goal.

By 2009, Bwin had scaled to nearly 20 teams delivering continuously every four weeks. This capability was rare for that era. The difference was not better processes or smarter individuals. The difference was alignment around a shared outcome.

The Challenge of Scaling

As enterprises grow, communication becomes increasingly complex. Without structure, communication effort grows quadratically. Ten people require 45 communication channels. One hundred people require 4,950. This explains why growing organizations feel chaotic despite everyone working harder.

Teams offer a solution by compartmentalizing communication. Internal team communication stays manageable while inter-team communication handles coordination. However, this structure has a critical threshold.

The team-based approach breaks down when Teams must coordinate constantly with each other. At that point, the benefits of team structure disappear.

No organizational approach scales linearly. The question is how to manage the inevitable complexity.

You cannot simply add more Teams and expect proportional output. Dependencies between Teams create coordination overhead that can consume all productivity gains.

Conway’s Law and the Architecture of Work

In 1967, Melvin E. Conway observed that organizations produce designs mirroring their communication structures. This insight, now known as Conway’s law, reveals why reorganizations often fail to change product architecture.

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” —Melvin Conway

But Conway added a critical insight that many overlook:

“Because the design which occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design.” —Melvin Conway

Product architecture and organizational structure are two sides of the same coin. You cannot change one without changing the other. An enterprise optimizing its product must simultaneously optimize its organization.

At Bwin, we experienced this directly. A Swedish component team created a dependency bottleneck that blocked progress. The solution was not better processes or more meetings. The solution was co-location—bringing the Swedish developers to Vienna. Once communication patterns changed, the architectural problems resolved themselves.

The lesson: treat organizational design and technical architecture as one problem, not two. Optimize both for flexibility—the ability to adapt when the prevailing system concept needs to change. And they will change.

The De-Scaling Cycle

Scaling reveals dependencies. These dependencies appear in two interconnected forms: between Teams and organizational units, and within the structure of products and services. Conway’s Law tells us these are the same problem viewed from different angles. Organizational dependencies mirror product and service dependencies.

Managing both requires a systematic approach. In AME3, we call this the De-Scaling Cycle—a continuous practice of reducing complexity across organization and product structure:

Identify Dependencies. Not all dependencies are visible from the start. New ones emerge as products and services evolve. Look for dependencies between Teams and organizational units that force constant coordination. Look for coupling in product and service structures that prevents independent work. These are the same problem in different forms.

Manage Communication. The immediate response is to manage work and communication along the dependency. For Teams and organizational units, this means taking responsibility for coordination. For product and service structures, this means establishing clear interfaces. For time-limited problems, management is often sufficient.

Reduce Dependencies. Sustainable improvement comes from eliminating dependencies, not just managing them. This requires simultaneous changes to organization and product structure. Restructure Teams along stable boundaries. Decouple product and service components. Because these dependencies mirror each other, addressing one often reveals solutions for the other.

Repeat. Each improvement reveals previously hidden dependencies. New dependencies emerge as products and services expand. The cycle never ends—it becomes part of how the enterprise operates.

Measuring What Matters

The Agile Manifesto shifted measurement from completed activities to working software. AME3 extends this principle: the measure of success is the Enterprise Product, not the output of individual units.

What you measure is what you get.

When departments measure their own efficiency, they optimize for departmental metrics. When Teams measure their velocity, they optimize for story points. These local measurements drive local optimizations that may harm the whole.

The Enterprise Product represents all products and services offered by the enterprise. It combines Arena Products from all Arenas with results from units not yet operating within AME3. This holistic view ensures that optimization efforts consider the complete picture.

Goals as Alignment Mechanism

The Goal in AME3 serves as the primary alignment mechanism. Unlike individual performance targets that fragment effort, the Goal unites all Teams in an Arena around a shared objective. Multiple Arenas can share the same Goal, creating enterprise-wide alignment.

The Goal differs from individual targets in crucial ways:

Shared Direction. All Teams within an Arena work toward the same Goal. There are no competing individual objectives that pull people in different directions.

Owner Accountability. The Owner must ensure the Goal aligns with the Ambition and the Arena Backlog. This creates clear accountability for strategic alignment.

Flexible Duration. A Goal spans one to nine Matches, allowing for both short-term focus and longer strategic initiatives.

Continuous Presence. The Owner must ensure at least one Goal is always in focus. The enterprise never operates without direction.

The AME3 Response

AME3 addresses suboptimization through several integrated mechanisms. These reinforce each other: transparency reveals misalignment, flexibility enables correction, empirical validation proves the correction worked, and evolution focus ensures corrections serve the product’s future.

Enterprise-Wide Transparency. The Tournament provides regular inspection of the Enterprise Product by Accountable Representatives. This quarterly cycle ensures that local optimizations are evaluated against enterprise outcomes.

Structural Flexibility. The Arena structure allows organizational boundaries to evolve with product architecture. System Leads work with Owners and Teams to experiment with structures that minimize dependencies.

Empirical Validation. Through Empirical Control, AME3 ensures that optimization decisions are based on evidence, not assumptions. The Anticipate-Advance-Assess loops provide regular feedback on whether local changes improve or harm the whole.

Evolution Alignment. Evolution Focus ensures that optimization considers where products and services are on the evolution path. What works in Genesis differs from what works in Commodity.

Practical Implications

Overall Optimization requires shifting how enterprises think about improvement:

Slice Organizations Along Stable Interfaces. When creating Teams or Arenas, choose boundaries that minimize ongoing dependencies. Stable interfaces reduce coordination overhead.

Slice as Late as Possible. Every organizational boundary creates communication barriers. Delay creating new boundaries until the cost of not splitting exceeds the cost of coordination.

Consider System and Organization Together. Technical architecture decisions are organizational decisions. Organizational decisions are technical architecture decisions. Make them together.

Optimize for Learning Speed. In Complex Adaptive Systems, the ability to learn and adapt matters more than initial design. Shorter AAA-Loops provide faster feedback for enterprise-wide optimization.

The Third Doctrine

Overall Optimization completes the strategic foundation of AME3. Empirical Control provides the mechanism for learning. Evolution Focus provides the context for decisions. Overall Optimization ensures that improvements benefit the entire enterprise.

These three doctrines work together:

Empirical Control answers: How do we know if we are improving?

Evolution Focus answers: What should we be improving?

Overall Optimization answers: Who benefits from the improvement?

An enterprise practicing all three doctrines creates a self-improving system. Local experiments generate data. Evolution context guides decisions. Enterprise-wide measurement ensures alignment.

The goal is not to optimize the parts. The goal is to optimize the whole through the parts.

The challenge is continuous. Dependencies shift. Products evolve. Markets change. Overall Optimization is not a destination but a practice—a commitment to ensure that every improvement serves the enterprise, not just the unit making the change.