SaFe VS Team Topologies

My Experience with Scaling Agile the Right Way

Over the years, I’ve seen organizations wrestle with the challenge of scaling agile. There’s always that moment where leadership realizes that a handful of high-performing teams are not enough—they need to scale their success across the entire company. That’s when the big frameworks come in.

For manyorganization, the defacto standard to run to is SAFe (Scaled Agile Framework). It’s structured, it promises alignment, and it provides a clear playbook for large enterprises. I’ve worked with SAFe implementations before, and while it looks great on paper, in reality, it often introduces as much complexity as it tries to solve. And, very important, you can hire certified consultants to get it all implemented

When I came across Team Topologies (somewhere around 2022)—and I immediately saw the difference. Instead of trying to scale agile through processes and hierarchy, Team Topologies focuses on team structure and interactions. And honestly, that approach makes way more sense.

This post is about my experience with both—and why I believe Team Topologies is the better choice for real agility.

My Experience with SAFe: More Process, Less Agility

I do understand why most large corporations think SAFe is a great solution for them. It gives you a structured way to coordinate multiple teams, and it promises alignment at scale. In theory, it should help teams work together more efficiently.

But here’s what actually happened in practice:

1. SAFe Created More Complexity, Not Less

When working with customers who implemented SAFe, I quickly realized that instead of making things smoother, it actually added layers of process overhead. Suddenly, they had:

• New roles (Release Train Engineers, Solution Architects, Business Owners, etc.).
• Multiple levels of planning (PI Planning, ART Syncs, Solution Trains).
• A rigid structure that felt more like waterfall with agile ceremonies sprinkled on top.

Instead of making teams faster, SAFe introduced more dependencies, more meetings, and more waiting. Agile is supposed to be about iteration and speed, but with SAFe, it often felt like we were stuck in coordination hell.

2. Decision-Making Moved Up, Not Out

One of my biggest frustrations with SAFe was the top-down decision-making.

Even though agile is supposed to empower teams, SAFe often reinforced the opposite. Major decisions were made at higher levels (in leadership meetings or Program Increments), and teams were expected to execute rather than decide. This completely contradicts what Agile and SCRUM try to achieve. It is up to the team to decide how time is spent during a sprint (in coordination with the product owner, of course).

Instead of enabling fast, autonomous teams, SAFe sometimes made teams feel like cogs in a giant agile machine—less empowered, less engaged, and ultimately, less effective. Team members often got overwhelmed by the stress of working in this setting.

3. SAFe Encouraged Agile Theater

I also noticed that SAFe gave organizations an easy way to claim they were agile—without actually changing their culture.

Executives loved it because it provided structure and predictability, but at the ground level, teams were still dealing with long approval processes, dependencies, and rigid planning cycles.

We had all the agile ceremonies, but none of the real agility. We call it agile but we practice waterfall. It gave management the peace of mind (or an easy way out, depending on how you look at it), without changing attitude.

The Shift to Team Topologies: A Breath of Fresh Air

During one these engagements, I came across the Team Topologies book. It was a game-changer. I felt right at home, recognising all the challenges explained in the book. I started to see how I could implement this in my circle of control.

Instead of scaling agile through bureaucracy, we scaled it by rethinking how teams worked together.

Here’s what worked:

1. Autonomous Teams, No Waiting Around

One of the first things I did was align teams around value streams (instead of organizing around projects or technical components). This meant:

• No more constant dependencies between teams.
• Teams had everything they needed to deliver without waiting for approvals.
• We stopped fighting over priorities—each team owned their stream.

For me, this was real agility. Instead of a top-heavy framework dictating how teams should work, I built small, independent teams that could move fast on their own.

2. Cognitive Load Became a Priority

Something I never thought much about before discovering Team Topologies was cognitive load.

SAFe assumes that teams can take on whatever is thrown at them—as long as they have the right planning and coordination. But in reality, teams get overwhelmed.

With Team Topologies, I actually started structuring teams around their ability to handle complexity:

• Stream-Aligned Teams focused on delivering business value.
• Platform Teams provided internal services, so stream teams didn’t have to reinvent the wheel.
• Complicated-Subsystem Teams handled the tricky, specialized parts of the system.
• Enabling Teams helped other teams level up their skills without creating bottlenecks.

This setup allowed us to scale effectively without overloading teams.

3. Fewer Meetings, More Async Work

One of the best things about switching to Team Topologies was the shift to more asynchronous communication.

With SAFe, we had endless sync meetings, PI planning sessions, and status updates just to keep everyone aligned. With Team Topologies, we moved toward:

• Clear documentation and self-service tools (instead of needing a meeting to get help).
• X-as-a-service models, so teams could request services from platform teams without endless coordination.
• More flexibility in work schedules, since we weren’t waiting on approvals or dependencies.

I remember being able to go to the gym in the middle of the day and finish my work later in the evening—without worrying that another team needed me online at the same time. That’s real agility.

Why Team Topologies Wins for me

After working with both SAFe and Team Topologies, I can confidently say that Team Topologies is the better approach for true agility.

👉 If your organization wants structure and predictability above all else, SAFe might work.
👉 If your goal is real agility, speed, and autonomy, Team Topologies is the better choice.

The bottom line? Agility isn’t about frameworks—it’s about how teams actually work. And for me, Team Topologies is the approach that actually makes teams faster, happier, and more effective.