Linear vs Exponential: How to Bet on the Right Technologies

Every investment of your time depends on what kind of change you're facing. Get this wrong, and you'll spend years mastering something that becomes irrelevant — or dismiss something transformative as hype. The distinction between linear and exponential evolution isn't academic. It determines whether your experience works for you or against you.

Linear Evolution: Where Experience Compounds

Some technologies evolve predictably. SQL has been declared dead more times than anyone can count, yet it remains the backbone of nearly every data system. Python keeps growing. Relational databases keep running. These aren't exciting bets, but they're safe ones.

The Lindy Effect explains why. The idea is simple: the longer something non-perishable has survived, the longer it's likely to continue surviving. A technology that's been around for 50 years has better odds of lasting another 50 than a technology that launched last year. SQL, born in the 1970s, isn't going anywhere soon.

For these technologies, your experience compounds. Each year you spend deepens your expertise, and that expertise remains valuable because the underlying technology stays relevant. You're not racing against obsolescence.

Warren Buffett avoided tech stocks for decades, famously saying "Technology is based on change; and change is really the enemy of the investor." He preferred boring businesses that serve everyday needs. The career parallel is clear: betting on stable, enduring technologies may be less exciting, but the returns are more predictable. Sometimes the smartest move is to master the boring stuff.

Exponential Shifts: The Brave New World Problem

Then there are the changes that rewrite everything. The cloud didn't iterate on data centers — it made them optional. AI isn't improving traditional automation — it's replacing entire categories of work. These shifts don't flow naturally from what came before. They break the pattern.

Here's the uncomfortable part: your experience can work against you. When a paradigm shifts, the mental models you've built become obstacles. You see the new world through the lens of the old one. You pattern-match to things that no longer apply. You dismiss what doesn't fit your existing framework.

This is why startups led by young, inexperienced founders can win against established players. We assume it's raw brain power, but that's not the whole story. They win because they're less constrained by the past. They don't know what's "supposed" to be hard. They don't carry the accumulated assumptions that tell experienced professionals what's possible and what isn't.

The Lindy Effect works in reverse here. The more time you've invested in the old paradigm, the harder it is to see the new one clearly. Your greatest asset becomes your biggest blind spot.

You Are Your Own Biggest Obstacle

The hardest bias to overcome is the one you don't notice. Familiarity bias makes you reach for solutions that worked before, even when the situation has changed. You reason from analogy instead of first principles. You assume constraints that no longer exist.

I learned this the hard way. Fresh from startup work where every dollar mattered, I brought that mindset into a large enterprise project. The task was building a change data capture pipeline. I designed an in-house solution: custom parsers for database logs, a complex system that would avoid any licensing costs.

Two quarters later, I finally looked into what commercial CDC tools actually cost. The answer was painful. Services existed that would have done this for a price the client would have approved without hesitation. My startup frugality — the very instinct that had served me well before — had wasted months of effort on a problem someone else had already solved. The client had money. I just never asked.

The problem wasn't a lack of skill. It was an assumption I never questioned.

The Capability-Demand Gap

Technology capability almost always precedes commercial demand. The tools exist before the market cares. Understanding this gap is crucial for timing your moves.

Consider large language models:

Event	Date	Impact
GPT-3 launches	June 2020	Impressive but limited access — market barely notices
ChatGPT launches	November 2022	Fastest-growing consumer app in history — 100M users in 2 months

The underlying technology had existed for over two years. What changed was accessibility. The same pattern repeats everywhere:

Apache Spark started at UC Berkeley in 2009. Databricks was founded in 2013. It's now valued at $62 billion.
Cloud computing had AWS patents filed from 1998-2005. AWS launched publicly in 2006.

If you wait for widespread demand to signal that a technology matters, you've already missed the best window. By the time everyone agrees something is important, the early movers have already established themselves.

Neither Strategy Is Universally Correct

First mover advantage is real, but it's not the only path to success.

Being early means less competition and more room to establish yourself as an expert. It also means higher risk. You might invest heavily in something that fizzles.

Moving later has its own advantages. The developers who arrived after app store ecosystems matured found a larger market, clearer rules, and customers who already understood what apps were. The late movers built bigger businesses with less friction.

The key is choosing deliberately based on your risk tolerance, your resources, and your read of where the technology sits in its lifecycle.

Adaptability Beats Prediction

In an environment where hype cycles compress into months rather than years, adaptability beats prediction. You can't reliably forecast which specific technology will dominate five years from now. But you can build the capacity to learn faster than your competition.

The question isn't just "what should I learn?" It's "how quickly can I learn whatever turns out to matter?"

Here's an exercise that helps: design your approach to a project, write it down, then throw it away. Now redesign the solution without using any of your initial ideas. Force yourself to start from a blank slate. The goal isn't necessarily to find a better answer — it's to discover which of your assumptions were invisible constraints rather than actual requirements.