As software production time trends toward zero, how will the business of software evolve? The shift from floor stock trading to high-frequency trading offers a rich analogy.

AI will enable software to be delivered at least 10x more efficiently. There is no theoretical speed limit on how fast software business can become. It’s a pure digital domain, not restricted by physical processes like shipping materials. Stock trading similarly had no speed limit—resulting in a competition between automated systems trading 40 million times per day, reacting far faster than humans could.

When a game speeds up by 10x, it’s not the same game anymore. A phase shift occurs—like water turning to vapour: it’s not just hotter—it’s a different thing entirely. The skills that made you successful at the original game often don’t translate to the faster game.

Imagine the traits that made someone successful in “the pit” trading stocks in the New York Stock Exchange in the 1980s. Compare that to the prototypical “quant” building market making algorithms that trade thousands of times per day. These are different universes.

Let’s use this analogy to predict what SaaS may look like after a 10x phase shift.

Agility & Low Conviction Strategies

Hedge funds are not beholden to narrow longterm theses. They aren’t constructed around a singular “mission” that teams spend decades climbing towards. They can take thousands of positions and back out of those positions in a day. When transaction costs approach zero, low conviction strategies like swing trading and high-frequency trading become viable.

Software organizations have historically used strong, pointed narratives to drive alignment around longterm bets. Pivoting an organization of 500 people has an extraordinary cost. But what if a single person can launch 10 landing pages in a day? What if user feedback instantly becomes a live beta feature? What if entering adjacent verticals becomes 99% less costly?

We had high conviction about the problem we were solving at Spellbook, but low conviction on the solution. We launched 100+ landing pages in 3 years in order to find product-market fit. What if we could have done that in 3 weeks?

Software companies of the future will look a lot more like funds: a rapidly evolving portfolio of bets.

Optimized for Latency

High-frequency trading firms go to extreme lengths to optimize for speed. Winning often comes down to one question: how fast can they ingest signals and respond with a “buy” or “sell”? Funds invest in fibre lines and microwave towers. They rent racks next to the US economic data servers so that they can receive inflation data milliseconds sooner than competitors. Lagging behind by 10 milliseconds can mean being left out of the race entirely.

High-frequency software teams will be optimized to respond to the market within hours, not quarters. A new customer request comes in? A prototype will be built by AI immediately. An opportunity emerges in an adjacent market? You’re testing 20 landing pages within 24 hours.

Software teams should be aiming for comically low latency. The lengths that HFT firms have gone to be milliseconds faster would have been considered comically unreasonable to a trader in the 1980s.

If you’re not leaning into “comical speed” territory, you’re probably not thinking fast enough.

Front Running

One way HFT firms take advantage of low latency is front running: algorithms can quickly detect that another party is trying to take a big position. Within milliseconds, the HFT firm can react and make a move first, seizing the opportunity from the competitor.

While originality and first-mover advantages used to be important in SaaS, we are seeing signs of this changing. Front running works. You can see another company starting to do something successful—and replicate it 10x faster with leverage. Ramp executed this playbook well against Brex, even before AI was broadly adopted.

Across AI-capable software companies, front running of competitor functionality is now a constant.

Leverage

When market inefficiencies disappear in seconds—you need leverage to exploit them as fully as possible. You can’t wait to recycle your capital in many loops. Especially when you know your competitors are going to try to front run you as soon as your intent is visible.

Leverage can be a weapon used to capture alpha before competition can react. As speed becomes the advantage, we will see software companies raise larger and larger rounds in order to immediately wipe out competitors. We’re already seeing this happen. In legal AI (Spellbook’s domain) we’re seeing massive rounds—and we’re seeing the herd of AI companies that launched in 2023 get radically culled 2 years later. We hear from a legal AI company looking to get acquired every couple weeks—because they’ve been wiped out by low latency competitors with leverage—and can’t get a foothold.

Edge Funds: Startup + Fund Hybrids

The existing VC model will be at a significant latency disadvantage after 10x acceleration in software. Today, when an opportunity arises in the market, a founder must identify it, collect evidence on it, pitch it, get a term sheet, go through legals, wait for a wire to arrive, hire a team, and execute against it. This takes months.

This wasn’t a bottleneck when it took years to bring software to maturity. But when companies can output mature software in days, and are front running each other in weeks, a 6 month fundraising process becomes a problem.

In response, we’ll see new entities bring capital allocation intelligence down from the VC layer to the market’s edge. Let’s call these new entities “edge funds”. They’ll have significant capital earmarked for future unknown opportunities and have a much broader mandate than traditional startups: make money.

Edge funds will have radically low roundtrip latency compared to VC funds. They’ll be like running your trading algorithms next door to the stock exchange. They’ll be able to identify an opportunity in the market and respond to it in hours or even minutes. The traditional “identify an opportunity and then fundraise” model will look comically slow by comparison.

In deep tech, hardware and tough vertically integrated businesses, the traditional VC model will continue to be competitive, because the latency introduced by the fundraising process is fairly low relative to the time to develop a bet.

But in software, I think we’ll see combined startup + fund entities allocating capital much faster, more dynamically and more broadly than we’ve ever seen.

Reinventing AWS for HFS

High-frequency software companies will need a whole new kind of infrastructure to operate: they’ll be managing hundreds of applications and databases—some ephemeral and some long-lived. They’ll have hundreds of homepages and sub-brands, hundreds of advertising accounts managed by AI, and AI sales teams working across many products.

They’ll also need new piping built to feed market signals back to their AI product team: scraping social media, ingesting customer emails, watching competitors, and so on. Their team of AI agents will interpret signals, build feature specs and roll out beta features on their own—monitoring to see what “hits” and what doesn’t.

Maintaining reliability, visibility and security in these environments will be a unique challenge. 10x shifts are phase changes, like water turning to vapour—we won’t just need bigger tools, we’ll need different tools.

There’s a great opportunity for someone to build AWS for the AI era. And many companies will build proprietary software, like quant funds do.

Volatility and Flash Bubbles

High speed automated trading, combined with leverage and front running, can create feedback loops, which result in flash bubbles and flash crashes.

If everyone is front running everyone else, with leverage—it will mean one successful company will quickly become 100 copycat companies—all competing for the same advertising spaces—all competing for the same customers.

Exchanges eventually had to control and regulate activity in order to combat these feedback loops. “Circuit breakers” trigger to halt trading activity when excessive volatility and feedback loops are detected.

It will be a long time before circuit breakers come to SaaS, so we’ll need to be wary of getting sucked into runaway copycat feedback loops. Relying on front running alone is very risky—we still need original ideas.

Order Flow

Order flow, the list of incoming trades on an exchange, is a coveted asset that enables front running. Robinhood originally made money by selling its order flow to hedge funds, rather than charging fees to retail traders. This enabled hedge funds to better front run retail traders.

Who gets to see the “order flow” of opportunities being bet on in software, before anyone else? Although large scale funds may be at a disadvantage in terms of latency, they currently have the clearest view of order flow. For now, they are able to front run, and they can help their portfolio companies front run, by having a broad view of all the bets being made in the market.

Stealth Becomes Cool Again

“Ideas are worth little, execution is everything”: that’s the startup mantra for the past two decades. NDAs are taboo in fundraising. You’ll get laughed if you ask a VC for one.

But what about when execution becomes 10x easier with AI? What about when everyone is trying to front run with superhuman speed? Then ideas start to gain more relative value. A one month lead on executing an idea starts to become meaningful.

I predict we’ll start to see smart founders become more sheepish about sharing their plans. They will pitch less and more selectively. Trust will be more important than ever.

There’s another advantage to startups and VCs merging into a singular edge fund entity: it keeps order flow confidential. LPs may end up investing directly in these entities, without knowledge of how exactly their magic works or about what products will be launched.

