Stuck in the Middle: When Your Agile Transformation Creates a Reporting Layer Instead of a Leadership Layer

The Transformation That Looked Perfect on Paper

I worked with a Danish financial services firm in late 2025 that had done everything right — on paper. They'd invested in a full SAFe implementation, trained over 200 people, hired three Release Train Engineers, and run six Program Increments. Their PI planning events were textbook. Their backlogs were groomed. Their tooling was immaculate.

And yet, delivery velocity had flatlined. Teams were disengaged. The best engineers were quietly updating their LinkedIn profiles.

When the CTO asked me to diagnose the problem, he expected me to recommend a framework adjustment — maybe a shift from SAFe to LeSS, or a retooling of their PI cadence. Instead, I spent two weeks watching what their middle managers actually did all day.

What I found was damning. Twelve experienced, capable managers — people with deep domain knowledge and genuine leadership instincts — had been systematically reduced to human Jira dashboards. Their calendars were wall-to-wall status meetings. Their primary output was aggregating information from teams and reformatting it for executives. They had been stripped of decision-making authority and given reporting obligations in return.

The enterprise hadn't built a leadership layer. It had built a reporting layer. And that single structural failure was poisoning everything downstream.

Why This Matters Right Now

This isn't an abstract organisational design debate. 2026 is shaping up as a reckoning year for scaled agile across the Nordics and beyond.

A wave of SAFe 5 and 6 transformations launched between 2022 and 2024 are now hitting their 18-to-36-month inflection point — the moment where these investments either compound into genuine delivery capability or visibly stall. The PMI Pulse of the Profession 2025 report identified organisational structure and middle-management role confusion as a leading factor in transformation failures, a finding echoed by Scrum.org's failure analyses and enterprise post-mortems surfacing across industry publications in early 2026.

Nordic enterprises face an additional, very specific pressure. Denmark's Joint Government Digital Strategy 2026–2029 is compressing delivery timelines across the public-sector supply chain. The strategy explicitly demands faster, more integrated digital service delivery — which means every enterprise supplying into the Danish public sector is now operating under tighter velocity expectations. If your middle-management layer is functioning as a reporting bottleneck rather than a delivery accelerator, the cost of that dysfunction just went up dramatically.

This isn't a framework problem. It's a structural problem. And it requires a structural fix.

The Reporting-Layer Trap

Here's how the trap gets set. It's rarely intentional, and it's almost always invisible to the people who create it.

How It Happens

When enterprises adopt scaled agile frameworks, they face an immediate question: what do we do with our existing middle managers? These are typically people with 10-20 years of experience, deep organisational knowledge, and established relationships across the business. They're too valuable to let go and too embedded to ignore.

Most frameworks offer elegant theoretical answers. SAFe positions the Release Train Engineer as a servant-leader. LeSS emphasises that managers should focus on "improving the system" rather than directing work. The Scrum Guide itself is deliberately silent on management structure, leaving organisations to figure it out.

In practice, what happens is far less elegant. The transformation team — usually a combination of external consultants and an internal agile centre of excellence — redesigns team structures, ceremonies, and delivery cadences. But the middle-management tier gets retrofitted rather than redesigned. Existing managers are slotted into new boxes on the org chart, given new titles, sent to certification courses, and told to "be agile."

The problem is that nobody redesigns their actual work. Their meeting structures, their reporting obligations, their performance metrics, their decision-making authority — these remain largely unchanged. Or worse, they change in exactly the wrong direction: managers lose the authority to make decisions (because "teams are self-organising") but gain new obligations to collect and report status (because executives still want visibility).

The result is a layer of experienced professionals whose primary function is information pass-through. They attend team standups to gather status. They attend leadership syncs to report it upward. They spend their afternoons formatting updates, reconciling Jira data, and preparing slide decks. They have become, in the most literal sense, human middleware.

Why Executives Don't See It

Executive sponsors rarely recognise this pattern until the transformation is already stalling, for three reasons.

First, the reporting layer produces visible output. Dashboards get updated. Status reports arrive on time. PI objectives are tracked. From an executive vantage point, the system looks like it's working because information is flowing.

