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.
