When SAFe Stops Scaling

The customer had asked for something reasonable.

Not a rewrite of the product. Not a science project. A change that would make their people faster at work they already pay us to support. I left the call knowing what they needed. I also left knowing I could not simply go make it happen.

As a Vice President of Product, I was accountable for that relationship. The path to yes still ran through a committee.

I would prepare the case — the customer need, the business impact, the cost of waiting. Sometimes product was in the room. Sometimes the meeting happened without us. Sometimes the answer came back as a simple no. Not because the request was wrong. Because it didn’t fit the plan already locked in place.

After that, the options were familiar and mostly useless. Argue. Escalate. Wait for the next planning cycle. Meanwhile the customer was still waiting, and I was still the person they called.

I remember how often the coordination around the work took longer than the work itself. Meetings to align. Meetings to re-align. Dashboards that looked fine. Epics and stories moving. Commitments recorded. And a customer who could not get a straightforward change because the system that was supposed to help us deliver had become the thing we were delivering to.

It got harder to tell the difference between protecting the plan and protecting the customer. Product and engineering spent more energy navigating the process than sitting with the problem. Creativity waited its turn. And more than once I had to tell people who trusted us that we couldn’t help them for months — not because we lacked the people or the skill, but because we lacked the permission.

I felt responsible for outcomes I could not steer. That is a bad place for a product leader to live. It is a worse place for a customer to wait.

I keep coming back to the same question.

How did we get here?

It would be easy to conclude that the framework itself was the mistake.

That is not how we got here.

We were building software across many products and many teams, on top of shared services and legacy systems that did not move independently just because a roadmap said they should. Work that looked local rarely stayed local. A change in one place surfaced a dependency in another. Teams could move quickly on their own and still arrive out of sequence with everyone else.

Priorities were not always consistent. What mattered to one part of the business collided with what another part had already committed to. Leaders could see activity. It was harder to see the whole — what was truly in flight, what was blocked, what was waiting on whom, and whether the organization was making coherent progress or simply staying busy.

That is a real problem. It is also a common one in large software organizations. We did not invent it, and we were not wrong to take it seriously.

What we reached for was structure: shared planning, a common cadence, a way to make dependencies visible before they became emergencies, and a shared language for commitments across teams that otherwise operated in different worlds. The hope — my hope — was that this would help us manage the complexity between our codebases and our legacy software without relying on heroics and late discovery.

For a time, that structure helped.

Planning gave us a place to put the work in one view. Dependencies that used to appear after a team was already deep into a change showed up earlier on a board where people could see them. Commitments became clearer. Delivery surprises did not disappear, but they became less frequent in the ways that used to catch leadership off guard. Project managers absorbed a meaningful amount of coordination so builders could stay closer to the work. People who lived inside the system still say that mapping and scheduling dependencies was one of the things that approach did well. They are right.

The mistake was not deciding that a growing, interdependent organization needed more than informal coordination.

The mistake was quieter. We treated a solution that fit a particular stage of our complexity as if it would keep fitting as the organization changed — as if yesterday’s coordination problem were the permanent problem, and yesterday’s answer were the permanent answer.

We were still solving the problem we had when we reached for the framework.

The harder question came later: what happens when the structure that once created clarity begins to create a different kind of constraint?

What changed was not that the organization suddenly became foolish.

What changed was what we began protecting.

At first, the plan existed to serve delivery. Commitments existed to create clarity across teams that needed each other. Predictability mattered because customers and the business needed to know when something would arrive. None of that was wrong. Those were answers to real problems.

Then the center of gravity moved — slowly, almost politely.

A customer need that arrived after planning had locked would wait, even when waiting cost more than changing the plan. Responsiveness started to look like disruption. Changing priority inside an increment felt like breaking a promise, even when the original commitment had been made before we fully understood the work. Inside the organization, people began describing the planning cycle the way you describe a waterfall with agile language wrapped around it: fixed scope, fixed timeline, limited room to learn once the train had left.

We got better at defending the roadmap than at questioning whether the roadmap still matched the customer in front of us. Dashboards tracked whether we were on plan. They were less interested in whether the plan was still the right plan. Output had a scoreboard. Outcomes had anecdotes.

Nobody set out to build that.

