Scaling Agile Without SAFe: Lightweight Approaches for Growing Engineering Orgs

Here's a pattern I've seen play out at least a dozen times. A startup grows from one team to three or four. Coordination gets messy. Someone proposes SAFe (Scaled Agile Framework) as the solution. Six months later, the engineering org is drowning in PI Planning ceremonies, Agile Release Trains, and role definitions nobody can keep straight. Engineers spend more time in alignment meetings than writing code.

SAFe solves a real problem. But for most engineering orgs between 20 and 50 engineers, it's the wrong solution — a framework designed for enterprises with hundreds of engineers, crammed into a mid-scale org.

The Real Problem SAFe Tries to Solve

Let's be fair to SAFe by naming what it addresses. When you go from one team to multiple teams, you hit coordination problems that didn't exist before:

• Dependencies between teams. Team A can't ship their feature until Team B finishes the API they need. Nobody finds out until the last day of the sprint.
• Conflicting priorities. The product team tells Squad 1 that feature X is urgent, while Squad 2 is working on infrastructure that feature X depends on — but nobody connected the dots.
• Shared codebases and services. Multiple teams deploying to the same services, sometimes overwriting each other's changes or causing unexpected regressions.
• Strategic alignment. Each team optimizes for their own backlog without understanding how their work connects to the company's quarterly goals.

These are real problems. I've lived through all of them. The question isn't whether you need to address them. It's how much process overhead is justified for your org size.

Why SAFe Overshoots at Mid-Scale

SAFe introduces massive structure: Program Increments, Agile Release Trains, Release Train Engineers, System Demos, Solution Trains, and a whole taxonomy of roles and ceremonies. For a 200-engineer org in healthcare or finance, maybe justified. For a 30-engineer startup with four squads? Here's why it's absurd:

The ceremony overhead is brutal. PI Planning alone is a two-day event every 8-12 weeks. Add prep, follow-up, and ongoing ceremonies, and you've added days of meetings per quarter to every engineer's calendar.

Role proliferation adds cost without value. Release Train Engineer, Solution Architect, Epic Owners — in a 30-person org, these roles either don't exist or are filled by people already stretched thin.

It optimizes for predictability over speed. Locking into 10-week PI commitments actively harms your ability to respond to market feedback.

It discourages informal communication. "That's a Scrum of Scrums topic" becomes an excuse not to Slack the person who can unblock you right now.

The Lightweight Alternative: What Actually Works

I've seen the following approaches work well for orgs in the 20-50 engineer range. They solve the same coordination problems with a fraction of the overhead.

Weekly Cross-Team Sync (30 minutes)

One representative from each team joins a weekly meeting. The agenda is simple:

1. What are you shipping this week? (2 minutes per team)
2. What's blocking you from another team? (surface dependencies)
3. What's changing that others should know about? (shared services, API changes, infra updates)

That's it. No status reports. No progress percentages. If something needs deeper discussion, schedule a follow-up. The sync is for surfacing, not solving.

Quarterly Dependency Mapping Workshop (half day)

Once a quarter, team leads and product managers map the next quarter's planned work on a shared board. Not a detailed plan — a rough map of dependencies. You're looking for: two teams changing the same service, features depending on unprioritized work, shared infrastructure nobody owns.

This is the useful core of PI Planning, stripped of ceremony. Half a day instead of two days. Write dependencies on a Miro board, assign owners, move on.

Joint Sprint Reviews

Instead of each team doing their sprint review in isolation, do a shared demo session every two weeks (or monthly, depending on your cadence). Every team shows what they shipped. The audience is the other teams.

This does three things:

1. Builds shared understanding. Engineers see what other teams are working on and how the product connects.
2. Creates informal coordination. "Oh, you're building that? We have a similar need — let's talk after."
3. Raises quality. When you know other engineers will see your work, you're more intentional about what you ship.

Keep it tight. 10 minutes per team, max. If demos run long, they stop being useful.

Shared Backlogs for Platform Work

If multiple teams depend on shared infrastructure, create a platform backlog that any team can contribute to. You don't need a dedicated platform team yet. But you need a visible, prioritized list of platform work so it doesn't get lost in each team's feature backlog. Assign an owner — usually a senior engineer or tech lead — to prioritize and ensure work gets picked up.

Cross-Squad Rituals

Two lightweight practices that pay outsized dividends:

Tech talks. Every two weeks, one engineer presents something for 20-30 minutes. A new tool, an architectural decision, a production incident. Spreads knowledge and builds cross-team relationships.

Rotating review partners. Assign cross-team reviewers for PRs that touch shared services. This catches integration issues early and builds cross-team familiarity.

When SAFe Actually Makes Sense

I'm not against SAFe categorically. There are contexts where the overhead is justified:

• Very large orgs (100+ engineers) where informal coordination physically can't scale
• Regulated industries where audit trails, traceability, and documented planning are compliance requirements
• Multi-product companies where different business units need to coordinate releases
• Organizations with low engineering maturity where teams need more structure, not less (though I'd argue there are better places to start than SAFe)

But if you're a startup or scale-up with 20-50 engineers and 3-6 teams, you almost certainly don't need it.

The Principle Behind All of This

The underlying principle is simple: coordination should be as lightweight as the complexity requires and no heavier. Start with the minimum viable process. If it breaks, add structure. If it holds, leave it alone.

The right question isn't "what process should we adopt?" It's "what's the smallest amount of coordination that lets us ship without breaking each other's work?"

At Conectia, the teams we build for European and US startups often join at exactly this growth stage — three to five squads figuring out how to coordinate. Our senior LATAM engineers have experience working across distributed, multi-team setups, and they bring practical patterns for coordination that don't require adopting an enterprise framework to work.

---

Growing your engineering org and need engineers who know how to work across teams? Talk to a CTO — our senior engineers integrate into multi-squad setups and bring coordination experience from day one.