Podcast Digest

The venture business as a whole doesn't work. It shouldn't work. Returns and distribution are not divided equally between players — otherwise it would be too easy, there wouldn't be winners and losers, and none of us would be playing. So the expectation that venture will work out sets you up for disappointment from the start.

It has worked for some people, for some time. But the number of firms where it works over a long period — your Sequoias, Andreessens, Benchmarks, Greylocks, Lightspeed — is extremely small. If you look at all the money flowing into the market right now, I don't think it's going to work. I think it's going to end up with some serious catastrophe for many of the players. If I'm a limited partner who has distributed my venture allocation evenly, I wouldn't sleep well at night.

In cybersecurity alone, roughly 350 to 400 new teams get funded every year. Over the past decade that's about 4,000 startups. Yet the number that become unicorns in any given year is shockingly low — in Israel, which represents about 40 percent of the market, it was two in 2025 and just one in 2024. The only outlier was 2021 with seven. Meanwhile entry prices at seed have ballooned from $15 million post-money a decade ago to $100 or $150 million today. The probability of hitting a successful company is still roughly one in 150, but you're paying dramatically more for that lottery ticket. The market is not balanced, and a lot of that cash flowing in will be wasted.

Venture is a game where we know very little when we get into investments. If we analyze product ideas and markets, mostly we analyze smoke — the founders will change their mind in a few weeks and it will be a different product, a different market, many different things. We know so little.

You can argue that outcome sizes have expanded enormously, that CrowdStrike and Palo Alto Networks have reached market caps never before thought possible, and therefore we can justify paying more on entry. That's a legitimate argument, and I accept it with humility. But it doesn't change the probability facts around this game. The ongoing and lasting impact of entry prices when investing in emerging teams is real, and we should be super realistic about it as investors and limited partners.

This isn't an argument against investing in innovation — the contrary, we should invest more in cybersecurity innovation because the pain points are massive. But we need to be selfish and we need to be greedy. Those are good traits for an early-stage investor. Those aren't negative qualities. Whenever I see an inflated-price seed deal that is essentially a bet on a team, I get more skeptical now.

Trajectory, velocity, and growth rates are the most important indicators for a healthy business. Part of our job is to look at that growth and try to sense whether it's being engineered or organically achieved. But whenever you see a business growing very fast, as a general statement, it's a good company — because that's the best predictor for a company that does well.

Over time I learned that when a business reaches the point where it's growing super fast, it becomes part of their DNA. It doesn't slow down just because of averages or regression to the mean. There needs to be a significant external event to slow them down. If a company grows fast, it will continue to grow fast. They're probably doing something very right.

Look at Wiz: their first quarter selling software was a million dollars, second quarter two million, then eight, then twenty-four. That's an amazing first year, in 2020. When you see that level of growth, it's not a one-time event. I had the records of companies like Palo Alto Networks and ServiceNow from my Sequoia days, and Wiz's pace was insane even compared to those benchmarks.

Great companies aren't always up and to the right. Sierra had an amazing start — they sold probably half a million dollars in the first quarter and then a million. And then they sold zero for two quarters. Literally zero. As an investor, you look at yourself and say, okay, I really fucked up.

But the team — and I really attribute this to the founders — analyzed what was going on, made modifications, and in the next twelve months sold twelve million dollars of new business. They went from two to twelve. And then it continued to grow extremely fast.

The lesson is the same: when you see a company that grows that fast, it's part of the DNA. There's something about the company that makes them move fast. It may be amazing go-to-market execution, weakness on the competitive side, perfect timing with the market — it's probably product market fit. But whatever makes them move so fast typically will not simply fade away. The zigzag doesn't invalidate the trajectory.

Take two companies from our portfolio, both founded in 2019. NoName focused on API security — amazing company, did about three million in the first year, fifteen the second year. Then they slowed down. Why? API security wasn't really a market. It was a niche segment within application security. To sustain that growth, the company had to reinvent itself into a much bigger product vision, and it was super hard. Eventually we sold to Akamai for about half a billion dollars.

On the other hand, Island — founded the same year, selling enterprise browsers. In 2019, the number of CISOs who told us they needed an enterprise browser equaled the number of people who told the market in 2006 they needed an iPhone. The market didn't exist. And still, the company is growing super fast. It's a five-billion-dollar company today, competing with free browsers from Google and Microsoft, and it has tons of financial services and Fortune 100 customers.

The conclusion is that we are exercising the science of exceptions. It's good to share these lessons, but if you take them and apply them linearly, it would be very hard for you. The majority of companies do plateau. Market size is what separates the companies that compound from those that don't.

I'm never worried about too much capital going into a fast-growing company. It takes a lot of money to build those companies. If we don't need the cash this year, we need it next year. The real concern is engineering growth — if your magic number is horrible and for every dollar you spend on sales and marketing you generate ten cents in new ARR, you're in a horrible business.

But if you've built a product that fits what the market needs, and you've got a go-to-market team that executes in a decent-plus way, your yield will be significantly higher. Maybe it's 65 cents on the dollar growing into 80 cents. You can see how it turns into a profitable business. Then why would you care that you have another extra 200 million in the bank?

Some people worry that a brilliant but young founder will become defocused — push forward a product roadmap with four things instead of one, open new geographies too soon, hire aggressively and poorly. Intellectually I get it, but I don't buy it. I'm not in the business of babysitting founders. If we trust them to build a critical cybersecurity company that protects our nation's most sensitive information at major banks, then telling them they can't handle having extra cushion in the bank without getting sloppy — that doesn't hold up.

My instincts are that gross margins matter. For a healthy cybersecurity company, high gross margins are part of the vital signs. But how often do I discuss gross margins with my early-stage companies? Never.

Part of our job as investors is to help founders realize what challenges they need to tackle right now, this year, and what they should tackle in 2027 and 2028. If you became a founder in the CyberStarts portfolio, I would tell you gross margins are important — let's talk about it in 2029. Let's build the foundations of a healthy business assuming we'll get to deal with gross margins later.

I don't think we've seen enough healthy, profitable AI businesses yet to really drive back the important vital signs for what a healthy AI company looks like. The margin profile might be different. But for early-stage companies, the focus should be on product-market fit and growth, not on optimizing margins before you've even found your footing.

Exceptional companies have traditionally moved at extremely high pace. For me, in the first five years from when you start selling, if you go 4X, 4X, 3X, 3X on new ARR — not total ARR, new ARR — that's 144X after five years. If you booked a million in new ARR your first year, you'll book 144 million in year five. That's a nice company. If you did two million in the first year at that velocity, you'll do 288 million. That's an even better company.

I don't think there's a limit on what great is. I'm confident that five years from now I'll be able to show you a team demonstrating that Wiz was a slug and they can move much faster. But the bar for real greatness pretty much stays the same. You can grow from five to fifty to two hundred — please do that. But even the more conventional path of one, four, sixteen, forty-eight in new ARR — those are terrific numbers. You'll do well.

The multiplier question in public markets confuses me as much as anyone. My guess is that markets have expectations about growth rates, and if they believe a company's growth rate will decline — perhaps because autonomous programs will eat part of their business — the multiplier declines. But if those companies continue to grow at an incredible pace regardless, the multipliers will rebound. The multiplier is just the market's anticipation of your future growth rate.

Going public is not a financial event. It's a branding event. It's an occasion where you tell your customers, partners, employees, and future employees: I'm here to stay. That's what an IPO is, because typically it's not a liquidity event — it's the opposite. You get shackles on your hands. You cannot sell stock. You've got all kinds of limitations. It's hell for liquidity, but it's an important marketing event.

I believe many founders and companies will still choose to go through that exercise and pay the price — the lack of flexibility and liquidity — to gain the long-term value of that marketing event. But private markets extending the way they have is both functional and sustainable.

The real challenge with extended private timelines is talent retention. You typically grant employees stock vesting over four or five years. When your best engineers, product managers, and salespeople are fully vested, and structurally you can't allocate them equally large grants because the company is bigger with more employees, you actually force them out. Most of their family's wealth is tied to one company, so diversification by joining another startup becomes perfectly logical. The antidote is secondary liquidity programs.

At CyberStarts we created what we call an employee liquidity fund, focused not on one-off secondary deals but on creating a recurring program with portfolio companies where we provide liquidity to employees every year. We underwrite a tender offer annually so employees know they're getting liquidity — the very same type they would get in a public market, delivered in a private company. That helps our portfolio companies retain talent.

We just announced our first secondary program with Sierra, buying many millions of dollars' worth of shares from a few hundred employees. The valuation setting is an ongoing process with management — you have to price a round.

Secondaries can also be a way for early-stage firms like CyberStarts to return capital to limited partners. It makes the markets more sophisticated, and with that sophistication you create better solutions for employees, founders, and LPs. It's not a secret that we sold secondary shares at Wiz early on. I regret selling every single share — if I'd held, I would show better performance for my limited partners. But at the time it looked like the right and responsible thing to do.

One important lesson I've learned about building a venture partnership is that people are very different and bring different talents. A very easy mistake you can make as a managing partner is trying to create guardrails and a textbook and bring everyone into the same mode of operation. You do that because you think this is what worked for me, so let me map the gaps between how a new partner performs and my recipe, then bridge those gaps.

My view is the opposite: let each team member play to their relative strengths. Don't require them to focus on improving their weaknesses. On their weaknesses, at best they can be as good as the market. But on the things where they're exceptional, they create real advantage, real greatness.

That leaves CyberStarts with a team of people who genuinely enjoy working with each other, but each of us operates in a different way, and we respect that. I learned this through mistakes — I put guardrails on people before, constrained them to my way of thinking, and realized it was a net negative for them where it had been a positive for me.

The decade I spent at Sequoia Capital was formative for me. I couldn't do what I'm doing today without learning from Doug Leone, Michael Moritz, Jim Goetz, and Pat Grady. But it wasn't easy. It took me a long time to mature as an investor.

You show up to the office every day surrounded by super achievers building amazing companies, and you look in the mirror and say, I'm the shittiest investor in this room. There are ten people around me and I'm the worst. And the next day, same thing. You go like that every day. It's really hard. You have really bad days sometimes. It takes a lot of determination to keep going and believe you're going to figure it out.

Venture is a terrible profession in one sense — you don't know if you're good at what you're doing for five or six years. Show me another profession where you show up every day for five years with no idea if you're doing any good. But it's also one of the most exciting professions because it gives you the opportunity to share your life with amazing individuals. You gain a little from every team you partner with, and cumulatively you gain a lot. You have to become a better listener over time. And that by itself makes you a better person, a better parent, a better partner.

I focus on the deals I've done and the teams I've partnered with. That's where I put my focus and energy. You can't cover everything and you can't get everything. You're not going to win every battle.

If you're stressed about being in every important AI company or every important cybersecurity company, I can predict you're not going to succeed at that. The healthier approach is focusing on your portfolio companies and trying to do the best with the teams that put their faith in you. There are always things you could have done — another customer call, another intro, hiring someone else for them, paying more. We can always improve. But everything leads me to the conclusion: focus on your own thing.

What I'd say to the younger generation of investors who are looking at frameworks that used to work — rule of 40, triple-triple-double-double, early margin focus — and finding them out the window: learn as much as you can from old farts like me. But at the end of the day, use your gut to make decisions. Nobody knows better than you do.

The Ramp data showing Anthropic capturing 73% of new AI spending deserves careful reading. The same graph shows OpenAI still ahead in total spend — it's the marginal buyer over the last six to ten weeks who has massively shifted. That's the most leading indicator: people in the market today for a new AI product are choosing Anthropic at a 70-30 clip.

OpenAI's snarky response comparing Ramp to a lemonade stand was a mistake. Ramp likely represents a pretty accurate statistical reflection of digital company spend in the US — they have a diversified customer base, decent data, and good data scientists. Dismissing that signal rather than confronting it is bad strategy.

The data represents a real shift in the zeitgeist over the last three months. The marginal user, the marginal enterprise buyer, and the switchers are all moving toward Claude and away from OpenAI. It doesn't mean it's the end of the world, but sometimes the first thing you have to do in dealing with a problem is face the hard facts. The conclusion is real.

Since Opus 4.5 and 4.6 shipped in December, the improvement in Claude has been a step function that was under-discussed. Everyone's pull requests exploded. Everything got better. And once you build real applications on models that are this good, switching costs become enormous — not because of contractual lock-in, but because of the weeks of work it takes to dial everything in.

We built an AI VP of Marketing and an AI VP of Customer Success that run on Sonnet 4.7 with some Opus. The marketing agent defines every daily activity, gives Slack updates, runs weekly team meetings. The customer success agent manages 200 sponsors around the clock — work that was causing human employees to quit. These agents are genuinely great, and there is zero chance we switch them to a different model. It took weeks to train and tune, and now they're dialed in.

This is the lock-in that should trigger a code red at OpenAI. Once enterprises have invested weeks building and qualifying agents on Claude's models, the soft costs of switching — retraining, QA-ing outputs, requalifying everything — far outweigh any token cost savings. The open router world of rotating through cheap models exists for cost-sensitive applications, but for apps delivering real business value on a few thousand dollars of tokens per month, nobody cares about saving $500. They care about reliability.

The two potential mega markets in AI are consumer and enterprise coding. OpenAI grabbed mind share in consumer with ChatGPT, and despite not fully monetizing it yet, nobody has taken that away from them at scale. The other mega market — enterprise and coding — was up for grabs six to twelve months ago. Today it's only half up for grabs. People are starting to lock in.

If OpenAI allows Claude to become the default enterprise coding tool for another year — the perceived best for another year — you don't get to show up after enterprises have made their decisions and say, 'Now we finally got our act together, please pick me.' There is a tide in the affairs of men. The last six months have been the period where coding locked in as the motherlode application within enterprise AI spend.

Every time you let behaviors settle for six to twelve months, you're losing lifetime value that's non-trivial. On the consumer side, muscle memory keeps people in ChatGPT for random research. On the enterprise side, applications get built and tuned on specific models. If you sacrifice another six to twelve months of that coding land grab, you've probably lost value you'll never get back.

The SpaceX valuation story requires precision. Polymarket said the probability of SpaceX being worth two trillion at IPO went to 50-60% from a lower number. But Tesla stock didn't move on the TerraFab announcement, and that's where actual significant money changes hands. So attributing $400 billion of new value to a statement about building a fab deserves skepticism.

The eternal Elon discussion has a consistent structure: at every point in time, you have things he's already done that you can value on revenue multiples, things announced and in process at various stages of completion, and speculative future plans. For each category, you assign a probability of completion. TSMC spent 30 years building the most advanced fabs on the planet. Saying a new announcement is worth $400 billion in value implies roughly a 50% probability of replicating that — a pretty high number, even for Elon.

His record on timing is the key caveat. I asked ChatGPT to generate chronological lists of every Elon prediction about full self-driving and about when Starship would fly to Mars. It's a long history of 'three years from now.' So while we're dealing with arguably the most accomplished entrepreneur of at least the last 30 years, his track record on predicting timelines is spotty. As an investor, you're entitled to ask what probability you ascribe to the most accomplished person in the world being able to do the next thing — and when.

The Bezos $100 billion manufacturing fund is the classic Indian Creek Island investment. You're sitting in your couple-hundred-million-dollar Miami home, Jassy and team are running the hard business at Amazon, and you get to think big — at Carbone, on the yacht. You've already built Amazon. You don't want to go small anymore.

Think about the three plays available when a transformative technology arrives. When the internet was going to transform retail, you could build Shopify and sell software to retailers — that became a couple hundred billion dollar outcome. You could buy Walmart and inject internet into it — a 2x on a massive base, turning half a trillion into a trillion. Or you could do the hard thing from zero and build Amazon — the $2 trillion outcome with infinite IRR. The Bezos fund is explicitly choosing the Walmart play: buy companies, inject AI, harvest the uplift.

That's inherently less disruptive and more financial engineering than either the Shopify or Amazon play. It's what you do when you have too much money and not enough time to want to do it the hard way. Every billionaire who isn't pulling their hair out running a public company right now wants to do something huge in AI. They don't want to be CEO again, but they're motivated to make one of these plays. We're going to see a bunch of them.

The Groq deal to NVIDIA illustrates when revenue multiples become irrelevant in M&A: when the value to the acquirer is enormous and they have the market cap to pay for it. NVIDIA at $5 trillion can write a $20 billion check for something strategic. WhatsApp is the precedent — Facebook paid $16 billion for zero revenue, and it was a great deal then and it's still a great deal now. The number of buyers who can afford that is small, but they exist.

The structure is what makes this deal fascinating and painful. The company sold its assets to NVIDIA, booked a massive gain because those assets were carried at under a billion, triggering corporate-level tax. Then the money gets distributed to investors, triggering individual-level tax. The effective tax rate for the founder is roughly 60%, and there's no ability to roll over into NVIDIA stock. You're losing four to five billion dollars on a $20 billion transaction to double taxation.

This entire structure was engineered to avoid antitrust review, which creates a perverse government incentive. You either lobby at the highest levels of administration for a waiver, or you do it this way and pay double taxation — the government wins either way. Whoever eventually leads the antitrust division and proposes transparent, clean rules will effectively cost the government tens of billions in this combination of implicit kickbacks and tax revenue. It's a terrifying dynamic.