Edge funds may operate with extreme privacy, like Renaissance Technology’s Medallion Fund.

Black Box Algorithms: Embracing Illegibility

Complex AI systems, pushed to peak performance are illegible: they are messy, organic and hard to pull apart into components that we can easily make sense of. They’re like a massive matrix of numbers.

If you play chess against a top AI engine, it will make moves that are impossible to reason about. The engine is viewing the world as a large matrix of numbers. Its strategies can’t be explained using simple narratives like: “a great offence is a great defence”.

Similarly, trading firms train blackbox machine learning algorithms which work well, but that can’t always be understood.

Both investors and companies may need to learn to trust AI recommendations even when those recommendations can’t be explained simply in words.

We’ll gain trust in these systems through backtesting.

Backtesting

How do we know when we can allow AI to take over bet making for humans? If the AI has developed a positive track record of making good bets over years—you can extrapolate those returns to the future.

But what about when an AI system is brand new? In trading, firms backtest their automated strategies against historical data to see how they would have done. They feed in historical data and test to see when the model would have bought and sold.

Backtesting is harder to do in software, as our market orders and their results are a lot more complex to model. How would your ideal customer have responded to a hypothetical ad 5 years ago? It’s hard to say.

But elements of SaaS companies are backtest-able. For instance, we ran a backtest recently to see if an AI PM could have come up with the right feature ideas before our own team did, by feeding in customer feedback. In a couple cases, it did beat us.

AI Fracking Kills Bootstrapping

The vast majority of retail traders lose money. Professional traders have too much skill, speed and leverage for retail traders to be able to compete.

There are specialized crevices of the market where a retail investor might have an advantage over Wall Street. Maybe you could learn about a small cap company that doesn’t have enough volume to be interesting to funds.

However, AI algorithms can split their attention in a million directions at once. They can watch all assets, all the time. The better AI gets, the more it can crawl into deep crevices, “fracking” alpha from the market.

Similarly, bootstrapped companies have been able to do well filling needs in small crevices of the market—where the prize is too small for VC-backed companies.

But what about when VC-backed companies have 100 AI tentacles that can reach into these micro-segments?

This is already happening: I spoke with a company the other day that used AI to spin up over one thousand integrations in a month. Previously entire bootstrapped companies existed to service one obscure integration. These crevices in the market are about to be filled by well-capitalized companies, leaving little for bootstrappers.

Winner Takes All

The VC power law will amplify even further. Winners won’t just win one war—they will build a machine that will win hundreds of wars across many products and markets.

Every SaaS company will become a threat to every other SaaS company, as we develop AI tentacles that reach across geographies and verticals. Top SaaS companies will look like top hedge funds.

What Software Companies Should Do

When quants build trading algorithms at Renaissance Technologies, they are not allowed to override the algorithms to make manual trades. They trust their algorithms more than they trust themselves.

Software engineering may take a similar turn over the next 5-10 years, where we must focus on coding the “meta-software” that is ingesting feedback and building products—not on the individual product commits.

We’re not there yet, but there’s a lot companies can do today:

• Set up an automated product development workflow that can identify new opportunities and prototype them

• Prepare your team to operate with comical speed: many things that would have previously been impossible are now possible. Don’t let your team be traders in the pit rolling their eyes at electronic trading.

• Prepare marketing infrastructure to run many product marketing experiments simultaneously—you should be able to stand up and manage landing pages with AI

• Start backtesting AI systems (like an AI product manager) against your historical information flow to see where they can beat you, and where they can’t

Welcome to the high frequency software era.

Modularity is seductive in product development: Rather than doing one thing, give the user a system of components—ingredients. Allow them to combine those ingredients to create the workflow they need. Kill 50 birds with 1 system.

I tried this a lot in my early journey as an engineer, and it failed 90% of the time. Now I believe that this tendency—let’s call it Modularity Bias—is one of the most common risks for early stage product teams.

Avoiding Hard Choices

Modularity is seductive because it frees us from the anxiety of making hard choices.

Building a great product requires tradeoffs. You need to say “no” to 80% of what customers ask for, in favour of the 20% that deeply matters. Otherwise you end up with a bloated product that serves no person in particular.

It’s stressful to make these subjective calls, so we gravitate towards building a solution that can “do it all”.

It’s easy to imagine how the meetings play out:

“Users want X, Y and Z—which should we focus on?”

“Easy—we can build a flexible system that can support all of those needs.”

It’s difficult to disagree with a position that makes every stakeholder happy.

Mentally, it’s like a completing a satisfying Sudoku puzzle. Snap, that’s it! We don’t need to make any hard choices. We can plug the hole elegantly in a way that satisfies all our needs. When you’re inexperienced, these solutions feel like architectural genius.

But…

Modular UX Almost Never Works

1. Failure by Complexity

Modular experiences require at least one extra layer of engineering complexity. This complexity spirals out in unexpected ways. A 1 week PoC becomes a 3 month PoC, becomes a 12 month herculean effort. Most modular products don’t succeed because they don’t get finished (see the reference to Phonebloks at the beginning of this article).

2. Failure by Bad Abstractions

If a modular product does get to a v1, it probably still sucks.

Reality has a surprising amount of detail (blog post). The lego brick abstractions we thought were genius start falling apart the moment we contact reality. We get feature requests that destroy our mental model—and we find ourselves rearchitecting 50% of the system we spent months building.

This is brutal if we’re still “exploring the idea maze”. Most product ideas are wrong. In this failure mode we may have slowed our iteration speed by a factor of 10 with no great benefit.

3. Failure by Bad UX

Even if we do functionally accomplish everything users asked for—our UX will often still cause the vast majority of users to churn.

People have become accustomed to hyper-specific, opinionated workflows in consumer products. In the age of TikTok attention spans are at an all-time low. Any moment of confusion or open-endedness can cause a user to bounce. The most successful UX in 2025 is the one-way doomscroll. No decisions at all: just scroll down.

Users generally won’t read your documentation. They won’t join a training call. And they definitely won’t “imagine the possibilities”. Either the guardrails force them to be immediately successful or they bounce.

It takes so much thoughtful polish to build a simple experience that 90% of users can flow through without issue. It’s typically impossible to do this kind of polish if you are optimizing for infinite flexibility.

The vast majority of people want toasters and kettles, not material heaters and water tanks. We can build much better, much simpler products when we build things that have a single purpose.

Start with the Specific

There’s an easy solution to this problem: always start by designing the optimal, non-modular experience for a user. What does the absolute peak, single-purpose experience look like? Bet with conviction on what exactly your user wants to do, and think out every detail for the best possible experience for that specific workflow.

Once you know what the optimum looks like, you can consider tradeoffs in the direction of modularity:

• Are there existing components we could use to quickly build a compromised version of the vision?

• Should we build a quick brittle, inflexible version to test our assumptions rapidly?

• Or—is this a rare case where modularity might actually work well?

Generally I think a team should only commit to modularity when they have released a specific feature with proven product-market fit, and they are looking for ways to scale and expand that feature longterm. Otherwise, the team should start with the specific and assume that v1 will fail. You may need to build many brittle versions before finding something that hits.

Hidden Modularity

Up until now I’ve been speaking about user-facing modularity. But what about engineering modularity that is hidden from the user? This can useful and necessary—but it often still fails due to bad abstractions and complexity—and we need to be careful about how it leaks into the user experience.

My earliest memory of architecture leaking into the UX was seeing the gameplay code for Jumper (a precursor to Celeste and inspiration for Super Meatboy). Most game developers I knew would build a simple modular physics engine for their game, and then tweak a handful of physics parameters to get movement. A realistic physics engine seems like a flexible solution that can solve a lot of gameplay problems.

