Reading Time: 15 minutes

Bertrand’s Health Insurance has a problem. Their software system is hard to maintain.

The systems still rely on tools that had their heyday in 1990. The SOAP API doesn’t always return valid XML. The search calls take twenty seconds to return.

Bertrand’s CTO and CIO decide that it’s time to rewrite the system from the ground up.

And you’re going to lead the team that will do it. Congratulations!

You’re excited. You’ll get to decide who joins the team, consider new tech stacks, and assess modern software-building methodologies. Maybe, if the project really succeeds, you’ll get the chance to transform the way Bertrand’s Health Insurance builds all of its software.

However.

Before you start, I want you to prepare for your rewrite team to face friction.

Rewrites don’t happen in a vacuum. They happen in an organization that contains people, all of whom have different priorities for the system and the team. Some of these people are above you on the org chart. Some of these people own the budget that makes your project possible. And some of these people are your users, too—the ones you want to please with your brand new software.

If you decide to pretend these forces are not there, then the friction will worsen. You’re not likely to get the best outcome by fighting those forces head-on, either. You need to determine how to best interact with all of those people to make your rewrite teams’ lives as easy as possible.

I have been involved in six software rewrites for large companies so far in my career. In all of these, I have noticed some patterns in the environments surrounding the rewrite teams. By understanding these patterns and working with stakeholders, you can make it much easier for the development team to get their work done.

Common Threads in Enterprise Rewrites

1. The user doesn’t put food on the table. In an organization that’s large enough and old enough to be rewriting a software system, your application’s end user is not the person who is bankrolling your rewrite¹.Bertrand’s for example, makes most of its revenue on large employee health insurance plans. This means that they’re pitching the COO or the Director of Human Resources at other large companies. Ultimately, the people using Bertrand’s mobile app are the employees of the client companies—but those aren’t the people who pay Bertrand’s. So the desires of the COO or Director of Human Resources, even if they’re disconnected from the desires of their employees, direct which features Bertrand’s promises to include in the app that those employees will use. And when employees don’t see the features they want in the app, they rate it accordingly in the app store.You want to write an app based chiefly on feedback from your end users, but your bosses and funders also have ideas for what the rewrite should look like. Maybe those ideas come from their personal preferences or the way they imagine they would use the app, were they the end users. Or maybe they tie back into who pays for what: given a limited budget, it is in a department lead’s interest for project costs to come from another department’s bucket as much as possible. Regardless of the reasons that your sponsors’ desires might compete with your users’ desires, you have to balance these two different sets of priorities. We’ll talk about how to do this later on.
2. The more high-profile the rewrite, the more voices you’ll hear. More people want to have their fingers in your company’s flagship mobile application than, say, a better logging system. Apps with user interfaces get more attention than systems with APIs, and apps with more users get more attention than apps with fewer users. The more visibly central your application is to the business, the more members of the business will knock on your door. You’ll be responsible for balancing their needs on the project.Maybe you can afford to ignore some of these voices—the mouthy contractor who likes to complain but ultimately works on not-your-project, for example. But sometimes you’ll be hearing from VPs of several different departments, all of whom have mutually exclusive desires for the app.You need to be able to manage all of these voices in a way that doesn’t endanger your project and doesn’t get you fired. We’ll talk about how to do that, too.
3. Someone’s baby is getting thrown out with the bath water. If you’re writing version 2 of an app, that means that somebody was in charge of version 1. That person probably still works for the company—and chances are they don’t like you.Here’s the part that you don’t want to hear: you need this person. Maybe it doesn’t look like you need this person. Maybe you can even fire off a minimum viable product without this person. But if you want the big success—the one where Bertrand’s loves your work so much that they ask you to help revamp all of their software practices—you need this person to get that kind of success. We’ll talk about why that is and how to get that person on your side.

Prioritizing Sponsor-Driven versus User-Driven Features