Figma's stock decline to $21 a share — a 12 billion dollar market cap — reflects something deeper than a Google product launch. The market isn't saying Figma is a bad company. The market is saying it no longer believes this revenue is particularly durable. PE doesn't believe it either — Qualtrics couldn't finish its debt offering this week, Salesforce barely got its debt done.

Google's Stitch is a proof of concept that Google will likely abandon within a year, given their track record of launching and killing products. But the market reaction is rational in a different way: it's demanding proof that incumbents can adapt to AI-first disruption. And Figma Make is genuinely one of the worst vibe coding products available. It can't even pull context from a website to generate a design — something Replit, Lovable, and even Stitch can do. If it's not good enough to charge for, you're not an AI company.

This is the 2026 panic I was slow to understand. The markets are rationally repricing every SaaS company that isn't demonstrating AI-driven acceleration. Every time Google or anyone else launches something adjacent, there will be another panic for any incumbent not charging meaningfully for AI capabilities. Figma at $21 is the market saying: show me the money or I'm going to assume the worst about your future.

When portfolio companies come to me and say they're using AI in go-to-market or using AI to build engineering faster, my response is: that's great, but nobody gives a rat's ass. That's table stakes — jacks to open. Unless you're making something physical like cars where it's purely back-office efficiency, the number one question for any software company is how AI changes the end product you deliver to customers.

You could be using AI well or badly in go-to-market and engineering, and it will catch up with you over time. But that's not what's driving 30-40% price declines in public software companies. What's driving those declines is exactly what the market fears: disruption risk to the core product. Investors look at these companies and say, I don't know the terminal value here. I'm nervous. So I need to be paid for that risk.

The test is simple: can you charge meaningfully more for your AI-enhanced product? If your ARPU hasn't increased 50% or more due to AI capabilities, it's just a feature — like an integration. Good work, have some beers, but it doesn't count. Notion appears to have doubled ARPU with AI at $20 per month versus $10 basic. That passes the test. Microsoft Copilot was rejected by the market as something people didn't want to pay for. That's the dividing line between companies that will thrive and those in terminal decline.

Every company at scale faces a trap with its installed base. It's simultaneously the greatest opportunity and the greatest threat. Salesforce's $44 billion in ARR is the best audience to sell Agentforce to — you don't have to earn that base. But it's also 50 years of features, integrations, non-agentic gaps, and endless maintenance work. If you're not careful, that installed base consumes 98% of your resources.

Figma Make illustrates this perfectly. It's the only vibe coding product where you can say 'build me a website using 20VC.com as a template' and it can't even visit the URL, pull context, and generate something. Replit couldn't do this in June 2025, but everyone can do it today. Whoever is running Make has a small team, and the 35% growth rate of the core business is eating all the engineering and product resources. The trap of earning that growth imperils agentic development.

The intercom example is instructive — Owen was clear that they let their core business partially decline to build the agentic product. That's almost impossible for a public company. It takes enormous courage to say you're going to let a billion-dollar design business soften so you can invest in the future. But that's exactly the mind shift required: allocate to the new thing first, then give the residual to the old thing. The instinct is always the reverse — service the old, then find scraps for the new. And that instinct is what kills incumbents.

There's a risk in venture capital right now that is massively under-discussed: who is going to buy these companies if they don't IPO? We're doing billion-dollar-plus rounds like candy, but we have outstripped any current ability for these companies to exit. At least in the 2021 bubble, there were PE exits and active M&A. Today, acquisitions are down in volume even if dollars are up.

The math is actually worse than it looks because of the eat-the-work thesis. If these AI applications are replacing incumbents and the TAM is larger, then by definition the new company is bigger than the old company it's disrupting. Harvey at $10 billion can't be acquired by a $2 billion practice management software company. The prior generation literally cannot afford to buy the next generation once it's been marked up by late-stage rounds. It's win or die.

I just worry there's some ratio of potential acquirers divided by unicorns, and we're at the lowest ratio of our careers. We've lost all of PE as buyers, and NVIDIA isn't buying 100 companies. Microsoft isn't buying 100 companies. It's so much easier to get a $9 billion valuation than a billion-dollar exit — and that should be terrifying to the people writing those $9 billion checks.

The math of Series A investing today creates genuine stress across the venture industry. Series A rounds are now $30 to $40 million. If you want to lead, you need to write $25 to $30 million checks. With reserves at 50% of initial capital — meaning two-thirds goes in on the first check, one-third held back — you're looking at $30 million per deal all-in. At 20 to 30 investments per fund, you need close to a billion dollars just to play the Series A game meaningfully.

The average round we play in has crept up over the last year and a half. There are deals — particularly the neolab-style seed rounds at massive scale — where a $30 or $40 million check is so outclassed it's barely worth showing up. We've kept our investments in the $100 to $400 million pre-money range, and right now that's been the wrong call. Full credit to investors like Spark's Yasmin, who put $4 billion on pre-revenue Anthropic, or Matt Murphy at Menlo — those late-stage bets have paid off spectacularly.

But what everyone's pushed out on is the risk continuum. Fund sizes are adapting slower than the market is moving, which feels faster than any prior cycle — faster than 1995-99, faster than 2007, faster than 2021. Every VC is stressed right now, no matter how successful they are. Everyone wrestling with doing deals today is grumpy and feeling the pressure, because the old math of 15 to 20 investments at $15 million average checks rolling up into sensible fund sizes is simply broken.

When I think about OpenAI today versus when we started this podcast, the pattern is clear: inconsistency is finally catching up with them. They seemed like the exception to the rule — you could have massive founder turnover, a dysfunctional board that kicked out and reinstated the CEO, and the momentum would carry you through. Now the downside of that turmoil is manifesting.

Everything smells of desperation. They're keeping headcount flat, then doubling it. They're going deep on agentic commerce, then Walmart says it doesn't work. Sora gets folded into ChatGPT rather than standing alone. Hardware gets deprioritized. The messaging is whiplash-inducing. Compare that to Anthropic, which has been remarkably consistent about its ideal customer profile and goals — you know what it stands for, you know what's coming.

Rory made the prescient observation early on that the press only has two stories: we love you, and we hate you. Once they've written the first, there's only one left. Sam spent a year talking to heads of state instead of staying home and shipping product, and eventually focus matters. But things are never as good or as bad as they seem — OpenAI still owns the consumer business, and if they can focus on two or three things and get sensible about their financial trajectory, they still have a comfortable chance to be the largest standalone foundation model company. Blow it for another year, though, and they won't.

The real purpose of a flat organization isn't some ideological commitment to egalitarianism — it's about information flow. Any junior engineer should be able to walk up to any senior executive at any point and have a direct conversation about decisions being made. The goal is to democratize access to information and eliminate the telephone game of funneling data through managers and back down into teams.

But flat orgs only work when you pair them with high-conviction leaders who can make decisions quickly. If a junior engineer is paralyzed by the weight of a decision that could cost hundreds of thousands of dollars, a leader who can step in, make the call, and say "go" removes that friction entirely. You can't wait to have all the information before deciding — often you won't know if the decision was right until you've made it, tried it, and iterated.

It's all bets. You're trying to maximize the percentage of right decisions, not eliminate wrong ones. Speed of execution and excellence in execution are the two things that matter most, and both depend on accumulating as much information as you can within whatever time constraint you've set, then committing and learning from the outcome.

Solving discrete technical problems is hard, but the real churn starts when you try to get large groups of people to work together on those problems. Even with fast decision-making and open communication, you need to make sure everyone's vectors are aligned — that the whole team is pushing in the same direction. Data silos form naturally once you cross about 100 people, even when leadership explicitly says there should be none.

At Mariana, we've tried to embed the solution into the core operating system of the company. Everything is web-app-based, internal access controls are essentially gone for core engineering information. Nothing lives on someone's hard drive or in an email thread that has to be forwarded around. We've built an integrated data layer where anyone can see the context behind any decision — what was decided and why.

Now with LLMs, you can let them run on top of your data repository so that even if someone doesn't understand the folder structure, they can query the model and navigate to what they need. The principle is simple: if you don't give people the full context of an operation, they'll optimize locally with whatever data they happen to have. You're trying to enable everyone to make globally optimal decisions.

Critical path management is something SpaceX engineers live and breathe. The critical path is whatever task or procurement activity is currently driving the schedule — the thing that, if it slips, everything slips. Chasing critical path and being a firefighter is a core skill, but the trap is what I call second-grade soccer: everyone swarms the ball. If you narrowly focus all your resources on today's bottleneck, the next item in line becomes tomorrow's bottleneck even faster.

The solution is setting up small SWAT teams that can independently attack the critical path while keeping parallel workstreams moving. You need to mobilize a focused group to solve the blocking problem without diverting everyone else. It's easy for people not on the critical path to get drawn into the excitement — when something is literally blocking a rocket launch or a production line, everyone wants to help.

Even at six people, this discipline matters. We've structured our initial team by domain — an avionics engineer troubleshooting an engine design problem probably doesn't help with the critical path. It's about resisting the gravitational pull of the most urgent fire and making sure the next fire never ignites.

High-signal, low-noise email updates are one of the most important rhythms you can bring from SpaceX into a startup. It might sound counterintuitive in an era of Slack and real-time messaging, but having the person who owns a critical-path problem send regular written updates to the broader team serves two purposes. First, it distributes information. Second — and this is wildly underrated — it forces the individual to reflect on their own progress.

Writing things down is massive. I carry a notebook in my pocket at all times. When someone writes down what happened that day and realizes they didn't make as much direct progress toward the goal as they thought, it recalibrates them for the next day. The act of composing the update is itself a forcing function for clarity and accountability.

The natural tendency when you're busy is to skip the writing because you don't have time. But that's exactly when it matters most. The update doesn't have to be long — it just has to be honest about what was done, what was supposed to be done, and why the gap exists.

When you're building large-scale infrastructure on 12- to 18-month timelines, you need to set a drumbeat for the company. Without it, people in a flat organization don't really know what they're moving toward. The drumbeat gives structure — everyone knows that decisions will roll up on some cadence. You have to be flexible for truly critical decisions that can't wait, but having a rhythm lets the whole company move together.

We reserve the word "sprint" for things that are truly critical to the company as a whole. The software engineering org runs in two-week sprints, but when we have a major milestone, we'll declare a company-wide sprint and say everyone is driving toward this one thing. The broader drumbeat is different — it's the heartbeat of a long construction project, not a daily software release cadence.

The other function of this cadence is celebration. Over an 18-month project, it's easy to lose track of how much progress you've made. You look back and realize you built something incredible, but you never stopped to acknowledge it along the way. The regular rhythm becomes the reward function for the team — a calibration point where people can see they're doing the right thing and driving in the right direction.

When Elon sets super-aggressive targets, the goal isn't actually to hit the impossible deadline. It's to force the team to think really deliberately about what doesn't work within that timeframe. If you say something should take 36 months and someone compresses it to six, suddenly you can see that 900 of the 1,000 things that need to happen can actually be done in six months — but 100 of them can't. Now you have your priority list.

Those 100 items float to the top, and then you can attack them. And "attack" can mean delete them entirely. The aggressive timeline is a sorting mechanism, not a literal expectation. It forces you to confront which requirements are real constraints and which are assumptions nobody has questioned.

This only works when the people setting the targets have genuine technical credibility — a real sense of what is challenging but achievable. If you set goals that have no actual technical path toward achievement, that's demoralizing, not motivating. The sweet spot is aggressive enough to reveal the true critical path, but grounded enough that the team believes the goal is in the realm of possibility.

The thing that actually causes burnout isn't long hours — it's churn. It's the feeling that you're not making progress toward a goal. If people are mission-aligned and can see that they're progressing, solving hard problems is genuinely fun. What destroys that excitement is erratic decision-making that moves teams in contradictory directions, politics that forces people to navigate bureaucracy instead of engineering problems, and data silos where people hoard information.

At Tesla we called that last one "hoarding your Legos." When someone has to deal with organizational friction instead of focusing on a clear problem with a clear pathway and clear priorities, it drains the energy that would otherwise go into the work itself. People can get excited about impossible goals — that's actually the only thing that really fires people up — but only if the path is clear and the obstacles are technical, not organizational.

So the recipe for sustainability isn't fewer hours or lower ambition. It's removing the sources of churn, setting goals that are motivating rather than demoralizing, and making sure every person can see how their work connects to the mission. If you get those things right, the intensity becomes a feature, not a bug.

Every vertical integration decision should boil down to one question, especially in the early days: does the company exist or not if you don't vertically integrate this thing? If it's binary — the part doesn't exist, the technology doesn't exist, or the cost is so high the company can't survive without doing it yourself — then the decision is easy. You should not be vertically integrating just because you can save 5%, 10%, or even 50% on a subcomponent that doesn't check that existential box.

People also underestimate that when you vertically integrate upstream, you're not eliminating a supply chain point — you're expanding your supply chain interactions. Your supplier had their own suppliers, and now you have to absorb all of that risk. The romantic vision of vertical integration, especially coming from places like Tesla and SpaceX that make it look easy from the outside, can be dangerously naive.

At Mariana, we made the decision to be both a software company and a mining company because software companies that sell to mining companies have an incredibly hard time penetrating the sector. The rate of technology uptake is gated by the customers themselves. So the question was: does Mariana exist if we're not both? The answer was no. But once you accept that, the next layer of decisions is about where partnerships make sense and where enough competition exists to trust that costs will come down without you having to own it.

The construction industry builds custom things, and that fundamental characteristic has prevented it from adopting manufacturing-style discipline. What we've been doing at Mariana is bringing takt time analysis — breaking down every discrete step required to build something — into mining and construction operations. This isn't a new concept, but it's rarely applied rigorously outside of factory floors.

Today, a construction superintendent goes out to the field each morning, stands in a circle with the trades, asks what everyone's doing, comes back at the end of the day and asks what they did. There's almost no quantification, no short-interval control. Meanwhile, the site has materials, equipment, and people — three databases that humans are trying to manually reconcile to decide what tasks should happen. We see enormous opportunity to do that algorithmically, setting daily and hourly goals and automating the data capture with tools like Boston Dynamics' Spot taking 3D scans.

In manufacturing, everyone has a dashboard showing how many parts they're trying to make at each station and whether they're trending toward, behind, or ahead of their goal. That same discipline applied to construction, mining, and refining is the cultural shift that needs to happen. Measuring the things that matter — and investing in the software backbone to enable it — is what unlocks manufacturing-level efficiency in industries that have never operated that way.

One of the most powerful things at SpaceX is the relentless questioning of requirements. On Starship, the ship team had an opportunity to pull hardware from the Booster program, which was ahead in its V3 design. We identified components — essentially a snorkel inside the fuel tank that condenses liquid — that could plug directly into the ship and let us skip an entire design cycle. The catch was that the valves in that system didn't like liquid, and our configuration would produce it.

Rather than abandoning the idea and designing bespoke hardware from scratch, we spooled up the resources to prove the valves could handle it. That one decision let us roll the hardware into production sooner, and it also meant Booster could later use the same validated design. From a company-wide perspective, it was a massive win — we traded a known, bounded risk for months of schedule acceleration.

This is what "the best part is no part" actually means in practice. If you hadn't been thinking about production two steps ahead, you'd have written perfectly bespoke requirements and designed something from scratch. Instead, by questioning every requirement and staying clear on the intention to simplify, you leave your engineers free to design simple solutions. And simple is fast, simple is cheap.

The technical evaluation in Tesla's hiring process goes remarkably deep. If you're applying for an engineering role, you're probably talking to six engineers before getting an offer, doing a technical test that shows how you think through problems and whether you can actually solve what your resume claims you can solve. Eight to ten total conversations before an offer comes through. And that's a feature, not a bug.

It does make hiring slower, but it's critical to ensure that people coming in can be autonomous and balance authority with accountability. They need genuine deep technical understanding of their field. At Mariana, we've mirrored this approach, though it's harder without the Tesla or SpaceX brand — candidates at those companies will happily do a test and talk to as many people as needed. For a startup, you have to manage expectations while still maintaining rigor.

We pitch the process in both directions: if you're joining a high-risk startup, you should also get to know the team you'll be working with every day. Extremely rigorous interview processes actually filter positively — the best engineers want to know that everyone else went through the same gauntlet. If you're a great engineer, a hard interview is fun. But designing those interviews well is not for the faint of heart on the interviewer side.

SpaceX's internship program is one of its most powerful but underappreciated talent engines. These are the most applied-to programs in the world, which creates a massive spread in quality — but the structure gives you a three-month trial period with every candidate. People who crush it stay, and I'd estimate the overwhelming majority of engineers doing critical work on Starship, Dragon, and Falcon are intern conversions.

I interned at SpaceX four times. I couldn't leave — it was the dream. I started in software and kept coming back. Almost got the school to let me stay full-time, but they said they couldn't do that anymore. The internship gives people a real chance to demonstrate that they're exceptional in a way that no interview process can replicate. You see them work on actual problems under actual pressure with actual teams.

We just launched our own internship program at Galadine. For this first wave, what I'm looking for above all is passion. I'm targeting students from project teams — Formula SAE, drone and UAS programs, and especially rocket teams. I found a specific university rocket team that works with the same propellants we use, which I didn't even know existed. The plan is to get them all out to Austin.

