For a company that does so many things right—and yes, I am a staunch Southwest Airlines fan, based on personal experience with numerous domestic airlines—they really messed up over the holidays, as we all know by now.
It turns out their dependency on legacy systems (and the logic behind them) really hurt them. They ended up canceling more than 16,000 flights because of the massive winter storm that affected most of the United States. According to an article in Gizmodo, the airline was responsible for 84% of the canceled flights within or out of the U.S. on Tuesday, December 29. The other airlines had recovered much faster.
There’s a big lesson here. Given how many company managers are making the same legacy system mistake, I’m a little surprised this type of disaster doesn’t happen more often. Of course, it depends on what you’re selling. Most companies are not as “exposed” as an airline that moves thousands of people and their luggage across the country every day.
The dependency on legacy systems is the elephant in the room in the IT world, and it deserves its own name. I figure “Southwest Syndrome” will serve, although I suggest it with a heavy heart. I have had many successful experiences flying Southwest.
What is the “Southwest Syndrome”?
It is the dependency on a system that worked perfectly well for a long time, but is not as agile as it should be or could be. It is not only about legacy applications, but legacy methods and strategies as well; all business systems depend on certain assumptions, and those assumptions can be disastrous.
I was talking to a client of ours about this the other day, the CEO of Applied Visions, Frank Zinghini, because his company helps people make the shift from legacy to the more modern systems.
“In the case of Southwest, the way they kept track of the location of their flight crews was by the flights they were taking,” he says. “During normal operations, if a flight got canceled, Southwest relied on manual processes and phone calls to deal with these exceptions. But when the situation shifted into ‘mass cancelation’ mode, their manual processes just couldn’t keep up.”
It has also been widely reported that the Southwest union and staff had been raising this issue for some time, including in their contract negotiations. The company was “still using 1990s technology to power its operations in 2022.”
There are numerous places to read about what went wrong, and more details will surely be forthcoming. What I want to focus on here is what you need to do if you are still running even a portion of your company on legacy systems.
What you need to know about your own systems
First, let’s define a “legacy” system. These days, that mostly means that you are not running in the cloud. It could be anything from an old, non-cloud database that you’re still using as your main customer relationship management (CRM) system; an outdated ERP system that is behind all of your ordering, inventory, and financials related to manufacturing; or a scheduling system that ran out of steam years ago but you’ve never bothered to update it.
Hopefully you know which systems I’m talking about in your organization. Or, put another way, you should know which systems I’m talking about in your organization. The more common situation is that top managers don’t know about the dangers lurking deep in their IT infrastructure.
“The role of the IT team is to keep the systems running,” says Zinghini. “It is the responsibility of the Chief Information Officer to make sure that the systems currently installed are solving the right problem.”
These legacy systems tend to linger in the background, chugging away, until one day something goes terribly wrong. Your IT manager will tell you that it’s broken and no one is around (or alive) anymore who knows how to fix it.
This leads to rushing into an alternative, which is never a good idea with IT systems. Rushing costs much more than moving carefully, not only in terms of cost, but because rushing can lead to some bad decisions that will cause yet another Big IT Mess.
There are several other characteristics of IT that come into play here. There’s never any shortage of IT work to do, while at the same time there is always a shortage of good people to do it. And there is a ridiculously small number of IT professionals who are both good at thinking through the process and business issues as well as the programming and technology issues.
The main Achilles heel that we can see in the case of Southwest is that when they couldn’t tell where their staff members were, they were faced with a massive calling effort, even as their staff members were trying like crazy to call in and say where they were, so they could work. Apparently there were people who could have worked, but they couldn’t get through to inform Southwest of their location or availability.
This is a business logic problem. In a perfect IT world, Southwest would have scrapped this method of scheduling and locating some time ago, and would have had a way for their workers to interact with the system via a cloud-based phone app.
One of the inherent benefits of cloud-based infrastructure is its scalability. Part of your work as a top manager is to keep asking “what ifs”—as in, what if there is a nationwide storm and we have so many cancellations that we can’t tell where our staff is? What is the automatic backup for that situation? Is the current system capable of a massive increase in activity? Do we have a tech-advanced way for our staff to inform the system and receive scheduling updates from the system?
Is your head in IT sand?
I’ve been in the tech industry since before PCs became mainstream. I’ve watched (and participated) as entire industries have become automated, and as the cloud emerged as the (current) IT infrastructure platform.
Some business owners have made it their business to keep up with tech as it has evolved, even assigning one person (as we have in my own company) to be their “app whisperer,” because they know that their ability to remain competitive and customer-pleasing is only as good as the applications they’re using.
Unfortunately, this is not the norm. Our clients, for example, tend to be managers and owners who have built good, solid companies but who are slipping behind when it comes to digital marketing. Zinghini at AVI has found the same, but he tends to focus on updating the underlying IT infrastructure.
“I’m not very technical,” a business owner will tell me. My response is that we all need to be technical now. No one running or owning a business can afford to ignore technology or be passively involved. Again, your business is only as good as your applications, and you need to be good at managing their selection, use, and retirement.
Not only do you need to depend on your tech people to educate you constantly, but you have to do your own research as well, because tech people are almost always biased. They have so much to learn and master, are so understaffed, and are so responsible for the successful running and security of the company’s systems, that they live in a very cautionary environment.
“If it ain’t broke, don’t fix it” is the first rule. “I would rather work with what I know than put the company at risk by changing to something I’m less familiar with” is the second rule. Making changes can be disruptive, to say the least, so they are reluctant to introduce new tech to your IT infrastructure.
And, as I mentioned, programmers are much better at writing code or integrating disparate systems than they are seeing the bigger business picture.
Business owners and managers need to keep thinking about the way the company is using tech to serve customers and manage all the logistics of the business, and they need to be constantly asking questions.
Anything less is asking for trouble.
How to avoid the Southwest Syndrome
Action #1: Conduct a System Audit.
First, you need an audit of your IT environment, preferably by an unbiased outside company (such as Applied Visions). You need a list of all the applications your company is running on, a diagram showing how they all interact, and the age and “brittleness” of those systems. I’d rank them on a scale of 1 – 10 based on various factors:
- Scalability—Can this application handle a sudden surge in usage?
- Redundancy—What happens when this application goes down? What is the backup?
- Internal staff expertise—How many people on our staff are familiar with this?
- Programmer availability—Is this an obscure system or technology that hardly anyone works with anymore, or a very common system that a lot of techs work with and understand?
- Ease of integration—The cloud is really just a bunch of applications that run on servers and are interconnected/integrated with other applications. How easy is it for your applications to exchange data with other applications?
- Cost—There are some really popular applications—Salesforce comes to mind—that are, in reality, a pain to integrate and maintain. Surprisingly, in the IT world, popularity doesn’t always mean that the application is the best one out there. I’ve seen countless “superior” applications fall by the wayside because they failed to market themselves successfully. It’s a sad fact of IT life, and one of the reasons I opened a digital agency.
- Proactivity—Do you have an app whisperer who is constantly checking on the latest tech and reporting back to you about it? Are you also devoting part of your time to learning what people are using in your business? Our “thirsty horse” business owner clients are.
- Universality—This ties in with programmer availability, but does need to be mentioned separately. As much as you can, it is best to stick with the more commonly accepted programs to ensure you are not falling into another “obscure application” trap.
- Efficiency of effort—When we look at what companies are doing with their systems, day to day, we often see duplication of effort. Instead of “enter once, populate everywhere,” your internal users may be using 10 different applications, only half of which talk to each other. People get used to entering the same data more than once in various applications, but it’s a ridiculous cash drain on your operations. Which brings us to action #2.
Action #2: Interview your users
Part of your audit should include interviewing your users. How do they do their work? Which applications do they use? How many times do they end up entering the same data twice? What challenges do they run into as they use the systems? How do they think they could be improved?
In our company, we use one cloud-based program, Avaza, for creating and sending estimates, managing projects, and creating and sending invoices. It is incredibly efficient; you only have to enter the client company information once, which can then be selected when creating those estimates, projects, and invoices. You can create an estimate using predefined roles and descriptions.
The estimate can then be turned into tasks with only a few clicks. Then those projects and the underlying tasks can be turned into invoices, again, with only a few clicks.
We kissed a lot of frogs before we found Avaza, but the effort was worth it. It is one of the best applications I have ever used, and it is a daily pleasure for the team to use it.
Action #3: Develop a plan of action and start chipping away at it
Whoever helps you create the audit should also be able to recommend the best next steps.
Start with a full list of what the application needs to be able to do, the applications it interacts with, what data is exchanged between systems and how often it needs to be exchanged (instantly, daily, weekly, etc.). Diagram the application and its dependencies.
As a manager, your job is to keep asking questions until you are satisfied that the project will go smoothly. Here are some good examples:
- What are the applications that can replace the legacy application?
- Will it be a one-for-one replacement (most likely not!), and what will have to be done to make sure the new application either does the same job better or does more than one job better, allowing us to reduce the number of applications we’re relying on?
- Did we check the usual application review sites, such as Capterra and G2?
- Have we interviewed other people who have bought the new application and gotten it up and running? What were their challenges?
- Who can help us get it up and running, how long will it take, and how much will it cost?
- Can it be done in stages? (Always a good idea.)
- How easy/difficult will it be to move the data from the legacy application to the new one?
- Can we make a full backup of the legacy system? How will we test to make sure all the information made it in, and is usable, in case there is a problem with the switch over?
- Is there a new and better way to look at the role that the legacy system plays, what we’re trying to accomplish, and how we might best accomplish it?
- How will we be able to make the switch without harming our business and systems?
- How stable/reliable is the vendor who will help us with the switch? (You don’t want the task to get stalled mid-stream—unfortunately a common occurrence.)
- Are there any show-stoppers? Is there a function that we absolutely need that the new system can’t provide? Is there an integration problem?
Action #3: Know what is out there and keep improving your IT
It’s definitely not common practice for IT teams to be constantly searching for better ways to automate their companies, for all the reasons we mentioned above. But the best companies are doing just that. They are constantly improving.
Amazon is a good example of a company that does this. As most of us have experienced as Amazon consumers, there are dozens of ways Amazon has made it easier for people to make a good buying decision. This is one of the main reasons that Amazon is so successful.
I’ve said before—and I’ll say now—that they were the first tech company I’d ever seen that made it their first priority to build a customer-friendly IT infrastructure. Their systems were their product; the fact that they were selling books was just a sideshow. Most other companies start with a product or service idea, not an infrastructure.
Just think of how many ways Amazon informs the buying decision, including what other people looked at, reviews with pictures, questions answered by other users, comparisons with similar products, and on and on. Someone in that company is always thinking, “how can we make it easier for people to buy from us?” No wonder Bezos is one of the world’s richest. Proof that “making it easy for your customers to buy” is a surefire way to sell more.
When you look at your systems from the standpoint of what you, your team, your partners and your customers are trying to accomplish, and do everything in your power to make that easier, your IT systems become a revenue-producing enabler.
This is a good time to say how much more your team, partners, and customers will enjoy doing business with you if your IT systems make everything easier for them. Southwest Airlines found that out the hard way, not only this Christmas season, but apparently a few times earlier this year.
It’s not enough to hire great people, and create a customer-friendly culture, as Southwest has done. Your people need great tools to help them do great work. Today that means up-to-date cloud applications smoothly sharing data, someone on your team constantly looking for better applications, and the regular removal of creaky old systems just waiting to wreak havoc with your company’s reputation.