…And then when I saw the gameplay code for Jumper, I saw something entirely different: A wall of bespoke, monolithic code, hand-tuned “magic numbers”, deep nesting of if/else statements. A wall of movement logic that felt completely bespoke and immodular—completely unrelated to real physics.

And the game felt better than any platformer game I had played at the time. Because it was optimized to feel good to the user in a very specific use case, not optimized for implementation elegance or code reuse. It was optimized to solve something very specific, not the broad problem of physics.

Developer experience is important. But UX needs to come first, because most products fail not because they are technically difficult to build, but because users simply don’t like them.

Flexibility Through Simplicity

There’s one kind of product flexibility that works well: simplicity. If you can reduce the number of moving parts in your user experience, if you can really get to its essence—then users will find many uses for your product without confusion. The simplicity of ChatGPT’s chat box, or of Apple’s Notes app, are examples of applications that can serve a broad number of use cases through simplicity—not modularity.

The simplicity of my air fryer makes it a great way to make vegetables, meat, fish, french fries, nachos, meatballs and many other things. But there is no “fish” module. No “french fry basket”. These modules would complicate the product more than help it.

The Obvious Counterpoint: Enterprise Software

What about enterprise software? Companies like Salesforce have made a killing selling ridiculously configurable products.

1. These Products Aren’t Good

I didn’t assert that you couldn’t sell these products, only that they aren’t good. I’ve never met someone who said they loved Salesforce, other than the consultants that make a killing maintaining it. I have met people who love more opinionated CRMs like Hubspot and Pipedrive.

2. These Products Are Good for People Who Need a Reason to Get Their Hands Dirty

Modular products are extremely sellable to innovation committees and internal development teams who want to show their chops. If you want to be paid like a chef, you want to buy ingredients and show what you can do with them, rather than ordering a fully prepared meal from a restaurant. Enterprise buyers often have a team of people that want a reason to get their hands dirty.

3. Configuration Lock-In is a Good Business Model

Enterprise products can take an entire development team to setup and maintain. Once you’ve made this investment, it becomes extremely difficult to migrate to any other platform. Your Salesforce Apex code won’t run on Hubspot. This makes modular enterprise software an extremely retentive business, even if the products aren’t great.

It’s a valid way to win. But if your joy is product craft? Pure enterprise SaaS may not be the place for you.

Modularity in AI

The idea that chat systems like ChatGPT and Claude will simply hook into all your favourite apps through MCP and dominate all AI use is just another example of the engineer’s modular fantasy.

History has shown repeatedly that specific, monolithic, purpose-built workflows tend often win in the end. For example—there is a tactility to tuning designs in Figma that can never be achieved through chat prompts. Single purpose UIs for AI workflows are needed in all verticals.

I walk on trails daily, and we get a lot of snow in the winter. 95% of the time I wear a pair of runners, because the snow is so packed that it's like pavement. It doesn't get cold enough to make my toes cold, either.

Every few days I come across people on the same trails trudging slowly with snowshoes and hiking poles.

Usually it's irrational for the conditions. They’re going 3x slower than they would with sneakers, and 2x slower than they would with winter boots.

I imagine them thinking: "There’s snow, so I should wear snow shoes". Or maybe they didn’t check the conditions. Or maybe they just had a romantic desire for snowshoeing that they had to fulfil.

Snowshoes in Organizations

A lot of bloat in organizations looks like this too:

Tools

We implement clunky tools that seem like they are “right for the job”, not realizing how much they are actually slowing us down—and how a “worse fit” but adaptable tool might serve us best. Similarly to having a romantic desire to snowshoe, we can feel a romantic desire to use a lot of technologies, or want to pick the tool that “checks the most features off the list”.

New Hires

This comes up in headcount planning: a new problem comes up like, “we need a better social media presence”, and the solution is “let’s hire a dedicated social media manager”. If you repeat this 50 or 100 times, you’ll have a very bloated and inflexible organization. Rather than hiring a snow shoe person (a deep specialist) to solve every problem, in many cases you could have just hired more sneaker people (great generalists who can help you solve a wide range of problems fast and adaptably). This is especially important in startups, which demand agility.

Process

Thirdly, this comes up as over-architected process: we have a desire to design robust processes that “check all the boxes” for our problem. We may have a romantic attraction to the idea of processes humming smoothly. But rigid process can result in people walking 3x slower in snowshoes. Even if process provides safety from errors, it’s often not worth the friction.

Bloat is Seductive

When people get frustrated with organizational bloat, it's often not overt waste that they are talking about.

They just see people walking 3x slower than they need to because they're wearing snowshoes.

They point out the inefficiency and people say: “Well, it’s snowing, of course I’m wearing snow shoes. I’m not going to wear sneakers. Are you crazy?”

It’s hard to convince people that they don't need snowshoes when there’s snow.

The dopamine reward I talk about in How to Finally Make Something is also incredibly seductive. Real creativity and real problem solving is deeply ambiguous and anxiety-inducing. Playing “match the tool to the problem” or “match the hire to the problem” gives us a reprieve: a concrete dopamine reward like what we get playing Sudoku or snapping together legos. We wish that if we selected the right two lego pieces, they would snap together and just work. But nothing ever works that way.

Snowshoe Groupthink

We are social creatures who continually underestimate how much we are motivated by our need to fit in. When we undertake an identity like “engineer” or “executive”, there is intense pressure to look the part. We look around at what others are doing and often mirror it. We know that we won’t be singled out if we do the same thing others are doing.

That’s how you get a team of 500 people all wearing snowshoes.

Caveats

There is of course a time and place where snowshoes are warranted:

1. It is rude to break fresh trails with your boots or sneakers, as it makes it bumpy for other walkers, skiers and bikers.

2. Sneakers are also just not going to serve you well in breaking trails. If you are exploring off the beaten path, you might need snowshoes.

It takes a nuanced understanding of the world to recognize when the situation calls for a specialized tool.

Most of my losing bets, in both business and investing, were driven by narrative reasoning: short compelling stories about the world that sound smart.

“Marijuana is about to be legalized in Canada. This is a rare opportunity to invest at the ground floor of a new industry.”

“I’m going to invest in a cobalt mining company because they won a contract with Tesla.”

Before we launched Spellbook, we thought: “Let’s launch Shopify for Lawyers, because hourly billing lawyers care more about getting business than efficiency”

We love stories. Narratives are like a virus and a mind-altering drug. When they hit our ears we feel: “Ah! That makes sense”. They add clarity in an overwhelming world. And then we feel compelled to share the story with others. The clarity felt good and we want to share that feeling. More importantly, sharing the story makes us feel smart.

This contagiousness makes narrative reasoning extremely dangerous. Because simple stories often make horrible bets.

Multi-Causality

Concise stories don’t work well to drive action in the real world, because the real world is so multi-causal. There are hundreds, or even millions of factors that cause a bet to have a good outcome.

Imagine the best chess AI engine in the world: for any board state, it has to consider hundreds moves, and then a huge number of branching futures. Great chess engines can’t simply use narrative reasoning like: “a good offense is the best defense” to win. These engines are more like spreadsheets: massive matrices of numbers and probabilities. They can make moves that are impossible for us to comprehend using language-based reasoning.

The worst part? Real life is way more complex than chess.

From this we can conclude that the most optimal way of strategizing about the world is definitely not by using a short sequence of words.

Legibility Bias

Raw reality is not very legible. That is, it’s not simply structured and easily comprehensible by us. Although narratives make us comfortable, they’re not enough to capture the essence of reality. Reality is messy.

One of the most impactful things I’ve ever read is Venkatesh Rao’s “A Big Little Idea Called Legibility”. It talks about how we are drawn to orderly, legible systems—but how those systems often fail. We even tear up messy, working systems, replace them with nice orderly systems, and see the order fail terribly. We put too much value on legibility. Let’s call this legibility bias.

