Achieving exponential outcomes by choosing the right axe

Adding more people to the choir doesn't make it easier for them to reach the high notes.

Certain problems can only be solved once you've built the right competence.

In a world of hard problems, competence is a key differentiator for outcomes. Brute forcing without competence often fails.

Like the quote attributed to Lincoln: "Give me six hours to chop down a tree, and I will spend the first four sharpening the axe." – Some trees can never be cut without the right axe, sharpened the right way.

So let's talk about choosing our axes.

Marathon time is defined in your training

How long it takes for you to finish a marathon is a function of your speed over time.

If you could draw a chart where the x-axis is time and y-axis is your speed, you'd finish the marathon around the time when the area under the chart adds up to 42 kilometers (26.1 miles).

In the green chart, the person can run faster (~7.5mph) than the blue person (~5mph) and so finishes sooner. Both charts have identical areas.

Since speed of running a marathon is a normal distribution ("bell curve") over trained people, most people cluster around the average. Train seriously for a marathon, say 1-2 years, and you'll likely go somewhere in that middle.

Even if you're really behind the curve, as long as you can keep going, you'll eventually finish the marathon. At 4mph, you'll be done in 6.5 hours, a typical marathon limit.

Of course if you're completely sedentary and haven't trained at all for the marathon, you won't finish it.

Your marathon speed over time is a function of your conditioning, which is in large part a function of your training.

There are no elite marathon runners who don't train. There's no "winging it." It's a "competence-heavy" field, where a lot of the competencies needed to perform at a high level don't come naturally to people – they need to be built.

Most hard problems in life are "competence-heavy" like marathon running: to a large extent, it's how much you spent building your competence in the past that will determine your performance today, and that can't be replaced by grit and determination alone.

As leaders, and in our personal lives, we'll sometimes get tunnel vision over our performance on the task, instead of stepping back and thinking where on that bell curve we lay: ahead, flat in the middle, or behind?

Sometimes you better stop chopping at the tree and start sharpening your axe.

Particularly because, for some problems, the distribution of performance is not a bell curve at all.

Power laws in the absence of constraints

Elite marathon runners are only about 2x as fast as a good hobbyist, able to run a marathon in a little over 2 hours instead of 4. The amount of work and talent necessary to get close to a 2 hour marathon is tremendous, and we likely won't see any marathon runners doubling that again to a 1 hour marathon, ran at 26mph, anytime soon.

Without some miraculous technological improvements, the human body has hard constraints that will keep our marathon running time very far from 1 hour, the equivalent of running the 100m dash for 1 hour straight instead of 10 seconds.

But some problems and areas in life lack any such hard constraints. Like the library of babel which has infinite shelves with infinite books, lacking any physical constraints, many areas of human endeavor have a power law distribution instead of a normal distribution.

As a typical example, VC investment returns follow a power law: a minority of investments yield the majority of returns. Many investments will yield nothing (company folds) or 0.1x-1x the investment. But a few investments will yield 100x or even 1,000x returns.

Here's an example of what it'd look like if we were only looking at VC investments that yielded some return (an estimated ~25% of total VC investments) and see how the distribution on a log scale compares with the marathon bell curve.

The y-axis on the VC chart increases on powers of 10: 0.1x, 1x, 10x, 100x, and 1,000x

As you can see, in a power law distribution, there's a minority with an oversized amount of returns, up to 1,000x the investment, as was the case for some investors of Facebook, Google, Instagram, and Whatsapp.

While this power law chart is in logarithmic scale, which is typically used because it helps us humans reason about the magnitude of big numbers, here's what it'd look like in linear scale:

Above, we see the power law on linear instead of logarithmic scale

Now both charts are using the same type of scale, and you can see how absurdly different they look.

Honestly, few charts scream "Here's what modern life looks like sometimes" to me compared to that last power law chart on a linear scale. It's such a clear example of many problems and curiosities we get from modern life's lack of constraints.

So why am I talking to you about marathon running and VC investments if you do neither of those?

Because some things in life are more like VC investing than marathon running. Many modern things lack physical constraints, and their outcomes will be closer to a power law than a normal distribution.

And in many of those cases, no amount of brute forcing will allow you to get outcomes near properly building competencies.

Technology breaks the constraints

A thing in common with areas that have power law distributions is their connection to technology: VC investment returns, wealth distribution, financial markets distribution, Saas number of users, influencer's number of followers, artist's number of listeners, etc.

When constraints don't apply, it's typical for things to get easier the more you have them, like VC investment, than for them to get harder the more you have them, like marathon running speed. And technology typically removes these constraints.

