Make timeline tradeoffs using iterative elimination tournaments.

Years ago, I found myself in a small room with large glass double doors that didn’t quite close properly. Those misaligned doors were leaking crescendoing frustration into an open office layout filled with people furiously refusing to acknowledgem the sounds of dispute filtering out.

I was trying to mediate a disagreement between two teams about our approach to collecting data from the Facebook Ads API. The API provided the necessary data, but didn’t provide a sufficiently granular time series of changes, which we need as an input into a budget rebalancing algorithm.

One team wanted to build a novel DSL-powered abstraction over the APIs, allowing folks to describe custom crawlers to navigate the API, and custom infrastructure that would crawl specified data periodically; it was a novel approach, but so far had not gotten much traction. The other team wanted to pursue a hardcoded crawling strategy, that wasn’t particularly extensible but could be finished almost immediately.

I’d like to write an article about the de-escalation strategy I used to bring everyone together, but this one went rather poorly – so I can’t write that article – but I did come away with an idea that I’ve relied on heavily since, the iterative elimination tournament.

An iterative elimination tournament is a competition where you have to win your current round before advancing to play in the next round. If you don’t win, you don’t keep playing. If you have a great strategy for next round, but don’t do well in the current round, then you’ll never get a chance to take advantage of that strategy. If you have a great approach for today, but no plan for tomorrow, it’ll be a futre mired with regrets.

This model is so effective because it focuses you on (1) identifying what success looks like over various time frames, (2) selecting an evolution of approaches for your shifting needs.

I use this mental model all the time!

A few of the more recent scenarios were identifying when to invest in new technologies versus extending the existing ones, prioritizing projects during quarterly planning, and making headcount and resourcing decisions.

It’s a powerful tool for considering your approach both today and tomorrow, and I’ve yet to have it lead me astray.

As an aside, I really wanted to work this idea into my upcoming presentation on How to invest in technical infrastructure, but that talk is already so packed with ideas that I just couldn’t work it in.