Southwest Airlines Baker Group Making actions transparent to reduce disruption and delay

Southwest Airlines (SWA), based in Dallas, operates more than 4,100 flights daily to more than 100 destinations. As the nation’s largest carrier in terms of originating domestic passengers boarded, SWA operates a point-to-point network with a fleet consisting entirely of 737s. SWA prides itself on quick turns at the gate from time of arrival to time of departure, and it constantly seeks to improve how it makes decisions that affect the network (for example, to delay or cancel flights, slow down traffic, or close an airport) when the unexpected happens, dramatically increasing on-time performance and transporting more customers to where they need to be, when they need to be there.¹

Seemingly essential to Southwest’s overall success is its nerve center, the Network Operations Control (NOC). NOC is home to two workgroups whose methods and behind-the-scenes innovations many credit for greatly improving the experience of those who fly Southwest—and for giving a sustained boost to the airline’s performance. The Baker workgroup is one. The other is the Field Tech workgroup, a specialized unit of aircraft mechanics who fix what no one else can.

The workgroup: Baker

The Baker workgroup is made up of dispatch superintendents and software developers focused on improving decision-making around unanticipated operational and weather-related events. This workgroup meets our key criteria for a frontline workgroup:

• Size: Baker is composed of four supervisors of dispatch (SoDs), three main software engineers, and two software engineers in support.
• Sustained involvement: The software engineer members of Baker are fully dedicated resources. The workgroup’s four SoDs carry out their regular duties while spending a majority of their time with Baker, developing a tool to support decision-making as well as devising and testing new approaches for handling unanticipated disruptions to the Southwest network.
• Integrated effort: The ongoing design, development, and enhancements to the decision-making tool require the group’s integrated and collective effort. Much of members’ work is interdependent—in particular the analysis and interpretation of trade-offs and impact that feed back into the tool.

Supervisors of dispatch “manage the business operations of the airline” through network decisions. SoDs are the people who balance overall flight flow—canceling flights, shutting down airports, swapping aircraft. In determining how best to get customers home on time, they take into account everything from customer and crew needs to weather to runway arrangement and maintenance. They touch all parts of operations and work closely with the dispatchers, who are the people on the ground responsible, with the pilots, for the safety of the flight.

When Southwest was a small regional airline with a handful of planes and routes, operations were comparatively simple. But with rapid growth, the established process of dispatching and modifying flight plans, and cascading through the other parts of operations (for example, crew scheduling), became complex and time-consuming—developing just one solution for a particular flight path could take hours. As one SoD described the network: Not only were there more planes—there was a lot more momentum, and no one was able to stop on a dime and redirect, a response that had worked well when the airline was small.

A group of SoDs charged with increasing Southwest’s on-time performance (OTP) took it upon themselves to build a tool to make their jobs easier and more effective and to devise new ways to make complex network and routing choices. They named themselves Baker in honor of a late colleague, Mike Baker, who was passionately committed to improving the airline’s routing system.

When the workgroup first formed, its primary focus was on developing a tool that could accelerate SoDs’ ability to address major disruptions more effectively for both passengers and crew. After creating a preliminary version, Baker members split their time between further developing and refining the tool, managing the actual network operations using the tool, and using the results as a basis for reflecting on and refining their collective approach to making trade-offs in large, network events. The humans in the network still must weigh the trade-offs and make the decisions, but the tool can give them visibility into the implications of their decisions. By being intimately involved in the development and use of the tool as well as in real-life, real-time decision-making, the workgroup members have a firsthand perspective on where the program successfully accelerated performance—and where it needed improvement.

The results: On-time performance leap and better outcomes

Thanks perhaps to the workgroup’s efforts to rethink how Southwest handles unanticipated disruptions, the Baker group seems to have helped the airline boost on-time performance (OTP) during extreme winter storms by more than 200 percent, while canceling fewer flights.

