Designing for Paradigm: Bringing Business and IT Together at Europe’s Largest Tech Firm
- Chiel van Ewijk
- Mar 1
- 14 min read
Background
This case study documents an ongoing organizational design journey within the IT department of one of Europe’s largest and most complex technology companies—a global high-tech systems manufacturer operating at the frontier of precision engineering and software development.
The IT organization is structured around the Scaled Agile Framework (SAFe), with Agile Release Trains (ARTs) organized primarily around business capabilities—planning, Procurement, Materials Management and so on—rather than around value streams or end-to-end solutions. This blueprint, common in large enterprises, creates capable delivery engines for their respective domains but also embeds structural patterns that make speed, autonomy, and genuine business-IT integration difficult to achieve at scale.
The focus of this case study is one particular ART working in the planning domain. It currently consists of three distinct units:
One development team is responsible for a separate, standalone product—not directly related to the platform described in this case study and not part of the Paradigm initiative.
Two DevOps teams are maintaining and operating the current planning platform, which is approaching end-of-life. Their primary mandate is operational continuity, not feature development.
Into this context arrives Paradigm—a next-generation planning solution that will eventually replace the current platform. Paradigm is not simply a technology refresh. It is, as we will explore, an opportunity to redesign the organizational structure around it from the ground up—before the patterns of the existing organizational structure extend to Paradigm.
I came into this engagement as an Org Design Consultant, initially coaching the project lead before the scope broadened into participatory design workshops with business and IT leadership. My aim throughout has been to bring the language and tools of Org Topologies to a group of leaders who are genuinely motivated to do things differently—and to help them make that ambition concrete and shared.
Design Timeline
The design process is structured across four stages, moving from assessment through to implementation:
R0 involved the initial mapping and assessment workshops—bringing together the Release Train Engineer, Chief Product Owner, IT group leads, Head of Product, and senior business representatives, placing their teams on the Org Topologies map, and naming the gap between where they are and where they want to be. The candor in those sessions was striking. Business leaders acknowledged the distance between themselves and the teams building for them. IT leaders acknowledged the narrowness of the work mandate their developers were operating under. That shared diagnosis became the foundation everything else is built on.
A Brief Introduction to Org Topologies
To make sense of the maps that follow, a short primer on the Org Topologies framework is useful. Org Topologies provides a visual language for describing and designing organizational structures—not in terms of job titles or org charts, but in terms of mandates: what a team is empowered to work on, and how broad or narrow that mandate is across two distinct dimensions.
Horizontal axis—Scope of Skills Mandate
How broad is the range of skills within an organizational unit? Units to the left are functional—single-skill and highly dependent on other teams to deliver. Units to the right are end-to-end capable—they hold all the skills necessary to deliver value without asynchronous handoffs to others.
Vertical axis—Scope of Work Mandate
How close is the unit to the customer and the full solution? Units at the bottom are task-focused—they receive discrete tasks to execute. Units at the top operate at a whole-solution or unbounded scope—they can respond to business and customer problems directly, end-to-end.
The intersection produces sixteen recognizable archetypes, grouped into four families: Doing Archetypes (lower-left, high dependency), Delivering Archetypes (lower-right, technically strong but narrow work scope), Directing Archetypes (upper-left, broad scope but incomplete skills), and Driving Archetypes (upper-right, the ideal: complete skills, broad mandate).
“The map reveals not just where you are, but the distance — and the nature of the effort — required to get where you want to be.”
Most large enterprise IT organizations cluster in the lower half of the map—a natural consequence of scale and specialization pulling toward functional boundaries and narrow mandates. The value of the map lies in making the direction of travel legible and surfacing the specific interventions needed at each step of the journey.
Mapping the Current State
The R0 mapping workshop placed the Paradigm-related units on the Org Topologies map for the first time. The result was a clear and somewhat sobering picture of how fragmented the current structure is—five distinct units spread vertically across the map, with limited horizontal integration between them.
Reading the map from top to bottom:
Business Owner—positioned at the WHOLE-1/WHOLE-2 boundary (where “whole” refers to the complete Paradigm solution scope within the larger enterprise context): whole-solution scope, operating as a Directing Archetype. Close to business strategy, but separated from the delivery layers below by several organizational tiers.
Central Solution Team (Architects and Business)—at WHOLE-2 / PART-2: multi-skill, combining IT architecture and business understanding. A directing layer providing strategic coherence, but not yet a delivery unit in its own right.
Functional Workstream—at PART-2: multi-skill, partial solution scope. Functional and domain experts are beginning to coalesce around Paradigm, building toward end-to-end delivery capability.
Expert Consultants and BPAs—at CAPS-2: multi-skill, capabilities-focused. External Paradigm platform expertise and business process analysts delivering capabilities within a narrower work mandate, with solution outcome accountability set to grow as the design evolves.
DEVs—at TASKS-2: multi-skill, task-focused. Technically capable developers operating with the narrowest work mandate on the map, working from discrete tasks and at a distance from business context and solution ownership—the core constraint the design is built to resolve.
The stack is tall and the layers are distinct. Business and IT operate in parallel streams with limited integration at the delivery level. The DEV team sits at the very bottom—capable, but disconnected from context, customer, and solution ownership. Feedback loops are long; decisions travel upward before they travel back down.
This pattern is consistent with the wider ART landscape in this organization. What makes the Paradigm initiative distinctive is the explicit intention—backed by management on both sides—to design the team structure deliberately from the outset, building on a shared diagnosis of what needs to change.
The Paradigm Opportunity
The arrival of Paradigm in this ART is more than a platform replacement. It is, in organizational design terms, a greenfield moment: an opportunity to build the team structure around a new solution before the constraints of legacy working patterns, reporting lines, and coordination habits have time to calcify.
Business leadership has been through design workshops to understand the need for bridging the gap between business and IT. Leadership across both functions is on board to elevate the design. The Org Design Consultant has worked closely with the project lead to develop the shared language and direction that now underpins the initiative. This groundwork—the investment in shared diagnosis before shared design—is not accidental. It is the first Elevating Kata of the journey.
The design ambition for the Paradigm teams goes further than anything currently in place elsewhere in the ART landscape of this organization. Where other ARTs have worked to integrate competences on the IT side, the Paradigm design targets something more fundamental: bringing business stakeholders directly into multidisciplinary delivery teams, alongside developers, architects, and platform engineers.
This challenges several of the organization's deep structural norms:
Reporting lines—Business staff joining delivery teams typically still report into functional business management. Formal agreements around time allocation, accountability, and career development within a non-traditional team structure must be made explicit.
Role identity—Business Process Analysts and functional workstream leads are accustomed to being consulted. Becoming a team member—sharing a sprint, contributing to a Definition of Done, co-owning a solution outcome—is a different orientation entirely.
Feedback loops—When business and IT share a team, the distance between a discovered insight and a delivered solution collapses dramatically. Achieving this is the central prize of the design; it also requires new habits, new trust, and new working ceremonies.
Compliance and security—This organization operates in a regulated, high-security environment. Any team design must respect non-negotiable requirements around data governance, audit trails, and system access—constraints a good design accommodates, not obstacles it ignores.
The optimizing goals for the Paradigm design were surfaced explicitly in the workshops:
The design is also explicitly inspired by federated development — the idea that a loosely coupled network of empowered, semi-autonomous teams, held together by shared goals and standards rather than centralised control, can outperform a tightly coupled hierarchy in a complex environment.
A critical enabling condition: management alignment
One of the most significant features of this initiative is the breadth of leadership support it has secured. Multiple management layers on both the business and IT sides are actively engaged and aligned on the direction of travel. This is not a bottom-up experiment running under the radar; it has genuine organizational permission.
In my experience as a design consultant, this kind of top-down enabling is frequently what determines whether a design reaches implementation. The workshops run to date have been important not just for their outputs, but for the alignment they have built. Business and IT leaders have sat in the same room, placed themselves on the same map, and agreed—sometimes for the first time explicitly—that the current structure is not the structure they want.
The Intermediate Design: R2
Organizational redesign rarely succeeds as a single leap. The distance between a TASKS-2 development team and a PART-3 end-to-end, partial-solution team is real—measured not just in the structure on paper, but in the habits, trust, skills, and governance that need to develop along the way. The R2 design is a deliberate intermediate stage: ambitious enough to represent genuine progress, grounded enough not to require everything to change at once.
R2 is targeted for Q3–Q4 2026. By that point, the R1 design work—currently underway—will have established the organizational structure needed to deliver Paradigm. R2 then represents the first stable operating configuration: the moment when the new structure begins to be lived, not just planned.
The R2 map shows several significant movements from the current state:
Three emergent partial solution teams begin to form—each focused on a distinct planning domain. These teams are positioned between CAPS-2 and CAPS-3, building end-to-end capability and progressing toward the PART-3 archetype as their skills broaden and their work mandate expands. Critically, each team begins to include both business and IT members.
The DEV team continues moving rightward—from TASKS-2 toward TASKS-3, as developers broaden their technical and contextual skills and begin working against goals rather than tasks. They are moving toward full integration into the partial-solution teams as their mandate and skills grow.
The Central Solution Team remains at WHOLE-2—continuing to provide architectural direction and strategic alignment, but with the gap between it and the delivery layer beginning to narrow as teams grow in capability.
Three practical levers drive the movement from R0 to R2:
Lever 1 — Skills Broadening
Developers are supported in building understanding of the business processes their work serves. Business analysts and functional workstream members begin participating in sprint ceremonies and technical discussions. The goal is informed versatility—enough shared understanding between IT and business that the team can work as a whole rather than as adjacent specialists.
Lever 2 — Work Mandate Expansion
Teams shift from receiving capability specifications to receiving partial solution goals. Teams are given a slice of the solution space and trusted to determine the best path to an outcome. Product Ownership evolves accordingly: less tasking, more goal-setting.
Lever 3 — Dependency Resolving
Explicit attention is paid to the handoffs currently flowing between separate Paradigm sub-teams. Where a dependency can be internalized—through skill transfer, co-location, or team merging—it is. Each dependency removed shortens the cycle from requirement to delivery and reduces the coordination overhead carried by management.
The R2 state is designed to be stable enough to operate in through 2026 and into early 2027, while the organizational capability required for the optimal design continues to develop. The R2 stage gives teams the time and space to build the habits, trust, and governance the optimal design will require—a deliberate investment in organizational readiness.
The Optimal Design: A Team-of-Teams at PART-3
The optimal design is the most progressive configuration under consideration and the one that most directly challenges the prevailing organizational blueprint. Reaching this state is not guaranteed—it requires sustained commitment, deliberate investment, and continued management alignment across both business and IT. But it is the clearest articulation of what the Paradigm teams are designed to become.
The optimal map shows a striking consolidation around the PART-3 archetype:
Three Partial Solution teams at PART-3—end-to-end skilled, partial-solution mandated, and—the defining structural feature—containing both business and IT members. Each team owns a partial solution within the Paradigm planning domain. Each partial solution represents a distinct value stream end-to-end—business and IT together, working toward shared outcomes.
Business Owner and Central Solution Team remain at WHOLE-2—providing strategic direction and architectural coherence. In the optimal design these roles become fully enabling: setting direction, holding the strategic picture, and creating the conditions for teams to thrive.
The DEV team is fully absorbed—developers who have grown in mandate and skills are embedded within the three partial-solution teams. Developers are fully integrated into the partial-solution teams, contributing as end-to-end members with expanded mandates and skills.
“When business and IT share a team with a genuine partial-solution mandate, the distinction between ‘IT delivering for the business’ and ‘the business building its own capability’ begins to dissolve.”
In the optimal design, the dynamics between teams change qualitatively. At the CAPS and TASKS level, coordination is typically imposed from outside—a manager or RTE facilitates alignment because the teams themselves lack the scope to self-organize. At PART-3, with genuine partial-solution ownership, teams begin to coordinate themselves—around the solution, the user, and the outcome. This is the Team-of-Teams dynamic: instead of coordinating teams from above, you coordinate the topology of teams.
Operations: Embedded from the Start
One area given deliberate early resolution in this design is the role of operations. The intention is to include Ops capability within the Paradigm teams from the earliest lifecycle stages as an integral part of each delivery team from the outset.
Why embedded Ops matters
Embedding operational expertise inside the partial-solution teams serves two goals simultaneously. First, it closes the feedback loop between production behavior and development decisions—operational insights inform the backlog directly, without translation through an external team. Second, it ensures that quality support is designed in rather than added after the fact. A team that owns and runs a building has fundamentally different incentives to one that only builds.
In Org Topologies terms, including Ops within the PART-3 teams reinforces their end-to-end skills mandate and prevents the re-emergence of a new dependency at the bottom of the stack—exactly the pattern the overall design is working to eliminate.
Why this design is progressive in this context
Most ARTs in this organization operate at CAPS-2 or below on the work mandate axis, with IT-only team composition. The optimal Paradigm design targets PART-3 with mixed business/IT/Ops teams. This is a qualitatively different model of how enterprise IT relates to the business it serves—treating the Paradigm planning capability as a jointly owned, jointly operated product, built and run by the people closest to it on both sides of the traditional divide.
Elevating Katas for the Paradigm Journey
Elevating Katas are structured, repeatable routines that turn organizational design intent into lived behavior. Rather than one-off transformations, they create safe, deliberate ways to reshape structure, mandates, and ways of working while learning from real work. The Paradigm initiative applies several Elevating Katas from the official Katalog, organized by the dimension of organizational design they address.
Katas Currently Applied
Strategy Dimension:
Adopting Strategic, Outcome-Based Backlog
Teams currently work from team-level backlogs derived from the ART program board. The intention is to transition toward outcome-oriented goal-setting, where teams work toward measurable solution outcomes—adoption rates, process cycle times, error reduction—rather than lists of features or tasks.
Re-Centering Product Ownership on Strategy and Outcomes
Evolving the Product Owner role to focus outward on stakeholder engagement and outcome framing, while teams take increasing ownership of tactical delivery decisions within their partial-solution mandate.
Structure Dimension:
Expanding Units Toward End-to-End Outcome Ownership
Deliberately broadening both the skills mandate and work mandate of teams—moving from narrow, task-focused units toward PART-3 teams that own partial solutions within the planning domain. This includes embedding business staff directly into delivery teams with formal agreements on time allocation, accountability, and career development.
Forming a Team-of-Teams
Building the three partial-solution teams as a coordinated Team-of-Teams structure. Rather than coordinating teams from above, teams coordinate themselves around the shared planning solution space, with leadership providing strategic direction and removing obstacles.
Processes Dimension:
Expanding and Sharing the Definition of Done Across Teams
Including operational readiness and production ownership in the Definition of Done from the earliest stages. Ops expertise is embedded in teams so that quality, monitoring, and support concerns shape decisions from day one.
Holding Multi-Team Product Backlog Refinement
Establishing regular refinement sessions where the three partial-solution teams align their understanding of upcoming work, surface dependencies early, and coordinate around the shared planning domain.
People Dimension:
Using Synchronous Teamwork to Expand Capability and Ownership
Supporting developers to build understanding of business processes through participation in sprint ceremonies, backlog refinement, and stakeholder conversations. Business analysts gain technical context through pairing and mob sessions. The goal is reducing hard boundaries between IT and business understanding within shared teams.
Potential Future Katas
As the Paradigm teams mature and the design stabilizes, additional Elevating Katas could be introduced to deepen the transformation:
Merging Product Backlogs: If multiple product backlogs currently exist across the planning domain, merging them into a single shared backlog would reduce competing priorities and ensure all teams work from the same strategic view.
Designing Tailwind Career Paths: Creating career progression models that reward breadth and multi-skill growth while adhering to the larger organizational design framework. While functional job families remain fixed within the enterprise structure, roles within teams can be more flexible, enabling multi-skilling and versatility that supports the teams’ end-to-end mandate.
Holding Product-Level Reviews: Moving beyond team-level sprint reviews to product-level demonstrations where all three partial-solution teams showcase integrated progress. With business embedded in the teams, these reviews naturally attract important stakeholders and clients, creating direct feedback loops with the people who use the planning solutions.
The selection and sequencing of Elevating Katas should be driven by the actual constraints the teams encounter in their work. The katas listed above represent a starting point; the real power comes from iterating on them as the organization learns what works in its specific context.
Open Questions
The design process has surfaced a set of important decisions that deserve deliberate attention as the journey progresses. Each one represents a genuine choice point—where the answer will shape the team structure, the governance, and the pace of change.
How much work lies ahead?
The gap between the current TASKS-2/CAPS-2 state and the PART-3 target is real. A detailed change roadmap—with milestones, owners, and review checkpoints beyond the high-level stage gates—is the next planning task.
Is this sustainable mid/long-term?
Mixed business/IT teams with partial-solution mandates are genuinely new in this organization. What governance protects their composition under workload pressure? How do career paths work for business staff embedded in delivery teams over years, not months?
How to embed in ART / SAFe?
PART-3 teams operating within a SAFe ART need a clear model for PI Planning, backlog ownership, and dependency management. The standard SAFe playbook was designed for lower-mandate teams—adapting it and deciding who decides how needs explicit resolution.
How stable will the teams be?
Business staff in delivery teams are particularly vulnerable to reallocation under pressure. What structural agreements—and what management commitment—protect the organizational structure once it is established?
What is Paradigm’s lifecycle and roadmap?
The current platform is at end-of-life, with decommissioning planned as Paradigm matures. The transition timeline—from today’s operational continuity work through Paradigm maturity and legacy retirement—shapes the urgency and sequencing of every design decision.
How does this design scale if Paradigm grows?
A 50–100 person organization operating as three partial-solution teams is manageable. What happens when the solution expands or new domains are added? Building in the design principles for scaling—without defaulting back to the capability-ART structure—is worth naming now.
Conclusion
The Paradigm initiative sits at a rare intersection: a new solution, a deliberate design process, and an unusually aligned leadership environment—all arriving together in one of the most technically and organizationally complex companies on the continent. That combination doesn’t happen often, and it is being met with genuine ambition.
What has struck me most in this engagement is the quality of the shared diagnosis that the design workshops produced. The leaders in the room during R0 did not need to be convinced that the current structure has limitations—they already knew. What Org Topologies provided was a shared vocabulary for naming those limitations precisely, and a map for reasoning about how to address them systematically rather than anecdotally.
The three-stage journey described here—from the current fragmented stack through the R2 consolidation to the optimal Team-of-Teams at PART-3—is a clear direction of travel. It does not ask the organization to abandon what it does well; it asks it to extend its best instincts further than they have been taken before. The cross-functional ambition is already present. The business engagement is already underway. The appetite for speed and autonomy is real. The design work is making those instincts structural.
The open questions are crucial decisions that will shape how the design lands in reality. The Elevating Katas are the specific, repeatable practices that build the organizational muscle the design requires—embracing them is what carries the topology from the map into the team room. The journey ahead is substantial, and the conditions for success are unusually well aligned.
Immediate next steps
To move from design to implementation: complete the R1 design specification, including team scope and initial composition; formalize the governance model for business staff participation; resolve the SAFe integration model for partial-solution mandate teams; and initiate the Ops embedding process in parallel with the first Paradigm delivery sprint.
This experience report presents a personal perspective on an organisational design journey currently in progress, written by the credited consultant. Details have been generalised to preserve confidentiality. The Org Topologies maps reproduced here are working documents from the design process and reflect the state of thinking at the time of writing. Should you have alternative views or additional details about this change story, please do not hesitate to contact Org Topologies and submit your version for publishing.