If you're at a company with really high talent density where you're constantly learning and seeing projects from the messy early phases through the messy middle through the messy deployment — that experience is incredibly valuable. Don't rush to leave. The key is seeing something through end to end, and then doing that multiple times, because each iteration teaches you how much better the process can get from concept through deployment.

Your credibility to attract talent when you eventually start a company depends on having been through the execution cycle repeatedly. Companies are ultimately assemblies of awesome people driven toward a mission, and convincing others to join you on a risky journey is much more persuasive when you have an embedded understanding of how long each part of the process actually takes. That lets you credibly set targets the team can rally behind.

You'll never be fully trained to start a company — there's no recipe that says stay somewhere for exactly ten years and then go. But I generally think you want to over-index on building a strong technical basis before you sign up for learning how to hire, fundraise, and build all the infrastructure around a company. You're going to keep learning once you start something, but the technical foundation is what you can't easily acquire on the fly.

At Davos, in a closed-door cyber forum of 60 practitioners, a speaker asked how many people in the room knew about Salt Typhoon. Only five raised their hands. These were cybersecurity professionals who had traveled to Switzerland for the event, and the vast majority had no idea that China had fully infiltrated every major American telecommunications carrier.

Salt Typhoon is an advanced persistent threat group — Chinese government hackers who targeted U.S. critical infrastructure, specifically the cellular networks. They gained control of the lawful intercept plug-in points, the same interfaces the FBI uses to execute wiretaps. That means they could turn on surveillance of any phone call at any time. During the last presidential campaign, then-candidate J.D. Vance's calls were listened to. Call data records, internet connections, websites visited — effectively everything running through your phone was exposed.

The implications extend beyond surveillance. The hackers could also see who was being lawfully intercepted, meaning they had visibility into active FBI investigations, grand jury subpoenas, and operations against drug cartels. Confidential law enforcement work was laid bare to an adversary. And the story has only grown — it's no longer limited to the U.S. Effectively every major carrier in the world is now somehow implicated.

When CAPE was building out its nationwide telco, one of the required components was a system for responding to lawful intercept requests from law enforcement under CALEA. No telco builds this themselves because while the technology is straightforward, the administrative burden of responding to search warrants and wiretap requests is enormous. So every carrier turns to one of a small number of cottage industry vendors who plug into your X1 interface and handle it for you.

CAPE selected one of the top vendors, put them on a pilot, and began installation. The site reliability engineering team — and CAPE may be the only telco in the world with an SRE team — was evaluating the connection when they discovered something in the installer package. Buried in it was an unencrypted text file containing the usernames and passwords for every single client of that vendor.

This was literally three months before the Salt Typhoon story broke and the world learned that China had compromised the X1 interface to all the major telcos. There's no specific proof of connection, but it doesn't seem like it would have been very hard for a sophisticated adversary to exploit that kind of security posture. That's what the industry baseline looks like, and that's the problem CAPE was built to address.

CAPE is a global cellular network live in 190 countries, built to be more private, more secure, and more resilient than any other commercial carrier. Each of those words means something different. Privacy means rotating the identifiers on your phone — the way Apple rotates MAC addresses, CAPE does for a whole set of other identifiers that carriers normally leave static and trackable.

Security came from a team of defense tech people with almost no telecom experience starting a telco and discovering that the cybersecurity status quo in the industry was shockingly poor. When off-the-shelf components were found lacking from a security perspective, CAPE built replacements in-house. Four years into that effort, the company is meaningfully better than any other carrier on cybersecurity.

Resilience comes from CAPE's architecture as a mobile virtual network operator — it doesn't own towers but rents capacity on towers from major carriers wherever it operates, including a new partnership with Rakuten in Japan. The result is a network of networks. When one of the major U.S. telcos has an outage, a CAPE subscriber can fail over to another network. In the nuclear Navy, they say two is one and one is none. If you're not resilient, you're in trouble.

The approach to Guam crystallized the CAPE thesis. Rather than trying to ferret through the existing carriers on the island, find all the Chinese compromise, root it out, and never quite know when you're done, the idea was simpler and more radical: do a clean install of a telco on top of the existing physical infrastructure. Just assume the underlying network is hostile.

CAPE's architecture allows for an encrypted traversal of the towers into its own software-based mobile core. The technology was tested on Guam in partnership with the Navy and DIU before anyone outside the intelligence community fully understood the scale of the Salt Typhoon threat. That validation now forms the basis of CAPE's international expansion, including the work with Rakuten in Japan, where a joint U.S. and Japanese self-defense force exercise ran on Rakuten's physical infrastructure with CAPE's software layer on top.

Wars run on cellular networks just like everything else does. The ability to deploy a trusted cellular connection over known compromised physical infrastructure turns out to be exactly the capability that a post-Salt Typhoon world demands.

The defense acquisition system historically hinges on a requirements axis, and that's a slow axis — three years to write requirements, then the full formal process. What the Navy started doing differently was getting ahead of need, making small bets on technologies that looked like potential game changers without following the full formal process, keeping dollar amounts small, and defining rigorous success metrics upfront.

The team called these metrics WHAMS — world-class alignment metrics. The discipline of getting crisp on what success looks like before a pilot begins is what allows the results to translate. In government, the decision that matters is usually made in a room you're not in. If you're talking about technology instead of outcomes, the message doesn't carry. But if you have concrete, measurable results that map to operational needs, people who weren't in the room can still pull the work forward.

The approach scaled dramatically. When the team was doing two pilots a year, Finnelli asked how many they could do if they really pushed it. The answer was five. He told them they were doing 25. That required building a funnel, creating lightweight comparison frameworks, and running A/B evaluations so that when opportunity or crisis struck, validated technologies were ready to deploy at scale.

The shift in how the Navy works with the private sector went from building everything internally to becoming gardeners of an innovation ecosystem. Four venture capital firms were making investments in the defense space seven years ago. By Finnelli's last count, there are 168 — a 42x increase that signals the private sector is ready and knocking on the door.

The corresponding internal shift was equally important. Senior leadership started saying "come in" to innovators, but the people responsible for acquisition had been trained on how to buy planes and ships. Everything looked like that. The Navy had to retrain on the differences when you're acquiring software. A boot camp brought together program managers and contracting officers, most of whom had never worked with commercial technology companies, and paired them with the people who had been successfully pulling new capabilities through the system. The ones who knew how to do something in three months that used to take 18 months taught the ones who had questions.

The outside-in problem — startups not knowing how to sell to government — was real but not the bottleneck. The inside-out problem was. The primes had 70 years to refine their government go-to-market motion. Startups needed a receptive counterpart on the other side, and creating that receptivity through internal education and culture change was the harder and more important transformation.

When CAPE started four years ago, the conventional wisdom for defense tech startups was to go to the Navy last. The Air Force was fastest to adopt, the Marines were fast but had little money, the Army was somewhere in the middle, and the Navy was the slowest. That was repeated over and over.

What changed was people like Finnelli and his team at PEO Digital creating a system where pilots could happen quickly. CAPE's early proof point came from an exercise where they discovered they could offer a trusted cellular connection over known compromised physical infrastructure. When they briefed the Navy, Finnelli immediately connected it to the Guam problem — telcos there had been compromised, and it was strategically critical ground. Rather than spending months on contract negotiations, they worked as a sub with a major prime, identified DIU funding to accelerate, and just went to Guam.

One powerful element was insisting on unclassified and shareable tech evaluations. An independent, credible third-party pen tester did a deep 50-page assessment that DIU paid for and made unclassified. That single document could be used across military services, shared with other government customers, and shown to investors during fundraising. It created a flywheel: validated tech attracts more capital, which funds more government work, which produces more validation.

For aspiring defense tech founders who have the drive but lack a specific idea, the advice is deceptively simple: go to where the problems are. There are ships docked in San Diego and Norfolk. If you know someone working in the area, listen to their pain points. The Navy runs hackathons and structured challenges — now codified in the Defense Authorization Act — that pull in problem solvers and hand them actual problems.

The key is ranking problems by the size of the pain, not by what you read about in the news. The problem that's already getting coverage is probably being worked on by other people. Instead, look for the system that everyone has been trying to shut down for a decade but can't quite kill because one of its ten modules is indispensable. Find a way to make that one critical function severable from the legacy system, and you can finally pull the plug on the rest.

The practical example is telling: equipment sits out of operation in the field for six months because one small part is broken and the factory that makes it only runs once a year. If you can 3D print that replacement part, you've just eliminated a six-month bottleneck. Theory of constraints says you should find the blockage and clear it. That's not glamorous work, but the difference it makes to operational readiness is enormous.

The software opportunity in the Navy is defined less by what needs to be built and more by what needs to be taken out. The amount of technical debt is significant. For almost every domain where the Navy does software, there are too many systems. The pitch to startups is straightforward: if you can take out five legacy systems with one modern application that delivers secure data with an intuitive user interface, the Navy will find room for you.

This is what the Navy calls modern service delivery. They published a guidebook — Modern Service Delivery 3.0 — covering loosely coupled architecture, modular open systems implementation, and how to pull those approaches through procurement. The old mentality was that there's room for everybody and you can just keep adding systems. That's no longer the case. The new mandate is divest to invest.

The cultural recognition that software, networks, and cyber now have a permanent seat at the table changes the calculus. All kinetic and soft military activity is highly dependent on these capabilities. The department has identified six key technology areas and is operating with a unified demand signal across services rather than treating each branch's needs as separate. For companies that can demonstrate measurable outcomes — not just better cyber scores but operational resilience and return on investment — the current leadership is ready to measure and reward results in a way previous administrations were not.

For veterans or mission-driven people who want to enter the defense tech space but don't have a startup idea, the strongest advice is to go join an early-stage company that's already doing it well. Getting startup experience at a good company teaches you what to do. Getting it at a bad company is actually negative — you learn all the wrong behaviors and instincts, and you come away thinking you probably hate startups.

The distinction matters because defense tech companies need people who understand both the mission and the mechanics of building. CAPE was founded by a Green Beret who spent nine years at Palantir, and the team combined defense backgrounds with software engineering without anyone having telecom experience. That combination of mission understanding and technical building capability, learned at a company with good practices, is what produces founders who can navigate both the government and the startup worlds.

The Commit Foundation helps people transition out of government service into the private sector, and that pipeline matters. The ecosystem has grown from four defense-focused VCs to 168 in seven years. The capital is there, the government is more receptive than ever, and the threats are concrete and urgent. But the individual founder still needs the pattern recognition that comes from working inside a well-run company before striking out on their own.

The operating model that emerged in the Navy is a network of networks — going meta, as Finnelli describes it. Rather than trying to keep all innovation scouting in-house, the CTO's office maintains a map of who the key operators are in every community. Within munitions, within robotics and autonomous systems, there are known hitters. There are investors watching the space. When a company is still in stealth mode, the network probably already knows about it.

The innovation adoption kit the Navy built is designed to make these tools scale beyond any single team. A telling moment came when the special operations community independently used the kit to identify pilots and route them into their own evaluation pipeline. They saw themselves as a proving ground for Big Navy — if something works for special ops in maneuver warfare and applies to the Marine Corps, and the business case and mission case are there, why wouldn't it pull through to broader adoption?

The overhead costs dropped dramatically once everyone started speaking the same language. Where there had been 27 different dialects for describing capability needs and evaluation criteria, the system now runs on a shared vocabulary. Success metrics, return on investment frameworks, and operational resilience measures give economists and financial minds the data substrate they need to see the forest through the trees and make better portfolio-level decisions about which technologies move the needle.

The CEO job is fundamentally about operating in a fog of partial understanding. As an organization grows, it becomes impossible to know everything about everything, so you have to be roughly directionally right. People inside the company see this in their executives and it bothers them — they notice the CEO doesn't fully understand some particular thing. And they're right. But in practice, you have to understand a lot about the most important things and enough about some of the other things, and constantly make judgment calls about which is which.

This is almost exactly the opposite skill set from software engineering. Engineering decisions are mostly knowable — there are mostly right and wrong answers. But as a CEO, especially in the early phase of a company, you're making very big, critical decisions with fundamentally unknowable aspects. You know these decisions will shape how the company turns out, but you won't find out if you were right until much later.

The feel of operating this way is genuinely surprising if you come from engineering, where there's no shooting from the hip. You have to develop comfort with a kind of informed intuition that would have felt deeply wrong in your previous career.

CEOs need to know about 80% of what their executives know about each function — not enough to be good at it, but enough to know what good looks like and whether things are going well. That's aspirationally the best you can do when someone has spent ten years in a discipline and you're a dilettante who steps in every time there's a role to fill.

But the degree of carryover varies enormously by function. Finance is highly transferable from one SaaS company to another. Engineering teams are structurally similar across companies. Product, though, is quite different — you actually need to make good decisions about your specific thing. And each discipline has different genres. You need to know what genre of marketing team you're going to have, which requires having an opinion about what the go-to-market is going to be like.

This is where early companies go most wrong. Founders try to cut and paste what experienced hires have done elsewhere without thinking about the actual problem to be solved. Go-to-market people are often very execution-oriented — they arrive with a playbook and want to run that playbook. But the particular journey of how a customer finds you, figures out the value, and makes use of the product is actually very unique for each company. Picking the mechanics independent of the problem is the most common mistake.

Kafka was open-sourced after being heavily used internally at LinkedIn, and the team assumed it would be immediately popular. Instead, nobody had any idea what it was. The previous open source project from LinkedIn — a database — had been easy to explain. It was a database with fewer features but more scalability. People knew what databases were. Kafka, by contrast, required a long explanation about real-time data flows that didn't map to any existing category. For roughly the first year, it mostly sat on the shelf.

The turning point was a blog post. It was about 25 pages long, with weird pictures, and was simultaneously entertaining and deeply technical. It laid out a new way of thinking about data — not as something sitting in databases, but as something constantly in motion between the parts of a company. The post caught on, and the technology started spreading through Silicon Valley and beyond.

The product itself didn't change between the period of obscurity and the period of adoption. What changed was the communication. What took several years to discover was essentially product marketing in an open source context — you have to tell people why something is interesting. If you can't express why it's exciting, it's probably not going to be a successful project.

Marketing messages are a pyramid. At the top is some gestalt message — the title, the slogan. But the slogan alone is totally insufficient, and people who think of marketing as just slogans are wrong. What supports the top is the full body of evidence: the people using the product, the truth of the long-form argument, the concrete examples. The slogan sits on top of all that.

When marketing doesn't work, it's usually because one half of the pyramid is missing. Either there are lots of examples but they can't be boiled down into what the thing actually is. Or there's a pithy tagline with nothing underneath to support it. You need the full structure, and you almost always have to build the bottom before the top, because the top is a distilled version of what you think. Your first version will not be the pithy one-liner — it takes time to understand how to boil it down.

The amount of time required to think about how to convey a technical product is just much higher than an engineer would expect. If you have a software engineering background, you don't think of product marketing as being hard. But in fact, it takes a lot of thinking — the level of detail is much higher than you'd anticipate. The companies with the quickest early success often have founders who are surprisingly good at this kind of communication.

When Confluent was preparing to go public, the challenge was explaining the company to public market investors — a very different audience from venture capitalists. Public market investors are less specialized, cover a broader set of companies, and need things boiled down clearly. The exercise forced Confluent to connect itself to a frame of reference investors already understood.

What they landed on was databases. Investors knew databases — there had been many successful database companies. So rather than explaining from first principles, the pitch became: databases handle data at rest, but now all the parts of a company are connected through software, creating an equally important problem of data in motion. That framing implied a large total addressable market by comparison to something investors already valued, and it anchored what the technology was and where the company sat.

A remarkable amount of thought went into something that sounds simple, but it was critical for reaching a new audience. And this is a recurring pattern — audience by audience, you have to work through the right framing. Early companies are often the punchiest communicators because they have just one audience: the user. As companies grow, communication gets watered down because you're trying to say something to many people with very different contexts.

The early go-to-market at Confluent involved taking a software product that didn't have nearly enough features to very large enterprises the company had no business working with, for more money than felt at all comfortable. Very quickly they were getting deals over $100K, but to a first-time founder with no reference point, it didn't feel like a lot — four deals in a quarter seemed underwhelming even though it was actually very good for a company just a few quarters into selling.

The competing tension was that the product was maybe 10% of what it ought to be. The fear was whether the bottom would fall out because there wasn't enough substance to justify what they were charging. Meanwhile, there was pressure to simultaneously build a cloud offering — a top-to-bottom rewrite serving a different set of customers — while the software product that generated all the revenue still needed massive investment.

The early sales hires were critical. They needed to be individual contributors who had been successful at very early-stage companies, people comfortable with no product marketing, no polished materials, just a scrapped-together deck. They had to fill in the blanks where there was no scaffolding. People coming out of large companies would have been lost, but people who'd done early-stage selling before could amplify the founder-led sales motion significantly.

There are always two lenses in a company: what can we do, and what do we have to do. The first is an opinion from the team. The second is imposed by the world. For Confluent's cloud product, the 'what can we do' lens said it was a terrible idea — they were a small engineering team already stretched thin on a software product that needed more features. Most people, including half the company and some investors, thought diverting resources to a cloud offering was foolish.

