High-Context Triad. @ Irrational Exuberance

Hi folks,

This is the weekly digest for my blog, Irrational Exuberance. Reach out with thoughts on Twitter at @lethain, or reply to this email.

Posts from this week:

- High-Context Triad.
- Useful tradeoffs are multi-dimensional.

High-Context Triad.

The past couple weeks I’ve been working on three semi-related articles that I think of as the “High Context Triad.” Those are Layers of context, Navigating ambiguity, and Tradeoffs are multi-dimensional. One of my background projects, probably happening in 2025 or 2026 after I’ve finished my nascent project on engineering strategy, is publishing a second edition of Staff Engineer, and I intended these three articles as supplements.

I’ve really enjoyed writing these pieces, because the first on context layers is really necessary to establish the vocabulary to even talk about the other two effectively. I’ve been trying to write about navigating ambiguity for four or five years now, but really struggled to do so until I was able to write “Layers of context.” Once I wrote about context layers, then the piece on navigating ambiguity fells together in an hour or two, following years of staring at a blank page. Similarly, I struggled to write “Layers of context” until I was in a specific set of discussions with an engineer that framed the specific concept clearly enough in my head that I could write it down, which is a good articulation of why I believe so deeply in the unique opportunity of Writers who operate.

In addition to pulling in this triad, Navigators is another likely supplement, perhaps following Where do Staff-plus engineers fit into the org? Altogether, I think that Staff Engineer is holding up well, but there’s a lot of interesting thinking happening in the space–especially Tanya Reilly’s The Staff Engineer’s Path–and a light revision will be worthwhile. Eventually. Until then, I hope folks interested in this topic get something out of this High-Context Triad.

Useful tradeoffs are multi-dimensional.

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.

That's all for now! Hope to hear your thoughts on Twitter at @lethain!

This email was sent to you why did I get this?    unsubscribe from this list    update subscription preferences Will Larson · 77 Geary St · co Calm 3rd Floor · San Francisco, CA 94108-5723 · USA