How to Enable Ambidexterity in Safety-Critical Software Development

Overview: In a competitive environment, continually improving new products and services requires new knowledge and novel solutions. Managing projects also requires the careful control of resources for effective delivery. Ambidexterity, the simultaneous achievement of novelty through exploration and efficiency through exploitation, is challenging to achieve in practice. The ways in which companies can achieve ambidexterity are context dependent. It is especially hard to promote new and uncertain concepts in situations where lives are at stake. This article reports on a case study of a safety-critical IT development project that successfully achieved ambidexterity. Leadership behaviors that support ambidexterity in this setting are critical. We highlight four leadership behaviors key to developing an environment where creative solutions can flourish.

competitors are much more likely to succeed (Knudsen et al. 2023).This need for innovation is also present in safety-critical settings, which present special challenges (Milosevic, Bass, and Combs 2018).Cost, performance, and delivery time must be satisfied; the fact that failure in use could have catastrophic consequences adds pressure.Flexibility, creativity, and the embracing of ambiguity may seem to be at odds with the needs of safety-critical system development, where a more structured, controlled, and "lower risk" approach might be expected (Heeager and Nielsen 2018).In this article, we show how a safety-critical IT development project-specifically, air traffic management software-successfully achieved ambidexterity in its work, balancing the conflicting goals of using and building on existing knowledge (exploitation), while also implementing new solutions (exploration) (March 1991).Our analysis reveals specific leadership responses that can enable ambidexterity by providing project direction alongside an environment in which creative solutions can flourish.
literature review Duncan (1976) coined the term "ambidextrous organization" to describe the achievement of both efficiency and novelty, or repeatability and innovation.Ambidexterity is paradoxical, given the conflicting nature and differing demands of exploitation and exploration (Cunha, Bednarek, and Smith 2019;Gregory et al. 2015;Smith 2017;Wang and Rafiq 2009).Exploitation and exploration rely on different aims, methods, and approaches: behavior that drives efficiency prevents innovation, and behavior that encourages novelty reduces reliability and repeatability.In a competitive setting, firms must accommodate both of these requirements if they are to remain in business for the long term (O'Reilly and Tushman 2008).
Scholars have explored the concept of organizational ambidexterity extensively (Birkinshaw and Gupta 2013;Raisch et al. 2009) as they seek to understand the practicalities of ensuring effective exploration and exploitation.Researchers and practitioners recognize mechanisms that can enable ambidexterity: structural, which refers to separating exploitative and exploratory units, such as the R&D team and the manufacturing function (O'Reilly and Tushman 2004); temporal, which are defined time periods of exploitation and exploration (Tushman and O'Reilly 1996); and contextual, which refers to individual autonomy in task-dependent choice (Birkinshaw and Gibson 2004).
Although predominantly considered at the organizational level, ambidexterity is well-established within the project context (Petro et al. 2019) and researchers have studied it at the individual and project level (Aubry and Lièvre 2010; Turner, Maylor, and Swart 2015).Extensive research reveals how projects incorporate ambidexterity (Pellegrinelli, Murray-Webster, and Turner 2015;Sailer 2019) by drawing on organizational processes and participant expertise both in task completion and in overcoming unexpected challenges in a complex environment (Turner, Aitken, and Bozarth 2018).
Despite extensive conceptual and organizational-level articles published on ambidexterity, managing it in practice is challenging.Different settings require different approaches to achieve an appropriate balance between exploitation and exploration (Andriopoulos and Lewis 2009; Gregory et al. 2015;Wang and Rafiq 2009).

ambidexterity in Safety-critical Settings
The added layer of difficulty inherent in safety-critical environments (Reiman et al. 2015)-since they require a high level of reliability to protect human lives and minimize adverse consequences-potentially discourages exploratory activities.These circumstances therefore present a strong tension between the primary and immediate need for safety and the longer-term strategic need for innovation.Safety-critical IT contexts-where systems have the potential to cause harm or loss of life-include health care (Martin et al. 2019), industrial control systems (Zhang et al. 2022), automotive (Myklebust, Stålhane, and Hanssen 2020), aerospace (Baron and Louis 2021), and nuclear (Merk et al. 2018), among others.In a safety-critical setting, the tension between exploration and exploitation gets magnified since exploration increases the number of ideas, including bad ideas (O'Reilly and Tushman 2013).It is especially hard to promote new and uncertain concepts when lives are at stake.Safety-critical contexts often involve evolving technologies, changing regulations (Griffin, Cordery, and Soo 2016;Saunders 2015), and emerging risks (Heeager and Nielsen 2018).Few studies are investigating the particular role of ambidexterity in a safety-critical setting-in particular there seems to be a lack of empirical insight.Researchers have proposed ambidexterity as a structural objective that managers can apply in safety-critical software development (Vinekar, Slinkman, and Nerur 2006).Ambidexterity is "one of the key paradoxes in high reliability projects" (Saunders 2015, p. 30), and a challenge that requires a flexible approach in projects that have uncertainty and ambiguity.Researchers have shown that ambidexterity is a key element enabling dynamic change in core safety systems and identified the need for leader ambidexterity to provide an integrated vision that allows for competing goals (Griffin, Cordery, and Soo 2016).Rosing, Frese, and Bausch (2011) have presented ambidextrous leadership as an effective way to manage the conflicting demands of innovation by opening and closing behaviors.Another proposition suggests that organizational ambidexterity enables major leaps forward in safety-critical settings by enabling a "flex between exploitation and exploration" (Gotcheva, Watts, and Oedewald 2013, p. 94).
How, though, do we understand the practices that support ambidexterity? Turner et al. (2016) identified five key actions managers of IT projects undertook that helped attain both exploitation and exploration (Table 1).Swart et al. (2019) validated these actions in a multi-level study.Those actions, however, were derived from "waterfall" (more linear) projects and structures.Only limited research exists regarding how to enable ambidexterity in a safety-critical setting, and much of it is conceptual, so the best way to apply these actions directly in a new context is unclear.
While the literature highlights the importance of the role of leadership in safety-critical settings, the topic is underexplored.Our study focused on this question: Is ambidexterity evident in a safety-critical IT development project, and if so, how do leaders support it?

Method
We used the case study method (Eisenhardt 1989) to investigate "a contemporary phenomenon in depth and within

Role expansion
Manager takes clear ownership of a problem, doing "more" of their tasks until it is resolved Tone setting Manager sets the exploratory/ exploitative ethos for the project its real-life context" (Yin 2009, p. 18), noting that a single, interesting case can be persuasive (Siggelkow 2007).This approach is also appropriate for an exploratory research question (Yin 2009).Our case study organization develops and tests safety-critical air traffic management software.We use the pseudonym ATM-Soft to ensure anonymity.Air traffic management is highly regulated, and not an area one would consider likely to embrace radical changes in ways of working, or trialing uncertain, risky approaches.The development team comprised several different specialtiessoftware coders, mathematicians, and air traffic control experts-each with limited knowledge of each other's domain expertise.
The software development team used Scrum (Schwaber and Sutherland 2020), an Agile development method (Bianchi, Marzi, and Dabic 2022).Scrum uses short (normally 1-4 weeks) "sprints" to implement the next phase of design work, after which the results are reviewed by the development team.Scrums are a highly "social" approach, with daily stand-up meetings to coordinate activities and share progress.
We interviewed 19 R&D managers and engineers at ATM-Soft.Each interview lasted an average of one hour.We also observed four Scrum meetings, which lasted from 7 to 52 minutes.We recorded and fully transcribed all interviews and meetings and coded them using the NVivo software package.
Our data analysis consisted of three stages: 1) we coded the data for evidence of ambidexterity by looking separately for and selecting instances of exploration and exploitation; 2) we coded for existing managerial actions thought to support ambidexterity; and 3) we used inductive (Gioia) coding to understand how R&D managers and engineers managed ambidexterity in this safety-critical setting.
We used Turner et al.'s (2016) managerial actions framework, which enables ambidexterity, and initially coded our data for evidence of those actions.We subsequently used the Gioia method (Gioia, Corley, and Hamilton 2013) to examine the raw data and identify the key concepts, which we then grouped into higher-level second-order themes.Finally, we combined these themes into a small number of aggregate dimensions.

