"Monkeys first"

Astro Teller, computer scientist and head of X (the "moonshot factory" owned Alphabet, not the online social media service formerly know as Twitter), shared in a 2016 blog post a powerful mental model for anyone tackling an important challenge:

Don’t use up all your resources on the easy stuff

Since then, I have used his "monkeys first" analogy countless times in consulting projects and as an advisor to startup founders:

Let’s say you’re trying to teach a monkey how to recite Shakespeare while on a pedestal. How should you allocate your time and money between training the monkey and building the pedestal?

The right answer, of course, is to spend zero time thinking about the pedestal.

Yet, without even thinking, many people jump into work carving a great pedestal (the straightforward part of the solution) and neglect training the monkey: the risky, uncertain part, without which nothing else matters.

In Teller's line of business, an upfront pursuit of a successful "monkey-training technique" is critical. If none can be found, the company resources can be redeployed in inventions more likely to succeed in a reasonable time frame.

The same line of thinking could have prevented so many cases of failed initiatives I've witnessed over the years. Often when invited to join an early startup, or become an angel investor, my final conclusion was, "Sorry, but you're focusing on the pedestal here."

A few examples that come to mind:

• A sophisticated mobile app built for a two-sided marketplace without first figuring out how to attract sellers without having buyers first, or vice-versa.
• A costly platform to host fancy business dashboards developed without first confirming there would be reliable data to generate usable insights.
• A startup created to develop and market an AI model meant to revolutionize mental health treatments without first validating that service providers would be willing to participate in trials.

This list could go on and on. In most cases, the biggest mistake was to treat the technology (software, AI system, BI platform) as the monkey, when in fact that was an easily solvable pedestal that only required resources and time to build.

The real "monkey to be trained" typically had nothing to do with technology, and consisted of the ability to forge some crucial partnerships, or develop trust with potential customers, or gain access to the right internal or external data.

Only once did the founder listen and give up on her idea after concluding that she didn't want to deal with the non-technical monkey after all.

Several startups (some of them paying customers of "pedestal consulting" services I was hired to provide despite my warnings) folded after reaching the end of their runway. Two founders were kicked out of their ventures by unhappy investors. None achieved a financial reward remotely close to the compensation they'd have received as a salaried employee during the time spent in their venture.

I'm sure you have witnessed the same problem even if you work for a big corporation. An executive starts a "pet project". The delivery team immediately rushes off to solve the parts of the problem that they're confident will work while ignoring the sticky portions. After millions have been spent, the team reaches a dead end, and another executive kills the project.

As Teller says,

It's human nature to want the boss to say, “Hey, nice pedestal, great job!” and think of your authentic Elizabethan-era carving techniques when you’re up for promotion instead of the long list of monkey-training techniques that have failed so far.

How to avoid this kind of "short-termism" when starting a challenging initiative?

My tool of choice to fight this tendency is the premortem. Time and again I avoided failure in my data science projects simply using this evidence-backed technique to gain a different, superior vantage point.

It consists of pretending that a success or failure already happened, and trying to come up with the details why.

When you think that way, it's much easier to see the point of failure most likely to happen, the biggest issues in the current thinking, the hardest stuff to be tackled early on.

When do you want to know if [your project] has a massive flaw… as soon as possible, or only after we’ve put in a couple of years of work?

As I was writing this article, I followed a link from Teller's blog to his Wired piece where the quote above comes from, and realized that X also uses the premortem technique as part of their process. I learned the approach from the work of renowned academics like Daniel Kahneman and Karl Weick, but it's not surprising to see it applied in a company whose mission is to pursue highly risky endeavors.

It's true that many of us will never work on game-changing technology like X, the moonshot factory, does. Still, we similarly work in environments, where it's essential to allocate resources where they can make the largest impact. And to achieve that, we must fight our natural tendency to go for the "low-hanging fruit" that creates the illusion of quick progress, and focus on the hard stuff that may become our project's Achilles heel.