For instance, in the image below there is a legible “scientific forest” and an illegible organic forest. “Scientific forests” were a failure, even though their legible structure made us feel confident in the approach. Messy illegible forests remain successful.

Why does legibility bias persist across society, even when we are aware of it? One answer is: it soothes people. We are conditioned from kindergarten onwards to believe that there is a crisp, clear structure to the world. That there are crisp reasons why things happen. In the world of startups, that illusion is demolished if you stick at it long enough. But large organizations “cast the illusion” of legibility to soothe and create a sense of order among employees, while those in the inner circle of upper management face messy reality head-on.

Also in organizations, communication bandwidth means that you need crude, simple stories to get the ship headed in the right direction. Simple stories are a necessary evil in management. But big decisions at the top of an organization are not actually being made this way. Simple stories are a tool to motivate and direct people in approximately the right direction.

If someone has spent years at a large company, and has not been in the “inner circle” of management—it is easy to see how they might confuse the tool that is being used to motivate them with the process in which effective decisions are actually being made.

People misunderstand the utility of simple stories. They’re more of a management tool, a political tool, a motivation tool, and a marketing tool than a decision making tool.

Finding Alpha By Correcting Against Legibility Bias

Good bet making is about “finding alpha”. That is, betting on opportunities that others have underestimated. Since humans have a strong bias for legibility, highly legible bets get bandwagoned.

For example: “Since marijuana just got legalized in Canada, I’m going to buy $WEED stock to get in at the ground floor of a new industry”

Here’s how that worked out:

Even if these narratives are correct, they are too visible to markets and get quickly over-bought. In other words: The stock price gets too high before you make your bet. Or too many competitors get to the business idea before you. Or too many musicians make similar sounding songs. This reasoning works across any competitive domain.

A really good place to find bets that are underestimated is in the illegible.

Intuition

If stories don’t work, how do we survive at all in a world so complex and multi-causal? Well, simple stories can work for basic survival: “I need to eat to survive”.

But to find good bets that others don’t see, we need to leave crisp stories behind and think more like a chess engine. We need to digest raw hyper-dimensional reality. But how do we do that without putting our situation into a 100,000 x 100,000 spreadsheet?

The first answer is: intuition.

We already have 86 billion neurons in our brain that are doing something similar to a chess engine. We can’t see exactly how it works, but it can send us much more valuable signals about the world than narratives do. If we digest enough data, our brain starts pattern matching automatically. Pattern matching is how we position ourselves to throw a basketball and recognize our friends faces. Those are not things we think about in words.

Running fast using intuition to make decisions can be extraordinarily effective.

But what if our intuition is bad? What if our intuition differs from that of our team?

Manual Pattern Matching for Teams

That’s a lot of words to say: “trust your gut!”. But what if you haven’t developed intuition? Or what if your intuition disagrees with the intuition of your team?

There is a slightly more legible approach that I’ve found effective:

Look at your past bets and ask yourself: what are the 10-20 attributes that mattered? List them out, and then go through each of your winning and losing bets, noticing which attributes they had.

We did this for all the product feature bets we made at Spellbook, and were able to correlate 16 attributes with what made a successful product bet. And many were surprising.

Almost none of our correlated attributes had to do with the narrative of the feature itself. We discovered a bunch of other things that mattered:

• Can a lawyer get value from the feature instantly with absolutely zero configuration?

• Was someone on the team so inspired to build something that they “started without permission”?

• Is the feature “whole” rather than a stepping stone to get somewhere else?

• Can the feature be fully prototyped in 2 weeks?

We ended up with a framework that is a middle ground between legible, narrative based reasoning and intuition. And the best part is we could objectively score prospective bets in this framework.

It brings us a little closer to reasoning like a chess engine. These signals increased our hit rate significantly when we used to not hit at all.

For years we had been listening to the gospel: “talk to your customers! Build what they ask for!” This was helpful, but it had an catastrophic blindspot that was causing us to make losing bets for years.

We were missing an entire universe of patterns outside of the tunnel vision of stories.

Pattern Matching in Investing

This approach also helped dramatically improve my performance in investing.

When I started noodling in active investing almost 20 years ago, I relied on narrative “reasons” and news headlines to make bets. My active portfolio produced neutral returns for nearly 10 years (adjusted for inflation, that’s a big loss). Those narratives simply didn’t capture the thousands of factors that impacted stock price. And if they did: well everyone else was jumping on the same bandwagon and pushing up the buy price where the bet became too expensive to make sense.

Over the last 9 years I switched to a pattern matching approach. My active portfolio has performed ~20x better than my passive portfolio over that period.

To improve my ability to pattern match, I really like to “soak” in data. I read lots of charts and try to make written predictions on them regularly. I check back on how my predictions fared. Eventually making trades started to feel like throwing a basketball. My brain started to develop a deep intuition for technical and fundamental signals, and how they combine to make a “swish”.

Independent-Mindedness

Pattern matching is not hard. Our brains are wired to do it. The hard part is being independent-minded enough to believe your own conclusions.

To do that, you need to escape the universe of simple stories we are surrounded by. Stories are the threads that hold society together. We are fish and stories are our water. Repeating popular stories grants us head nods and social acceptance.

For example, “You can’t beat the market, dollar-cost average into index funds!” is the kind of viral story that will earn you nods of approval from millennials and upvotes on Reddit.

Pattern matching, on the other hand, can drive you to make moves like an advanced chess engine. Moves that others find alien and incomprehensible.

If your bets don’t generate some confused looks, they’re probably too obvious, and thus overdone.

“To believe that what is true for you in your private heart, is true for all men,—that is genius” —Ralph Waldo Emerson, Self-Reliance

I originally wrote this in October 2022, around the time that we launched Spellbook. It has been lightly edited and republished as a lead-in to an upcoming "What AI Agents Mean for Lawyers" post.

When I wrote this, we knew that something big might be coming, but had no idea that Spellbook was about to be adopted by 2000+ legal teams worldwide.

This blog is about bet making as a kind of competitive philosophy: seeing the truth about the world before others do. It’s useful to reflect back on what “great bets” about the future felt and looked like—so that we can recognize them again.

I think we might be in a similar moment again as agentic AI enables complex multi-step legal workflows to be automated. More on that soon!

Why AI-powered lawyering is actually here this time

Lawyers have put up with a lot of false promises from technologists. Besides email, search and the Word processor, legal workflows still haven’t become much more efficient—despite the creation of hundreds of legaltech and legal AI companies over the past couple decades.

I think that’s about to change.

GitHub Copilot is an AI assistant for computer programmers that has altered the profession’s perception of what AI is capable of.

It’s powered by OpenAI’s GPT3 large language model (LLM), and is like a super-powered autocomplete that suggests the text you’re looking for before you’ve thought of it yourself.

It sounds simple, but in practice it can help a programmer move 10x faster. In the example below, a programmer is trying to write code to fetch the text of tweets from a Twitter user. After typing a few characters, the AI gets the gist and outputs the rest of the code needed for the programmer!

What does this have to do with the legal profession?

Lawyers and software engineers have a lot in common. Both spend their days working with text & logic. Both are trained skeptics, who have the important job of finding problems & shortsighted thinking. Both have been very skeptical that AI could alter their day-to-day.

And, for both professions, there is a massive database of text on the Internet to train large language models on. Take the SEC’s EDGAR for example, it has over 400,000 contracts in it alone.

The Success of GitHub Copilot

GitHub Copilot is the first AI product for programmers that has broken through their skepticism. And for good reason.

Quantitative data below shows how GitHub Copilot enabled engineers to complete a complex task over twice as fast!

Subjectively, engineers love the experience too (and again, they hated the idea of AI tools until now):

I’m a software engineer too, and the first time I used it, I couldn’t get over the feeling of Copilot “thinking ahead of me”, sometimes by miles. It would output confusing code, which I believed was wrong. Then 10 minutes later I would realize the AI was foreseeing a problem I hadn’t even considered.