results
We present the results of the three phases of investigation: the evidence for ambidexterity, the relevance of the managerial actions framework, and the findings from the inductive coding.

Evidence of Ambidexterity
We identified exploitation and exploration clearly.Agile requires expertise in knowing what to do and how to do it but incorporates flexibility and problem-solving as part of the development.Interviewee 3 said, "Generally you are up against a fairly tight timescale, so actually doing it in a way that you know gives you results is normally the safest option."Interviewee 1 stated, "I want a novel solution, so I will think about doing something maybe that's outside my comfort zone and take a bit of risk. . . .It's a creative kind of process that I go through at the beginning of a project." We identified more than 100 supporting codes, which revealed that ambidexterity was clearly evident in this ostensibly risk-averse context.Interestingly, we found slightly more codes for exploration than exploitation, even in a safety-critical development environment.We answered the first part of our research question-namely, evidence of ambidexterity in a safety-critical IT environment.

Enabling Ambidexterity: Applying the Managerial Actions Framework
Using the managerial actions framework-originally derived from more linear (predominantly "waterfall") IT projectswe found that some of the five actions were highly relevant, whereas others operated quite differently in this Agile project setting.We discuss each.
Buffering-We identified buffering 10 times, but in this case, managers acted more as enablers rather than as barriers.We also identified ring-fencing of resources to support more effective working, and the "Scrum Master" was highlighted as someone who coordinated and supported the team.We associated the product owner more with words such as "filter" to enable smooth working amongst customers and teams.Prioritization was a more prevalent emergent theme throughout the data, and there was an emphasis on the clarity of what needed to be done next, as well as a shared understanding of the wider goals.As Interviewee 13 noted, "I think it does focus you, it does particularly on prioritization . . .right at the beginning rather than saying, 'This is what we want.We want all of it please,' and then towards the end panicking because we physically can't do it.It sets more of a realistic target on what we're actually going to get." Gap-filling-We found that gap-filling, where managers do extra tasks to fill gaps created during exploration, was noticeably absent from the data.The working relationships between staff and the frequent communication created an environment where only rarely were issues not addressed and required a manager's attention.This finding reflects the nature of Scrum versus waterfall and is in itself interesting.Instead of gap-filling, potential problems are caught through what we characterized as detail orientation amongst the staff.Detail orientation was a common theme, with a group rather than an individual approach to ensuring is ambidexterity evident in a safetycritical it development project, and if so, how do leaders support it?that important priorities were identified and resolved, and that non-important work was deprioritized.Interviewee 12 remarked, "There's much more, I suppose, productive interaction with colleagues in the sense that you ' Integration-This theme emerged strongly within the Scrum operation.We coded 155 instances of integration, which is bringing knowledge together as a coherent whole.The group shared knowledge through communication and collaboration; over time group members gained knowledge of others' expertise, and trust grew through shared product development.Interviewee 2 shared, "The whole team gets together so everyone gets an update of what everyone else is doing, so we're all aware of how the project is progressing from everyone's point of view.That kind of knits the team together, I think."According to Interviewee 9, "We do concept design workshops . . .bring together the pure operational perspective of the guys who do air traffic control as their day job together with engineering knowledge of all the guys who work on the software . . .trying to push the concepts and bring some understanding of those sides." Role expansion-We saw very limited role expansionrather, the team took collaborative ownership, which appears to be closely linked to integration.Again, the team functioned to ensure that the priority tasks got completed-in line with the principles of a Scrum approach-and it would not generally fall on individuals to do "more" to achieve targets.As Interviewee 10 noted, "It forces us to collaborate.It forces us to communicate with each other and to accept that someone else is doing one thing, and bite off a bit for myself and then add those interfaces." Tone setting-We found managers were not setting the tone to favor either an exploitative or exploratory approach, since both appeared in the work.Instead, the flexible and collaborative approach both in the managerial and working style supported the adaptability necessary for exploratory (and thus uncertain) work.Similarly, the Scrum meetings facilitated face-to-face contact and discussions, enabling shared understanding of the task complexity.Interviewee 3 explained, "I think that becomes the norm in that there's this understanding from both sides.There's an understanding from the developer that the R&D person hasn't necessarily got all the answers of what they wanted to do, and what they're asking you to do, they may change their mind, the requirements may change.But, similarly, from the R&D person's point of view . . . it may take longer than expected." The interviewees emphasized the importance of psychological safety (Edmondson and Lei 2014;Liu and Keller 2021;McCausland 2023;Thorgren and Caiman 2019) for all those involved.Psychological safety was a new and significant theme that emerged from the analysis.Within the data, we observed multiple instances where team members identified more effective, unanticipated solutions and ways of working.For example, air traffic controllers could clarify what they needed, which made the software more useable, and the software team showed what they could implement, which opened up new options for the controllers.Given the emergent nature of air traffic controllers' work, relying on documented requirements would limit such innovation but might be deemed "safer."All parties recognized and acknowledged the benefits of this way of working.
Coding in this case differed quite markedly from previous studies, as indicated by the lack of consistency with the actions.This inconsistency with Turner et al.'s (2016) managerial actions framework led to a final inductive approach to develop a more grounded understanding.

