top of page

Case Study: Introducing Org Topologies in an Aviation Program

Writer: Kevin RomijnKevin Romijn

Updated: Dec 17, 2024

Make Org Design Sexy Again! Yes, you read that right. We're here to spice up the way you think about frameworks and practices, with a case study that showcases how understanding and adapting to your organizational context isn't just necessary—it's exhilarating.


Introduction

This case study is presented anonymously by two Kevin Romijn and Marloes Naber working on a critical technology program for a major player in the aviation industry. This program is pivotal in developing systems crucial for aviation safety and functionality, divided strategically into two segments: the business section dealing with overarching responsibilities like safety and education, and the technology section focused on developing end-user functionalities. 

 

Organizational Context

Our focus is the technical side of the program, where the organizational structure positions management at the helm, branching out into several projects each led independently. We are particularly concentrating on the teams highlighted in blue. Here’s a quick rundown of the roles involved:

 

  • Architect: Oversees the entire systems architecture.

  • Spec Team: Manages requirements specification.

  • CPO (Chief Product Officer): Heads backlog management.

  • Development Teams (A, B, C): Handle different aspects of development.

  • Test Team: Responsible for verification and validation testing.

  • D Team: Focuses on special function testing aligned with the architect to speed up system development.

  • SIM Team: Develops training simulators, operating independently with some dependencies on testing.

 

Mapping the Current Situation

The Org Topologies map uses two primary axes to assess organizational capabilities and focus, which are essential in adapting to rapidly changing market conditions and optimizing internal processes. We have mapped the current organization during an OT workshop with a representation of the teams and roles as earlier described.

 

We incorporated the concepts of switching costs, adaptivity, transaction costs, and speed into our workshop explanation, laying the groundwork for the following detailed map explanation:

 

  • Horizontal Axis (Completeness of Capabilities): Ranges from single-skill individuals with limited scope to fast-flow units capable of end-to-end delivery with high autonomy. Advancing rightward on this axis correlates with reduced transactional costs, enhancing delivery speed and operational efficiency.

  • Vertical Axis (Scope of Work): Extends from a narrow task focus to a broad whole business focus. Ascending this axis means lower switching costs, allowing teams to shift focus and adapt more easily and cost-effectively to new priorities or changes in the business environment.

 

 

Insights on the Current Situation

During the mapping process, valuable discussions took place. Below is a summary of some insightful comments.

 

  • Separate Technical and Business Programs: Technical teams operate in isolation from teams in the business program. This likely leads to misalignment between business objectives and technical execution.

  • Lack of a Unified Roadmap: The organization lacks a comprehensive roadmap, focusing instead on immediate needs and easily prioritized tasks. This could result in short-term thinking and inefficiencies in resource allocation.

  • Role of CPO and SPEC: The Chief Product Officer (CPO) dictates specifications, which are then executed by SPEC in a project setup. SPEC handles feature-level requirements with good environmental knowledge but is not driven by project management or agile methodologies like Scrum.

  • Team Structure (Teams A, B, C): Teams are multi-skilled and use Scrum, yet roles such as the Scrum Master are not integrated with development roles. There’s no dedicated Product Owner within teams, contributing to a lack of clarity regarding the larger goals. Testing and specification processes are not included within these teams.

  • Separate Testing Team: There is a distinct testing team responsible for validation, which interacts with Scrum teams A, B, and C primarily for testing and automated testing. Communication between these teams is poor, impacting effectiveness.

  • D Team: The D team specializes in creating test scenarios and works closely with the architect to accelerate system development. This team has a specific function that directly supports system enhancements.

  • SIM Team: Operates independently, developing training environments. This team has dependencies on testing outputs but functions separately from the development teams



  

Objective of the Program – Ambition of Change          

The main objective of mapping the current ecosystem was to increase the speed within the program, improve the quality of delivery, and enhance the teams' knowledge level to enable more cross-functional work.

 

What’s next – an Incremental Approach to Adaptability

The current insights inspire us to realize that improvements are possible to achieve quicker and more targeted outcomes. The green blocks on the map represent the new variants and movement on the OT map.

 

Step 1: Transitioning Development Teams to A2

 

  • Roadmap Based on Customer Journey Flow: Create a roadmap that guides development based on the aircraft's lifecycle.  This encourages teams to align their development efforts with the user’s end-to-end experience, which is  one step closer to customer-centricity.

  • Feature Prioritization: Implement a priority matrix to regularly review and adjust feature priorities based on user feedback and business needs. This directly addresses the need for agility in response to the business needs, preventing over-commitment on less impactful features.

  • Clear Definition of Done (DoD): Develop a standardized DoD checklist that includes all necessary steps, from development and testing to documentation and stakeholder approval. It standardizes completion criteria across teams, which is crucial for maintaining quality and uniformity in multi-team environments.

  • Knowledge Sharing on Features: Implement a peer mentoring program where experienced developers share their knowledge on specific features and systems. This intervention promotes an internal culture of learning and collaboration, essential for sustaining innovation and continuous improvement.

  • Visual Management (Obeya Room):Use large boards and digital displays to show project timelines, key metrics, and current impediments in a central location accessible to all team members. The Obeya enhances transparency and accountability.