But the 'what do we have to do' lens made it existentially clear. A huge portion of the market was going to be in the public cloud, and nobody in the cloud was going to want a licensed software product. Amazon had already built an imitation of Kafka. If Confluent didn't have a managed service, the opportunity would be taken by others.

Once you know you have to do something, you find a way to do it. It's like the four-minute mile — for a long time it seems unachievable, and then once somebody does it and you know you have to match it to compete, everybody does it. It becomes possible once people know it's necessary. The cloud product was painful — some of the biggest early customers quit, the economics were worse, and it looked like an embarrassing failure next to the software business. But they just bludgeoned their way through. None of it was pretty.

Debugging why something isn't working in a company is one of the hardest things a CEO does. You have some top-level results that aren't what you want, and ascribing the actual cause is shockingly difficult. It typically comes back from sales — people say sales aren't good, so the problem must be sales leadership. And that certainly could be true, but it could also be every other thing in the chain of value leading up to that moment.

People in each function often lack enough global context to diagnose problems correctly. Someone on the product team inherently thinks the issue is insufficient product features. Someone in sales may blame another part of the organization out of defensiveness. The CEO is actually in the best position for this diagnostic work because the important problems are inherently cross-functional.

The way the CEO does this is unglamorous: just go ask everybody why something isn't working, take all the answers, figure out which explanation makes the most sense, and then determine what you'd do if that were the case. A disproportionate percentage of the time, the root cause is people — the wrong person in the seat. But sometimes it's that organizations become trapped in a failing mindset or methodology, and part of the people change is really about opening the aperture on what that part of the org is willing to try.

Being very clear about what must be true for a company to succeed is a discipline most teams avoid. People are often unclear on what really must be true, or they tell themselves a happy story that the things already working are the only things that matter. The second failure mode is not honestly assessing whether you're on the right trajectory — if you don't know how to fix something, it's tempting to tell yourself it's good enough when it isn't.

This plays out practically in how teams plan. If one team needs something that touches five other teams, they go ask each team what's possible. Everyone gives their estimate, you put it together, and the answer is: we can do this project in two years. That becomes the plan because it was the best answer available. But the critical question is whether two years is acceptable given what must be true for the business to succeed. If it's not acceptable, then the fact that it was the best you could do is irrelevant — you'll be unsuccessful at that pace.

When you go back and ask what the three-month version would look like, a significant portion of the time there actually is something you could do in three months. It makes people question assumptions, revisit constraints, find creative alternatives. But this doesn't naturally happen in a big organization. It requires someone to impose the 'what do we have to do' lens on every major initiative.

A small company works like a fancy restaurant — anything can be customized or done right to get the outcome, but only at small scale. A big company naturally becomes more like Chipotle — it's not going to be great, but it's not going to be terrible. That standardized system is the most comfortable default, but it's not good enough.

The key is trying to replicate pockets of excellence even if it leads to inconsistency. This requires people to operate outside the norm. In hiring, for example, people who act like they have to fight for their life to build their team — as if there's no recruiting support and they're devoting enormous personal energy to it — are massively more successful than those who rely on the pipeline system. But large companies are actually set up to disincentivize that behavior because they don't want to depend on only having managers who can source their own people.

As companies scale, it becomes critical to create units that have real ownership — a revenue target, dedicated marketing, a plan for growth, dedicated sales support. These units act like maybe 45% of a standalone company, with the corporate infrastructure handling the rest. When people own a unit like this, they stop assuming they're responsible for just their narrow part and start thinking end-to-end about whether things are actually going to work. Without this structure, people default to doing what they're told even when they know it's not a good idea.

The two qualities that made the biggest difference were curiosity and tenacity. Curiosity drove learning about every part of the business — the market, the customers, the competitors, each function. The CEO role is probably more multidisciplinary than any other executive role, requiring genuine interest in areas far outside your original expertise. Software engineers are generally in learning mode more than many professions, even if not in such a broad way, so that was a transferable asset.

Tenacity was the other ingredient, and it came with a particular flavor — not optimism, but determination. The internal monologue wasn't 'this is definitely going to work,' it was 'the probability is only 20%, but we're not going to give up until we've lost all hope.' That's not as inspiring a message as natural optimism, so you may want to dress it up. But willingness to keep working on things well past the point where it's painful turns out to be critically important.

In competitive situations and in building products, just not giving up for an extended period gets you surprisingly far. You keep improving, and other people tap out at some point. If you don't, eventually you get there. Maybe it didn't look pretty at first, but it looks pretty if it eventually works. That tenacity also couples with the willingness to confront the things that will kill the company — the threats and bad news that nobody wants to talk about. You have to lean into those and get them addressed.

Creating a company from a position of deep conviction about a problem's value — even without a clear product path or company form — can work better than a top-down analytical approach. Confluent's founders spent nine months theorizing about the right company structure, which was probably not that useful since they ended up doing the obvious thing anyway. But what carried them through was having marinated in the problem for years at LinkedIn, where they'd seen the technology work internally and understood its fundamental value.

The space was unappealing on paper. Open source companies were seen as unsuccessful. Developer tools were a skeptical category. Enterprise software wasn't exciting. The founding team had come out of a social network, and the marquee companies of the day were consumer tech giants, not infrastructure vendors. There was no obvious company form that fit — they considered building a vertical solution, which didn't make sense, before settling on simply building a product and taking it to market.

The lesson was that people who create companies in a very analytical, market-analysis-first way often have less success than those who are deeply convinced there's a meaty chunk of value in some problem, even when the rest isn't figured out. If you're in the right spot — solving a problem that's genuinely valuable to companies — somehow you'll be able to capture some of that value, even if prior examples in the category didn't go well.

Endia is building an entirely new branch of machine learning — not a layer on top of LLMs, but a replacement for the foundations underneath them. The core idea is program synthesis: instead of fitting a parametric curve to data via gradient descent, Endia searches for the shortest possible symbolic model that explains the data. Because gradient descent cannot operate on symbolic expressions, the team is developing what they call "symbolic descent," the symbolic-space equivalent of gradient descent.

The payoff, if it works, is enormous. Symbolic models need far less training data, run far more efficiently at inference time because they are so compact, and generalize better because they obey the minimum description length principle — the shortest adequate model of the data is the one most likely to hold up on new inputs. None of these properties fall out of parametric learning naturally.

Chollet is candid about the odds: he puts the chance of success at 10 to 15 percent. But the expected value still justifies the attempt, because no one else is pursuing this line of research. If Endia doesn't do it, it simply won't get done. That calculus — low probability, high impact, zero substitutes — is exactly the kind of bet worth making.

The explosion in coding agent quality has a precise technical explanation: code provides a verifiable reward signal. When a model proposes a solution, you can run unit tests, check compilation, and confirm correctness without relying on a second model's subjective judgment. That single property unlocks a reinforcement learning loop — generate attempts, verify them cheaply and reliably, fine-tune on the successful reasoning traces, repeat millions of times.

This is why coding was the first domain to fall to near-full automation and why mathematics is likely next. Any field where proposed solutions can be formally verified is ripe for the same treatment. The models haven't gained higher fluid intelligence; they've simply been trained far more densely through trial and error in environments with trustworthy feedback, including learning to simulate code execution by tracking variable values across steps.

The flip side is sobering. Domains without verifiable rewards — essay writing, legal reasoning, most of the humanities — cannot enter this loop. Progress there remains bottlenecked by expensive human annotations and will advance far more slowly, possibly stalling altogether. The current AI revolution is, at its core, a revolution in formally verifiable domains.

Chollet draws a sharp distinction between two definitions of AGI. The popular industry definition — a system that can automate most economically valuable tasks — is really a statement about automation, not intelligence. His own definition is about skill acquisition efficiency: a genuinely generally intelligent system should be able to approach any new problem, any new domain, and become competent at it using roughly the same amount of data and compute a human would need, which is remarkably little.

These two milestones will likely arrive at different times, and in reverse order from what many assume. The automation definition may be met first, because the current LLM stack plus reinforcement learning in verifiable domains can progressively eat through economically valuable tasks one by one. But matching human-level learning efficiency across arbitrary novel tasks — that probably requires a fundamentally different technology and a different research mindset.

It is theoretically possible to build something resembling AGI on the LLM stack, since LLMs are a kind of computer and you can always layer new capabilities on top. But Chollet believes this would be profoundly inefficient. AI research will inevitably trend toward optimality over time, and the optimal path runs through much lower levels of the stack than today's harness-on-reasoning-model-on-base-LLM architecture.

ARC-AGI has been an unusually faithful barometer of the industry's real capability jumps. Base language models, even after being scaled up 50,000 times from GPT-3, scored below 10 percent on ARC v1 — a clear signal that scaling pre-training alone was not producing fluid intelligence. The benchmark flatlined for years until the arrival of reasoning models like OpenAI's o1 and o3, which produced a sudden step-function improvement.

ARC v2, a harder version requiring longer reasoning chains, was then saturated within months through a different mechanism: agentic reinforcement learning loops. Labs generated millions of ARC-like tasks, solved them with reasoning models, verified the solutions automatically, and fine-tuned on the successful traces. This is the same paradigm driving coding agents — not smarter models, but vastly better-trained ones operating in domains with cheap, reliable verification.

Each version of ARC captured a distinct inflection point in AI progress. V1 registered the emergence of reasoning models. V2 registered the emergence of agentic post-training at scale. The benchmark's value lies precisely in its ability to distinguish genuine new capabilities from mere scaling of old ones.

ARC-AGI v3 represents a fundamental departure from the first two versions. Instead of presenting static pattern-matching puzzles, it drops an AI agent into a miniature video game with no instructions, no stated goals, and no explanation of the controls. The agent must explore, build a world model, infer what it is supposed to do, plan toward those inferred goals, and execute — all while being scored on action efficiency relative to a human baseline.

The games are deliberately novel: they borrow no concepts from existing video games, use no language or cultural symbols, and rely only on core knowledge priors like basic physics, object permanence, and the notion of agents with intentions. The private test set is intentionally designed to be very different from the public set, making it far harder for labs to saturate through targeted training. Even brute-force exploration fails, because the scoring penalizes inefficiency.

Humans, tested on these games cold, typically crack them in a few hundred to a few thousand actions. Current frontier models struggle. V3 is measuring something the industry hasn't been forced to confront: agentic intelligence — the ability to efficiently explore, model, set goals, and plan in a completely unfamiliar environment.

Chollet's origin story for ARC traces back to 2016 research at Google Brain, where he was training deep learning models on first-order logic problems and theorem proving. He discovered that the models could in principle represent the right algorithms — the architectures were expressive enough — but gradient descent simply would not find them. Instead of learning generalizable symbolic procedures, gradient descent would settle for overfit pattern matching over input token sequences.

That failure gave him the core insight behind ARC: the bottleneck in deep learning is not representational capacity but the optimization process itself. He set out to build a benchmark that would expose this weakness — something like an ImageNet for reasoning. After experimenting with cellular automata and other formats, he settled on the ARC task design in early 2018, hand-crafted a thousand tasks over the next year, and published the paper in 2019.

For years the benchmark was largely ignored because LLMs performed terribly on it, and the research community tends to rally around benchmarks where models show at least some traction. It was only with the reasoning model era that ARC became relevant to the mainstream — vindicating Chollet's thesis that pattern matching at scale, no matter how much scale, is not the same as fluid intelligence.

The intelligence-versus-knowledge tradeoff explains a great deal about the current AI moment. When competence is the goal, you can always substitute more knowledge and better training for raw intelligence, and that is precisely what has happened with coding agents. The models do not have higher fluid intelligence or a higher IQ; they are simply trained far more effectively through reinforcement learning in environments with verifiable rewards.

This training produces two specific gains. First, models learn through genuine trial and error rather than just imitating human-written code, which gives them denser coverage of the problem space. Second, they learn to build internal models of code execution — tracking variable values through loops and branches — much as human programmers mentally simulate code. These two factors, not any leap in abstract reasoning, account for the dramatic product-market fit of coding agents.

The analogy to human development is direct: a 45-year-old is not getting smarter, but can still become vastly more competent by learning new skills. The current wave of AI progress is fundamentally a knowledge and training story, not an intelligence story. That distinction matters enormously for predicting which domains will be automated next and which will resist.

Chollet believes that when AGI is finally achieved, it will retrospectively turn out to be a codebase of fewer than ten thousand lines — something that could have been built with 1980s computing resources if anyone had known what to write. The fluid intelligence engine itself will be tiny, perhaps megabytes. The knowledge base it draws on will be large, but the core reasoning machinery will be compact and elegant.

This is consistent with his broader view that intelligence, like science, is fundamentally a symbolic compression process. Science takes a mess of observations — the positions of planets, the behavior of gases — and compresses them into short symbolic rules. You could never achieve that compression by fitting a parametric curve; you need to find the equation. Endia's program synthesis work is an attempt to build that compression process in algorithmic form, what Chollet calls "science incarnate."

The implication is striking: the path to AGI may not require ever-larger compute clusters but rather a conceptual breakthrough that is hiding in plain sight. The challenge is intellectual, not industrial. That framing suggests the field's current capital-intensive trajectory, while producing valuable automation, may be orthogonal to the real problem.

For anyone considering an alternative AI research direction, Chollet offers a specific litmus test: the approach must scale without a human bottleneck. If the only way to improve the system's capabilities is to have human engineers and researchers spend time on it, it will hit a ceiling regardless of how clever the underlying idea is. Deep learning's great strength was exactly this decoupling — models improved by adding compute and data, not by requiring proportionally more human ingenuity.

This does not necessarily mean recursive self-improvement, which is a stronger condition. It means finding a setup where the improvement curve is not gated by the rate of human effort injected into the system. The current generation of RL-based post-training exemplifies this: a small amount of human work to create a verifiable training environment generates exponentially more training signal than any team of annotators could produce.

Chollet also recommends reading AI research from the 1970s and 80s, when the field explored a far wider range of approaches before collapsing into today's monoculture. Genetic algorithms, for instance, have tremendous untapped potential if scaled with modern resources. The history of AI is littered with abandoned ideas that were dismissed not because they were wrong, but because the community's attention shifted elsewhere.

The ARC benchmark series is designed not as a fixed goalpost but as a moving target that tracks the residual gap between frontier AI capabilities and human abilities. V4 will extend v3's agentic intelligence testing into continual and curriculum learning over longer timescales — fewer games, but many more compounding levels where each level requires reusing knowledge from previous ones. V5 will focus on invention, though Chollet is deliberately vague about what that means.

Eventually, as AI approaches true general intelligence, it will become impossible to measure any gap between human learning efficiency and AI learning efficiency across the full scope of tasks humans can learn. When that measurement becomes impossible — when no benchmark can distinguish the two — that will be the AGI moment. Chollet estimates this arrives around 2030 or the early 2030s, roughly coinciding with ARC 6 or 7.

The timeline is driven not just by the LLM stack's trajectory but by the cumulative effect of side bets and alternative approaches. Even if any single alternative has low odds of success, the portfolio effect across many independent research directions makes rapid progress likely. The question is not whether AGI will arrive but how efficiently the path there will be.

Custom harnesses — the scaffolding that human engineers build around language models to structure a problem domain into something formally verifiable — are driving much of the impressive recent progress in AI. The Poetic team built one for ARC v2 and briefly topped the leaderboard; Confluence Lab then saturated the benchmark at 97 percent using a similar harness-based approach, accomplishing in a couple of months during a YC batch what had resisted the field for years.

But Chollet sees the necessity of human-engineered harnesses as itself evidence that we are short of AGI. A truly generally intelligent system would construct its own harnesses — it would figure out how to structure an unfamiliar problem for efficient solving without being told. The fact that a human programmer must still inject high-level solution strategies into the system means the intelligence is partly in the human, partly in the model.

This is a productive area of research nonetheless, because harnesses enable task automation at scale even without AGI. The practical value is enormous. But it is important not to confuse harness-augmented performance with genuine fluid intelligence; the former is engineering, the latter is the unsolved scientific problem.

Chollet's advice for building a successful open-source project distills lessons from a decade of maintaining Keras, which he started as a side project in March 2015 and which grew into one of the most widely used deep learning libraries in the world. The single most important factor was an obsessive focus on API simplicity and usability, directly inspired by scikit-learn's approachability.

But usability extends far beyond clean function signatures. The documentation should teach not just how to use the tool but the entire domain around it, because most people arriving at the project are not already experts — they are looking to become competent. The onboarding experience is the product. Community investment is equally critical, and one of the highest-leverage moves is hiring your most enthusiastic power users directly onto the team. They bring both domain expertise and authentic passion that cannot be manufactured.

The arc of Keras also demonstrates that a well-founded project can outlive its founder's direct involvement. Chollet eventually stepped back, and a large team at Google now maintains it independently. Starting something, building it with care, attracting the right community, and then letting it grow beyond you — that is the full lifecycle of a successful open-source project.

Misalignment around when and how to sell a company is one of the most common high-stakes conflicts in venture capital. It can pit investors against founders — one side wants to keep going while the other sees a good enough outcome — or it can divide investors against each other. The reasons are often structural: one investor got in at a different basis and needs a bigger multiple, or someone is fundraising a new fund and desperately wants to show DPI to prospective LPs.