Enabling Ambidexterity: Applying Inductive Coding
We present the results of our analysis based on the Gioia method (Gioia, Corley, and Hamilton 2013) (Figure 1), including the distinction between the exploitative and exploratory characteristics of each aspect.This inductive analysis has parallels with previous research, with some notable differences.The existing framework shows the actions managers undertook.Our new framework-which we dub "PESP" because it encompasses prioritization, expertise, systems, and psychological safety-shows that the emphasis is on the delivery of work by team members, and the managerial role entails maintaining a supportive environment and ensuring that the individual work is integrated effectively.Interviewee 10 (an R&D manager) commented, "When they're on task they are very productive, and they're all personally very, very dedicated engineers.It's like holding the reigns of a racehorse rather than whipping oarsmen, if you like [laughter]." Building on the racehorse analogy, this Agile way of working may be a significant shift for some managers if their background has been with waterfall projects.The managerial role is more about allowing the team the freedom to use their expertise to deliver against the priorities and drawing on their judgment to accommodate the uncertainty of exploration.The emphasis for the manager is on leading and enabling the team and supporting a context for both exploitation and exploration.
We note that the second-order themes represent tensions within the operating environment.These exploitative and Psychological safety was a new and significant theme that emerged from the analysis.
exploratory requirements are all valuable and aid in project delivery yet require reconciliation, which is a continual challenge.