This data highlights the airline’s performance in severe weather disruptions—defined as major storms affecting three or more major cities for an extended duration. To measure its efficacy, Southwest looked at performance across three winters over the course of the Baker group’s activities. Winter storm Hercules occurred in 2014, prior to the Baker workgroup shifting to emphasize more proactive decisions; Thor hit in 2015, after the SoDs had adopted a proactive stance and had implemented several of the workgroup’s changes, such as not defaulting to operate all possible flights; and Olympia, in 2016, followed further refinement of the Baker group’s solutions and implementation of the Baker tool.²

Since its formation in 2015, the workgroup has not only improved the airline’s performance during adverse weather conditions—it has helped improve OTP for all Southwest flights by 2.11 percent. This is a significant jump given that airlines normally measure improvement in OTP in tenths of a percentage point. And while many airlines have gamed their OTP numbers by canceling flights, Southwest canceled 900 fewer flights than it had prior to Baker over a similar period of time.³

In addition, the total number of customers delayed by two or more hours decreased by 95 percent over two years once the workgroup’s solutions were fully implemented in 2016.⁴ And when a flight did have to be canceled, the workgroup’s efforts allowed Southwest to give passengers more advanced warning. Prior to the workgroup’s formation, SWA passengers regularly received cancellation alerts two hours or less before departure time. By the end of 2016, passengers were receiving such notifications up to 10 hours in advance,⁵ averting many situations in which passengers arrive at the airport only to learn their flights have been canceled. The more lead time Southwest could offer passengers, the greater the likelihood the airline could seat them on new flights. As a result, the itinerary completion—the rate at which passengers that reach their intended destination—has improved dramatically as well.

OTP, cancellation rate, and passenger itinerary completion are the three measures of success that matter most to these frontline workers. They believe that an impact there could generate both greater customer satisfaction and lower operational costs across the airline, directly affecting both revenue and margins. In addition, the proactive, faster, and more-informed decision-making enabled by the Baker workgroup’s solutions have reduced turnover. As one SoD said, “With three hurricanes in a month, in the past that would have been all hands on deck, 24/7, for weeks to repair the system and get passengers home. With the tool and our approach, it’s a whole different job.”

Practices in play

The Baker workgroup uses five intersecting practices: Commit to a shared outcome, Reflect more to learn faster, Maximize the potential for friction, Prioritize performance, and Frame a powerful question.

Commit to a shared outcome

The Baker workgroup formed around the shared desire to create a tool that would help the SoDs improve on-time performance while also making their jobs easier.

Dealing with disruptions such as snow and strong winds had required highly manual work and hours of coordination. Not only had it been difficult to see the impact of a certain set of decisions until things were already in motion—separating skill from luck after the fact was challenging. As the group gained momentum on the tool, the shared outcome shifted: It was less about the tool itself and more about an ongoing commitment to improving itinerary completion, canceling fewer flights, and having more flights arrive on time. This commitment aligns with Southwest’s long-standing commitment to being passenger-friendly. The workgroup believed that if it could have a significant impact in those two areas, it would improve the experience for both passengers and crew. Having the dispatchers spearhead the creation of the software tool they themselves would use ensured that the outcome sought by developers and users was shared, too.

Reflect more to learn faster

One important practice that the Baker group brought to network operations was that it celebrated exceptions. Until the workgroup was convened, exception handling remained a sort of “shadow activity” within the organization—every SoD had her own way of dealing with network disruptions. Even more frustrating: Disruptions and ad hoc solutions often went unacknowledged because they seemed to provide evidence that the processes in place weren’t working.

As operations expanded and the frequency of disruptions increased, group members had no choice but to confront these exceptions. However, Baker went beyond confronting them—it aimed to adopt a new mind-set about treating disruptions as an important part of the business and changing the culture of the organization to one of making these disruptions and the impact of decisions transparent so that members could learn from them. For instance, with winter storm event Thor, Southwest had moved toward being more proactive, but it still took the airline a painfully long time to execute the decision to shut down an airport and reroute those flights. For Olympia, the Baker group had learned the cost of delayed action and was able to make rerouting and cancellation decisions much faster; not only did it affect passengers less negatively—it affected all operations less negatively, with less pain for employees. The Baker group celebrated such exceptions, seeing them as opportunities and embracing each chance to get better at handling situations members couldn’t fully anticipate.