Wow. I really had never felt a machine “thinking ahead of me” like that before.

The Magic of GPT3 for Lawyers

After our engineering team had this experience with GitHub Copilot, we raced to prototype Spellbook, an analogous tool for transactional lawyers using the same technology.

After selling template-based automation software to lawyers for 4 years—this was a big “aha” moment for us.

Lawyers wanted to make their routine drafting workflows more efficient with templates, but every customer had the same problem: templates struggled to capture the nuance of their bespoke deals. They ended up going off the rails and ditching templates, even after working on their templates for months. They did not work in “structured text”, everything they did was bespoke at the end of the day.

Using GitHub Copilot was the first time we felt that a tool could riff off our own unstructured text, and truly speed up the production of unstructured text, by as much as 10-fold.

It also worked immediately out of the box, without tons of upfront work like template building.

First Use Cases

Here are some examples of some of the things we were able to build so far, right inside Microsoft Word:

1. Drafting New Language

Much like GitHub Copilot does for lawyers, Spellbook “auto-completes” the section you’re working on, or can draft entirely new sections based on a heading. This is shockingly useful. What feels really magical is how it interprets the context, tone and defined terms in your contract to generate full paragraphs that fit really quite well.

I love how my friend, attorney Ryan Juliano from Howell Legal, put it: “It may not be perfect, but it gives you marble to carve where you didn’t have any.”

‍

Auto-Completing a Section by Typing “+++”

‍

Drafting a Section with Some Additional Instructions

2. Reviewing Documents

Not only is GPT3 able to generate text, it’s also able to provide insights on text:
‍

Find Missing Clauses
In this example, we're able to instantly list clauses that may be missing from an agreement.

‍

Explain Section
We're able to explain sections or entire contracts in language a 10 year old might be able to understand! Great for sending clients explanations.

‍

Finding Key Dates
We're able to extract key dates from a document, instantly, no matter how buried they are.

Just Scratching the Surface

These are a few quick applications of LLM technology for lawyers, but there’s a lot left we’re excited to try and build. I anticipate many other legaltech companies will build new features on top of this technology as well. It may take a decade to understand the impact of the technology on legal workflows.

What makes us even more optimistic is the rate at which this technology is improving. GPT4 is just around the corner. We are using the worst version of this technology that we ever will, and it’s already enabling 10x workflow improvements. I think it’s safe to say: large language models are about to change everything in legal, and they’ll be with us for a long time.

Maybe AI-powered lawyering is finally here this time.

“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” - Abraham Lincoln

Does it make sense to spend hours sharpening our axe when the chainsaw will be invented tomorrow?

Maybe it doesn’t.

There’s a threshold on the technology acceleration curve where new technologies are released faster than we can master prior technology. There were nearly 8000 years between the invention of the axe and the the chainsaw. There were 4 months between the release of ChatGPT and GPT4!

Mastery Dividend Period

In other words, axe mastery paid dividends for up to 8000 years: over 100 human lifetimes! Optimization and mastery have been no-brainer investments for most of human history.

But we’ve crossed a threshold where the metagame has fundamentally changed. Mastery of tools no longer pays dividends for the rest of our lifetime—we’re lucky if a new AI tool stays relevant for 12 months! It’s incredibly disorienting when the “sharpen the axe” strategy that worked for thousands of years suddenly stops working.

There are two overwhelming sentiments on AI Twitter:

1. The Axe Sharpeners: I’m overwhelmed! How is anyone supposed to stay on top of the firehose of AI advancements? I’ll stay on the sidelines for now.

2. The Blunt Axe Choppers: I have no idea what I’m doing, but look at this cool thing I built in an afternoon 🤷

There is an anxious sense of paralysis amongst the Sharpeners who are used to finding victory via the dividends of skill mastery: Will the skills I learn today be relevant tomorrow? Why build something today when better technology will come out tomorrow? Why invest in an AI company today when everything will fundamentally change tomorrow?

Many companies that invested deeply in building ML expertise before LLMs are now struggling to compete with blunt axe choppers who are outperforming their proprietary models using GPT4. They’re desperately marketing why their fully custom approach is better, but customers can tell that the results of GPT4-powered products are often better than those that came from application-specific models or fully custom LLMs.

A Golden Opportunity

A shift in the metagame presents an enormous opportunity to generate alpha—as players grapple with a completely new set of rules. If you can adapt to this reality, you can generate huge excess returns.

I’m betting that the optimal strategy is to:

1. Dive in and get comfortable with the feeling of using tools you haven’t mastered

2. Treat the dynamic trading of tools as a the #1 skill for teams to master: Pick up new tools as soon as they are released, leaving old tools behind. Don’t get attached to the old romantic idea of mastering a single tool. Get comfortable wielding tools you don’t 100% understand.

3. Stay focused on mastering things that are stable (eg. marketing, positioning, UX, orchestration, infrastructure & data) around the rapidly shifting software foundation.

Startups are designed to succeed against established competitors in times of disruption. Small teams are able to be live players that adapt first to a new environment and write the playbooks for the decades to come.

"If you’re efficient, you’re doing it the wrong way. The right way is the hard way. The show was successful because I micromanaged it—every word, every line, every take, every edit, every casting. That’s my way of life." -Jerry Seinfeld

When we were building Mune, I was lucky to collaborate with an incredible woodworker named Don Taylor. Don built world-class acoustic guitars, among other things.

I spent some time with him in his workshop while we figured out how to bring our mere 3D design into the real world.

One afternoon I asked him, “what’s your secret?”, and his response stuck with me for a decade.

Don pointed to a guitar-in-progress hanging on the wall:

“See that? That guitar broke in half last week!

When the neck broke, I didn’t fret for a second. Not one bit. I just glued the guitar back together without missing a beat.

The secret is to learn not to let that kind of thing bother you at all, and to see it as a normal part of the process.”

Don’s mentality wasn’t just about accepting accidents. Every painful manual step, from measuring, to cutting, sanding, gluing and staining, he accepted without a hint of regret or frustration. And he would keep redoing things until he got them just right. I had never encountered that kind of patience before.

Don calmly accepted the manual toil required to create an amazing product.

Lego Brick Mindset

I grew up with Lego bricks that snapped together, and with products that behaved predictably. Woodworking overwhelmed me. Every single piece of wood was unique and needed to be treated as such. Nothing was certain.

As an engineer, I loved creating predictable, modular systems. I longed to feel the *snap* of Lego.

We can expect all sorts of things in life to *snap* together, with neat little checklists:

• Tool Syndrome: “If I use the right tools for the job, I’ll do well!”

• RFP Syndrome: “If we buy the software that checks these 10 boxes, our problems will be solved!”

• Method Syndrome: “If we follow The 12 Step Process, our organization will run smoothly!”

• Fill the Seat Syndrome: “If I hire a VP Sales, our revenue will grow faster!”

But reality doesn’t respond well to this thinking when you’re building something new. Things are always more granular than we hope for. Hidden behind every great outcome lies uncountable hours of manual toil, sanding, gluing and polishing.

It Shouldn’t be Like This

We can feel absolutely miserable when the world doesn’t respond to us like Lego.

“It shouldn’t be like this.”

“I must have made a mistake, this is so inefficient.”

“This thing is rotten at the core and there’s no saving it.”

“It shouldn’t be like this.”

After digesting Don’s words and spending a couple years working on Rally, I realized that those words, “it shouldn’t be like this” were an enormous source of stress. A drain on energy and emotional resources.

But, it was the third startup I had been part of, and I noticed the repetition of the same old problems:

• Ad campaigns didn’t work as well as we had hoped

• Users had surprising feedback, requiring tons of product improvements

• Sales cycles were longer than anticipated