Second, the metrics that matter are lagging indicators. Delivery velocity, team engagement, and time-to-market don't collapse overnight. They erode gradually over 12-18 months. By the time the numbers are undeniable, the root cause is buried under layers of compensating behaviour.

Third, middle managers themselves rarely raise the alarm. They've been told this is what agile looks like. They assume the discomfort they feel — the sense that they're not adding value, that they've been hollowed out — is a personal adaptation problem rather than a systemic design failure. Many of them quietly disengage. The best ones leave.

Three Signals Your Middle Management Has Become a Bottleneck

Before you conclude that your framework is broken, look for these three observable patterns. They're the diagnostic fingerprint of a reporting layer masquerading as a leadership layer.

Signal 1: Decision Latency

In a healthy scaled agile system, the vast majority of decisions should be made at or near the team level. Middle managers and value stream leads should be handling the genuinely cross-cutting decisions that teams can't resolve independently — and they should be handling them fast.

Measure the time between when a decision need is identified and when a decision is actually made. In a reporting-layer structure, this latency is typically 5-10x what it should be, because managers don't feel empowered to decide. Instead, they escalate upward, wait for direction, and then relay the answer back down. A decision that should take hours takes weeks.

The tell-tale sign: teams have learned to work around the middle layer. They make decisions informally, avoid asking for help, or simply wait — burning sprint after sprint — rather than engage a process they know will be slow.

Signal 2: Escalation Frequency

Count the escalations reaching your senior leadership team each month. Now categorise them. How many are genuinely strategic — requiring executive judgement, resource reallocation, or stakeholder negotiation? And how many are operational decisions that a confident, empowered middle manager should have resolved?

In a reporting-layer structure, escalation frequency is high and escalation quality is low. Managers escalate not because the decisions are hard, but because they've been structurally stripped of the authority — or the confidence — to make them. Executives end up making dozens of tactical calls per week, which crowds out their actual strategic work and reinforces the very centralisation the agile transformation was supposed to eliminate.

Signal 3: Team-Level Disengagement Patterns

This is the most damaging signal and the hardest to measure with standard metrics. Look for it qualitatively.

Are your best team members still proposing improvements, challenging assumptions, and taking ownership of outcomes? Or have they settled into a pattern of executing assigned work, attending required ceremonies, and keeping their heads down?

In a reporting-layer structure, teams learn quickly that the system doesn't actually want their initiative. Decisions get made elsewhere. Status gets collected regardless. The ceremonies feel performative. Talented people respond to this environment by either disengaging in place or leaving entirely. The teams that remain become competent executors — but they stop being the self-organising, problem-solving units that the agile transformation was supposed to create.

If you're seeing all three signals — decision latency, escalation frequency, and team disengagement — your problem almost certainly isn't the framework. It's the structural role your middle management is playing.

The Nordic Context: Why This Dysfunction Is Newly Expensive

Nordic enterprises have always operated under particular structural pressures — flat organisational cultures, consensus-driven decision-making, strong labour protections that make restructuring slow and politically sensitive. These characteristics make the reporting-layer trap both more likely (because cultural norms resist the explicit authority redistribution that scaled agile requires) and more persistent (because the people trapped in reporting roles are protected from the market signals that might otherwise force change).

Denmark's Joint Government Digital Strategy 2026–2029 adds a new dimension of urgency. The strategy's emphasis on accelerated digital service delivery, cross-agency integration, and private-sector collaboration creates real consequences for enterprises that can't deliver at velocity. Public-sector contracts increasingly include delivery-speed requirements. Cross-agency integration demands rapid coordination across organisational boundaries. The enterprises that win in this environment will be the ones whose middle-management layers function as decision-making accelerators, not information bottlenecks.

I've observed this dynamic playing out across several Nordic enterprise transformations over the past 18 months. The organisations that are thriving aren't the ones with the most sophisticated frameworks or the most expensive tooling. They're the ones that got the middle-management structural question right — that designed their leadership layer for decision velocity rather than reporting fidelity.

The organisations that are struggling, by contrast, tend to share a common pattern: they invested heavily in framework adoption, team-level training, and executive alignment, but they left the middle-management tier to figure itself out. That tier, predictably, defaulted to what it knew — collecting information and reporting upward — and the transformation stalled.