How can you reconcile the requirements that your marketing team promised to their new clients…even if those aren’t the things that the app’s users want? In a large enterprise, sometimes you’re going to end up doing work that doesn’t make sense from your perspective. Huge organizations are broken down into several departments that each handle a subset of the company’s concerns. All those departments operate independently and, sometimes, at odds with one another. But if a feature is written into a contract for an app that you need to build, then you need to include that feature in the app. Set the feature aside on a ‘business obligations’ track along with all the other features that aren’t priorities for the end user. Have a portion of the development team work on this track until you get through it. That way, you contain the effort to one part of your team, and when the track is finished you can focus solely on developing based on the results of your user testing.

Your job is to keep the ‘business obligations’ track of features as short as possible. This will mean initiating a conversation with the Bertrand’s Health Insurance marketing team. You want to find out as much as possible about the contractual obligations your sponsors need fulfilled. Why did we sell this solution? Presumably, either your sponsor or your company’s client felt some pain that this new feature is supposed to solve for them. People don’t pay out money and forego opportunity costs to explore their harebrained software ideas, no matter how good they think their ideas are. People pay out money and forego opportunity costs to alleviate pain. You need to root out this pain and determine the minimum viable feature that could lessen this pain.

For example, maybe Bertrand’s marketing team sold Alta’s Aviation on  a brand new doctor video chat system in the app. Your user research suggests that people don’t want to video chat with a doctor, so you don’t want to do the feature. Well, that feature is in the contract because Alta’s wants to pay less for their employees’ doctor visits. This is the underlying pain. 

There are two things to consider here:

1) Fulfill the contractual obligation. What does the contract say? Does it require an in-app solution, or can your app have a button that opens the doctor video chat system in the browser? This might be a lot easier for developers to implement and only slightly more clunky from a UX perspective—which is fine by you because your user research suggests that users won’t be using this feature anyway.

2) Alleviate the pain. If users don’t want to use the video chat feature, then it won’t bring down Alta’s costs for employee doctor visits. If Bertrand’s wants to make Alta happy, it has an opportunity here to alleviate Alta’s pain in a way that their users do care about. This is your chance to go to your beta test group, to your app’s potential users, and find out why and how they decide to visit the doctor. Identify the drivers there. Nobody loves doctor visits, so if your users can help you unearth some good ways that your app could make it easier for them to stay out of the doctors’ office, you’ll be looking at better ratings and happier clients for the company. This is the kind of success you need to end up advising the whole company on how software is built.

Managing the Voices: Protect Yourself and Your Project

I mentioned above that the more visibly central your application is to the business, the more voices you’ll hear chipping in their opinions and demands of your rewrite project. This one ties back into the ‘business obligations’ track that we started writing above. Remember, your job is to keep this track as short as possible.

What goes in this track? Formal obligations that made it into a contract before undergoing user testing. What doesn’t go in this track? The design idea that your boss came up with in the shower. Maybe putting that in the app would make your boss very happy, but the idea is not user-validated and it’s not written anywhere that you have to include it.

You can also make your boss very happy by building an app that enchants its users and convinces Bertrand’s clients to renew their contracts. If you can do this, your boss will forget all about his UI idea. So stick to features that are backed either by legal contracts or by evidence that your users need them. For everything else, you need to make sure your sponsors feel heard, even if their concerns are not highest priority.

Let’s say someone in a different department comes to you with a feature idea that you’re 99% sure is never getting on the priority list. It’s still your job to listen carefully to the idea and record it in your project planning dashboard. If you can, let the person see you write their item into that dashboard. Include the person’s name in the note.

Stick that item in the ice box, or at the bottom of your project’s priority list, so you can pull it up later if new information reveals that it should be a priority. Do this each time someone brings you an idea. Then, when you have meetings with people in the future, search for their names in your project plan prior to the meeting. You want to remember their previous suggestions in the meeting. This is critical; even if you haven’t gotten around to implementing what this person wanted, when they see that you remember what they said, they’ll feel more heard. You can explain that, though their idea is excellent, so far you have needed to prioritize other stuff first—whether due to contractual obligation or user-based evidence. So they don’t really have a case against you. This allows you to play the waiting game without too much damage to your reputation with this person.

Befriending the Bereaved: Get the Leader of Version 1 on Your Side

If you’re writing version 2 of an app, that means that somebody was in charge of version 1 Maybe you hate this person and you think of them as a screwup whose gross failings as a professional and a human are the reason this rewrite is necessary in the first place.