“Hmm. Maybe it is like this.”

And with that, the gut-churning anxiety of foundership melted completely.

“It should be like this. The manual toil is the game.”

“Rather than playing the game, I’ve been doing everything I could to run away from it!”

When I accepted the inevitability of the manual cutting, sanding and gluing required to make something great, everything became fun rather than anxiety-inducing.

I could finally get good at that game, rather than constantly trying to run from it.

I knew a secret.

We could become master woodworkers like Don.

L is for Lego, and Legibility

Lego Mindset might sound like laziness. Sometimes it is. But it’s deeper than that. It often arises from the belief that legible systems are best. That they are what experts build.

In Venkatesh Rao’s seminal piece on legibility, he discusses how humans have a tendency to look at chaotic systems, determine that they must be flawed, and then desire to re-create them in a more legible form.

He pulls an example of failed “scientific forests”:

He goes on to cite a common failure recipe:

How often have you seen this pattern in software?

Even tech influencers like George Hotz believe in the “High-Modernist Recipe”. And he’s not totally wrong. Software developers need to refactor and tame complexity to stay productive. And sometimes do full re-writes (that’s part of toil). Yet, despite his confidence, he walked away from Vicarious after 6 months, walked away from his own startup before achieving his goals and walked away from Twitter after a few weeks. Three premature walkouts in a row! I bet I know what he was thinking:

“It shouldn’t be like this”

But not only is illegibility an acceptable trait of optimal systems. It is a trait that all systems optimized against complex realities will tend towards. The real world is complex and extremely high-dimensional. When we see a successful company that’s chaotic, we shouldn’t think: “wow, it succeeded despite chaos!”, we should think: “Of course! This is what a complex, optimized system looks like: an illegible forest.”

We believe in the power of Legos because they make our output and process legible. And we believe legible solutions are better solutions.

Manual toil & massage add a lot of illegibility to a process which is hard to describe in a task list. It’s hard to know if massaging is complete. It’s hard to explain the massaging process to others. It adds fuzziness and non-determinism. It is painful if you think it’s a symptom of bad process.

The Systems Sleight of Hand

I’ve probably spent hundreds of hours of my life massaging CSS. I couldn’t really tell you what I was doing or why. It’s mostly trial and error until the output feels great. It’s always tempting to believe that a Lego-like Design System can totally remove this toil. It is more legible and feels professional to build components in a Design System than to do style hacking. But I still haven’t seen a truly great product where a rigid design system was obeyed. Or if it was obeyed, it was built after someone style-hacked their way to something that worked. There are just too many edge cases. The eye is too fickle.

Since object-level woodworking problems are annoying and illegible, many of us perform a clever sleight of hand:

“Rather than wasting time on one-off problems, I design scalable systems to solve many problems.”

I’ve interviewed a few hundred job candidates in sales, marketing, design & engineering, and over one third of those have led the interview with this as their core value proposition. I don’t think people realize that this skill is so popular—and I don’t think they realize how extraordinarily rare it is to celebrate manual toil.

There is, of course, nothing wrong with designing scalable systems. It can be brilliant. But it is hard to do right unless you’ve built unscalable solutions first. And at the end of the day, someone needs to passionately solve nitty-gritty object-level problems. That part is important. And few people want to do it.

A lot of people think that nitty-gritty object-level problems are only for juniors, that to “level up” they must migrate to the systems level. But, in my experience, it’s the most senior people that are thinking about the nitty-gritty details. Because they have a greater responsibility to force outcomes. Forcing outcomes requires painful woodworking:

"If you’re efficient, you’re doing it the wrong way. The right way is the hard way. The show was successful because I micromanaged it—every word, every line, every take, every edit, every casting. That’s my way of life." -Jerry Seinfeld

“Pre-product market fit, the job of the co-founders is to do the shittiest, worst, low status work you can think of.” -Dalton Caldwell

Getting Good at Woodworking

If we accept the inevitability of toil, how do we then get good at it?

At the risk of being overly legible, there are two main components for me: flow and taste.

Flow

The micro-actions required to perfectly sand a piece of wood are too numerous to coordinate methodologically. You can’t put them in a todo list or a Kanban board. The only way to do 1000 tiny actions is to lose yourself in the task. To not be there. To be in a state of No Mind, organically responding to what the object of your creation requires. Whether the object is an entire company, or a UI component.

For me, I need to schedule big chunks on my calendar for these “sanding tasks” that are too numerous and tiny to put on a list. I commit fully to getting inspired and to seeing what happens.

It also helps to exercise, to sleep well, eat well, to drink coffee. It takes a lot of raw energy and inspiration to execute 1000 micro-actions.

Taste

The second component is developing good subjective taste. Polishing is inherently subjective. How do you know when to stop? How do you know what the goal is? Taste is the answer. You can develop it in two ways:

1) Consume great work & analyze it: Why do you like that song? What kind of music gets popular? What does the CSS look like for that app you love? If you can afford it, use Tier A, design-first products to set your bar high.

2) Practice and evaluate your own work: Learning to make good things takes a lot of practice. You will make a lot of bad things at first, and then you will notice why they are bad later. Keep trying, keep iterating!

Woodworking in The Next Era of Software

After working with large language models like GPT-3 at Spellbook, I’m convinced that software development is about to become even more like woodworking. LLMs are non-deterministic, especially once you start chaining calls together. Exact correctness gets traded off for flexibility and nuance. API calls become paragraphs. UI becomes conversation.

LLMs are anything but nice predictable lego bricks. They’re organic components that need to be sanded until they feel right. Building prompt chains feels more like CSS massage than programming—with some added non-determinism.

It’s hard to logically test these systems, or to configure them using purely quantitative methods.

Those who master woodworking will be at an even bigger advantage in the next decade of software development. These systems are incredibly powerful, but they require Don-like patience to polish.

But The World Still Needs Lego, Right?

It does. The reality is, most customers will not develop the patience for manual toil. That patience will become increasingly rare.

That creates an opportunity to create Lego-like products for customers. Consumer electronics will tend towards Airpods + iPhone + Macbook style interoperability. Users will still demand correctness from non-deterministic AI products. The appetite for legibility will grow.

Makers will never live in a world of Magic Lego Bricks, but, through tireless toil, we can create the illusion of Magic Lego Bricks for our customers.

Lastly: this post itself is overly legible, and doesn’t really address the nuances of reality. The Woodworking Mindset is undervalued, but it’s not the One True Answer. We shouldn’t replace the Dogma of Lego with the Dogma of Woodworking.

Sometimes, we get lucky. Sometimes things can be snapped into place. Smooth systems are crucial to the operation of any organization. Someone needs to build lego bricks.

Reality is messy and no single metaphor can make sense of it.

It should be like this.

Epilogue: Templates

I thought of this after the post was published: Woodworkers don’t use lego bricks, but they do use templates & jigs which help them repeatedly build the same parts.

Woodworking templates are a great metaphor for what real Lego looks like. They’re still organic, they can still break, they don’t guarantee perfect results. They are made of atoms that erode away. They don’t remove the need for skill. They require you to build them manually in a one-off way first. They don’t remove the need for sanding, gluing, staining and polishing. But they’re a hell of a lot easier than cutting the same parts from scratch every time.

In my experience, this is what real life legos feel like. A good design system is minimal and doesn’t try to do too much or to be overly prescriptive. Good cultural values are to be interpreted flexibly. We can systematize lots, as long as we aren’t looking for Magic Lego Bricks. Magic Lego Bricks are an illusion reserved for customers.

Since we launched our GPT-3 tool for lawyers, I’ve heard founders and investors calling this kind of product ‘too easy’. Is it really defensible if you don’t have a team of 10 PhDs and terabytes of documents to train on? Surely tinkering is not enough? Surely people should take some machine learning courses before trying something like this?

