In some pockets of the industry, an axiom of software development is that deploying software quickly is at odds with thoroughly testing that software. One reason that teams believe this is because a fully automated deployment process implies that there’s no opportunity for manual quality assurance. In other pockets of the industry, the axiom is quite different: you can get both fast deployment and manual quality assurance by using feature flags to decouple deployment (shipping the code) and release (enabling new functionality).

The deeper I get into my career, the more I believe that example holds within it a generalizable pattern for making useful tradeoffs:

1. Two-dimensional tradeoffs always disappoint someone
2. You can usually make a tradeoff that doesn’t disappoint anyone by introducing a new dimension

In the “quick vs safe deployment” tradeoff, the additional dimension is decoupling feature activation (“release”) from shipping the code necessary to enable that feature (“deployment”). Introducing that dimension makes it possible for engineers to get fast, predictable deployments and for quality assurance to get the chance to review before enabling the feature for users.

While most people have already intuited these rules to some extent, I think that stating them explicitly is a lightly transformative experience, and I’ll dig into applying these rules a bit.

Examples

Before talking about the mechanisms of identifying dimensions to improve tradeoffs, let’s briefly walk through a few more examples of where adding a dimension makes for cleaner tradeoffs:

• Project budgets – During annual planning, many companies struggle with intense debates about whether they invest into international expansion in new markets or do they instead prioritize their existing markets. By adding the dimension of fixed budgets, they can get varying degrees of both rather than debating existentially about doing one or the other
• Diversified portfolio – For a long time, investors felt stuck either making safe investments that underperformed the stock market or making risky bets that might overperform the stock market but also might go to zero. Burt Malkiel’s A Random Walk Down Wall Street introduced the dimension of diversification, such that you could both get stock market-like performance and lower risk
• Data-informed restrictions – You’ll often hear debates between Product and Security teams about the tradeoff between safety for your users and usability of your product. However, by taking a data informed approach you can often get both. For example, instead of debating about removing permissions from users, start by removing all permissions that each given user currently doesn’t use. By including real-world usage as a dimension of the tradeoffs, you can usually identify a tradeoff that improves security without reducing usability
• Feature flags – As discussed in the introduction, many engineers believe we must have slow-and-safe deployment or fast-and-risky deployment, but decoupling deploy and release via feature flags allows us to get fast-and-safe deployments

Beyond this small handful of examples, I suspect you can identify quite a few more tradeoffs from your work history where an additional dimension turned a messy disagreement into an obvious path forward. When you work with someone who’s particularly good at this, the entire idea of tradeoffs starts to melt away to be replaced by thoughtful solutions.

How to add dimensions

Once you start thinking about tradeoffs this way, you’ll notice people who already take this
approach to improving tradeoff decisions. The challenge is that most people do this intuitively
rather than following a specific set of steps, which makes it difficult for them to explain it.
Frankly, I have this challenge as well. Over time I’ve gotten better at doing it, but it was only
very recently that I found the right vocabulary to describe it.

Here’s by best attempt to reverse engineering this practice into steps:

1. Go into each tradeoff discussion believing that there’s an additional dimension you can add
   that will greatly reduce the current tension in decision-making. Socialize this belief with
   others so they understand where you’re coming from, this can be as simple as a statement
   like, “I wonder if there’s a dimension we can add to this tradeoff to make it easier.”

2. Get very specific on all stakeholder requirements. The missing dimension is usually only evident in the details,
   so you need to force people to be precise about their needs. If you have stakeholders who cannot be precise about
   their needs, then you should spend time working with them to get more clarity.

   Yes, it is their problem that they can’t articulate their needs, but it’s also your
   problem now too.

3. Seeing dimensions is the same as seeing layers of context.
   You’ll either need to expand your awareness of additional context layers or pull together a working team
   who have broad knowledge. This doesn’t need to be the decision making stakeholders, just folks who
   understand the relevant teams, technologies, and product.

4. Test new dimensions for usefulness. At the simplest, as your working group
   “How might we simplify untangling this tradeoffs with this additional dimension?”
   The key is to explore many dimensions quickly, try them on for usefulness, and then move on to another.
   Don’t go deep into any given dimension until it shows some promise.

5. See around corners by asking those who’ve solved similar tradeoffs before.
   I feel like a broken record, but it really does work to just ask people who’ve solved this specific problem before.
   Once again, this is why it’s so valuable to develop a network of peers.
   They can probably just tell you what the missing dimension is!

6. Ultimately, you should only add a dimension to a tradeoff if it provides significantly better outcomes
   for the stakeholders involved. Once you start thinking about this idea, there’s a temptation to add
   dimensions everywhere, but avoid additional dimensions that make things decisions harder to explain
   without greatly improving your options.

This process won’t work every time, because some working groups simply won’t know enough about
the missing dimension to suggest it. This is why you shouldn’t get discouraged if you can’t find
the missing dimension in any given tradeoff, and also why it’s useful to reconsider hard tradeoffs
every couple of years. Just because you didn’t know about the missing dimension last time doesn’t
mean you are unaware of it now.

Late-career abilities

Sometimes people will talk about engineers becoming senior in five to seven years, and then being wholly competent at the job they do. This is true in one sense–you can be a very good engineer with five years of experience–but also misses on the many abilities that are only beginning to take root at that point. Adding dimensions to tradeoffs is a good example of the latter category: there are very few folks with the necessary context layers and the breadth of experience to get good at identifying the missing dimension to make difficult tradeoffs easier. There’s always more to learn.