Now, even Saas users and VC investments have some ceiling constraints, even if they don't get harder. This is why Dropbox had to go into other verticals: everybody was already using something like Dropbox. Some of these big companies deal with ceilings only when they run out of humans in the world.

But generally in Saas companies like Dropbox, which heavily provide their value through technology, you often run into negligible marginal cost of replication. You have a setup for serving 100 users, and when you need to serve 200 users, the cost and disruption for scaling 2x is pretty minimal.

By comparison, my brother-in-law has a few schools, and when a nearby school went bankrupt, and his number of students similarly doubled, it was total mayhem: construction work, hotels used as temporary classrooms, kids without teachers, etc.

In the technology world, sometimes "the marathon runner" does run at 26mph. Or even at 260mph.

So, it often pays off much more to invest in becoming a faster runner in the virtual world, constrained by technology, than in the physical world, constrained by physics.

And one of the greatest ways this shows off is in software engineering.

Programming with zero bugs

"If it compiles, it works."
– Typical claim for languages like Elm, Haskell, and Rust

Compilation: The step of turning the code you write into code your computer can run.

I didn't know my writing was gonna take me here, but here we are: In July 2024, CrowdStrike released a broken software update for Falcon, causing an outage on 8.5M windows machines, disabling hospitals, airports and TV stations.

Did you hear what the root cause was? Something extremely complicated? Here it is, quoted from their RCA report:

[..] the new IPC Template Instances were evaluated, specifying a comparison against the 21st input value. The Content Interpreter expected only 20 values. Therefore, the attempt to access the 21st value produced an out-of-bounds memory read beyond the end of the input data array and resulted in a system crash.

In plain-speak: a part of the software expected 20 fields but was given 21 fields. When it tried to read field 21, it crashed the computer.

Pretty basic stuff.

Their number one mitigation? From the same document: "Mitigation: Validate the number of input fields in the Template Type at sensor compile-time"

In plain-speak: If the programmer writes code that tries to read more fields than exist, the software should not compile.

So CrowdStrike added a compile-time check to prevent this specific issue on IPC Templates from happening again, but of course, nothing would prevent it from happening elsewhere in their software and causing similar issues.

Enter Rust, a different programming language from the one CrowdStrike uses. Here's Rust's claim from their home page:

Reliability

Rust’s rich type system and ownership model guarantee memory-safety and thread-safety — enabling you to eliminate many classes of bugs at compile-time.

If CrowdStrike Falcon was written in Rust, it would have caught this error by design. In Rust, this bug is impossible.

Hence "if it compiles, it works."

Note: Post publishing, my friend Brian Hicks clarified that, by default, Rust could actually allow out-of-bounds array access, even though it also has a very convenient way to guarantee safety in this same scenario.

Your choice of programming language is not inconsequential. In this case, it is the difference between whether you cause one of the biggest outages of recent times – or not.

Now CrowdStrike could try to brute-force and task its engineers to add compile time checks to as many areas as they can find like this one part of their code. This won't address the root cause, and won't get them anywhere near where they'd be with software written in Rust.

CrowdStrike is just not using the right axe to chop their tree.

So why am I talking about programming languages? Because I think this concept generalizes.

Some areas of technology are extremely superior to others at achieving outcomes, even if they can't be easily quantifiable, and building them right can yield orders of magnitude higher results.

Like having CrowdStrike Falcon written in Rust would have.

Technology competence varies by orders of magnitude

It's hard to quantify how much better CrowdStrike Falcon would be if it had been written in Rust and not been susceptible to the issue that caused the CrowdStrike outage. We don't have great measures for this yet.

But due to its lack of physical constraints, the variance in technology is in the orders of magnitude. It follows power law distributions like VC investments and not normal distributions like marathon runners.

The same applies to all areas you're focused on that rely heavily on technology or other aspects independent of physical constraints:

• AI and Machine Learning: Predictive analytics to find the Google Ads you want to click and Netflix movies you want to watch.
• Your usage of programming language and libraries: For example, choosing Rust over C for systems programming and eliminating full classes of bugs and security vulnerabilities.
• Your writing and content distribution: The exponential difference in influence and reach among people depending on their network effects and their choice of social media platform.
• Your investment strategy and tactics: Like in the book "The Man Who Solved the Market," which tells the story of how Jim Simons built a fund with 66% gross returns a year on average from 1988 to 2018 – a ~40,000,000,000% increase!


With technology, we're playing the game of life without the safety net of physical constraints.

And in areas of life that are heavily determined by technology, competition will almost certainly be determined by who has the right axe, sharpened the right way.