The bounty of the commons

You'll never be able to make effective trade-offs without thinking holistically about the entire system, and the other people within it

Good news, picnickers - it’s almost picnic weather (here in the Northeast, anyhow). Here are some ideas to ponder while sitting on a patio somewhere nice.

Reading Material

Today’s picnic is inspired by the work of Elinor Ostrom. Her name is unlikely to be familiar to many. Instead, you’ll probably recognize a different name - Garrett Hardin - or at least his best-known essay, the Tragedy of the Commons. Most people aren’t familiar with the context of the phrase, and only know the general idea: the only way to stop everyone from stealing from a public resource is to steal all of it for yourself first.

Ostrom won the Nobel Prize in Economics for debunking this idea (she was in fact, the first woman to ever win this award).

Her framing is an extremely valuable one: what if instead of optimizing for individual ownership, we studied successful cases of collectively defined systems of creating value? Hold on to that thought as we dive into one of my favorite subjects: making trade-offs.

The ideal engineering solution is one that does not exist, costs nothing, and perfectly achieves the desired result with no compromises or undesirable effects

If you stop to think about it (many decision makers don’t) a trade-off is a simple question: how do we get the most value out of the least investment? This, of course, assumes that you have successfully defined the value you’re after (many decision makers haven’t).

One of the simplest ways to make a trade-off is to take the consequences of your actions, and push them all the way over there where we can’t see it. This works super great when you have metricized all your outcomes, so anything “off the radar” doesn’t register as a cost. “Productivity” is often one of these metrics, insofar as it’s quantified: while the functional outcomes of productivity enhancing tools can be high, the social outcomes are extremely negative.

One of the interesting invisible negative externalities is the infrastructure load required to make our software run. The costs of AI infrastructure are the most obvious (it’s fortunate that cloud providers are hitting the brake on it) but every unnecessary Javascript library constitutes another notch in the infrastructure cost.

The Timeline

If that sounds big and abstract, let’s think about the local, team level. One common trade-off made at the level of teams is the 10x engineer, who typically requires 9 people to clean up after them. This concept is, amusingly, a retread of the Stakhanovite movement and “shock workers” of the USSR, which was eventually discontinued for similar reasons: having one person who “moves fast and breaks things” does not make up for needing many people to fix what was broken.

It seems that the industry is starting to learn that the superhero approach just doesn’t work. I don’t know if it’s a ZIRP thing where you can’t just add zeroes to the paycheck until you get a brilliant enough engineer to solve all your problems. But managers have now soured on Green Lanterns who can brute force problems. They are now looking for people who can a) make cost-effective tradeoffs, and b) make those decisions understandable to the team.

If you post an AI answer to a question verbatim, are you really still human, or just a clerk for the machines?

This bodes ill for a certain type of contributor, who is chasing “velocity” by juicing their work with generative AI support. These are the people who increasingly cannot explain their decisions, because the AI decides for them.

In a world where resources are finite and trade-offs matter, the name of the game is “opportunity cost.” You’re not just after moving the needle - the real cost of a choice is not monetary, but not being able to solve a different problem. So you better make sure you’re working on the most valuable problem, instead of just features that you like.

Why does nobody seem to want to buy an “objectively valuable product?”

One of my favorite framings of trade-offs is Rodrigo Alem Fernández’ “time to Hadoken” which I expand on here. This is a significant component of what Jared Spool calls experience rot - the trade-offs that we make are not just about what to work on, but about where to add complexity to our product. If we do this thoughtlessly, the cost for our users grows and grows, without commensurate benefit.

Diagram of the Week

Perhaps you are very junior, with no influence at all on the priorities of your team. But you are never too junior to influence how you yourself show up: where you give 100%, and where you work to the requirements.

There’s a simple rule for how to determine what’s worth your energy:

  • Is the outcome going to be visible to leadership, and valued by them?

  • Is a successful outcome within your control?

Working on invisible outcomes is a waste of your time; achieving success that you don’t get recognition for is only worthwhile if you need a portfolio piece before going somewhere else.

But equally wasteful is throwing your whole self at a problem where you cannot tip the scales from failure to success. If the outcome fully depends on someone else pulling their weight, then building up more work behind that bottleneck isn’t going to make any more of an impact.

Perhaps the most important element is the note in the middle: it is not enough to do the work. Being seen to do it - ideally not “supporting” but leading - is critical for advancement in any field. The key trade-off in every successful career is between doing the work, and marketing that you’ve done it. The right amount of marketing varies, but it’s never zero.

– Pavel at the Product Picnic