The workgroup also promoted a more proactive approach to managing the network, requiring a new level of pre-reflection to anticipate the effects on multiple parts of the system. This included bringing in perspectives from outside the workgroup, including those of dispatchers and crew schedulers, to capture the collective experience from previous events, especially for large disruptions.

Measuring the effects of exception handling had been incredibly challenging, but Baker’s tool allowed Southwest to identify patterns, establish trends, and recognize anomalies far more quickly. The tool enabled the workgroup to reflect on the trade-offs before taking action; it also provided new transparency, across the entire network, feeding reflection and discussion with hard numbers, both in the moment and after an event. There are so many different ways to dissect a solution that, even with the tool, there’s rarely a right or wrong answer, but it has allowed SoDs to focus their energy on looking at the trade-offs rather than on manually playing out the decisions in spreadsheets.

For the workgroup members, being both creators and users of their own tool paid extra dividends. They constantly sought feedback from their colleagues—indeed, their colleagues sought them out to give feedback—and the faster they implemented features and enhancements, the better their own work lives became. Discussing the feedback on the tool and prioritizing tool enhancements and fixes have actually served as a vehicle for the workgroup to reflect more broadly on the trade-offs and how to weigh certain variables. The tool revealed some things that members didn’t understand previously—for instance, that cancellations might be less damaging than delays or that they should focus more on “canceling the right flights” rather than just avoiding cancellations. These types of revelations opened the door to revisiting other assumptions they all made about the network.

Where previously SoDs made many decisions on gut instinct and had little way of evaluating the quality of their decisions, the tool provided a rich data input that changed their ability, as individuals and as a group, to reflect on the trade-offs they made. One learning that came from this reflection was that following gut instinct often led to suboptimal decisions.

Maximize the potential for friction

When it came to recruiting members, the workgroup prioritized passion over skill. Not all SoDs were eager to embrace change, but Baker members seemed to have a deep passion to improve the way things worked—and they sought out others with the same mind-set. A key driver of the group’s success was its ability to catalyze and amplify the passion of each of its members.

Importantly, the SoDs who formed the workgroup also recruited members from beyond their own departments, bringing in software developers who could challenge and guide the work as core members. They also continued to leverage the connections they had with all of the operational groups in their traditional SoD roles to bring in needed skills and perspectives as they debated trade-offs and alternatives and developed the tool.

Typically, tools such as the one the Baker group was developing might be built in isolation by a technology department, then rolled out to users who would love it or hate it; the developers would never see it in action or talk with users about their reactions to the tool. What feedback developers get is often limited to short, one-way written comments. By bringing together the diverse perspectives of SoDs and developers, shoulder to shoulder in a room with live feedback from their SoD peers, the Baker group heightened the friction that could help create a better tool. They could all also see what worked and what didn’t in the moment, bolstered by trust and a shared understanding of each other’s jobs. For example, one day the Federal Aviation Administration ordered a noise-restricted approach path for an airport in the Midwest (a request SoDs were accustomed to addressing). Instead of following the traditional, multistep procedure, the SoDs in the Baker group wheeled their chairs over to the software engineers and together created the new approach in a span of a few hours.

Prioritize performance trajectory

The Baker workgroup needed to optimize the network’s performance based on multiple factors. When it came to choosing which factors to prioritize, trade-offs abounded. Members prioritized a trajectory of continuous improvement of the key metrics that represented what was most important to their business: satisfying customers.

As a starting point, members acknowledged that they no longer really knew, in the larger system, how some of their daily trade-offs worked. That was the genesis of the tool, but practically it meant that they would inevitably make mistakes on the way to understanding the interdependencies and making the best decisions for the business. It also acknowledged that they would inevitably suboptimize certain parts of the system or certain metrics, in service of driving improved overall performance. The difference now was that they would have more data to compare trade-offs—and a tool that actually let them test out different solutions.