What a Genuine Leadership Layer Looks Like

If the reporting layer is the disease, what does the cure look like? It starts with a fundamental reframe: middle management in a scaled agile system isn't about information flow. It's about decision-making, impediment removal, and capability development.

Here's what that looks like concretely across three critical roles.

Release Train Engineers: From Ceremony Facilitators to System Optimisers

In a reporting-layer structure, RTEs become meeting schedulers and status aggregators. They run PI planning, facilitate system demos, and track progress against PI objectives. These are necessary activities, but they're not sufficient — and when they become the entirety of the RTE role, the position loses its strategic value.

In a genuine leadership layer, the RTE's primary function is optimising the flow of value through the Agile Release Train. That means they spend the majority of their time on three things:

1. Identifying and removing systemic impediments — not the tactical blockers that teams can handle, but the cross-cutting organisational friction that slows delivery across multiple teams.

2. Making or facilitating cross-team decisions — resolving dependency conflicts, prioritising shared resources, and negotiating trade-offs between competing team needs.

3. Building team capability — coaching Scrum Masters, developing team leads, and creating the conditions for genuine self-organisation.

The shift is from running the train to improving the railway.

Value Stream Leads: From Reporting Consolidators to Business Outcome Owners

Value stream leads in a reporting-layer structure spend their time consolidating metrics from multiple ARTs and presenting them to portfolio leadership. They become the human glue between operational delivery and strategic oversight — but their contribution is purely informational.

In a leadership-layer structure, value stream leads own business outcomes. They have explicit authority over prioritisation trade-offs within their value stream. They make resource allocation decisions. They negotiate directly with business stakeholders about scope, timing, and quality trade-offs. They are, in effect, general managers of a delivery business — not reporters on its progress.

This requires a corresponding shift in how portfolio leadership operates. If value stream leads own outcomes, portfolio leaders need to govern through objectives and constraints rather than through status reviews and approval gates.

Line Managers: From People Administrators to Capability Builders

This is perhaps the most neglected role redesign in scaled agile transformations. Line managers — the people responsible for hiring, development, performance management, and career progression — are often left almost entirely out of the agile transformation design. They continue operating under traditional HR processes while the delivery organisation around them transforms.

In a leadership-layer structure, line managers become the primary engine of capability development. They work closely with RTEs and Scrum Masters to understand where skill gaps are constraining delivery. They redesign hiring profiles to match agile team needs. They restructure performance management to reward collaboration, learning, and outcome delivery rather than individual output and status reporting.

Most importantly, they create the safety that genuine self-organisation requires. Teams won't take risks, challenge assumptions, or own outcomes if they believe their line manager is evaluating them on compliance and predictability. Line managers in a leadership layer explicitly reward the behaviours that scaled agile depends on.

A Practical 90-Day Diagnostic

If you're a programme leader looking at a stalling scaled agile transformation, resist the urge to immediately redesign the framework, hire new consultants, or launch a retraining programme. Instead, spend 90 days having three specific conversations.

Conversation 1: The Middle-Manager Reality Check (Days 1–30)

Sit down individually with every middle manager in your delivery organisation — RTEs, value stream leads, chapter leads, line managers. Ask them three questions:

1. What decisions did you make last week? Not "what decisions did you participate in" or "what decisions did you escalate." What decisions did you personally make?

2. What percentage of your time is spent collecting or reformatting information that already exists in your tools? Be specific. Get them to walk you through their calendar.

3. If you disappeared for two weeks, what would break? This reveals whether they're adding unique value or serving as an information relay.

The answers will tell you whether you have a leadership layer or a reporting layer. In my experience, the results are usually stark — and usually surprising to the executives who commissioned the transformation.

Conversation 2: The Team-Level Truth (Days 30–60)

Talk to teams — not in retrospectives or official feedback channels, but in informal, psychologically safe conversations. Ask:

1. When you need a decision that's beyond your team's authority, what happens? Map the actual decision path, not the theoretical one.

2. **Who in the management layer makes your work easier?** Not "who do you report to" but "who actively helps you deliver?"

3. What would you change about how management interacts with your team? Listen for patterns, not individual complaints.