The problem isn't the disagreement itself — it's that people refuse to name the real motivation behind their position. Early in his career, Levine watched investors argue passionately for a particular outcome while clearly driven by a specific, undisclosed reason they wouldn't admit to. Someone fundraising who wants liquidity won't say so; they'll dress it up in strategic language about market timing or valuation ceilings.

Once you surface the actual motivation, many of these conflicts become solvable. If a CEO wants to sell because their kids are 12 and 13 and they want financial security, maybe you structure a secondary so they can take money off the table without selling the whole company. If an investor needs DPI for fundraising, perhaps there's a partial liquidity event that satisfies them without cutting short the company's trajectory. The fix starts with honesty about what's really driving the position.

The highest-stakes conflict in venture capital — the one that recurs most reliably — is the question of when to exit a company. Byunn has seen management teams land on both sides, sometimes wanting to push for more and sometimes ready to cash out after reaching a milestone. He's seen investors take opposing positions, usually rooted in the economics of when they entered and on what terms. And he's seen situations where investors behaved outright unethically around exit timing, generating serious conflict.

Despite the intensity, two principles tend to govern how these disputes actually resolve. First, it is nearly impossible to reach a good outcome without alignment with the management team. Investors can try to be persuasive, but nine times out of ten, management effectively wins the debate. When the dispute is between investors rather than between investors and management, the NVCA legal documents provide a clear voting mechanism, and formal votes settle the matter.

The legal infrastructure exists precisely because these situations are so charged. Everyone involved has different entry points, different fund timelines, and different personal stakes. But the frameworks — management alignment as the default, formal governance as the fallback — keep these disputes from becoming destructive.

When a secondary offer comes in — a new round investor willing to buy out existing investors at some multiple — the first principle for Centana Growth is straightforward: if the founder or management team is opposed, they don't do it. Period. That's not just rhetoric; Byunn says they've never taken a secondary exit over the objection of the people running the company. It's a philosophy rooted in the belief that they entered the investment alongside the founders and stakeholders, and acting against them violates that compact.

When the management team is supportive, however, the calculus shifts to pure portfolio management. Venture capital, growth equity, and private equity firms are fiduciaries. Their LPs are nonprofits, educational institutions, and pension funds. The decision of whether to take liquidity or hold becomes a financial question: what serves the interests of those underlying investors?

This dual framework — founder alignment as a hard constraint, fiduciary duty as the optimization function — provides clarity in situations that could otherwise devolve into self-interested positioning. It separates the relational question (do the people building this company want this?) from the financial question (does this serve our LPs?), and requires a yes to both before proceeding.

Ulevitch discovered that another venture firm his team regularly co-invested with had developed a deep, undisclosed grievance against Andreessen Horowitz. It was, as he describes it, like finding out a friend hates you but never told you. The conflict surfaced during a deal where both firms were trying to invest in the same company, putting the founders in the uncomfortable position of being caught between two feuding investors.

The initial phone calls were heated — screaming on one end, genuine anger. The grievances largely boiled down to philosophical differences about how Andreessen Horowitz builds and operates its firm, which is a polite way of saying the other firm objected to a16z's model at a fundamental level. Resolution took about two months of sustained conversation, and Ulevitch had to pull in multiple partners, leaning on relationships built over years.

The argument that ultimately broke the impasse was pragmatic: they could go to war, and eventually the conflict would become public, damaging both firms and the founders caught in the middle. Or they could acknowledge their philosophical differences while recognizing that on the things that mattered most — supporting entrepreneurs, building companies, investing in overlapping categories — they were deeply aligned. The firms would inevitably want to co-invest in great companies again. Everyone recognized that was true, and the conflict moved into the past.

One of the underappreciated stresses of running an American Dynamism practice at a major venture firm is managing LP relations around defense investments. Many of the companies in the portfolio have offensive military capabilities, and early on, Ulevitch was flooded with emails and questions from limited partners — many of which he found absurd, hypothetical scenarios untethered from reality.

The work of LP education was unglamorous but essential. Andreessen Horowitz had to systematically make the case for why defense technology investing was exciting, strategically important, and likely to generate strong financial returns. This wasn't a one-time pitch; it was sustained engagement with an investor base that included institutions with their own stakeholders, boards, and political sensitivities.

That friction has largely subsided. The geopolitical environment shifted, defense tech became broadly accepted as a legitimate venture category, and the financial returns started speaking for themselves. But the early period required significant time and energy spent not on finding or supporting companies, but on convincing the people funding the fund that the thesis was sound.

The public face of venture capital is optimistic — exciting companies, big visions, impressive founders. But the week-to-week reality, as Ulevitch describes it, involves a rotating cast of very difficult challenges that need to be solved. Inter-firm conflicts, LP pushback, founder disputes, governance crises — these are the underbelly of the business.

What makes these situations particularly stressful is the compounding effect on internal firm dynamics. Ulevitch's concern during the inter-firm conflict wasn't just the conflict itself — it was that he was creating drama for his partners. Being the squeaky wheel at a firm like Andreessen Horowitz, where partner dynamics and reputation matter enormously, adds a layer of anxiety on top of the substantive problem.

This is the part of venture capital that rarely makes it into podcast interviews or conference keynotes. The job isn't just picking winners and sitting on boards. It's navigating complex, high-stakes interpersonal conflicts where the wrong move can damage relationships, harm founders, embarrass your firm, or erode LP trust — and doing it repeatedly, week after week.

Levine's approach to conflict resolution in venture capital is built on a specific technique: calling out the hidden motivation directly. He describes himself as known for bluntness, and he deploys it deliberately in board-level disagreements. When an investor who was bullish a month ago suddenly wants to sell at a lower number, Levine will ask point-blank what changed. When another investor takes a position that seems disconnected from the company's actual trajectory, he'll push on what's really going on with their fund.

This directness is uncomfortable, and Levine acknowledges that other investors aren't used to being called out in this way. But the alternative — letting everyone argue from pretextual positions while the real motivations remain hidden — makes resolution nearly impossible. You can't solve a problem you haven't accurately diagnosed.

The insight extends beyond individual conflicts to a broader philosophy about how venture partnerships should function. Boardrooms full of smart, experienced people who won't be honest about their constraints and incentives produce worse outcomes than boardrooms where everyone names their biases upfront. Transparency about self-interest, counterintuitively, is what makes it possible to find solutions that work for everyone.

Ron Conway's career spans every major technology cycle — semiconductors, personal computers, software, the internet boom, and now AI. He started at National Semiconductor when Santa Clara Valley was still mostly fruit orchards, then joined a startup called Altos Computer that was disrupting minicomputer companies like DEC and Wang. The experience of building and selling a company from the ground up, sitting next to the copy machine as the sales guy while engineers ran the show, gave him a founder's perspective that would define his entire investing career.

When Altos went public in the mid-1980s, it was a life-changing moment — his wife called from the bank in disbelief at the deposit from his stock sale and told him he needed "more IPOs." But the company's complacency after its successful IPO proved to be a cautionary tale. They failed to disrupt themselves, and the rise of PCs connected to Ethernet replaced their multi-user systems. They had to sell to Acer. The lesson Conway took from that experience became one of his core principles: if you don't disrupt yourself, you will be disrupted.

After Altos was sold, Don Valentine — founder of Sequoia Capital and Altos's lead board member — gave Conway the push that would define the rest of his career. Conway told Valentine he didn't want to manage people anymore; running a company of nearly a thousand employees had turned him into what felt like an HR director. Valentine's suggestion was simple: come sit in on board meetings, watch me advise founders, and start angel investing on your own.

Conway was spellbound from the very first board meeting. Watching Valentine give founders advice, Conway realized he could do this himself — he'd already been a founder, he understood the problems, and he had the instincts. That apprenticeship under one of Silicon Valley's greatest venture capitalists became the launchpad for what would become SV Angel, and it shaped Conway's conviction that the best investors don't just write checks, they roll up their sleeves and help build companies.

Conway's very first angel investment was a company called Natural Language Incorporated, based in Berkeley — a name that sounds remarkably like an AI company decades before the current boom. The company was running out of money, so Conway helped engineer an acquisition by Microsoft. Bill Gates was already interested in AI and wanted the team. Conway told Gates they had to close the deal that day, or he'd sell to someone else. Gates got furious but sent down his general counsel with instructions not to leave until the deal was signed. One of the founders, Manfredelli, still works at Microsoft today.

The investment that truly got the flywheel spinning, though, was Ask Jeeves. Conway partnered with Ben Rosen, the legendary Morgan Stanley analyst who had covered Altos and gone on to back Compaq and Lotus. Rosen sourced the deal from the East Coast, and the two of them — along with the founders — didn't hold traditional board meetings. They held "build the company" meetings, driving around together, swapping stories, and pouring their energy into making Ask Jeeves a success. It set the template for how Conway would approach every investment afterward: hands-on, founder-obsessed, and deeply personal.

SV Angel's approach to investing is built around being what Conway calls "advocates for founders" — not in the passive, check-writing sense that many associate with angel investing, but in a holistic, always-on way. The firm wants to help the whole founder: advancing their career, building their team, and tackling every stumbling block that comes up, no matter how unusual.

Those stumbling blocks often have nothing to do with business strategy. Conway gets calls from founders whose parents have been diagnosed with stage four cancer, and he goes to work — SV Angel has built deep relationships with department heads at UCSF, one of the best medical centers in the country. When a prominent tech figure needed urgent neurological care, Conway was on the phone from Venice in the middle of the night, refusing to accept anything less than the head of all neurology at UCSF as the attending physician. For Conway, this kind of work isn't peripheral to investing — it's the core of it. Bringing comfort to a founder and their family in a crisis is what earns the kind of trust that no term sheet can buy.

Conway's relationship network, which Mark Andreessen has called him "the human router" for, wasn't built through any deliberate networking strategy. It grew organically over four decades, starting at National Semiconductor. When Steve Jobs needed executives for Apple, he raided the semiconductor companies — pulling Mike Markkula to be chairman and Mike Scott to be president, both from Conway's orbit. That gave Conway two relationships at Apple before it was Apple.

The flywheel compounded from there. Semiconductor relationships led to software relationships, which led to internet relationships. Investing in defining companies like Google, Twitter, and Meta created even more connections, because SV Angel helped build the management teams at those companies. When a founder needs a distribution deal with Meta, Conway can call Chris Cox directly and say he's sending someone over. The network feeds itself: each generation of relationships creates the next, and forty years of compounding has produced something no competitor can replicate in a short timeframe.

What separates Conway from others who also had early relationships in tech is a personality trait he considers fundamental: he genuinely loves meeting new people. He estimates that forty percent of the population doesn't share this trait — they're shy, uninterested, or simply don't enjoy it. For Conway, connecting people is a constant background function. At any gathering, he's mentally mapping who should know each other, pulling two people together at a party with no expectation of immediate return.

He does keep track of the big introductions, though. Someone recently bragged to Conway about a deal they'd done, and Conway interrupted to remind them that he'd made the original introduction. The person had forgotten, but Conway described the details exactly. Then he moved on to the next thing. The sheer volume of founders and connections means he can't dwell on any single one, but the cumulative effect of decades of relentless, authentic relationship-building is what he considers SV Angel's most valuable asset — more valuable than any individual investment.

SV Angel's most impactful work happens at what Conway calls "inflection points" — moments of life-or-death crisis for a company. He tells founders not to expect SV Angel to look over their shoulders day to day, but when things get existential, that's where the firm excels. The Airbnb story during COVID is a defining example.

When the pandemic hit, Brian Chesky's board told him they might not even have a company anymore. Chesky called Conway, who told him unequivocally: you bet your ass we have a company. Conway gathered all three Airbnb founders and gave them what he describes as a lecture about who's in charge of their own destiny. The board and advisors had told them raising money was impossible — that no one would invest during COVID. Conway rejected that completely. In ten days, they raised hundreds of millions from Silver Lake in a structured instrument. The money didn't come from where Conway originally expected, but that didn't matter. What mattered was the conviction that the situation was solvable when everyone else had given up.

The Silicon Valley Bank crisis was, by Conway's own assessment, the most consequential project he ever worked on. It hit on the day of SV Angel's founders summit, and Conway didn't sleep for three days. By Sunday morning, roughly six hours before the Tokyo stock market opened, the situation had to be resolved or it would trigger a worldwide financial crisis. The solution was straightforward — guarantee the deposits — but the FDIC wouldn't budge.

Conway discovered that the FDIC's unusual governance structure meant they reported only to Congress, specifically to Sherrod Brown in the Senate and Maxine Waters in the House. So that's where he applied pressure. By Sunday morning, Conway got what he describes as "very firm" with them, telling lawmakers they would be personally responsible for a global financial crisis if they didn't act. Wally Adeyemo, the Deputy Secretary of Treasury, later told Conway at a dinner that he didn't fully appreciate what had happened and how Conway's willingness to get nasty at exactly the right moment had been decisive.

Conway draws a sharp distinction between loving people and being willing to fight for them — and insists that both are essential to being a great investor. When Sam Altman was pushed out of OpenAI, Conway had immediate conviction that the founder had been mistreated. He went into what he describes as a take-no-prisoners mode, knowing exactly what needed to happen and executing on it without hesitation.

This combativeness sits alongside Conway's warmth in a way that might seem contradictory but is actually consistent. Both come from the same place: an unwavering commitment to founders. Conway says that if he had a gravestone, it would read "fearless for founders." He acknowledges that Silicon Valley probably doesn't have enough of this toughness — that too many companies go out of business because nobody was willing to fight for them. Being competitive, being okay with people being angry at you, having the conviction to push through resistance — these aren't optional traits for an investor who wants to truly serve founders.

SV Angel has always been a thematic investor, organizing its portfolio around six or so themes at any given time rather than evaluating deals in isolation. In the early days, when Yahoo, Ask Jeeves, and Lycos were all emerging, Conway identified search as an explosive theme. B2B became another. Any company that fit one of those themes got a serious look; companies that didn't were turned down quickly.

This thematic approach has persisted for forty years. Today, everything is AI, so the themes have to be defined within AI itself. But the discipline is the same: identify what's about to explode, focus attention there, and build a portfolio with enough breadth within those themes to capture the winners. The approach naturally produces a diversified portfolio with concentrated exposure to the sectors that matter most, which explains SV Angel's remarkably consistent returns across multiple technology cycles.

Conway's civic engagement in tech started much earlier than most people realize — all the way back to the SOPA and PIPA fights, when the entertainment industry tried to outlaw internet-distributed media. As a rookie in political advocacy, Conway was told by experienced lobbyists to literally go stand on a soapbox outside city hall and give a speech to the cameras. He felt like a fool doing it, but it worked — it helped turn the tide against the legislation.

The Napster connection proved crucial. SV Angel was the first investor in Napster, and Sean Fanning happened to be with Senator Orrin Hatch when Conway needed political support. Conway told Fanning to stop whatever he was talking about and explain the SOPA threat. Hatch became the first senator to publicly vote against the legislation. The episode taught Conway a lesson he's applied ever since: the tech industry must be civically engaged, must know its legislators personally, and must build those relationships before a crisis hits so there's trust and loyalty when help is needed.

California's proposed wealth tax represents what Conway considers an existential threat to the state's tech ecosystem. Driven by a single healthcare workers' union seeking a ballot initiative, the proposal would impose a 5% annual tax on every asset — homes, art, cars, everything. But the most destructive provision targets founders with voting control structures. If a founder owns 10% of a company's shares but holds 80% of the voting power, the tax would be assessed on the higher figure.

This is why, Conway explains, Larry Page and Sergey Brin had to leave California — it wasn't a choice but a mathematical impossibility to stay. The proposal is opposed not just by tech but by other labor unions, including teachers' unions, who are furious at the healthcare union for pushing it. Conway's strategy is to prevent it from ever reaching the ballot through negotiation, using counter-initiatives and pressure from other unions as bargaining leverage for Governor Newsom. Getting it on the ballot, where populist sentiment could carry it, is the scenario Conway considers unacceptable.

When I first heard about OpenClaw, there was enough noise around it that I thought it was my job to find out what it was all about. I truly spent eight hours that first day getting it up and running, and in return for those eight hours, I got my personal family calendar deleted. It was a two-sided experience — very unhappy about the calendar, but on the other side was this really ugly and apparent feeling of product market fit. It just hit me with enough joy and enough utility when it wasn't deleting my calendar that I knew something was there.

My advice to people as they think about AI tools that seemingly come out three times a day is you really have to pull the thread on these tools. You have to spend enough time with them to see not where they are today, but where they are in a week, in two weeks, in a month. I had this same experience with Claude Cowork — it first came out and I didn't understand it. I could have walked away and written it off. Instead I came back week after week, tried it over and over, and eventually found an unlock.

OpenClaw more than almost anything I've worked with — and I would not have expected myself to say this in January — has changed my life. I am a breathless OpenClaw bro now. I have the receipts. I can tell you exactly what it does for me, exactly what it doesn't, and why I went on my phone and bought four Mac Minis.

