Do you ever face tradeoffs? “We’ll have to release right away and worry about quality later,” or perhaps you’ve heard something along the lines of, “That’s scope creep: just fix what needs to be fixed and leave the rest of the code alone.” These are some basic examples of tradeoffs every software company deals with. Do you release a buggy product right away, or wait until it’s in better shape? Do you make minimally invasive changes, or eliminate some technical debt while you’re in the code? Do you focus on producing more features, or fewer, higher quality features? If you’re working on a web app, you might have faced the tradeoff of creating very fluid interaction (using Javascript) that won’t work for some users versus less-than-fluid interaction that works for everyone. One debate that arose at the office the other day was whether to avoid code duplication by having all code in the same repository or to split code up into multiple repositories in order to avoid tightly coupling several unrelated projects that happen to use some common routines.
Tradeoffs are an age-old problem; “You can’t have your cake and eat it too,” is a well-worn phrase. But is it true? Tradeoffs indicate that a conflict is lurking, a contradiction persists, unaddressed, undermining everyone’s efforts to do the best they can. The developers might want to have a high-quality product, but management is anxious to get their foot in the door of a new market. Who’s right? Which tactic should be taken? How will the most revenue be realized?
Allow me to make a bold statement: you can have your cake and eat it too. You don’t have to make tradeoffs. When someone says you have to make a tradeoff between A and B, don’t believe them. A tradeoff indicates a conflict, and if you can resolve the conflict, you don’t have to make the tradeoff.
The first step is to identify that there is a conflict. Anytime you start talking about tradeoffs, you are talking about conflicts in disguise. Either/or thinking means: conflict. Mandates (“I don’t care if it makes sense, get it done”) mean: conflict. Feudal thinking (“This is my turf”) means: conflict. Unexplained legacies (“I know it doesn’t make sense, but this is how we’ve always done it”) mean: conflict. Practice identifying conflict. We’ve spent so much of our lives living with conflicts—managing them instead of resolving them—that we’ve stopped recognizing conflicts when we see them. Learn to start noticing them again. As they say, admittance is the first step.
Once you have a conflict in hand, it’s your job to figure out what makes it tick, and that means finding the assumptions behind it. For this, I find Goldratt’s conflict resolution diagrams to be very helpful (if you haven’t, read It’s Not Luck).
The basic premise is that most conflicts arise out of trying to serve a single goal in two different ways. In the above, very real example of the developers who want to address problems with the existing products and managers who want to get on to new products, the goal is the same for both: have valuable products. Management sees keeping products relevant in new markets as the means of providing valuable products, while developers see creating high-quality products as the way to go. Is either of them wrong? Not in the least! Both paths will improve the value of the product to users. Which do you choose? Why do you have to choose? Because, you say, there is a conflict (good eye): you can’t move onto new projects AND address issues in old products.
There are several assumptions involved in this conflict. Each arrow in the above diagram is an assumption. One is that entering new markets will increase the value of the product. Another is that changing to new projects will get you into those new markets. On the other side of the conflict is the assumption that creating a higher quality product will increase it’s value, and that staying on old projects has to happen in order to improve the quality of existing products. Lastly, there is the conflict itself: that you can’t both move onto new projects and address problems in existing products at the same time.
If you can invalidate one of the assumptions, you can resolve the conflict. After all, the assumptions are what create the conflict. Without one of them, the whole problem collapses. Why can’t you both move onto new projects and address problems in the existing products at the same time? What’s stopping you? The number of developers? Okay, double the size of your team and you resolve the conflict. Not an option? Alright, let’s move on to the next assumption: changing projects quickly will allow you keep your product line relevant. What would it take to invalidate that assumption? Are there other ways to keep the product line relevant in the marketplace? If you can find one, you can invalidate the assumption that you have to change projects on a regular basis. What about the assumption that you have to stay on old projects in order to address problems and create a higher quality product? What if you spent one day a week addressing existing problems? Would that be sufficient to create a higher quality product without staying on the same old projects for month after month? If it will, then you can change projects quickly and still create higher quality products.
There are other assumptions involved in this scenario, but the premise is the same: if you can find the assumptions in play, and unravel one of them, you can remove the conflict, which means eliminating the tradeoff. Instead of having to stick to old projects or change to new ones, you can now change to new projects AND address problems in existing products. You can have your cake and eat it too.
What if you just can’t resolve the conflict? What if the tradeoff just has to be made? That sounds suspicious—even defeatist—but I’ll bite. In the event that you have to make a tradeoff, a decision has to be made. It’s been said that a decision is something you must make when you have incomplete information: you don’t know absolutely what the best course to take is, so you have to choose, you have to decide. Trying to gather more information is not a decision, it’s an attempt to know for certain so a decision doesn’t have to be made. I’ve seen people in power put decisions into endless cycles of information gathering because no one wants to make a decision for which they’ll have to be responsible. Part of the reason this happens is because there are no principles to fall back on.
Principles are devices that tell us what to do when a conflict cannot be resolved. For instance, “Always tell the truth” is a principle. Most of the time, it does not come into play because there is no conflict, but when you’ve broken a window with a baseball, that’s when it’s necessary. If you do not adhere to the principle of always telling the truth, you might be tempted to indefinitely weigh your two options: run away or admit that you did it? With the principle, however, you have only one option: admit to it. There are no long cycles of information gathering, collecting survey results on the consequences of admitting to it versus going on the lam. You know precisely what to do because you have a principle to go by.
In business, most decisions are not so morally cut and dried. They can require research. But without guiding principles, the decision might never come out of research mode. In the standoff between the developers and managers over moving on versus fixing old problems, what’s the solution? If you decide that you can’t have your cake and eat it too, what do you do? In some companies, the principle may seem to be, “Managers get what they want.” That may be a fact, but it’s not a principle. If the principle is, “Enter new markets as quickly as possible,” it’s clear what should be done. If the principle is, “Have the highest quality product available,” the decision is obvious. Neither of these is right or wrong; whichever one you choose to abide by depends on your priorities as a company. The important part is to have backing principles. Without a set of guides to go by, you’ve got nothing but politics guiding your company, which means you sail in dangerous waters.
Leaders are important to a company, but their role shouldn’t be resolving day-to-day conflicts. When Andy and Bob have an argument over whether to use a lot of Javascript on the site or to make sure that the site works for those without Javascript enabled, they shouldn’t have to turn to a leader to make the final decision. The leaders in the company should have laid down a set of principles that make the decision obvious. The principle in play might be, “Have the best interaction experience possible,” or it might be, “Make it work for everyone.” Which it is will affect what’s done. The job of a leader isn’t to play mommy, resolving squabbles all day long. The job of a leader is to lay down principles that solve the squabbles without their involvement.