These conversations will reveal the lived experience of your structural choices. They'll show you where the reporting layer is creating friction and where genuine leadership is already happening despite the structure.

Conversation 3: The Executive Alignment Conversation (Days 60–90)

Armed with data from the first two conversations, sit down with your executive sponsors. This conversation is the hardest, because it requires executives to examine their own role in creating the reporting layer.

Present the data honestly. Show the decision latency numbers. Share the middle-manager time allocation. Relay the team-level feedback. Then ask:

1. What information do you actually need from the middle-management layer — and how often? Most executives discover they're consuming far more status information than they need, and that their appetite for reporting is directly driving the reporting-layer behaviour.

2. What decisions are you currently making that should be made two levels down? Executives in a reporting-layer structure are typically making dozens of operational decisions per week — not because they want to, but because the system routes those decisions upward.

3. Are you willing to trade reporting fidelity for decision velocity? This is the core trade-off. A leadership layer will make decisions faster, but executives will have less real-time visibility into operational details. That's a feature, not a bug — but it requires executive trust that many organisations haven't built.

This 90-day diagnostic won't solve the problem, but it will tell you whether the problem is structural — and if it is, it will give you the evidence base to redesign the middle-management tier rather than re-implementing the framework.

For organisations that need external perspective on this diagnostic process, experienced agile coaching can accelerate the pattern recognition significantly. The value isn't in the coaching methodology — it's in having someone who's seen the reporting-layer trap across multiple organisations and can name it quickly.

From Diagnosis to Redesign

If your diagnostic confirms a reporting-layer problem, the redesign work falls into three categories.

Authority Redistribution

Map every recurring decision type in your delivery organisation. For each one, define the lowest level at which that decision can competently be made — and then explicitly authorise that level to make it. Document it. Communicate it. Hold people accountable for deciding, not escalating.

This is harder than it sounds, because authority redistribution requires trust — and trust requires competence — and competence requires practice. You'll need to accept that some decisions will be made imperfectly during the transition. That's the cost of building a leadership layer, and it's far lower than the cost of maintaining a reporting layer.

Meeting Structure Overhaul

Audit every recurring meeting in your middle-management tier. For each one, ask: is this meeting primarily about information transfer or decision-making? If it's information transfer, eliminate it and replace it with an asynchronous update. If it's decision-making, ensure the right people are in the room, the decision rights are clear, and the output is a decision — not a status update.

In every reporting-layer organisation I've worked with, this audit eliminates 40-60% of recurring meetings. The time freed up is what allows middle managers to do actual leadership work — coaching teams, removing impediments, making decisions, and building capability.

Metric Redesign

Stop measuring your middle managers on reporting quality and start measuring them on decision velocity, impediment resolution time, and team capability growth. What you measure is what you get. If you measure reporting, you get a reporting layer. If you measure leadership, you get a leadership layer.

For complex, multi-stream transformations, programme management discipline becomes essential during this redesign phase — not to add another reporting layer, but to ensure the authority redistribution is coherent across value streams and that the new decision-making structures don't create gaps or conflicts.

The Deeper Challenge

I want to be honest about something. The reporting-layer trap persists not because it's hard to diagnose, but because it's hard to fix. The fix requires executives to accept less visibility. It requires middle managers to accept more accountability. It requires teams to accept more ownership. And it requires the organisation as a whole to tolerate the messiness of distributed decision-making after years of centralised control.

The EU's approach to digital transformation governance increasingly emphasises outcome-based accountability over process compliance — a directional signal that Nordic enterprises would do well to internalise at the organisational level, not just the programme level.

None of this is a framework problem. SAFe, LeSS, Spotify, or whatever hybrid your organisation has adopted — they all work reasonably well when the structural preconditions are right. And they all fail, predictably and expensively, when the middle-management layer has been designed for reporting rather than leading.

The question isn't whether your framework is correct. The question is whether your middle managers are spending their days collecting status or making decisions. The answer to that question will tell you more about the trajectory of your transformation than any maturity assessment or framework audit ever could.

If your scaled agile transformation is approaching its 18-month mark and the momentum is fading, start with the structural question before you revisit the methodology. The 90-day diagnostic outlined above costs nothing but time and honesty — and it might save you from solving the wrong problem.