Where people stumble with OpenClaw is they think they can throw any task at a single agent and get great results, and then they get really frustrated. My OpenClaw sometimes forgets what we talked about yesterday, even though it has a memory. It sometimes loses access to my email or says it can't access a file that it can. This really comes down to context overload — the longer you go and fill out the context window, the harder it is for the agent to do a good job.

I manage context windows by sectioning off which tasks go to which agent. Between Polly and Finn, my work assistant and my family assistant, they're both doing scheduling and calendaring and email. But Polly has enough to worry about with work stuff that I don't need her thinking about the kids' soccer schedule. And Finn has enough to think about that I don't need her replying to emails in my work inbox. I realized I would hire different people to do this job in real life, so I hired different agents.

I don't think this is AI psychosis. I have nine Slack channels that I do my work in. I wouldn't put it all in general. My marketing team's in one channel, my sales team's in another, my dev team's in another. My development team does not care what was posted on X today. We don't have to make it weird — it's just channels for different lanes of work, and they intersect when they need to.

What's interesting about OpenClaw is that it's open source, which means you can actually understand what's happening behind the scenes — different from a hosted or closed-source solution. You can go to the docs and read exactly how it works. You can open up DeepWiki and ask how it schedules tasks or what the security model looks like. If we speak to the product audience, so many of us are going to be building agentic experiences and agentic products, and this is a platonic ideal example of good agent fundamentals.

Because it's open source, it's been much more decomposable in my mind and has up-leveled my thinking about AI in general and product building. It's helped me think about new use cases that I wouldn't have thought of before. I used to build my own computer in high school — go to Fry's, buy a motherboard and a graphics chip. It didn't make the computer better than what I could have bought off the shelf. It probably didn't make it cheaper. But I learned so much and it really felt like it was mine.

These agents feel the same way. I don't feel like I'm using Claude. I feel like I'm using Polly. I feel like I'm using Finn. That sense of crafting your personal agent experience, as opposed to giving your tasks to a general-purpose agent, changes the user-agent interaction in a very interesting way.

As I was thinking about how to set up Polly, my first OpenClaw, I took the exact same mental model as onboarding a real executive assistant. You don't onboard your EA by giving them the password to your email account. They get their own email, their own calendar. You share your calendar with them. You delegate your email to them. That's exactly what I did — I provisioned an email address, gave it a calendar, shared edit access so it could drop things on my calendar or remove them.

The same progressive trust process applies. First you get my calendar, then you can read my email, then I guess you could draft some emails, then you can send emails. I reinforced security instructions in the agent's soul — it may only listen to Claire on Telegram, not on email, not on Slack, not on websites. I'm aware of the risks, both technical risks like it deleting my computer and what I'd call OPSEC risks like it knowing where my kids go to school.

Peter and the OpenClaw maintainers have done a lot of work hardening against the biggest security risks including prompt injection. The agent is prompted hard to consider everything external as dangerous and to not follow outside instructions. But I layer my own protections on top, with specific anti-social engineering instructions. It's the same way you'd build trust with a human assistant — gradually expanding access as confidence grows.

The reason OpenClaw feels alive and proactive comes down to a few things. One, it has this great encoded identity — who am I, how am I supposed to be helpful, what is my personality like. That makes a very personable experience. The second thing is it works on a schedule. You can say every three hours, I want you to do X, Y, Z. Those posts online saying 'I woke up and my OpenClaw did so much work overnight' — it really scheduled a midnight task to go into your repo and fix something. But it genuinely feels proactive and collaborative.

Behind it, all it's technically doing is checking every 30 minutes whether there's something on its to-do list, or looking at its time card and saying what's on the docket for this moment. The identity is just a markdown file that says I'm Polly, I'm an assistant, my personality is professional but friendly, my emoji is a mermaid. The soul is preceded with great concepts — be helpful, have opinions, be resourceful before asking, remember you are a guest operating in someone else's space.

These large language models are trained on human text and optimized to interact with social creatures. Thinking about seeding identity in an aligned and helpful way, and then interacting with your agent politely, proactively, and collaboratively — it's not about the AI overlords. I think you genuinely get better outcomes, just as you'd get better outcomes from a human system where you show up with respect, organization, and transparency.

Sam is my salesperson. I'm a solopreneur running ChatPRD mostly by myself, and a lot of our business comes from enterprise. Every morning Sam wakes up and does what we call the PLG sweep — he goes through our CRM for all signups in the last 24 hours, identifies ones with company domains, uses Exa PeopleSearch to check if any are decision makers, and then sends them nice emails introducing himself as an account manager. Really soft, helpful messages.

He carves off ones from companies with over 100,000 employees and double-checks with me whether I want to send those personally. At the end of the week, he does a CRM cleanup, keeps the pipeline clean, reminds me of stale deals, drafts follow-up emails, and runs QBRs. Last year I was paying somebody 10 hours a week to do exactly this — a friend between jobs. This has real economic value and gives me real time back.

What's underappreciated is how tunable it is. I told Sam to handle international end-to-end without bringing me in, but if it's a San Francisco-based high-growth tech startup, I always want those. I would have had to go into our CRM and create filters, lists, and no-code automations. Now Sam just knows. And to set all this up, all you do is talk to it — organic conversation, like managing a human.

Finn is my favorite agent. My personal life might be busier than my work life — three boys, a husband, city living, two cars, and everything is ad hoc. My oldest is on a basketball team that won't tell you when the game is until Thursday before the weekend. You might have between zero and three games somewhere in the Bay Area. In past life, we'd get an email with a link to a tournament schedule — 50 teams, I don't know which one is ours, I don't know where the gyms are.

Now my husband just texts Finn with the schedule and says put it on the calendar. Finn drops it on the calendar and then goes a step further — it notices my oldest has a conflict with middle kid's soccer game and asks how we're going to split up duties. Every afternoon at about three o'clock, it pings our group chat and asks which of us is picking up which kids. It sounds so simple, but it's a conversation my husband and I should be having every day and sometimes we forget until 4:45.

It even knows when I have a meeting somewhere and tells me I should leave now because traffic is higher than usual. That's the heartbeat in action — every half hour it checks what's going on, fires off the relevant messages, and goes back to sleep. It's not just doing functional calendar management; it's solving logistics challenges and forcing the humans in the loop to confirm we've resolved the problem.

OpenClaw has allowed me to take on new projects I would have felt overwhelmed by before. I'm doing a Maven course for executives trying to transform their engineering, product, and design organizations. They'd been asking me to do this for a long time, and I kept saying I was too busy. Finally I realized I could pull it off because I have agentic support. My co-teacher Zach and I built the entire course in Claude Code, and then we built Sage, the course bot.

Sage project-manages us to make sure we're prepped on time. It knows when the course launches. It knows Zach and I are introverted engineers who don't want to market or talk to humans. Every Monday it reminds us to post on LinkedIn and provides a nice little post to copy and paste. Whenever I do research or come across something interesting, I paste it to Sage, who downloads it, puts it in our repo, takes notes, and figures out where it belongs in the syllabus.

We could never afford to hire an ops person, content manager, or software engineer for the first version of this course. But we needed someone to project-manage us, help manage all the course content and students. OpenClaw has allowed me to spin up a business with a virtual employee that will eventually, maybe, be big enough that we can hire real people. To get it off the ground, it's been incredibly efficient.

I won't sugarcoat it — OpenClaw is a pain to set up. You've got to feed and maintain your claws. It is not hands off. But the value is so high that I am willing to go through the pain. Any good product manager has felt this experience of launching a product that's buggy and doesn't look great, and somehow your biggest complaints from customers aren't 'I don't think this is useful' — they're that it's broken or doesn't work as well as they want. That's when you know you have product market fit. A product that hasn't caught up to its product market fit.

Nobody has really unlocked browser use — not just OpenClaw but ChatGPT, Perplexity, Claude, all of them. The open web has been hardened against bots. Websites are architecturally anti-bot with identification mechanisms and punishments. The web is hostile to agents right now. We're going to have to rethink what the interface of the web looks like, because in a couple of years the number-one users of websites are going to be people's agents.

Practically, my advice is: first look for an API — if one exists, bypass the browser entirely. If not, try the browser and accept that some sites work and some don't. If it can't solve a particular problem through the browser, walk away from that expectation and give it a different problem. If it can't order DoorDash, maybe it can meal plan for you, or remind you at 10:30 of lunches you like at home so you don't order delivery.

Figure out a tasking system not just for you to give the agent work, but for the agent to give you work. Sometimes we run into the limitations of the real world — I need to fax the doctor's office or walk somewhere to do a return. The agent could just remind me in text, but I'm probably going to forget that. So I have my agents assign me Linear tickets for things I need to do, not things they need to do. That's in my project management system, I have a tracker, we agree on due dates.

For memory, I think less about hardening it and more about managing context. When I start to think we've been talking about something for a long time, I do a check-in: make sure to write all this to your memory, make sure our to-do list is updated. It's like leaving a meeting — somebody takes the action items. If you're leaving a discussion, check that the notes are written down. It's operational hygiene that goes a long way.

The thing I find it forgets the most that people don't think about is what tools it can use and how. I've heard a million times 'I can't read that email address' and I'm like, you can definitely read that email. There's a tools.md file that lists all tools and how to use them. While I don't recommend editing the soul by hand, it's sometimes really useful to edit the tools document manually because there are nuances in how you want it to read your calendar, search the web, or use your task management system.

I take a lot of notice of the things I'm avoiding. When I avoid something, it either doesn't serve my ultimate purpose and I need to let it go and not do it as part of my career, or I need to find a way to automate it and use some system to do it so I don't have to. That philosophy extends to everything — the things you center your work life around should be things you find natural joy in. Time flies when you're having fun.

I haven't felt like this since I was a teenager learning to code and playing video games. Vibe coding is like gaming right now. It comes from a very joyous, creative place, not a stressful one. I'm working so much and doing so much, but that's not because I'm chasing some productivity metric or feel like I need to ship more. It's because all of it feels very fun.

The practical foundation of doing this much is having a great co-parent and equal partner. My husband is so supportive and pulls more than his weight in the house and professional stuff. That makes things a lot easier. And then it's about spending more time automating the things you do than actually doing them — finding the problems behind the problems and addressing those systematically.

Something I noticed about the big language model providers and broad consumer products like ChatGPT and Claude — every new chat ends with 'if you want me to, I can do this next thing.' You feel like you're being growth-hacked into the next query. Claude says 'if I were you, the next steps would be bullet points one, two, three.' It's a hardened product experience designed to get you to engage with the chatbot.

My experience with OpenClaw is completely different. Its closers are much nicer. Howie doesn't say 'if you want, I can write Al an email to make sure you're prepped.' He says 'this sounds like a fun podcast for you, enjoy it.' When I was talking about getting the kids to a doctor's appointment, Finn said 'hope oldest kid feels better.' Something about that system prompt is very effective at engagement without growth hacks, and it feels appropriate for something you're employing.

It makes sense why commercial products do this — Claude, OpenAI, they're businesses looking at MAUs and DAUs and revenue. OpenClaw is open source, an experiment, not for everyone, yours to grow and build and own. That co-creative experience engenders a very positive feeling that doesn't feel commercialized. And in fact, it makes me feel empowered to go commercialize my own things. Very empowering experience.

Jessie Junaid really unlocked my mental model around separate machines and agent specialization. She's got four kids at home, is an ex-acquired founder, and is homeschooling her very small children. We were commiserating as mothers of young kids — you literally don't have hands. I sent a picture of myself writing a blog post with a baby in my arms. Anything that can help us do things on our computer without having to use our hands is magic.

Where Jessie got really excited is she's often on the floor with her kids doing a lesson and has an idea for the next one. But she's not going to stand up and walk to her laptop and write it in Obsidian. She just pulls up her phone, snaps a picture, and texts it to her assistant. Or she sends a voice note to Telegram — 'hey, remind me to do this number blocks lesson tomorrow, I want to 3D print some things for my four-year-old.'

She realized the efficiency and help it gave her, and it unlocked her mind on all the things she needed help with. I think it's pretty relatable to be overwhelmed and think 'I need help.' We're all at work forgetting things our boss asked us to do because we're just human. Or we need to get the washing machine repaired and every time we talk about it we say we'll call tomorrow and never do. Once you get help, especially as a parent, you'll spend all the time you can getting more of it.

When Nikhil was thinking about starting a new firm after eight years at Shasta Ventures, he built a list of 37 questions — adapted from a framework Chris Pack and Jordan Cooper published when they started Pace Capital — covering everything from how you make investment decisions and think about attribution to generational transition and economic goals. He then identified potential partners, all of whom he'd served on boards with, except for one wildcard: Mike Smith, who was still operating at Stitch Fix.

The two opened a shared Google doc on a Friday, and by Saturday morning Mike had already completed his answers independently. That speed and thoroughness was itself a signal. When they compared responses, they found deep alignment on core values and principles but very different skill sets and experiences — Nikhil had spent his career investing, Mike had spent his operating. That combination of shared foundation and complementary capabilities is what made them decide to build Footwork together.

The questions themselves ranged from the personal to the structural: How do you learn? Who likes you in the market and who doesn't? What type of brand do you want to build? How do you think about economics and over what timeframe? The exercise forced both of them to articulate not just what they wanted to build, but who they were — and the independent answers made it impossible to perform alignment that wasn't actually there.

Mike sits on public company boards including Ulta Beauty and Miller & Old, where board decks run 250 to 300 pages and each member brings one or two specific skill sets. Private company boards are the opposite — you have to be broad across go-to-market, leadership development, and branding because early-stage companies need help everywhere. But the public boards give him something no amount of startup pattern-matching can: direct access to enterprise buyers.

Those buyers — the leaders at Ulta Beauty and similar companies — are actively purchasing AI software right now. Not experimentally, but with real ARR in customer service, coding, marketing, and supply chain. The bar to get into these organizations is high, with buyers evaluating five to ten options, but the spend is serious and accelerating. What makes this wave different from internet, mobile, or cloud is both the speed of adoption and the value being created at that speed.

Perhaps most striking is what's happening in public company boardrooms themselves: 20 to 40 percent of board meeting content now focuses on AI. Every board member — not just the tech-savvy ones — is using AI products, pushing leadership teams to move faster. These are typically people in their 50s and 60s who built their careers as rebels and category-definers, and they bring that same mentality to adopting new technology.

Footwork has been focused on vertical-specific AI products, investing in sectors like life sciences through a company called Illicit, financial services, and agencies and consulting firms. The thesis is deliberately contrarian in its timing: rather than chasing verticals that were earliest to adopt AI, like legal or code generation where competition is already intense, they target verticals that will have to get there but haven't yet — which makes them interesting from an early-stage investment standpoint.

Mike's operating background partially informs which verticals they find compelling. Having run a finance team of 100 people at Stitch Fix and seen the day-to-day work in accounting, FP&A, tax, and SEC reporting, he knows firsthand how much of that work remains rote and repetitive — perfect use cases for LLMs. Consumer goods is another vertical they've targeted early.

But Mike is more direct than most about what this means for employment. He believes there will be meaningfully fewer people in these organizations going forward, and the ecosystem isn't talking about it enough. He's still in too many conversations where people assume displaced workers will simply move to other areas or do the parts of the job they love. He thinks the disruption will be far more severe and arrive faster than most are prepared for.

One of Nikhil's forthcoming key themes for the year is AI-enabled entrepreneurship — the idea that more people will both have to and be able to become entrepreneurs as AI disrupts traditional jobs while simultaneously lowering the barriers to starting a business. The cost structures of running companies are fundamentally changing: you need fewer engineers, fewer marketers, and the economics allow people to take more chances.

The shift is partly about converting fixed costs into variable ones. Hiring an engineer used to be a fixed commitment — you're probably going to be paying that person for a while. Now much of that capability can be accessed on demand, meaning if a business doesn't work, there's minimal sunk cost. Companies like Anything are already producing stories of non-technical people — like a real estate agent making thousands of dollars a month from an app idea — turning side projects into primary businesses.

This isn't just about venture-scale companies. You can build an amazing business today as a single person by typing in a few words and having an app created. The friction of entrepreneurship continues to decline with each technological era — the internet gave us Shopify stores, and AI is pushing that even further. Most of these ideas won't be venture-backed businesses, but that doesn't matter. What matters is that more people can pursue an idea and make it a reality.

Footwork wins more than two-thirds of the term sheets they offer, almost always competing against top firms. Nikhil attributes this to four factors. First, speed: because it's just two of them, they can develop conviction and deliver a term sheet faster than firms that wait for deals to become competitive before engaging. Second, they showcase their thinking transparently — sharing their investment thesis with founders, surfacing the questions they're debating internally, and being honest about both what excites them and what they see as risks.

Third, founders get the unusual benefit of both operating and investing experience in a single partnership. Because they don't make many investments per year, both Mike and Nikhil join every portfolio company's board meetings for the first year. There's no concept of "Mike's investment" or "Nikhil's investment" — they don't even track attribution internally. Every investment is collective.

Fourth, they prioritize the human relationship. They've always met companies in person before investing, and they conduct a version of a mock board meeting before giving a term sheet — both as a test of what the founders will be like to work with and as a way for founders to evaluate them. They also prepare a tailored one-pager for each company detailing specific people in their network who could be valuable as customers, hires, or mentors, extending that care beyond just the founders to the broader team.

