Kill Your Zombie Software

Simple Organizational Principles to Save Your Company

I have worked for and consulted with numerous tech companies that have buried themselves with perpetual development. They constantly build new features and products to stay ahead, and more code always seems to be the answer.

While the hunger for innovation is great, the sheer amount of tech to maintain creates strain on the company. And, with their eyes always on the “next thing,” older features and products fall into disrepair. Meanwhile, the engineering teams chase every new idea like eight-year-olds playing soccer: No positions, no passing, no strategy. Just a mass of people sprinting towards whatever looks exciting. Acquisitions compound the problem.

After a few short years, this approach yields dozens of products, each having been launched quickly by the company’s top engineers. But then they are forgotten. Security holes go unpatched, customers get confused, and no one knows who owns the product. More often than not, no one does.

The products turn into zombies–neither alive nor dead, rotting in front of your eyes. The chaos these zombies can create is both external and internal.

External Chaos

Companies with zombie products are always falling short in some element of their customer experience. The signs of zombie software often present as disjointed or nonsensical to the customer. In one company I worked at, it manifested as unique logins and different user interfaces for all the different apps.

From the customer perspective, having different passwords and different user interfaces inside of one subscription or site is frustrating and confusing.

The solution implemented wasn’t elegant code or a complicated new feature. It was just a unified login experience. It made it so the customers could access all of the features via one login. For the user experience, we didn’t rewrite everything or completely redo the pages, but we built shared headers and footers and committed to a single navigation structure. Then, we aligned the CSS of all the applications. That solved 75 percent of the problem right away.

Fixes like this can be nearly impossible to implement when there is no clear ownership or upkeep procedure across dozens of products. New products are built according to the standards of the day, and then you have a suite of legacy features that don’t match the more modern ones. Everything is stuck together with chewing gum and duct tape.

Then, every time you build something new or acquire a new company, things get worse. You paste another solution onto what you’ve got and hope the whole thing doesn’t topple over.

The only way to truly fix this is to pause, find or assign owners to every single product, and organize them into a single architecture.

It is labor-intensive, unsexy work, but it pays off tenfold every time. The user experience is coherent, customers are happier, support calls decrease, teams stop arguing, and things get fixed faster.

Oh, and the next time you want to change the look and feel of the suite of products? It is much easier and faster.

Internal Chaos

Underneath the inconsistent UIs and abandoned code is almost always a clear lack of ownership. When no one knows who owns what, every decision becomes harder. Someone needs to own every single product, even ones that haven’t been touched in years.

One of the highest ROI fixes you can implement on your tech isn’t technical at all, it is organizational. Simply designating an owner for all systems and products makes everything down the line much easier–especially the single most important decision you can take with your software:

When (and how) to kill the zombies.

How Much Is That Zombie Costing You?

At one company I worked with, we had a long meeting about how to update a shared gaming product due to a backend service change. Ownership of the product was disputed (no one wanted it), and no one knew exactly how the product worked because of how old it was and how little documentation had been kept. It was going to take weeks to understand the product and retool the integration, so I finally asked how much revenue the product generated.

The answer was $40,000 a year. This company is one of the largest in the world and we were spending weeks of senior leadership’s time on a product that only brought in $40k a year. I pointed out that all of this discussion had already cost us more than that, and we decided to kill the product.

Products like this are the danger of letting zombie software exist. It may seem like a harmless way to bring in a few bucks, but it can quickly turn into a problem that outweighs any of the benefits. If a piece of software no longer delivers value and no longer merits true maintenance and attention, shut it down completely. Don’t let it live long enough to cause you problems. This way, the company gets leaner, faster, and more focused on the products that actually drive revenue.

Kill It At The Root

Zombie software is a symptom, but the disease is organizational chaos. The cure is simplicity and organization. The cure rarely comes in the form of building more stuff. It almost always comes from getting rid of old, forgotten products and putting up some sensible barriers to building new ones.

I am going to write an article on my 9 simple rules for running a disease-free software organization, so follow along if you are interested!