Quantum Levels: Why Large Transformations Break Between Strategy and Delivery
- Kenneth Linnebjerg
- 6 days ago
- 15 min read
In every large transformation, work exists at more than one level at the same time
Most large transformations are full of activity. There are steering committees, workstreams, architects, product owners, project managers, agile teams, vendor teams, roadmaps, risk logs, sprint boards, workshops, status reports, and endless meetings.
Everyone is busy. And yet, progress often feels strangely unstable. Executives talk about strategic outcomes. Program managers talk about milestones and dependencies. Architects talk about platforms and integration patterns. Product owners talk about features and priorities. Delivery teams talk about stories, tasks, defects, and sprint commitments.
Each conversation may be valid.
But they are often happening at different levels of abstraction. That is where the transformation begins to break.
The organization believes it is discussing the same work, but in reality, it is discussing different versions of the work at different levels. A strategic initiative is treated like something executable. An epic behaves like a program. A user story carries an unresolved architecture decision. A technical task becomes the place where a business process is finally clarified.
The result is predictable: Work slows down. Decisions are delayed. Dependencies appear late. Teams compensate for upstream ambiguity. Reporting becomes unreliable. Progress looks visible at one level while remaining unclear at another.
This is the problem of Quantum Levels.
Quantum Levels describe the structured hierarchy through which transformation work must move from strategic intent to executable delivery. The concept builds on Quantum Work: the natural unit of change. But where Quantum Work asks, “What is the right-sized unit of change?”, Quantum Levels asks, “At what level does this work belong?”
That question is far more important than it first appears.
Work Exists at Different Resolutions - Quantum Levels
In large transformations, work does not exist at one level. At the top, leadership defines strategic outcomes: growth, simplification, compliance, customer experience, resilience, operating efficiency, or digital modernization.
One level below, those ambitions become portfolios, programs, strategic initiatives, transformation themes, or funding areas. Further down, they become capabilities, process areas, product domains, business features, epics, user stories, technical tasks, test cases, releases, training activities, and operational readiness items.
A transformation must connect strategic intent with executable change. Strategy must become design. Design must become delivery. Delivery must become adoption. Adoption must become measurable business effect. The problem begins when the levels are mixed.
A map is a useful analogy. A map of Europe is useful for understanding countries, borders, and major transport corridors. It is useless for finding the entrance to a specific building. A city map is useful for navigating streets, but useless for understanding continental trade flows. Neither map is wrong. Each map has the right resolution for a certain purpose.
Transformation work behaves the same way. At portfolio level, it makes sense to discuss investment, strategic priority, executive ownership, business benefit, and major risk exposure. It does not make sense to manage individual technical tasks. At user story level, it makes sense to discuss acceptance criteria, implementation detail, testability, and small delivery increments. It does not make sense to decide whether the whole transformation should continue.
Many transformation problems are not caused by bad people or bad methods. They are caused by using the wrong resolution for the decision being made.
Complexity Naturally Forms Levels
The idea that complexity forms levels is not new. Herbert Simon’s classic paper The Architecture of Complexity argued that complex systems are often hierarchical: systems are composed of subsystems, which are themselves composed of further subsystems. Simon also argued that stable intermediate forms make complexity easier to evolve and manage [1].
Executives ask for outcomes, but teams receive vague initiatives. Teams complete stories, but leaders cannot see whether strategic intent is being realized. Middle management creates summaries, status decks, and escalation forums, but these often translate activity rather than structurally connect the levels. This is why transformations often feel overmanaged and undercontrolled at the same time.
There are many management layers. But there are not enough meaningful work levels.
Quantum Levels Are Not Just Containers
A common mistake is to think of levels as simple containers. The portfolio contains initiatives. Initiatives contain epics. Epics contain features. Features contain stories. Stories contain tasks. This sounds logical, but it is too mechanical. Levels are not just containers. They are different levels of meaning. Each level answers a different question.
At portfolio level, the question is: which strategic outcomes deserve investment and executive attention?
At program or initiative level, the question is: which major change journeys must be executed?
At capability or domain level, the question is: which business or system capabilities must change?
At business feature level, the question is: which coherent units of business change can be shaped, sequenced, and validated?
At epic level, the question is: which delivery objects must be implemented to realize the feature?
At user story level, the question is: which small increment can be built and accepted?
At task level, the question is: which concrete action must be performed?
These questions are not interchangeable. A portfolio decision cannot be answered at task level. A user story cannot substitute for a business capability. A technical task cannot carry an unresolved business process decision. A feature cannot behave like a program without creating structural instability.
When levels are treated as simple containers, organizations assume that decomposition is enough. But decomposition without level discipline produces fragments. The work may be broken down, but the meaning is not preserved. Quantum Levels are not only about breaking work apart. They are about preserving meaning as work changes resolution.
Strategic Intent Is Not Executable Work
One of the most common level errors is treating strategic intent as executable work.
A leadership team defines an ambition such as:
“Create a modern digital customer platform.”
“Harmonize global product data.”
“Replace the legacy ERP platform.”
“Enable solution selling.”
“Improve order fulfillment.”
These ambitions may be necessary. They give direction. They justify investment. They create executive alignment. But they are not executable work. They cannot be estimated precisely. They cannot be assigned to one team. They cannot be accepted in a sprint review. They cannot be tested directly. They cannot be meaningfully reported as 62 percent complete unless the lower-level structure beneath them is clear.
When strategic intent is pushed into delivery without intermediate structure, delivery teams are forced to invent the missing levels. This often happens quietly. A team receives an epic called “Implement global catalog.” But inside that epic are product data models, publishing workflows, enrichment rules, permissions, search behavior, integrations, migration concerns, reporting needs, operating model questions, and data quality requirements. That epic is not an epic. It is a program disguised as an epic.
Another team receives a feature called “Enable solution selling.” But solution selling may require business model decisions, product bundling logic, configuration rules, pricing behavior, guided selling, sales training, master data changes, and integration to quoting or order systems. That feature is not a feature. It is a strategic capability disguised as a feature.
When work arrives at the wrong level, teams cannot simply “deliver better.” They must compensate structurally. They must clarify scope, negotiate priorities, identify dependencies, define architecture, split work, interpret business intent, and discover what “done” means. This may look like refinement. But in reality, it is uncontrolled level reconstruction.
The transformation loses time not because people are slow, but because the work arrived at the wrong altitude.
Stories Cannot Carry Strategy
The opposite error is also common. Organizations sometimes try to solve strategic ambiguity by writing more user stories. This feels practical. Stories are concrete. They can be placed in Jira. They can be estimated. They can be assigned. They can be moved across a board. They create the appearance of progress. But stories cannot carry strategy.
A user story is a low-level expression of desired behavior or system change. It can support dialogue between users and developers. It can help define acceptance criteria. It can help a team produce a small increment.
But a story cannot by itself preserve portfolio intent, business capability structure, architectural coherence, or transformation sequencing.
Requirements engineering has long recognized that goals and requirements exist at different levels of abstraction. Axel van Lamsweerde’s work on goal-oriented requirements engineering emphasizes that lower-level requirements should be understood as refinements of higher-level goals. This is important because requirements are not isolated statements. They carry intent from above [2].
If that chain is broken, the lower-level work loses its reason. Teams may still deliver stories, but they cannot tell whether the stories are advancing the right outcome. Executives may still sponsor the transformation, but they cannot see whether delivery activity is preserving strategic intent. That is why a transformation backlog cannot be only a list of things to build.
It must be a chain of intent.
Strategic goals must connect to initiatives. Initiatives must connect to capabilities or domains. Capabilities must connect to features. Features must connect to epics. Epics must connect to stories and tasks. Tests, releases, adoption activities, and benefit measures must connect back through the same chain.
Traceability Is Not Documentation
Requirements traceability research makes this point stronger. Gotel and Finkelstein’s classic work on the requirements traceability problem describes traceability as the ability to follow the life of a requirement both forward and backward: from origin through development, specification, deployment, use, and later change [3].
In transformation work, this must be expanded beyond requirements. We need transformation traceability. That means the ability to follow a line of change from strategic intent through portfolio investment, initiative design, capability impact, feature definition, delivery execution, validation, release, adoption, and benefits realization. This is not a documentation exercise. It is a way of preserving coherence across levels.
When traceability is weak, reporting becomes narrative-based. Leaders receive summaries of progress, but cannot inspect the structural link between what was intended and what is being delivered. Teams complete backlog items, but cannot always prove which business outcome they advanced. Weak traceability creates room for false certainty.
A transformation may look green because many items are moving. But if those items are not traceably connected to the intended change, green status may only mean that activity is being completed. Quantum Levels make traceability practical because they define the intermediate levels through which intent must pass.
Without these levels, the organization tries to connect strategy directly to tasks. That connection is too long, too brittle, and too easy to fake.
The Portfolio-to-Story Cliff
One of the most common structural defects in modern transformations is the portfolio-to-story cliff. This happens when an organization has a strategic portfolio and agile delivery teams, but weak intermediate structure between them.
At the top, leaders define strategic initiatives and funding themes. At the bottom, teams manage user stories and sprints. Between the two, there may be epics and features, but these are inconsistently defined. Some are business outcomes. Some are system components. Some are funding containers. Some are delivery backlogs. Some are unresolved questions.
The result is a cliff. Intent falls from portfolio level directly into team-level delivery.
Teams absorb the shock. They must interpret strategy, clarify business outcomes, identify dependencies, coordinate across teams, expose architectural issues, refine requirements, and still deliver sprint commitments.
When they struggle, the organization concludes that teams lack maturity or speed.
But often, the real problem is that the middle levels are missing or weak. This is why many large Agile transformations produce local team improvement without system-level flow. Teams become better at managing stories, but the organization remains weak at translating strategy into coherent, sequenced, validated work.
The portfolio-to-story cliff is not solved by more PI planning alone. PI planning can coordinate known work. It cannot fully compensate for missing level structure. If the work entering the planning event is already at the wrong level, the event becomes a compression chamber for ambiguity. For a few days, the system appears aligned. Then the ambiguity reappears in delivery.
Evidence Must Match the Quantum Level
Incorrect level alignment creates false reporting. A transformation can look healthy at one level and unhealthy at another. If reporting only shows the healthy level, leadership receives a distorted picture. At task level, many activities may be complete. At story level, sprint progress may look good. At epic level, delivery may be partially progressing. But at feature level, the business change may not be coherent.
At capability level, the operating model may not be ready. At program level, the dependency chain may be unstable. At portfolio level, the strategic outcome may still be at risk. This produces vertical reporting distortion. Lower levels show movement. Higher levels infer progress. But the transformation has not actually crossed the relevant state boundary.
Bent Flyvbjerg’s work on project bias is relevant here. He identifies optimism bias, strategic misrepresentation, planning fallacy, overconfidence, and escalation of commitment as recurring patterns in project planning and management [4].
Quantum Levels do not eliminate these biases. But they reduce the space in which they can hide. When progress must be reported level by level, it becomes harder to substitute activity for outcome. A green sprint does not automatically mean a green feature. A green feature does not automatically mean a green capability. A green milestone does not automatically mean benefits are secure. Each level must show evidence appropriate to that level.
A portfolio item is not healthy because tasks have been executed. It is healthy when strategic priority, funding, executive ownership, benefit logic, and major risk exposure are clear.
A program is not healthy because many teams are busy. It is healthy when the integrated roadmap, dependencies, governance, decision cadence, and delivery sequence are coherent.
A capability is not ready because a system component has been built. It is ready when the business ability can operate across process, people, data, technology, and control dimensions.
A feature is not done because stories are closed. It is done when the intended business change has been delivered, validated, and accepted.
A story is not done because code is written. It is done when acceptance criteria are met and the increment is integrated.
A task is not done because effort has been spent. It is done when the concrete action has produced its intended evidence.
Evidence must not be allowed to jump levels without interpretation. A lower-level completion may contribute to higher-level progress, but it does not prove it.
Dependencies Exist Across Levels
Dependencies are often discussed horizontally. Team A depends on Team B. System X depends on System Y. Vendor delivery depends on internal readiness. Testing depends on environment availability. Training depends on process documentation. These dependencies are real. But there are also vertical dependencies across levels.
A story depends on an epic being coherent.
An epic depends on a feature being shaped.
A feature depends on a capability context being clear.
A capability depends on program sequencing.
A program depends on portfolio priority and funding. A portfolio depends on strategic clarity.
When vertical dependencies are weak, horizontal dependency management becomes overloaded. Teams try to coordinate with other teams, but the real issue is that the feature boundary is wrong. Product owners negotiate scope, but the real issue is that the capability decision is unresolved. Architects manage interfaces, but the real issue is that the initiative has bundled incompatible outcomes.
Research on socio-technical congruence by Cataldo and Herbsleb is relevant here. Their work shows that coordination needs are linked to task dependencies, and that mismatches between required coordination and actual coordination behavior can harm productivity and quality [5].
This matters because level errors create hidden coordination needs. If an epic is actually a program, it will require program-level coordination even if it is managed as an epic. If a story carries an architectural decision, it will require architecture-level coordination even if it is assigned to a developer. If a feature contains multiple business capabilities, it will require cross-capability coordination even if it is owned by one product owner. The system cannot avoid coordination needs by mislabeling work. It can only make them invisible.
The Missing Middle
Many transformations suffer from missing middle levels. They have strategy and tasks.
They have vision and Jira. They have executive sponsorship and delivery teams. What they lack is a coherent middle structure that translates intent into governable units of change.
This missing middle often includes capability modeling, business feature shaping, architecture feasibility, dependency mapping, acceptance model definition, release slicing, and operational readiness planning.
When these middle levels are weak, several things happen. Delivery teams receive work that is too abstract. They must refine while delivering. Governance receives reports that are too summarized. It cannot inspect the real flow of work. Architecture becomes reactive. It is pulled into issues after delivery has already started. Product owners become overloaded. They must hold strategy, business process, architecture, stakeholder alignment, delivery slicing, and acceptance logic simultaneously. Decision latency increases. Decisions are escalated late because the level at which they belonged was never properly established.
The missing middle is one of the main reasons large transformations stall while appearing busy. It is also one of the main reasons methods disappoint. Agile teams may work well locally. Project governance may work formally. Architecture forums may exist. But without the middle levels, the system lacks the structural bridge from intent to execution. Quantum Levels define that bridge.
The Level Integrity Principle
The central principle of Quantum Levels is level integrity. Level integrity means that each level must do the work appropriate to that level and must not push unresolved work downward or hide unresolved work upward.
Portfolio level must not push unresolved strategic conflicts into delivery.
Program level must not push unresolved sequencing into teams.
Capability level must not push unresolved process and ownership questions into features.
Feature level must not push unresolved acceptance and dependency questions into stories.
Story level must not push unresolved business meaning into technical tasks.
Task level must not pretend that activity completion equals transformation progress.
Level integrity is not bureaucracy. It is protection against structural debt. When unresolved work is pushed downward, teams experience it as ambiguity, churn, rework, and blocked flow. When unresolved work is hidden upward, leaders experience it as late surprises, unreliable reporting, missed benefits, and loss of confidence. In both cases, the transformation pays interest on level debt.
A Simple Diagnostic
A transformation can test its level structure with a simple diagnostic.
Take any important item in the transformation and ask:
What portfolio outcome does this support?
Which initiative or program owns the integrated change?
Which capability or domain is being changed?
Which business feature expresses the coherent unit of value?
Which epics or delivery objects realize the feature?
Which stories or requirement slices are currently executable?
Which tasks are being performed now?
Which evidence rolls back up to prove progress?
If the chain is clear, the work has structural coherence. If the chain breaks, the transformation has a level problem. The location of the break matters.
Sometimes the strategy is clear, but features are weak. Sometimes features are clear, but epics are inconsistent. Sometimes stories are moving, but no one can say which capability they support. Sometimes the capability is known, but portfolio priority is unclear. Sometimes the task list is detailed, but the acceptance model is missing.
The break tells the organization where to intervene. A feature-level problem should not be solved with portfolio steering. A portfolio conflict should not be solved by writing more stories. A capability ambiguity should not be solved by asking developers to estimate tasks. A reporting distortion should not be solved by demanding more frequent status updates.
The right intervention depends on the level of the defect.
From Hierarchy to Flow
It may seem that Quantum Levels introduce hierarchy into a discussion about flow.
But this is not a contradiction. Flow does not mean flatness. In complex systems, flow requires structure. Work flows through roles, queues, decisions, interfaces, validation points, and levels of abstraction. Baldwin and Clark’s work on modularity reinforces this point: complex systems can be decomposed into parts only when the interfaces and design rules between those parts are clear [6].
Without structure, there is no flow. There is only movement. Quantum Levels provide the vertical structure through which transformation work can move without losing meaning.
The hierarchy is not there to create control for its own sake. It is there to preserve coherence. It allows work to be viewed at different resolutions without confusing those resolutions. It allows governance to ask level-appropriate questions. It allows teams to execute without carrying unresolved strategic ambiguity. It allows leaders to see whether delivery is actually advancing the intended transformation.
Quantum Levels do not slow transformation down. They reduce the rework, decision latency, false reporting, and coordination waste that make transformation slow.
The Implication
Quantum Work gives us the natural unit of change. Quantum Levels give us the structure through which those units relate across scale. Together, they create the first foundation for structural transformation management. Work must be shaped into coherent units. Those units must exist at the right level. The relationship between levels must preserve meaning. Evidence must roll upward without distortion. Intent must flow downward without becoming vague.
Decisions must be made at the level where they belong. When this works, transformation becomes more observable. Leaders can see not only whether work is active, but where it exists in the level structure. Teams can see not only what they must build, but why it matters. Product owners can see whether features are coherent. Architects can see where decisions belong. Governance forums can see whether progress claims are supported by evidence at the right level.
When this does not work, the system returns to familiar failure patterns. Oversized initiatives enter delivery. Epics behave like programs. Stories carry unresolved design decisions. Tasks become proxies for progress. Reporting becomes disconnected from reality. Governance reacts late. Teams compensate for ambiguity. Rework increases. Flow breaks.
The problem is not effort. The problem is structural mismatch. Quantum Levels make that mismatch visible. And once it is visible, the transformation can finally begin to govern work at the level where the real problem exists.
REFERENCES
[1] Simon, H. A. (1962). The Architecture of Complexity. Proceedings of the American Philosophical Society, 106(6), 467–482.
[2] Van Lamsweerde, A. (2001). Goal-Oriented Requirements Engineering: A Guided Tour. Proceedings of the 5th IEEE International Symposium on Requirements Engineering.
[3] Gotel, O. C. Z., & Finkelstein, A. C. W. (1994). An Analysis of the Requirements Traceability Problem. Proceedings of the First International Conference on Requirements Engineering.
[4] Flyvbjerg, B. (2021). Top Ten Behavioral Biases in Project Management: An Overview. Project Management Journal.
Alternative open version: https://arxiv.org/abs/2202.00125
[5] Cataldo, M., & Herbsleb, J. D. (2013). Coordination Breakdowns and Their Impact on Development Productivity and Software Failures. IEEE Transactions on Software Engineering, 39(3), 343–360.
[6] Baldwin, C. Y., & Clark, K. B. (2000). Design Rules, Volume 1: The Power of Modularity. MIT Press.
Alternative MIT Direct page: https://direct.mit.edu/books/monograph/1856/Design-Rules-Volume-1The-Power-of-Modularity
Comments