There was no meeting where someone proposed that the operating model should matter more than the customer. Intelligent people kept doing what the system rewarded. The system rewarded keeping commitments visible, keeping the cadence intact, keeping the plan coherent. Over time, coherence became easier to manage than judgment. And judgment — the kind that sits with a customer problem and decides what deserves to move — got quieter.

That is the inversion.

An operating model is built to solve a particular set of organizational problems. Organizations change. If leadership keeps optimizing the model for yesterday’s problems, the model eventually starts creating today’s. The tools that once created visibility begin creating rigidity. The planning that once reduced surprise begins reducing the organization’s ability to respond. The structure that once helped us manage complexity becomes another layer of complexity to manage.

In short: the operating model begins optimizing itself instead of the customer.

We eventually realized we weren’t simply managing complexity anymore.

We were managing the operating model itself.

Once you see the inversion, you start noticing it in ordinary days.

A small change would take a meeting to size, another to sequence, another to confirm it still fit the plan. The work itself was often straightforward. The path to permission was not. I remember looking at the calendar and realizing we had spent more time coordinating a change than it would take to build it — and still not having a decision.

Planning was supposed to reduce surprise. It began requiring its own preparation. People prepared for planning. Then they planned. Then they reconciled what planning had assumed with what the work actually needed. When something new arrived from a customer, the first question was rarely “what problem are we solving?” It was whether the request could survive the plan already on the board.

Internal metrics could look fine while a customer waited. Epics moved. Stories closed. Status stayed green. I was still the person on the phone explaining that we could not help yet — sometimes for months — not because the team lacked skill, but because changing course cost more organizational energy than staying the course. In our business, that waiting is not abstract. People dealing with insurance claims are not waiting on a process improvement initiative. They are waiting on tools that help them do hard work after hard days.

The tools absorbed the same drift. One product workflow grew toward forty statuses. Conversation got thinner; the ticket got thicker. Product managers spent more of their week administering work through the system — statuses, handoffs, readiness — than sitting with customers long enough to understand what actually mattered. Engineers learned the cheapest way to move was to navigate the process carefully. Direct collaboration between product and engineering did not disappear overnight. It just became harder to justify when the next coordination checkpoint was always coming.

None of this required bad intent.

Most people were doing exactly what the model rewarded: keep the plan coherent, keep the cadence intact, keep the dashboard healthy. Planning is valuable. Process is valuable. Both remain valuable until they begin consuming more of the organization’s energy than solving customer problems.

That is when the model becomes the work.

We were still shipping software. We were also spending an increasing share of our attention sustaining the system that decided what software was allowed to change.

Which left a harder question underneath the meetings and the statuses and the green dashboards:

If the operating model now controlled so many of the decisions — who actually owned the customer?

The customer still called me.

That is the part that is easy to miss when you talk about operating models in the abstract. The committee did not get the follow-up email. The dashboard did not sit in the quarterly review. I did. I was the Vice President of Product. I was supposed to own the relationship. I was also explaining delays I could not meaningfully change, and carrying business cases into rooms that already had an answer shaped by a plan I did not control.

At first, you push.

You make the case again. You escalate. You try to find the person who can unlock a decision. You tell yourself that persistence is leadership — that if you care enough, the system will bend toward the customer.

Then you learn the shape of the system.

Escalation becomes a ritual with a predictable range of outcomes. Working around the process becomes a skill. People get good at it. Product managers learn to keep work moving through administration because administration is what moves. Talented leaders adapt. They stop asking what they would do if they owned the problem, and start asking what the system will allow this cycle.

I felt that shift in myself.

I wanted extreme ownership. Without the ability to influence outcomes, ownership becomes a kind of performance — defending a team you cannot fully empower, accepting responsibility for results you cannot steer. That is a losing place to lead from. Eventually you stop volunteering for fights you cannot win. Not because you stopped caring about the customer. Because you stopped believing the next push would change anything.

That is not laziness. It is adaptation.

People still show up. They still work hard. They still want to help. What erodes is the belief that judgment matters more than navigation. Once that belief goes, organizations do not merely slow down. They teach capable people to wait for permission to do the job they were hired to do.

This is not only a product problem.

Wherever someone is measured on an outcome and blocked from the decisions that create it, the same pattern appears. Responsibility stays close to the customer. Authority drifts toward the system. Over time, the organization fills with people who can describe the problem precisely and no longer expect to fix it.