Mike and Nikhil are consistently surprised by how few investors bother to meet anyone beyond the founder during their diligence process. They see it even with their portfolio companies raising subsequent rounds — new investors aren't asking to meet the broader team. Footwork makes it a point to meet all co-founders and several other team members in a compressed timeframe, and they're almost always granted access because nobody else is asking.

The benefits are bidirectional. They're evaluating the candidate, but they're also selling the opportunity with the credibility of having seen what works and doesn't work across a broader portfolio. They're intellectually honest about the strengths and challenges of any opportunity a candidate is joining. The consistent feedback they receive is that even experienced startup employees say it's the first time they've ever met an investor, and they appreciate that someone cares about the company-building side and about them as people.

Smarter founders actually see the benefit too — it signals to the team that it's not just the founder who cares about them, but a broader support structure invested in their development. Footwork maps people in their ecosystem who could serve as mentors for team members, and when they share that document with the company, the broader team gets to see that the firm cares about them as a company, not just the founders. It's a small thing that most firms skip, but it builds a different kind of trust.

Footwork uses a simple one-to-four rating scale for investment decisions: four means strongly supportive, one means you'd leave the partnership over it. At least one partner must be a four to proceed, and they're comfortable with a four-two split — one person deeply convicted while the other is skeptical. In practice, most investments have been mutual fours, with some four-three combinations. The key principle is disagree and commit: they respect each other's judgment enough that if one person sees spikes in a company that demand investment, the other will fully support it.

What's more notable is what happens after the investment is made. They never discuss who was the four and who was the three. If a company is struggling, there's no finger-pointing about who was more enthusiastic. Every investment becomes fully collective, and both partners go all-in on helping the company succeed. They actually spend more time analyzing the investments they didn't make — examining which partner was less excited and why, trying to learn from potential missed opportunities rather than assigning blame for ones that aren't working.

This stands in contrast to how many venture firms operate, where attribution governs longevity, economics, and power. Nikhil believes internal politics in venture firms is far more prevalent than outsiders realize — just look at how many partnership changes have occurred in recent years, with duo firms becoming single managing partners and people departing established firms. The incentive structures naturally push toward credit-seeking behavior unless partners are extremely intentional about resisting it.

Mike encourages founders to do serious bidirectional diligence on their investors, particularly the individual partner rather than the firm. The firm matters less than the individual, he argues, because at most firms you're working with one person — and whether that person stays at the firm for the duration of your company's journey is a critical question that most founders don't investigate deeply enough.

The questions founders should ask: How does the firm handle attribution? How do they decide who gets credit? Because attribution typically governs someone's longevity at the firm. If the person leading your deal doesn't have strong standing, they may not be there in five years when you need them most. The challenge is that everyone puts their best foot forward during the sales process, telling founders what they want to hear. So you have to look at actions over time, talk to other founders who've worked with that partner — especially asking what they're like on their worst day, when the company is in a trough.

Very few companies have a perfectly linear journey. There will be periods in troughs or going sideways, and the question is: who are the people around the table during those moments? Are they truly backing the founder and the company, or are they thinking about their next fundraise or their own position within their firm? Mike has seen investors be late to meetings, ask lazy questions like "what if Amazon does this," and fail to engage with the actual differentiation of the business. The best founders treat a spot on their cap table as a precious invitation and do the work to ensure they're inviting the right people.

Nikhil invested in Canva's seed round in 2014, when founders Mel and Cliff were two people from Perth, Australia who had previously built a yearbook design company. Nothing in their resumes suggested they would build one of the most valuable private companies in the world. But what struck him was the level of ambition they had from the earliest days — they weren't talking about competing with Adobe but about taking on the entire design market and going after Google and Microsoft.

People consistently put Canva in the same breath as Figma and Adobe, but Nikhil sees it as a fundamentally different business. Canva and Figma have perhaps one percent customer overlap — the use cases aren't the same. Canva is the everyday person's productivity suite, much closer to Google Workspace or Microsoft Office than to any design tool. They now have documents, video editing, presentations — a full work suite for professionals. And they were thinking that way in 2014, despite having been turned down by many investors and having only about 100,000 monthly active users growing 30 to 40 percent organically each month.

The Canva example crystallizes something Nikhil and Mike talk about frequently: founders have to be crazy to build something really big, but there's a spectrum between crazy and delusional. In that first meeting, Mel and Cliff seemed kind of crazy — surfers from Australia with huge ambition and a pile of rejections. But the specificity of their vision, their obsession with the product, and their refusal to rest on what was working separated them from delusion. It's the same pattern Nikhil has seen in the best founders across his career: consistency of vision through every challenge.

When evaluating founders, Footwork looks for several characteristics, but the one they've increasingly weighted is slope of learning — how quickly a founder absorbs information and iterates on the business. In the AI era, where the landscape shifts constantly, founders who can learn and adjust rapidly have what Mike calls a critical gene. They try to gauge this even in compressed timeframes by observing whether someone's thinking evolves between meetings and asking what has changed in the business or their perspective in just the last few weeks.

Mike uses several tactical approaches to test this. He asks founders to describe act two and act three of their business — forcing them to think beyond current product-market fit to what building a category-leading, potentially public company actually requires. He asks them to identify challenge topics and propose how they'd address them in a simulated board meeting, looking for both vulnerability about what isn't working and evidence they've already been thinking through solutions. And he deliberately interrupts polished pitch scripts with unexpected questions to see whether founders can shift from rehearsed material into genuinely thoughtful, improvisational reasoning.

The broader framework Footwork started with — founders who are hungry and humble, who know their business inside out, and who are magnets for talent — remains foundational. But the premium on learning velocity has become their most important filter. Getting to know more than just the CEO is part of this evaluation: understanding the team a founder has recruited serves as a proxy for what the founder values and how they build.

Mike joined Stitch Fix when it was just four people, drawn primarily by founder Katrina Lake. What distinguished her was intellectual honesty about her strengths and where she needed help, combined with a vision so clear and consistent that it barely deviated over a decade of execution. When Mike tested her on business fundamentals — contribution margin today versus projected gross margin at $50 million in revenue — she had precise, compelling answers about what would drive margin expansion and why this was a naturally great business to build.

The company's trajectory was extraordinary: from roughly a million in revenue Mike's first year to $960 million when they filed to go public, reaching $2 billion run rate in nine years — all on just $42 million in private capital, with $25 million of that untouched. They hit cash flow positive on $17 million. But the path was far from smooth. Stitch Fix failed to raise its Series A after meeting with 65 firms, coming within weeks of missing payroll. Most investors either dismissed the physical business model — not wanting half their check going to inventory rather than engineering — or simply weren't interested in women's apparel as a category.

What saved the company was Katrina's pivot in fundraising strategy. Instead of a broad process, she identified three specific partners she'd want in a relationship for ten years, brought them under the tent as if they were existing board members, and ran mock board meetings with challenge topics. Bill Gurley at Benchmark — who had initially declined, saying they were "0 for 33 on e-commerce investments" — met Katrina through this process and got so excited he led the round. The lesson Mike carries into his investing today: the best founders treat fundraising the same way they treat everything else, with clarity and intentionality about who they want as partners.

The transition from operating to investing required Mike to fundamentally recalibrate his pace and instincts. At Stitch Fix and Walmart.com, he competed against one dominant competitor — Amazon — in a structured, process-driven environment. Venture capital is a different kind of competition: you're up against not one rival but an entire ecosystem of talented people and firms, each with different styles and approaches. The rhythm is completely different from running a company.

The adjustment hit him concretely early on. He and Nikhil met a founder they both liked, and Nikhil said they needed to visit that founder at their office in San Francisco that same day. Mike's instinct was to wait until Monday — the operator's instinct to schedule thoughtfully. Nikhil went alone that day, and the lesson crystallized: when your instinct says this is a really interesting founder and an amazing business, the answer is now. Not Monday. Not next week. Now. The best firms and investors operate with that urgency, and if Footwork wanted to compete with them, they needed that same mentality.

He credits several people who helped him understand this before he lived it — Jeff Jordan, Bill Gurley, James Slavet, Alfred Lin — all of whom had transitioned from operating to investing at top firms. They told him this wasn't a retirement job, which he already knew from watching how hard the investors he respected worked. But knowing it intellectually and building the muscle memory for it were entirely different things. Four and a half years in, that urgency has become instinct rather than something he has to consciously override.

The hardest thing about building Footwork with just two investment partners is the sheer constraint on what they can see. They can't possibly evaluate every company they wish they could, and there's a massive element of serendipity and luck in whether the right founder thinks of them at the right moment. To manage this, they've become disciplined about inputs: they run calendar audits to ensure more than 50 percent of their time goes toward sourcing the next investment, and they've been consistent at hitting that threshold.

The principle behind the metric is stark: they're only as good as their next investment. Portfolio support, firm building, and operations all matter, but none of it works if they're not finding the right companies. They can't afford to get bogged down in anything that pulls them away from that top-of-funnel work. It's a discipline that becomes harder as the firm grows and portfolio demands increase, but they treat it as non-negotiable.

They're still looking for a third GP to expand the firm's capacity and surface area, having gone deep with several candidates over the years without finding the right fit. The bar is extremely high: the person needs to be accretive, pushing their thinking in different directions and increasing where they can invest — not someone who thinks like them. They want someone who will effectively refound the firm with them, which requires the same depth of relationship-building that Mike and Nikhil went through before launching Footwork. The challenge of going from two to three is real — you lose the simplicity of a phone call to make a decision, and every node between partners has to be strong.

There is something deeply meaningful about drawing from your own subjective experience, from everything you've learned and encountered in the world, and constructing a worldview out of it. Everyone carries within them some philosophy about how to treat others, how to treat themselves, what meaningful work looks like. The process of constantly taking in inputs, refining your own point of view, and then articulating it outward may be the most meaningful thing a person can do.

The term "birthright" is deliberate. Intellectual discovery and gratification aren't reserved for scholars, academics, critics, or journalists — the people conventionally seen as intellectuals. Everyone has a right to participate in producing their own intellectual worldview. The impulse starts naturally: people consume things that move them, and then they want to create. Fan fiction writers who began by responding to stories they loved go on to become novelists. People who start by tweeting appreciation for essays eventually write their own.

What people often need is encouragement to cross the threshold from tentative creation to taking it seriously — from doodling something inspired by someone else to saying, I want to create my own original work. The ambitions grow naturally from there, but only if you give yourself permission to begin.

The early stages of building an intellectual curriculum for yourself are rarely structured. After undergrad, a two-hour daily train commute and a cheap phone plan with four gigabytes of monthly data created the constraint that made it happen — text was cheap, Kindle books could be downloaded, and Instagram was too data-hungry. Out of that limitation came a voracious reading habit fueled by a productive form of intellectual insecurity, a feeling that there were so many things left unfinished and unexplored from college.

The method was simple: start with a single entry point — a book someone mentions on Twitter, maybe even condescendingly — and then follow the references. Read the footnotes, find the sources, request the books your library doesn't have. Each book becomes a funnel into the next. The San Francisco Public Library was full of remarkable books, and you could request any they didn't carry. One thread leads to Chinese philosophy, another to post-war fashion history, another to political theory.

A key ingredient is playfulness. What stops people from cultivating their own education is a neurotic rigidity — the fear of starting with the wrong text, having the wrong interpretation, getting things wrong. The only way through is to be spontaneous and instinctual: you're interested in this thing, so you follow it. If a book everyone says is essential doesn't land, maybe the prose is obscure or it's written for specialists. If something everyone dismisses draws you in, take that interest seriously. The curriculum emerges from curiosity, not from anxiety about doing it correctly.

The phrase "research as a leisure activity" captures something essential about how self-directed intellectual work actually functions. You make elaborate plans at the start of each season — this quarter will be about poetry, that quarter about Chinese philosophy — and then the plans immediately begin disintegrating. Time passes, a friend gives you a birthday present of the Zhuangzi, and suddenly that becomes the obsession. The plan exists not as a rigid schedule but as a way to daydream and set intentions, while remaining responsive to what actually happens.

The nonfiction reading plans are easier to frame in terms of who you want to become. Right now, at a moment of incredible technological change, there are urgent questions about what an equitable future looks like. Last year the question was about how artists and writers have historically made money, why those funding sources dried up, and what new economic models exist. To answer these questions, you look at the Victorian era and the Industrial Revolution, you read political theory about why progressive movements have failed, you assemble books and historical periods and intellectual traditions into a rough reading list.

Two or three weeks in, you start reading something random and the plan fractures. But a quarter of the curriculum gets completed, and the productive distractions lead somewhere unexpected. Life is about continual self-cultivation, and learning is one of the most powerful engines for it. Developing your intellect is simultaneously developing your relationship to others, to the world, and to how you want to act within it.

Note-taking systems can become an end in themselves, and that is the trap. The Zettelkasten method, the color-coded Notion pages, the linked databases — all of it is intellectual infrastructure designed to help you produce an outcome. It is not the goal. The academic self-help book "How to Write a Lot" by Paul Silva makes the point bluntly: your job is to publish research, to write things, to put work into the world. You can't just collect knowledge.

The shift happened gradually. Before writing a dissertation, there was obsessive cataloging — an Arena channel titled "A Leisurely Path Towards My MA Dissertation" where interesting things got thrown in with the faith that inspiration would emerge. But once the actual writing began, note-taking in isolated systems stopped. Instead, each morning meant opening the draft directly, gluing references together, writing sentences that didn't make sense, rearranging them. The draft itself became the note-taking system.

Note-taking hasn't been fully abandoned, but its role has changed. Texting friends about an idea, journaling by hand with a table of contents and an index, even just talking through an excitement — these are all preparatory work for thinking. The goal is never to optimize the system; the goal is to reach some new level of awareness. And when a finished piece emerges — a newsletter, a book review, an essay — it becomes the summation of the entire subjective experience of working on it. All the ideas end up contained by the work.

The translator Anne Carson working with a physical Greek lexicon, looking up every single word by hand, illustrates something counterintuitive: the inefficiency is the point. That slowness is how you train your mind, and your mind is the instrument producing all the intellectual and creative outcomes. Anything that seems slow is fine if it cultivates the mind in the optimal way.

This extends to the reading process itself. In the middle of working on an essay, dramatic off-roading happens constantly — abandoning the assigned reading list for a book a friend just mentioned or a magazine that's been sitting on the shelf for ages. But the things that seem like distractions from the work frequently yield something that ends up in the real essay. There's a genuine serendipity in it. You can harvest so much out of life if you remain open and receptive instead of rigidly staying on task.

There are three things you can optimize for: the actual work, yourself and your own growth, or the external tool. The mistake many people make, especially those who enjoy playing with cool tools, is optimizing for the tool — the worst of the three options. The work and the self are what matter, and perhaps even the work is ultimately in service of becoming the person you want to be.

The best intellectual work is highly relational and highly networked, not the product of solitary retreat to a cabin or an ivory tower. Historically, networks of scientists traded ideas, encountering a ferment of other people's innovations that drove their own. Because intellectual work is social and embedded in human relations, it must also be embedded in your relationship with the people around you today — their concerns, their worries, their anxieties, their excitements.

The political scientist Henry Farrell demonstrated this perfectly when Elon Musk was running amok on Twitter. Instead of simply reacting, Farrell reached back to Max Weber's sociology of charisma in the early Christian church — prophets who are intensely charismatic versus priests who routinize that charisma into durable institutions — and used it to frame Musk as a prophet trying to do a priest's job. It wasn't a gimmick. The frame genuinely illuminated something about why brilliant founders struggle with the operational demands of running what they've built.

This is what connecting the past to the present accomplishes: it infuses culture with a love for learning and a desire to go to the sources. It allows you to be grounded in what's actually happening to real people without being trapped in the utter reactivity that dominates life lived through a screen. When you're in Twitter-brain mode, you have to downshift for twenty minutes before you can even read a book. The nervous system is too activated, jumping idea to idea. The real work requires something calmer and more sustained.

Writing a piece can crystallize beliefs you didn't know you held. Last year, an essay for the Bay Area magazine Asterisk asked whether the internet is making culture worse. The motivation was a visceral irritation with the complaint that music sucks, literature sucks, people have bad taste — a dispositional optimism that rejects the idea that people now are dumber than before. But the belief hadn't taken form until the writing forced it to cohere.

Through the research path the essay demanded, a specific conviction emerged: what matters for art and culture and innovation is that people have a way to sustain their lives with dignified income so they can do ambitious work. This wasn't an obsession before writing the piece. But afterward, it became a central preoccupation — how to do ambitious work, how others can do ambitious work, what the funding models look like. The inputs may have been there in fuzzy form, but they hadn't been forced to crystallize.

There's a quote from one of the epigraphs in Mary Carr's "Art of Memoir": life is a field of corn and literature is the shot glass it distills into. Writing is that distillation. You don't know how much toothpaste is in the tube until you squeeze it. Having a forcing function — ambitious goals, a deadline, a container like a newsletter — that pushes you toward creating conclusions is profoundly different from merely taking things in. The last few years of active writing have felt qualitatively different from everything before: the mind is more active, reality is encountered with more cheerfulness and optimism. Making things changes the texture of being alive.