Yet, self-taught hackers like Pieter Levels are launching successful AI apps and getting into the New York Times in ~15 days—using pre-trained transformer models.

…And then Pieter launched a second acclaimed AI product a few days after that.

Are these products “too easy”? Or are they clever?

My favorite piece on this duality is an excerpt by an ex-professional Street Fighter player titled Introducing… The Scrub, from his book Playing to Win. In it, Sirlin reveals the biggest trap that intermediates fall into:

“A scrub is a player who is handicapped by self-imposed rules that the game knows nothing about. A scrub does not play to win. In Street Fighter, the scrub labels a wide variety of tactics and situations ‘cheap.’ This ‘cheapness’ is the mantra of the scrub.”

The “scrub” believes that by learning to play the game the proper way, they will come out on top in the long run—that exploiting cheapness is shortsighted and doesn’t build skill.

Scrubs play for an imaginary version of “mastery”, while top players Play to Win:

“There is the mistaken notion, though, that by merely continuing to play or ‘learn’ the game, one can become a top player. In reality, the “scrub” has many more mental obstacles to overcome than anything actually going on during the game. The scrub has lost the game even before it starts.”

“You will not see a classic scrub throw his opponent five times in a row. But why not? What if doing so is strategically the sequence of moves that optimizes his chances of winning? Here we’ve encountered our first clash: the scrub is only willing to play to win within his own made-up mental set of rules.”

The scrub distrusts moves where skill is not demonstrated. They believe that winning in the long-run comes from the development of skill. It does, but the most important skill is finding and exploiting asymmetric opportunities as often as possible. Pros won’t even do that just once. Like in the Multi-Armed Bandit problem, they will pull a lever that has high expected value as many times as possible. 100 times, 1000 times, 1,000,000 times. They don’t care if it’s boring, low-minded and looks skill-less.

And unlike Street Fighter, real life is not a well-balanced video game. Real life has far more “cheap moves” than video games do, and new opportunities like GPT-3 pop up all the time, until they are eventually exploited and drained of alpha.

Would you rather invest in a company that only finds hard ways to delight its customers, or would you invest in one that finds easy ways to delight its customers over and over again?

It does take skill to win, but the skill is not what we initially believe it is.1 The most important skill is hunting for asymmetric opportunities and exploiting them repeatedly.

Will you use this secret to delight your customers, or call GPT-3 “cheap”?

I’m the co-founder of legaltech company Rally and we just launched Spellbook, which is GitHub CoPilot for legal contracts. Check it out here 🪄

If you’ve ever run a startup, you probably know the sinking, dreaded feeling of time slipping through your hand like a pile of sand. No matter how much grasping, sprinting and prioritizing we do, there never seems to be enough time in the day to accomplish what’s needed.

Is this just an illusion? Are days really so short?

The ubiquitous answer is: “Yes, this is just an illusion! Time is actually abundant! The secret is to work smarter, not harder.” But the popularity of this advice is likely in large part due to its high “advice virality”.

Unfortunately, this advice is not so different than the “one weird trick” that promises to help you lose weight without diet or exercise.

I’m here to blow the whistle: scarcity of time is the stark reality of an early-stage founder, and a founder needs to face this head-on in order to get anywhere.

If it weren’t so taboo to point this out, I think we’d have a lot more successful companies, and fewer founders wondering why they’re so stressed and not making progress.

Pushing the Boulder

Success in building anything, especially a startup, requires pushing a heavy boulder up a hill. Depending on your role, pushing the boulder can mean different things, but it always involves completing tasks that only you can do. You can’t push the boulder by reading, meeting, brainstorming, sitting at your desk, getting groceries, sleeping, exercising or going keto.

The only way to move the boulder is to consistently apply force directly to the boulder — to do the real work.

And if you don’t keep your hands on the boulder, it will roll back to crush you. Lack of progress becomes team demotivation, and eventually exhausts available time, energy and money.

Someday, the boulder will get to the peak of the hill and it can begin rolling down with its own momentum, but that’s a later stage!

Founder Time Budget

Below is a sample time budget showing how much time an early stage technical co-founder might have to actually push the boulder forward in a day:

This leaves a startling 2 hours a day to actively push the boulder. The rest of the time is spent on company maintenance or life.
 
The good news is this: if you can find 2 hours per day to work deeply on hard problems in your business, you will be doing better than most, and excel. The bad news is: this slim margin causes many to allow themselves to slip into runaway time debt.

Sinking into Time Debt

Let’s examine what happens if the founder experiences a single sick day, using the budget above: The founder will end up with a ~6 hour debt of maintenance work — this is missed work that is required, but that does not move the boulder forward. They also miss their 2 hours of boulder pushing during the sick day.

Paying off the 6 hour maintenance debt requires sacrificing three more days of boulder pushing sessions.

Four boulder pushing sessions total — almost an entire week’s worth of progress — has been decimated by a single sick day!

And what if something else comes up while paying off the time debt? An unnecessary meeting, a flat tire, a technical fire or a trade show? The debt continues to pile up!

To make matters worse, this debt bears a significant interest rate. An overwhelming list of things to do, combined with a lack of visible progress in boulder pushing, leaves founders and teams discouraged. Their ability to pay off their debt decreases by the day until one day they are time and motivation bankrupt.

If you hang around startups, you’ve seen the same unfortunate pattern again and again: people working really hard just to maintain their company, while seemingly getting nowhere. I believe runaway time debt is often the root cause of this.

This also highlights the importance of being able to say “no” to unimportant obligations and opportunities. A day at an unnecessary conference, an unnecessary day of meetings or a bad night of sleep have the potential to set off a disastrous chain reaction.

Mitigation

So — every early-stage founder is teetering on the edge of irrecoverable time bankruptcy. Isn’t that exciting?

Fortunately, those who perceive the utter seriousness of this risk, will usually find ways to mitigate it. Here are a few of the steps I’ve employed to maintain constant boulder-pushing force:

• Reserve one entire day each week for recuperation and deep work

• Say no to unimportant events and obligations. (Even use this post to make your case on why you need to protect your time, that’s partly why I wrote it)

• Ensure you know what your real boulder pushing tasks actually are (often difficult things that only you are able to do)

• Delegate anything that you don’t do best

• Keep the amount of maintenance work in your personal life to an absolute minimum. Use good procrastination on errands that can be pushed off. Many tasks such as cleaning, cooking, grocery shopping and filling the gas tank, are more efficient to do in larger batches less frequently.

• Be scrappy (strategically cut corners where possible)

The next comments go counter to popular self-help wisdom, but for me, they are the most important learnings, because they go unspoken. This advice may be perceived as taboo:

• Put in extra evening/weekend time to pay off time debt when you sense it’s starting to pile up

• Don’t work when totally burned out. Figure out what you need to get into a productive mindset (sleep, exercise, food, mental rest). But note that you can ultimately never relax or vacation your way out of time debt — and trying to do so can be quite stressful as you feel your debt accumulate exponentially. Relaxation comes naturally when your debt is manageable or paid off.

Caveat

I asked my friend Joe Teo to review a draft of this post, and he pointed out a really important caveat: pushing the boulder means very different things at different stages of a startup, and a failure to recognize that shift can also be devastating.

On day zero of a startup for a technical founder, pushing the boulder may strictly mean programming, but if that founder continues to believe that’s their job with a team of 20+, they’ll be in for major trouble. More and more, the job becomes about enabling a team to consistently push the boulder — the founder’s boulder then consists of management and directing the vision.

But while the mistake above is made frequently, it is has typically been discussed more openly. This article was aimed at illuminating a more taboo truth from the earliest stages: there really is no time.

Note: I wrote the first draft of this during the earliest stages of Rally, where it was just 3 co-founders hacking away with no VC backing. That is the context where this advice is most relevant. I’ll be reflecting back on this, and updating it, as Rally grows.