Step 2: Moving Teams to A3

  • Integrate Spec Team, Test team, Sim Team, and Architect: Reorganize teams to include members from the Spec, Test, Sim, and Architect teams to create cross-functional units. Moving towards a more integrated cross-functional unit setup is key in reducing dependencies and handoffs between specialized groups. It enhances the flow of information and work, reducing cycle times and improving response to feedback.

  • Pilot Project with User Integration (B1): Select one team to include an end-user (e.g., a pilot or maintenance member) to provide real-time feedback and insights. This encourages the continuous learning and experimentation but also increases customer-centricity.

  • Focus roles within the teams: Establishing clear roles with dedicated Scrum masters and Product Owners sharpens accountability and minimizes role ambiguity, streamlining team operations.

 

Step  3: Transitioning the CPO to C0

  • Integrate Business and Technology Programs: Establish a joint leadership team that includes key stakeholders from both business and technology sections to drive the integration. This emphasizes the blending of business and technology strategy to ensure cohesive decision-making and alignment on objectives.

  • CPO as the Driving Force: Create a governance framework that supports the CPO's role in decision-making and ensures alignment across all teams. Position the CPO as a pivotal leader in org strategic direction and, ensuring that product vision is closely tied to business goals again.


Recommendation: Gradual Organizational Transition

Given the program's placement within a traditional, project-based organizational structure, a phased approach to implementing changes is advisable:


  • Manageability and Stability: Large-scale changes can disrupt well-established management and operational systems. Incremental changes allow the organization to adapt without undermining existing management's control over budgets and personnel.

  • Sustained Delivery and Control: Gradual improvements ensure the organization continues to meet project timelines effectively while gradually introducing new tools and processes. This method respects existing governance structures, ensuring that management maintains oversight and accountability.


This step-by-step approach helps embed new practices within the existing framework, enhancing flexibility and efficiency without compromising the organization's operational commitments. Therefore, the teams will initially transition within Level A on the Org Topologies map, focusing on solidifying A-level capabilities before considering a move to Level B. This measured progression ensures that the foundational aspects are robust enough to support the next level's demand



 

Conclusion

By following this structured approach, the company can gradually transition towards a more agile and adaptive organization. This plan aims to improve the speed and quality of feature delivery, ensuring that the company meets the demands of the business and end-users. The integration of systems thinking and Org Topologies principles will help identify and address systemic issues, leading to sustainable and impactful improvements. Through targeted skill development, improved cross-functional collaboration, and effective leadership, this program will enhance its overall agility, delivering higher quality features faster and more efficiently.

 

Workshop participants’ reaction

 

"It's great to be involved. It's clear right away. Even though we thought we were already agile, we see once again how important it is to keep going and how nice the communication with each other is."

 

Kevin and Marloes in action.


 

 This experience report presents a personal view on the change story by the credited writer. Should you have alternative views or additional details about this particular company's change story, please do not hesitate to contact Org Topologies and submit your version for publishing.

 

 

Elevating Katas (addition of December 2024 by Alexey Krivitsky):


This article by Kevin and Marloes provides great examples of what we now call Elevating Katas.

Elevating Katas are introduced as repeatable, structured patterns or routines introduced into an organization’s ways of working that help teams and leaders build new capabilities, improve system-level performance, and “elevate” their overall approach to value delivery.

Elevating Katas Identified in this Case Study:


  1. Roadmap Based on Customer Journeys Routinely aligning development efforts with end-to-end customer experiences. By iteratively refining a customer-centric roadmap, teams continuously close gaps between business goals and technical execution.

  2. Peer Mentoring for Skill and Feature Knowledge Establishing ongoing, internal mentorship routines that break down silos and elevate shared understanding. Over time, this fosters broader skill sets, enabling multi-skilled teams that more effectively deliver complex features.

  3. Unified Definition of Done (DoD) Regularly revisiting and refining a standardized DoD ensures consistency and quality. By embedding this kata, all teams continuously align on clear completion criteria, speeding delivery and improving handoffs.

  4. Integrating Cross-Functional Expertise Into Teams Incrementally merging roles (e.g., spec, test, architect) into development teams. Repeated application of this practice eliminates external dependencies, improves flow, and enhances adaptability to changing requirements.

  5. Pilot End-User Integration Regularly involving actual users or domain experts directly within teams. Over time, this deepens customer empathy, guides product decisions, and ensures solutions better match real-world needs.

  6. Visual Management (Obeya Room) Consistently maintaining a visual, transparent workspace where teams track progress and highlight impediments. This continuous improvement routine builds shared understanding, faster decision-making, and quicker response to issues.


 

 

otp.png
  • Member Community Event: The Future State of Scrum
    Member Community Event: The Future State of Scrum
    04 Apr 2025, 12:00 – 13:30 CEST
    Zoom
    Gunther, a beloved conference speaker, will highlight the three challenges he believes are crucial to move Scrum downfield and overcome the stagnation.
  • Free Introduction to Org Topologies - Online Webinar
    Free Introduction to Org Topologies - Online Webinar
    22 Apr 2025, 18:00 – 19:30 CEST
    Zoom (link provided after registration)
    In this free, online webinar, we will explain the fundamentals of Org Topologies.
  • Munich (DE): Org Topologies™  Practitioner
    Munich (DE): Org Topologies™  Practitioner
    14 May 2025, 09:30 – 15 May 2025, 17:30
    metafinanz, Leopoldstraße 146, 80804 München, Germany
    This two-day practical class on Strategic Org Design for executives, managers, consultants - to master the skills to map, assess, design, and elevate org ecosystems.

Thank you for subscribing!

bottom of page