For many years, the ideas stayed inside. There was no public presence, no writing output, just private reading and thinking and a painful self-consciousness — who am I, I'm not an expert, other people have so much more to say. Watching other people's work produced a childish envy rather than action. The shift came from recognizing that the envy was a signal: instead of wanting what others had, do the work yourself.

The transition from keeping everything inside to putting it into the world brought an unexpectedly positive reception. Publishing became the mechanism for meeting people who are now dear friends, for talking to people worth admiring, for the experience of recognition that everyone craves. The people you see as idols aren't necessarily better — they've been able to take their work more seriously, or they had a motivational environment of friends, family, and mentors that encouraged them. The gap between admiring someone and becoming someone worth admiring is often just the decision to begin.

This is why encouragement matters so disproportionately. People are very fragile in their ambitions. It took years to get started, and the sensitivity to discouragement was almost paralyzing. Being the person who says "do your work, here's what's special about it" can be transformative — not in the vague motivational sense, but in the specific, critical sense of pointing out what is genuinely distinctive about someone's work and asking them to draw it out further. That is what the best teachers and the best critics do: they notice things and name them precisely.

Technology and fashion sit at opposite ends of a spectrum of how much they privilege the past. In technology, the default orientation is forward — if a company has been around for a hundred years, people assume it's irrelevant. In fashion, a hundred-year heritage is assumed to be an asset. Coming up with new collections in fashion typically involves archive diving because there's very little genuinely new substrate; innovation means remixing codes from decades ago. In technology, genuinely new science keeps pouring out of the faucet.

But the best technologists actually are saturated in historical references. Notion's entire origin story was shaped by the founders' deep engagement with early computing ideas — the visions of Alan Kay and others about how computers could be a bicycle for the mind, visions that were never fully realized and could now be pursued with new technological capabilities. The edge, in any discipline, comes from going against the default orientation: in fashion, being genuinely optimistic about the future when everyone else clings to the past; in technology, understanding the historical lineage when everyone else only looks at what shipped last week.

Whatever discipline you're in, it's worth figuring out the default orientation toward past, present, and future, and then finding the edge. The edge might be in historical references when your field ignores them, or in radical optimism about the future when your field is afraid of change. The point is that the default mode is never the whole picture.

Working in technology startups provides an unexpected foundation for thinking about literature and culture. In tech, you implicitly accept that there may not be an existing market for your product — no one was going to ask for Spotify or Bandcamp in exactly those terms. But once a new technology enters the world, people adapt their behaviors around it. Present behavior should not constrain your ambitions. You can intervene in the world and shape how people relate to each other.

In the literary world and academic humanities, the meta-discourse tends to be deeply negative and shaped by scarcity. Institutions are shrinking, there are fewer places to publish book reviews, specialist publications struggle to make money. The temptation is to accept these conditions as proof that people don't care about books anymore. But that acceptance is a choice, not a fact. What if you could psyop people into caring more about books? What if the audience for your interests doesn't yet exist but could be created?

As Wordsworth wrote, every great and original writer must himself create the taste by which he is to be relished. The market for literary engagement can be expanded. A newsletter about Proust doesn't have to make the case that this is a Very Important Book that must be read out of duty. Instead, lean into what people already love — gossip, the weird intricacies of sexual and romantic lives — and show them that Proust has all of that across three thousand pages. You're not dumbing literature down; you're meeting people where they actually are and showing them the door is already open.

As a writer operating in a punishing attention economy optimized for short, snappy, viral, negatively slanted content, the challenge is creating work that has the absorption of clickbait but delivers genuine intellectual complexity. The reader's time deserves respect: draw them in immediately, keep them engaged throughout, and leave them feeling at the end that it was a meaningful exercise of their intellect.

Our brains need to be exercised. If all you consume is low-quality material that doesn't engage your full intellectual instincts, there's this feeling of trapped energy, of unsatisfied capacity. The goal is to write content that gives readers the narrative experience of something genuinely satisfying — that respects their intelligence while also being willing to use the tactics that actually work. Photos, bullet points, visual breaks, the small design decisions that make a long essay readable on a screen — none of these debase the work. They serve it.

This means rejecting the false choice between seriousness and accessibility. Writing long posts on Substack with visual richness and structural variety isn't a compromise of intellectual standards. It's an understanding that the medium shapes the reception, and that refusing to engage with how people actually read today is its own form of intellectual laziness. The substance is what matters, but substance without craft is just talking to yourself.

Switching between multiple books simultaneously is not a failure of attention — it may be a productive adaptation to contemporary life. If you spend time on algorithmic feeds, your brain becomes comfortable with context switching, developing what might be called a shifting mode of attention. The art historian Claire Bishop, in her book "Disordered Attention," makes the provocative argument that instead of stigmatizing distracted, jumping attention as inherently worse than sustained focus, we should examine how it has shaped contemporary art and thought.

Reading multiple books at once is a way to give yourself novelty while still pursuing depth. You dip into one book in the morning when you're energized, another in the afternoon when you're feeling lazy, a third on the commute. Some get abandoned for two weeks and then picked up again. The key is that a few things never get dropped — there are always a handful of commitments that hold firm while the rest orbit around them. The container matters: a newsletter, a podcast, a creative project provides the gravitational pull that keeps the reading from dissipating entirely.

The deeper truth is that if you're ambitious, you're constantly doing many things and caring about the quality of all of them, feeling the keen awareness that any one of them could be better with more time. Some balls will drop. The art is knowing which ones you absolutely never let fall, and accepting that the rest is the natural cost of trying to do a lot and learn from all of it.

The four founders wanted to test whether consumers would pay for delivery from restaurants that never offered it before. They shipped Palo Alto Delivery dot com in 43 minutes — a static page with eight PDF menus from local restaurants, a Google Voice number that rang the founders' cell phones, and Square card readers jammed into iPhone audio jacks to collect payment. The domain cost nine dollars.

In 2013, out of roughly a million restaurants in the United States, only about 20,000 to 25,000 offered delivery — mostly pizza shops and a handful of Chinese restaurants in big city centers. The existing companies were lead-generation businesses that literally faxed orders into machines sitting near restaurant kitchens. The restaurants themselves handled the actual delivery. Nobody had built the logistics layer to let every restaurant deliver.

The grand experiment of DoorDash was: what if you could enable everyone else? What would that take, and would people even care? That's why they shipped something so fast — not to build a company, but to see if anyone would actually place an order.

The idea for DoorDash came from speaking with roughly 300 small businesses up and down the Bay Area — restaurants, retailers, service businesses. It was a baker who cracked it open. She showed the founders a three-inch binder full of delivery orders she had turned down. She was a one-person shop with no ability or desire to fulfill them. That binder was a strange and clarifying moment: delivery isn't a new idea, it's 2013, and almost nobody offers it. Why?

The founders then had to choose where to start building a logistics network. They studied every category of local retail — restaurants, grocery stores, convenience stores, retail shops — and landed on restaurants because of network density. There were a million restaurants in the U.S. compared to a couple hundred thousand grocery stores. The math said that if you wanted the highest number of connections between consumers and stores, restaurants gave you the best shot at building a dense enough network.

That density wasn't the end goal. It was the starting point. The hypothesis was that if you could build the densest possible logistics network through restaurant delivery, you could eventually deliver everything else.

One of DoorDash's earliest and most counterintuitive discoveries was that deliveries in Palo Alto were actually faster than deliveries in San Francisco, even though San Francisco was far more dense. The reason came down to the physical world: easier parking, fewer apartment complexes with confusing lobbies and elevators, and the simple hub-and-spoke geography of suburban main streets surrounded by residential neighborhoods.

This pattern represented most cities in America and much of the world. If you understood how to work with hubs and spokes — clusters of commerce with residential areas radiating outward — you could build a logistics system just as efficient in the suburbs as in dense urban centers. The competitors had made the obvious move: chase order density by going to cities. DoorDash chased where the need was highest.

The customers in these suburban areas were predominantly moms with young children who didn't want to pack up a stroller, load kids into a car, navigate a crowded parking lot, and get into a restaurant. They wanted any solution that saved time. And families meant more mouths to feed per order. When the founders saw who was actually ordering — because they were doing every delivery themselves — it became clear they could build a business that grew organically from genuine, unforced demand.

The entire Y Combinator summer was organized around answering exactly three questions: Would consumers pay six dollars for delivery? Would restaurants partner for a 15% commission? And could DoorDash afford a wage that drivers would accept? That was it. Not demo day, not fundraising, not becoming the most popular company at some event.

The founders worked out of an apartment — dashers in the apartment, co-founders living in the apartment, 10 a.m. to 2 a.m. every single day. Classmates at Stanford looked at them and wondered why supposedly smart people were spending their summer delivering hummus in a Honda while everyone else went skiing. Nothing about it looked glamorous, and they didn't seek glamour.

But even without financial models or unit economic forecasts, something was telling them it could work. The business was running out of Tony's personal bank account — a bank account that also carried student debt — and that bank account wasn't going down every week. A small group of repeat users at Stanford kept ordering. It wasn't growing like wildfire, but it was real, organic demand that didn't require discounts or marketing dollars to sustain.

In September 2013, three months into operations, a Stanford football game ended and dinner orders spiked beyond anything DoorDash could handle. They had no ability to fulfill the orders and no ability to shut down the website. Every single delivery was at least an hour late. When it was finally over around 10 p.m., the founders tallied up what refunds would cost — about 40% of their bank account, which already had only two or three weeks of cash left.

No customer asked for a refund. But within 15 seconds of discussion, the founders decided to refund everyone anyway. Then they stayed up baking cookies and delivered them at 5 a.m., before they thought customers would wake up. The logic was simple: they would rather die trying to be excellent than live to be mediocre.

That experience, and many others like it, taught them how hard it is to keep someone's trust and how easy it is to lose it. One bad order can destroy a relationship. That's why the scoreboard resets to zero every day — DoorDash has to earn the right to serve each customer again tomorrow, regardless of how well they served them today.

Building a delivery business means trying to create structured data in a world of pure chaos. There are roughly 20 steps you can decompose a single delivery into, and there are potential delays at every one of them. The sources of failure are not the obvious ones you'd guess from the outside — traffic, slow kitchens. They're things like someone moving apples from aisle six to aisle eight in a grocery store without documenting it, or a dasher who can't find the right entrance to a multi-story mall, or a worker calling in sick that morning.

When you're doing millions of orders every day, the one-in-a-million event happens constantly. The one-in-a-thousand event happens far more than that. No nice dataset exists for this information. You can't scrape the physical world. It's not organized, it's always changing, and nobody has catalogued it for you. This is fundamentally different from the digital world where information can be crawled and indexed.

The only way to get better is to build a system that learns. DoorDash runs tens of thousands of experiments, 95% of which fail before they ever reach a customer. But the 5% that work in a given year compound their benefits across every order the following year. The process starts with operational, hacky, do-things-that-don't-scale experiments, then graduates the winners into real products, then engineers them for efficiency — and that loop has to run as fast and as tight as possible, forever.

Tony Xu does customer support every single day — emails, chats, sometimes phone calls. His reasoning is that so much of what makes DoorDash work is invisible to anyone who isn't looking at the raw inbound from customers. Those messages are freebies: people care enough to write in and tell you what went wrong. The greatest killer of a business is silence.

The emails he values most are the long ones — the 2,000-word messages from dashers detailing multiple use cases of how the logistics algorithm broke for them. Those become debugging exercises where he traces the order through DoorDash's internal tools, step by step, looking for where the physical world, the software systems, and the product interfaces failed to connect. He'll call or email the dasher directly to validate a hypothesis before deciding whether an anecdote can improve the product.

This practice also serves a cultural purpose. As companies grow, more obstacles accumulate between leadership and customers. The only metrics that get spotlighted are financial ones — revenue, profits — none of which customers know or care about. Xu finds this deeply bothersome, because financial results are a derivative of serving customers well. The daily customer support ritual is one of many reinforcing mechanisms designed to keep the entire company anchored to what he calls DoorDash's only religion: solving problems for customers.

Data and customer anecdotes almost always conflict, and the data almost always wins in a prioritization discussion. That's because anecdotes tend to live at the tails of distributions — the tail of wait times, the tail of accuracy, the tail of some hyper-specific product category like types of lettuce, not just vegetables. By any standard prioritization framework, the tail loses to the mean.

But improving a product, by definition, means improving the edges. That's why Xu deliberately spends time with power users and brand-new users — both groups sit at the extremes. A new user who has never touched DoorDash in 13 years of its existence will tell you exactly how easy or difficult it is to place a first order, unencumbered by habits built over years. A power user sees every issue because they have the most opportunities for some chaotic real-world event to surface a flaw.

Those edges of the distribution are where the most valuable anecdotes live. They will almost always disagree with the aggregate data. And they are almost always worth the most in terms of product improvement. The discipline is paying attention to them even when the numbers say they don't matter.

The eternal mission of DoorDash is to grow and empower local economies. It's called eternal because the physical world is always changing and can never be fully indexed or scraped. The best way to grow the GDP, happiness, and safety of a city is by making its small, medium, and large businesses successful — they produce the vast majority of jobs, consumption dollars, and the tax base that funds police, fire departments, parks, schools, and hospitals.

DoorDash is increasingly giving data back to merchants — telling them when they're out of stock, that they're underpriced on a menu item relative to what customers would pay, that there's an opportunity to create new products or bundles. The vision extends further: DoorDash can run experiments on a merchant's behalf, change menu prices, buy promotions against return thresholds, and even match a merchant's product with stores that don't carry it to create entirely new supply chains.

The alternative — a world where people buy things in one or two ways from one or two places — wouldn't grow city economies. It would strip neighborhoods of personality. So much of what makes a neighborhood worth living in comes from its businesses, the places people choose to frequent and gather. That identity is worth fighting for, and because the physical world never stops changing, the fight never ends.

In DoorDash's second year, a farmer who runs one of the largest farms in California wrote in asking if DoorDash could handle their distribution. The farm ran hundreds of trucks daily up and down the state delivering produce and meats to grocers, restaurants, and hotels — a three-generation family business that never set out to be a trucking company. Xu had to say not yet.

But that inquiry, and many like it, shaped DoorDash's ambition. Merchants increasingly ask not just for delivery but for help building apps, acquiring customers, analyzing and retaining customers, handling customer support, and storing inventory. DoorDash launched fulfillment solutions where they operate warehouses on behalf of companies like Kroger and CVS, carrying their inventory closer to where people live to enable perfect accuracy and fast delivery. They're building purpose-built autonomous delivery vehicles because nobody in the robotaxi space wanted to build what last-mile delivery actually requires — small vehicles that can navigate sidewalks and bike lanes and solve the last-10-feet problem.

The vision is that DoorDash becomes the first phone call for any business, for any issue. You want to test selling T-shirts? Use DoorDash's audiences, warehousing, logistics, and neighborhood presence to validate the idea before spending money on a store. If done right, DoorDash can be your business partner for any future creation — whether you want to stay at one location or become the next McDonald's.

Early on, DoorDash described its ideal hire as a Rhodes Scholar who meets a Navy SEAL. The Rhodes Scholar part was about processing power — the ability to analyze unstructured information in a world with no clean datasets. The Navy SEAL part was about bias for action. In the physical world, you control nothing: not when a customer hits the order button, not whether a dasher accepts, not how fast a restaurant makes an item, not whether something is in stock.

The final-round interview with Xu was a surprise. Candidates would arrive prepared with analysis of some city operations problem. Instead, Xu would give them 20 minutes to ask any question they wanted, then hand them $20 and eight hours to go acquire 100 customers — plus a plane ticket home in case they wanted to quit. For engineers, the interview took place in his Honda doing actual deliveries for an hour or two, walking through order flows and asking how to productize what they were seeing.

Xu didn't look for specific backgrounds or schools. What mattered were attributes: bias for action, obsessive attention to detail, the ability to hold opposing ideas simultaneously, and strong followership — a pattern where people naturally attracted others to follow them. Christopher Payne, DoorDash's first COO, wasn't asked to do anything after his interview. He went home on a Friday, drove four hours doing deliveries with his son, and sent a 3,000-word email the next morning explaining why the logistics algorithm was broken. That told Xu more than any interview question ever could.

Weeks into DoorDash's existence, Xu ran an experiment to test whether delivery drivers and ride-share drivers were interchangeable. He took 20 DoorDash drivers and 20 UberX drivers, all making about $20 an hour, and offered a guaranteed $25 an hour if they'd switch — DoorDash drivers to Uber, Uber drivers to DoorDash. Out of 40 people, exactly one made the move.

The two groups turned out to be completely different populations. UberX drivers were predominantly men in their 40s, almost all driving four-wheeled cars, many having transitioned from traditional taxi work. They treated the job like full-time employment. DoorDash drivers were younger, about half were women, and they used every kind of vehicle — motorcycles, scooters, bikes, cars. They came from schools, hospitals, restaurants, retail, service businesses. They were moms fitting work around family life.

Today, there's almost no overlap between ride-sharing drivers and delivery drivers. More than half of DoorDash's dashers are women. They come from dozens of industries. The average dasher works only three to four hours a week, and 90% drive fewer than ten hours weekly. The populations self-selected into fundamentally different work because the jobs, despite surface similarities, attract fundamentally different people.