Let me be the one to tell you the other side of the story for this person. Then I’m going to explain why you need this person on your team to have runaway success.

So the previous version of the app, in some respect or another, failed. That’s why you’re rewriting it. Please keep in mind that, often, that project didn’t fail because of the people responsible for it. It failed because of the way the business handled it—because of the exact forces that you protect your rewrite from every day.

Let’s use Bertrand’s software system as an example. The systems still rely on tools that had their heyday in 1990 because the management team has pushed for new features in a continuous sprint. Under this pressure and guided by a desire to make management happy, the team never had time to take a step back and refactor the system—let alone replace the whole thing with a more modern stack or break it down into small pieces to modernize one by one.

The SOAP API doesn’t always return valid XML because, initially, it returned a simple success or failure flag with a little bit of data as a concatenated string. Then, somewhere along the line, the IT staff were commanded to convert it to XML without being told why. Oh, and it had to be done yesterday. So the team didn’t have time to find an XML serializer that would work with the outdated tech stack or learn how to use it. So they just string-concatenated XML-ish responses together to meet the deadline. They made a few mistakes along the way, so in some of the edge cases the string does not concatenate to valid XML.

The search calls take twenty seconds to return because the search feature was added after the database. When it was added, it had to have some filtering options that required filtering on a few different keys and then making a call to another table for each of the records that turned up. It wouldn’t have fit nicely in a SQL query the way the database was structured, but the database architects did not want to modify the database structure and risk any backward-breaking changes. So the solution was to make the first call, loop through the results, and make the second call in each case conditionally on some attributes of each row in the first set of results. The looping is what causes the search to be slow, but there was no way to produce all the necessary filtering options without it.

Do you see what happened here? Version 1 did not fail because the developers were bad developers or the team leads sabotaged the project. It failed because of breakdowns in the business’s interaction with the software team as that software team tried its hardest to make all the stakeholders happy.

This is where you want to befriend the team lead from Version 1. That team lead knows why those decisions were made on Version 1. You want to make an informed evaluation of how that project got to where it got before/during the early stages of the rewrite. This knowledge will help you put systems in place that prevent the same failures from happening again.

In fact, it’s often in your best interest to invite the owners of the old system to participate in building the new one. I’ll remind you, the failure of the old system was probably not their fault. Plus, they have critical subject matter expertise. Your new system will probably do a lot of what the old one did, and this person knows how to do those things. They can speed up your rewrite by sharing that knowledge. Conversely, especially if Bertrand’s has poor software documentation, they can slow down and block your rewrite by withholding information if they see you as a rival.

Conclusions

As the project lead on a rewrite that plays a critical role in Bertrand’s software ecosystem, you’re going to find yourself doing a little diplomacy. That’s part of the role. So we’ve talked about how to balance the competing priorities of your users and your contracts, your sponsors, the peanut gallery, and even the owners of the old system that you’re replacing.

I understand that you want to build the features that your end users will value the most. Sometimes, though, a large enterprise needs you to take care of other obligations, too. Learn to tell the difference between a contractual obligation that your company has made and a feature that a sponsor really wants you to do, but has not promised to anyone on paper. Include the former in your project build schedule and get them out of the way so you can focus on your users. As for the latter, write down the sponsors’ suggestions so you can remember them next time you talk to the sponsor, but don’t worry about doing them right away. Learn to dig deeper on feature suggestions to find out what pain they’re expected to solve. You can do user research to figure out whether users feel this pain and what they’d like the software to do to resolve it. This allows you to go above and beyond both for your end users and for your company’s clients

Also, when you’re doing a rewrite, you’re often better off including the owners of the original system in your rewrite project. They have subject matter expertise about what you’re doing, plus they can help you identify pitfalls and improve on the process that built the previous system.

By making a priority out of solving problems, making sure everyone feels heard, and surrounding yourself with knowledgable allies, you’re taking excellent steps toward making your project an even bigger success than anyone might have imagined.

Footnotes

1. The only time I have seen those two groups of people be the same are in a small business that takes no outside investment and survives solely on payments made directly to the company by end users. These businesses are not usually large enough or old enough to be doing a rewrite, anyway.