Ownership without authority creates learned helplessness.

If we wanted leaders to own customer outcomes again, decision-making could not keep living so far from the people who carried those outcomes.

The question was no longer what process we preferred.

It was where decision-making should actually live.

If ownership without authority was the damage, the repair could not be another set of ceremonies with different names.

It had to start with a different question: where should decisions live?

I have come to believe that leadership, at this level, is less about inventing the perfect operating model and more about deciding how close judgment should sit to the customer problem. Structure still matters. Guardrails still matter. Shared direction still matters. But structure should enable judgment, not replace it. Planning should inform decisions, not become the decision. Coordination should support the people closest to the work, not substitute for their ability to act.

We began asking different questions.

Who owns this product decision? Who owns delivery? Who leads discovery? Is there one backlog for the product, or many places where work goes to wait? Are leaders setting direction and problems to solve — or approving every move? When a customer need arrives, how many hands does it pass through before someone with context can say yes, no, or not yet?

The practical changes followed from those questions. Product managers were expected to own product decisions again, not merely administer tickets through a central system. Engineering leaders owned how delivery happened. Design led discovery with the team, not after the work had already been shaped elsewhere. We pushed toward one backlog per product. We reduced the number of centralized approvals that had turned reasonable requests into committee outcomes. Leaders spent more time clarifying strategy and the problems worth solving, and less time managing every decision the team was capable of making.

None of that is a finished answer. Every operating model creates tradeoffs. Move decisions closer to the customer and you accept new risks: uneven judgment, local optimization, coordination that has to be rebuilt in lighter forms. We underestimated some of that coordination work when the old scaffolding came down. We have had to put pieces back — carefully, and for different reasons than before.

The point was not to declare a new permanent system.

The point was to move the center of gravity back toward the people who could see the customer problem and still be held responsible for the outcome.

Maybe the useful comparison is not whether one operating model is better than another.

Maybe the better question is whether our decision-making still lives close enough to the customer.

And once you ask that, you also have to ask something harder: how would we know?

Moving decision rights closer to the customer feels right long before you know whether it works.

That is the danger.

It is easy to confuse a better philosophy with a better organization. We had made a real change — fewer centralized approvals, clearer product ownership, judgment pushed back toward the teams closest to the work. The question was not whether I preferred the new questions. The question was whether customers and execution were better off, or whether we had simply rearranged our own comfort.

So we set a deliberately unimpressive bar.

Before we looked for acceleration, innovation, or anything that would make a good story, we asked whether we had at least avoided making delivery worse. Before proving we were faster, we wanted to prove we hadn’t broken the fundamentals: throughput, commitments, the ability to finish work, operational stability. Break even first. Earn the right to believe anything more ambitious.

That was not a strategy for marketing the change. It was a way of testing our own optimism.

We assumed there would be unintended consequences. We expected tradeoffs — especially after removing scaffolding we later had to partially rebuild. We compared adjacent periods of delivery in the same part of the organization and looked for simple signals: were we completing work at least as well as before? Were we finishing more of the planned work and less of the ad hoc scatter? The early read suggested we were not behind. In places we were modestly ahead. That was enough to keep going. It was not enough to declare victory.

Mature leaders do not ask whether a new model feels philosophically correct.

They ask whether customers are better served, whether execution remains reliable, whether accountability improved, and whether decision quality got closer to the work. Feeling better inside the building is not the same as earning trust outside it.

Breaking even was never the destination.

It was the price of earning the right to believe the changes were actually working.

And even that belief has to stay provisional — because every operating model keeps becoming something else.

We are still becoming.

We keep adjusting where decisions live. We keep putting coordination back where the work truly needs it, and resisting it where it only protects the system. We keep watching for new forms of drift — because today’s answers have a way of hardening into tomorrow’s assumptions. Whatever we are using now will someday deserve the same scrutiny we applied to what came before.

That is not a failure of the transition. It is the work.

Every operating model eventually begins optimizing for something. The responsibility of leadership is to notice what that something has become — and to ask, before the dashboard answers for you, whether it is still the customer.

The framework was never the subject. The subject is whether the people closest to the customer still have both the judgment and the authority to solve the customer’s problems.

I do not know what operating model your organization should use.

I do know the question I hope you keep asking:

When a customer needs something reasonable — who can say yes?