Discussion
We first sought evidence of ambidexterity in a safety-critical development project and then to understand the ways in which ambidexterity is supported.Our case study coding found strong evidence for ambidexterity, with exploitative and exploratory elements interwoven and supporting each other in enabling project delivery.Although previously demonstrated in other project environments (Petro et al. 2019), our data showed the prevalence of exploitation and exploration in a safety-critical IT development, and the details of the enactment of ambidexterity.This may be counter to the expectations of many, since Agile and exploratory working might be considered as the antithesis of delivering "safe" outcomes (Heeager and Nielsen 2018).However, ATM-Soft found Agile and exploratory working to be highly successful and has no intention of going back to its previous waterfall approach.It was not obvious before the study that this should be the case, but because of the complexity of the work and the number of separate knowledge domains to be integrated, pre-planning for every eventuality is not realistic (Bianchi, Marzi, and Dabic 2022).The team realized that to make sure everything is picked up and no issues are missed, supporting exploration to accommodate such emergence is central to project success.This is enacted through extensive informal and formal communication to support task prioritization, knowledge usage, integration, and problem-solving, in a supportive environment.
A key to this was the move to a system solution.Exploration relied on collaborative ownership of the tasks because changes in one knowledge domain affected the others in unknown ways.The team, having a list of tasks and a clear sense of their priority, were able to flex the schedule-through the use of Agile practices-to allow time for both creative discovery and to meet their delivery targets.In this team there was a clear mandate to deliver novelty, supporting the idea of psychological safety by explicitly allowing new ideas and innovations to be tried even where that might threaten the deadline and mean reworking other tasks.