Scott is the co-founder and CEO of Rally, a legaltech software company which seeks to save significant lawyer and founder time.

Growing up in the early 2000’s, I spent a lot of time participating in online creative communities. This experience planted a question in my head— a question that would come to define a big portion of my life:

“Why do 99% of people struggle to get past the first mile in their creative projects? How could I join the 1% that actually make things?”

After a decade of introspection, creative attempts and reading, I found an answer that worked for me. Overcoming the barrier to freeform creation has felt like one of the best things that’s happened in my life.

If you’re a creative yearner like I was, I hope this insight will help you overcome the barrier too.

The Problem: Fantasy Games

Creativity ultimately means stepping forward without knowing where we’re going. Unfortunately, unstructured and ambiguous tasks make us anxious.

To avoid this anxiety we constantly substitute playing the real game of creation with other activities that feel more structured — what I’ll call “fantasy games”.

Most of the time we do this subconsciously, without even recognizing it. Many of us have been doing this for almost our entire lives, and will continue to do so until death (unless we intervene).

Making something original simply requires avoiding playing these fantasy games too often, in order to play the real, scary game of creation. That probably either sounds too simple, or too ambiguous — but let me elaborate below.

I’ll nickname four ways this ailment shows up as:

1. Learning Syndrome

2. Tool Syndrome

3. Process Syndrome

4. Maintenance Syndrome

1. Learning Syndrome

A programmer piling up technical books and not programming. A music producer completing online courses but not producing. A game developer completing tutorials but never making their own games.

The learner substitutes their creative pursuit with: “Just another book and I’ll finally be able to get started.” But that day never comes. Knowledge fades, becomes less relevant, and you can never know everything. But learning feels good. There is no apparent risk to reading a book: finishing it and putting it back on the shelf will always provide us with a dopamine reward.

The easiest cure for Learning Syndrome is to adopt an attitude of just-in-time learning: start your project, using any step you can conceivably make, and then only learn whatever you need to take step number two.

Of course, there is a definite place for long-form learning, but when in a creative mindset we need to err on the side of just-in-time learning if we are to avoid getting constantly sucked into this trap.

2. Tool Syndrome

As a music producer I accumulated a lot of hardware synthesizers, drum machines and gadgets. Some of my friends collected guitar pedals and other gear. Photographers accumulate cameras, lenses and other paraphernalia. Programmers spend a lifetime collecting development tools and configuring environments.

For me the feeling often was: “If only I had an MS-20, then I could sound like artist X and make good music!” I’d get a piece of equipment, enjoy the dopamine, have a great spurt of creative confidence, and then… “If only I had a Tempest”.

The solution to this plight? Find your set of tools and stick to them. Anything available today is probably 10x better than what your favourite creative was using 10 years ago. The yearning for new tools is very often an excuse to avoid the ambiguity of moving your project forward.

3. Process Syndrome

Process Syndrome is closely linked to Learning Syndrome. Processors believe they just need to learn the right method and follow it to realize their creative dream. This often results in “going through the motions” of creation without ever entering a state of deep creative flow or producing something original.

Processes replace the ambiguous creative tasks that we’re afraid of with a dopamine-rewarding prescription that feels like it’s sure to work.

We eat up general processes on how to do things (The Pomodoro Technique, Zen Habits, Getting Things Done), on how to live life (fad diets, fad exercise plans, regimented mediation routines, new years resolutions) and of course, on how to do our craft.

I once attended an event where filmmaking students were showing their work. They excitedly shared with each-other what kind of camera and lenses they used and what eclectic technique they used to process the film. It’s almost like their primary concern was not making art, but gaining the approval of their peers.

“Aha!” I thought. “This is exactly what is happening in my musical circles and I’m partaking in it”. Doing things a certain way and using certain pieces of equipment really did generate nods of approval from other musicians.

But no one except our creative peers cares how we accomplish our work. The idea that we can create good output by doing things The Right Way or The Cool Way is a lie, and this lie shifts our focus far away from the real, ambiguous task of trying to create something good.

Since the sausage factory of software development is so open and team-oriented, software developers are possibly more effected by this bias than anyone. Developers fight over the right way to format code, and try to implement the Right Processes the Right Way (test-driven development, pair programming, Scrum). Left to their own devices, programmers will re-write their code twenty times in a quest to Do Things Right.

But in all domains, we never find The Right Way, it’s just a mirage.

Does that mean we should never try? No, not at all. Some processes and standards are quite valuable. But we need to remind ourselves constantly: At the end of the day, it is not about the process, it’s about the output. There are absolutely no points for doing the process “right”, it is only a tool to use towards output.

4. Maintenance Syndrome

Constantly cleaning up, organizing files on our hard drive, running errands, putting out little fires and making inconsequential project todo lists: these are all symptoms of Maintenance Syndrome.

Maintenance tasks in our life and in our projects are usually very clear-cut. They seductively offer a clear problem and a clear solution. The structure-seeking part of or brain loves this and will endlessly procrastinate important ambiguous tasks in favour of taking these on.

When we are pulled into this game we usually think: “let me just check all these things off my list first, then I’ll do the hard thing”. There’s one big problem with that: there’s absolutely no end to these kinds of minor tasks in life. They will grow to take as much space as we have to offer — completely crowding out creation.

Many Others

These are just four examples of how we replace our scary and ambiguous quest of creation with structured fantasy games, but there really is no end to the number of ways we can be pulled off the creative path. Our temptations are unique to ourselves.

The intention is not to frame these activities as bad. They’re certainly not. But we need to be vigilant about them, and deeply understand our reasons for doing them — in order to make sure they are not crowding out creation from our life.

Mitigation

Whew. So, We’ve covered four “fantasy games” that we use to endlessly distract ourselves from actually achieving creative output. But what does the real game of creativity look like? I see it as two sub-games, which I’ll call the “tactical game” and the “long game”.

1. The Tactical Game

The tactical game is what happens when you sit down to actually do your craft. This largely involves discovering a state of flow, where you are not thinking too much about your actions and feeling a natural enjoyment as you progress. The main way I’ve found to achieve flow is to work on something I naturally enjoy, to force past the hurdle of getting started and to create interruption-free time/space.

But wait! This prescription is starting to sound a bit like Process Syndrome. Even the quest to find flow can just become another distracting fantasy game.

These are little things that work for me, but I don’t take them too seriously. If a moment of inspiration strikes and I have not completed my ritual, I just let it take me. That’s the most important part.

2. The Long Game

The hardest part is learning to emotionally navigate the life of a creative project from start to finish. It can take a lot of practice to really master this.

Knowing when to give up completely, when to press on, when to perfect and when to let flaws go, is an intuitive skill. This skill can’t be learned by proxy through any of the fantasy games above, it is only learned by actually attempting to go through the process with real projects.

And that’s why it is so, so critically important to be wary of the fantasy games: every day you spend completely absorbed in the fantasy games, is another day you could have used in learning how to ride the real rollercoaster better.

Final Thoughts

I’m still no expert at this, and am working everyday to improve my output. But I’d be ecstatic to report to my younger self that I did finally find a way make some things, finish music and write this blog post. These accomplishments bring me the deepest kind of satisfaction.

And now after having found a way to play the real game, I know that no matter what circumstances life throws at me and no matter what tools I have available, I will always be able to find creative joy.

I’d like to send a heartfelt “thanks!” to Elling Lien/Unpossible for bringing RPM (a challenge to write and record an album of music in 1 month) to Newfoundland. It was during this challenge that I finished my first creative work and really began to feel understand what it was to ride the real creative roller coaster from start to finish.

If you have yet to complete a creative journey from start to finish, deadline-driven events like RPM, Startup Weekend, Global Game Jam and NaNoWriMo are an amazing place to start.