How Your Portfolio Determines the Right Design
by Cesario Ramos
Portfolio Design Is the Real Scaling Constraint
If you’re an experienced agile leader, you’ve probably seen this pattern:
Your teams are in good shape: clear goals and steady value delivery. However, the organization feels slow. Work sits in queues, prio’s change and what are all these dependencies on other teams….?
You make improvements and suddenly you are scaling, ending up with more alignment ceremonies… but not more adaptability and outcomes.
The problem here might not be the process… It’s worth inspecting how the company is designed to make commitments and manage dependencies: funding & governance. Why? Adaptability is constrained less by team rituals and more by how the enterprise allocates authority, funding, and decision rights.
Why dependencies aren’t always “bad”
A dangerous thinking mistake is to assume that we should optimise for minimising team dependencies. Let me explain:
Autonomous Product Groups
If you have loosely coupled products (different strategies, different customers, limited reuse between products) in your portfolio then you want few dependencies between product groups. Why? because each dependency becomes a drag. Centralized planning and control often add cost without adding value. Loosely coupled products benefit from local autonomy, experimentation and decision power, This enables them to adapt quickly on their own which suite their independent business model.
In such a setup you will see different strategies, limited need for shared capabilities. Adaptability, speed and success comes from local decision-making.
What it feels like:
- Teams should ship with minimal coordination
- Heavy enterprise governance becomes drag
- Local outcomes matter more than global “alignment”
Synergetic Product Groups
On the other hand, in a strongly coupled product portfolio(shared strategy, shared business model, shared capabilities), integration is a source of advantage: standards, platforms, cross-sell, coordinated pivots. So, dependencies are a good thing as this makes it easier for the product portfolio to move as one.
As a leader you see different products, similar strategies and real benefits from shared platforms, services, capabilities, standards, and reuse.
What it feels like:
- Some dependencies are worth it (platforms, shared services)
- Guardrails matter (standards, interfaces, decision forums)
- Autonomy exists, but inside a shared direction
Figure 1. Balancing Adaptability source: Changing the Engine Midflight. Cesario Ramos, 2027.
So, dependencies are neither good nor bad on their own. Their value depends on your portfolio design. In a strongly coupled portfolio, you often want stronger, intentional dependencies. In a loosely coupled portfolio, you want weaker dependencies so each group can adapt at low cost.
Why this matters?
Most “scaling pain” shows up when the org tries to live in two quadrants at once (Figure 1 ):
- Needs high integration, but wants high autonomy → misalignment, rework, escalations
- Needs autonomy, but enforces heavy integration → waiting, approval gates, dependency theater
- Worst case: low integration and low autonomy → fragmented and slow (committees everywhere)
As a leader, you can’t “ceremony” your way out of that. What shows up in refinement, planning, and daily coordination might be a portfolio/governance design problem surfacing as team-level friction exactly the kind of mismatch Creating Agile Organizations warns about.
What you can do?
Try naming the portfolio pattern first and connecting it to the strategy. For example: In a retro or leadership conversation, replace “we need better process” with:“What level of connectedness do we actually require between these products?” Then either increase or decrease dependencies with governance, funding rules and centralized coordination. In a strongly coupled portfolio you want to P&L responsibility to be more centralised, while in a loose couple portfolio you want the P&L to be more decentralised.
- Strongly coupled portfolio → more centralized P&L / funding rules / decision forums
- Loosely coupled portfolio → more decentralized P&L / local funding authority / fewer cross-group gates
Key Point
Dependencies between teams and groups are not inherently good or bad, and your job isn’t to “scale Scrum.” It’s to help the system integrate where it creates advantage and to decouple it otherwise.