For example, consider an inbound plane that has just triggered an unexpected maintenance issue. If Southwest delays the next flight to fix the issue, it would result in 260 missed connections for individual customers and cause the crew to time-out one leg sooner, leaving them at different airports than they were scheduled to fly out of on their next shift. If the airline proactively cancels the flight—and the rest of those on that plane’s itinerary—and rebooked passengers on other flights, it would create 20-minute delays for 3,000 customers, but everyone would make it to their destinations. Which decision produces the least bad outcome? Should SWA cancel a flight with five hours’ notice, or use those five hours to try to increase the odds of giving customers what they expected? One thing the Baker group has learned is that the airline now has so many flights connecting throughout the system that sometimes canceling a handful of flights actually displaces fewer passengers than running a flight late.

This web of trade-offs was one that dispatch superintendents had navigated for years, but most of those trade-offs weren’t explicit or couldn’t be known with certainty. Previously, the airline had defaulted to letting all flights run. Canceling a fully booked flight just wasn’t done because SoDs assumed that canceling would clearly have the most negative impact on customers and the system. And given the complexity, just propagating a cancellation through dispatch, customer service, and crew schedules was overwhelming. Now, the Baker group has seen how making proactive cancellations or reroutings can have a positive impact not just on getting customers to their destinations but on other operating metrics as well.

The workgroup, and the tool, made more visible the implied trade-offs and the implications of their actions across the airline. Now SoDs could track how one cancellation’s effects cascaded across the network, affecting passenger connections, crew, and even scheduled maintenance. Previously, dispatchers would rely on gut instinct to make such calls, but they couldn’t inform their instincts with data. The Baker group changed that. Today, every Southwest dispatcher decision still has its trade-offs, but now all involved know what the trade-offs are. SoDs also have more informed discussions with other departments, especially in major weather events, where they can focus on the impact for the most important performance metrics for the network rather than for each department.

The workgroup also prioritized trajectory in the development of the tool itself, making trade-offs in the use of resources to focus on what would help the group make an impact faster on the metrics of on-time performance and flight cancellations. Rather than build a sleek interface that could impress upper management, they built a tool aimed at helping SoDs in the field. Baker members continuously prioritize development of changes that SoDs believe will improve their ability to run the network and have an impact on the metrics that matter to keep moving performance up the curve. At the same time, they’ve recognized that part of improving the airline’s performance is getting everyone to use the tool. While it hasn’t displaced the overall performance objective, Baker now prioritizes enhancements to the tool that can make it simpler and easier to use—plenty of defaults and a cleaner interface—so that all of the SoDs are using it more often, not just during complex weather disruptions. This has had an impact on the trajectory of adoption: Each new enhancement gets someone excited, often someone who wasn’t previously. According to group members, adoption of the tool rose 200 percent after one recent release.

Frame a powerful question

This group was formed when a few SoDs asked themselves a question their colleague had asked five years earlier: How can we use technology to see the impact of our decisions and make better ones?

It came from the recognition that what worked for a regional airline—relying on gut instinct, prior experience, and manual calculations and updates, operating all possible flights—was insufficient for a major carrier. Southwest had added more planes, routes, crews, and stations, but the way in which dispatchers approached network disruption hadn’t caught up. Meanwhile, they were working harder than ever.

An SoD colleague, the late Mike Baker, had asked a similar question—he was just a little ahead of his time. He was convinced that there had to be a better way to leverage the dispatchers’ years of experience, to learn from their past decisions, and make smarter routing decisions in the future. But without access to real-time data for decision analytics, the tool he envisioned was never operationalized.

Fast-forward five years. Now with access to abundant system-wide data, the powerful question for the SoDs was: How could they honor Mike Baker’s legacy to make smarter routing choices and make a complicated job a whole lot easier? They formed a workgroup committed to addressing the very question that he had posed and named it in his honor. Baker is now mentioned hundreds of times a day throughout the organization, and his passion for championing smarter routing decisions will live on throughout the next generation of SoDs. As one group member said, “When I first heard this idea, I thought it was science fiction—there was no way we could capture all of our knowledge, experience, and day-to-day decisions in a tool and put hard numbers to them and make us all better. Now we’re on the brink of completely changing the game for airline network operations. As we make progress, it opens our eyes to what is possible.”