When Frameworks Become the Problem

The customer had asked for something reasonable. Not a rewrite of the product. A change that would make their people faster at work they already pay us to support. I left the call knowing what they needed, and knowing I could not simply go do it.

I was the Vice President of Product. I owned 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 did not fit the plan already locked in place.

After that, the options were familiar and mostly useless. Argue. Escalate. Wait for the next planning cycle. 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, then meetings to realign. Dashboards looked fine. Epics and stories moved. Commitments were recorded. A customer still 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. More than once I had to tell people who trusted us that we could not help them for months. Not because we lacked the people or the skill. 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.

How we got there is easy to get wrong. It would be easy to say the framework itself was the mistake. That is not what happened.

We were building software across many products and many teams, on 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 actually in flight, what was blocked, who was waiting on whom, and whether we were 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. A shared language for commitments across teams that otherwise operated in different worlds. 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, where people could see them. Commitments became clearer. Delivery surprises did not disappear, but they caught leadership off guard less often. Project managers absorbed a meaningful amount of coordination so builders could stay closer to the work. People who lived inside that system still say that mapping and scheduling dependencies was one of the things the approach did well. They are right.

The mistake was not deciding that a growing, interdependent organization needed more than informal coordination. The mistake was treating a solution that fit one stage of our complexity as if it would keep fitting. The coordination problem we had when we adopted the framework was not the permanent problem, and the framework was not the permanent answer.

We kept solving the problem we had on the day we reached for it. The harder question came later. What happens when the structure that once created clarity starts creating a different 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 moved. Slowly.

A customer need that arrived after planning had locked would wait, even when waiting cost more than changing the plan. 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 as a waterfall with agile language wrapped around it: fixed scope, fixed timeline, and limited room to learn once the train had left.

We got better at defending the roadmap than at asking whether the roadmap still matched the customer in front of us. Dashboards tracked whether we were on plan. They were worse at telling us 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, and keeping the plan coherent. Over time, keeping the plan coherent became easier than using judgment. The judgment that sits with a customer problem and decides what deserves to move got quieter.

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 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.

The operating model begins optimizing itself instead of the customer.

We were no longer only managing complexity. We were managing the operating model itself.

Once you see that, you start noticing it on ordinary days.

A small change would take a meeting to size, another to sequence, and 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 we still did not have 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. 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. 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 that 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.

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 on the system that decided what software was allowed to change.

Which left a harder question. If the operating model controlled so many of the decisions, who actually owned the customer?

The customer still called me.

The committee did not get the follow-up email. The dashboard did not sit in the quarterly review. I did. 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 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 people 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 performance. You defend a team you cannot fully empower, and you accept 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, capable people learn 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, decisions could not keep living so far from the people who carried those outcomes. The question was no longer which process we preferred. It was where decisions should actually live.

If ownership without authority was the damage, another set of ceremonies with different names was not the repair. The repair had to start with a different question: where should decisions live?

I do not think the job, at this level, is inventing the perfect operating model. It is deciding how close judgment should sit to the customer problem. Structure still matters. Guardrails still matter. Shared direction still matters. Structure should help judgment, not replace it. Planning should inform the decision, not become the decision. Coordination should support the people closest to the work, not stand in 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 the problems worth solving, 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 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, and coordination that has to be rebuilt in lighter forms. We underestimated some of that coordination 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 decisions back toward the people who could see the customer problem and still be held responsible for the outcome.

The useful comparison is not whether one operating model is better than another. The better question is whether decision-making still lives close enough to the customer. Once you ask that, you also have to ask how you would know.

Moving decisions closer to the customer feels right before you know whether it works. It is easy to confuse a philosophy you prefer with an organization that works better. 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 liked 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, or for a story that would sound good, we asked whether we had at least avoided making delivery worse. Before claiming we were faster, we wanted to know we had not broken the basics: throughput, commitments, the ability to finish work, operational stability. Break even first. Earn the right to believe anything more ambitious.

That was not a way to market the change. It was a way to test 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 scattered, ad hoc work? 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.

I do not trust a new model because it feels right. I want to know whether customers are better served, whether execution remains reliable, whether accountability improved, and whether decisions 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. That belief has to stay provisional. Every operating model keeps becoming something else.

We are still in it. We keep adjusting where decisions live. We keep putting coordination back where the work actually needs it, and resisting it where it only protects the system. We keep watching for the next drift, because today’s answer has a way of hardening into tomorrow’s assumption. Whatever we are using now will someday deserve the same scrutiny we gave what came before.

That is not a failed transition. It is the job.

Every operating model eventually begins optimizing for something. The job 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 real 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?