Managerial implications
What does this mean for managers?The aggregate dimensions shown are more directed to the domain of project leadership than to that of day-to-day management.This emphasis may be subtle, but it is important.We use these and the wider findings from the case to generate the key takeaways from this study (Table 2).the manager's emphasis is on leading and enabling the team and supporting a context for both exploitation and exploration.These leadership responses highlight how the expertise of team members is a necessary but not always sufficient requirement for success.Leaders need to ensure that the team's needs are supported in their work, both in terms of the direction-the "scaffolding" of the project-but also in creating an environment in which creative solutions can flourish, even if some are imperfect initially.
What is the implication for managers and leaders who do not necessarily work in safety-critical environments, or use Agile?We believe the ambidexterity perspective is useful for reflection and discussion.Asking "How good are we at exploitation?" addresses the capability to deal with complicated projects in a robust and efficient way.Asking "How good are we at exploration?" addresses the capability to innovate, deal with uncertainty, and forge new paths.How do we do it, what have we got in place, and what could we do better?Different pieces of work will require a different balance, but articulating the both/and approach can drive valuable conversations in teams and trigger reflection on how to lead more effectively.We have used this approach with executive master's classes as well as in executive education teaching, and managers report that it is a beneficial way of operationalizing the sometimes rather obtuse ideas of ambidexterity into tangible business practices that can drive superior outcomes that had not previously been envisaged.

conclusion
This study investigated the enactment of ambidexterity in air traffic management software development.Although we cannot definitively say that the findings are directly applicable to other safety-critical applications, we believe they offer broad guidance and food for thought for managers across all project types.Regardless of the project process being followed, prioritizing and communicating the key aspects of the work, supporting the expertise within your team, encouraging collaboration and knowledge sharing, and facilitating psychological safety are important activities.Focusing on these leadership behaviors will likely not only improve project outcomes, but also enhance employee engagement and satisfaction.Given the challenges of project working, these are positive actions that not only support ambidexterity but should offer valuable benefits to the wider stakeholder community in terms of short-term project performance and longer-term benefits.
Due to the nature of this research, participants of this study did not agree for their data to be shared publicly, so supporting data are not available.

Disclosure Statement
No potential conflict of interest was reported by the author(s).Challenge 1: Prioritization It is important to balance both the short-term and long-term priorities.This involves ensuring the long-term "big picture" objectives of the work are clear to all so that the final goal is shared, while also communicating and enabling short-term deliveries in line with project and customer expectations.
Challenge 2: Supporting expertise and detail orientation Viewing the work from "above" enables the team to attend to the details in line with their expertise but remain guided by the leader.It is akin to conducting the orchestra, where the conductor's role is to produce an incredible symphony and create the coherent whole but not to play each instrument.
Challenge 3: Synthesizing a system solution This requires enabling integration and collaborative ownership to deliver the project solution.It is supported by formal and informal knowledge-sharing between individuals and disciplines to enable shared understanding of others' work and a greater comprehension of system-level issues.By encouraging the use of others' expertise, a superior solution is more likely to be obtained than would otherwise be the case.
Challenge 4: Facilitating psychological safety Ensuring team members can speak up to discuss new ideas or challenges without fear and without negative consequences is essential in the pursuit of new ideas.

TABLE 1 .
Managerial re sharing what you've done in terms of how you go about your tasks, what you've achieved.If you feel that you need support or you need to bounce things off someone, you just get on and do that and often you can resolve things quite quickly, and probably more quickly than you would have just trying to self-solve." Project Management Journal 41(3): 32-44.doi: 10.1002/pmj.20183.Baron, C, and Louis, V. 2021.Towards a continuous certification of safety-critical avionics software.Computers in Industry 125:103382.doi: 10.1016/j.compind.2020.103382Bianchi, M., Marzi, G., and Dabic, M. 2022.Guest editorial: Agile beyond software-In search of flexibility in a wide range of innovation projects and industries.IEEE Transactions on Engineering Management 69(6): 3454-3458.doi: 10.1109/ TEM.2022.3206408Birkinshaw, J., and Gibson, C. B. 2004.The antecedents, consequences, and mediating role of organizational ambidexterity.Academy of Management Journal 47(2): 209-226.https:// journals.aom.org/doi/abs/10.5465/20159573Birkinshaw, J., and Gupta, K. 2013.Clarifying the distinctive contribution of ambidexterity to the field of organization studies.Academy of Management Perspectives 27(4): 287-298.doi: 10.5465/amp.2012.0167