One Bad Quarter

I'm going to spend this post arguing you should start a company, so before I do that I want to be honest about what that actually means. I started one twelve years ago and there were long stretches of it that were hard in ways I didn't expect. There are days when being told what to do is easier than figuring out what to do next, and when something breaks there is nobody above you to escalate to. You are the last stop and you need to be comfortable with risk in a way that most careers never ask you to be, and you will make more mistakes than you think. I'm not sure I'm a better person for it, I'd leave that to the people who had to work with me, but I came out the other side knowing more clearly what I'm capable of, what I'm not good at, and what my limits are. I didn't know I had most of my red lines until I was already standing at them, which is probably the only way you ever really find out who you are.

I'm writing this because I think a lot of people are closer to starting something than they realise, and because the conditions for doing it right now are different from what they were a few years ago and from what they'll be a few years from now.

Paul called me this week. He lives on the ninth floor and runs a company that's been building a voice AI ordering system for a restaurant group with thirty stores opening Friday. The dev team had gone quiet in that particular way dev teams go quiet when they know they've shipped something that doesn't work, and he wanted to know where to find someone who could come in and fix it quickly and cheaply.

I told him the situation was like trying to fix a tunnel where the two sides didn't meet (his previous job was managing the new Silvertown Tunnel). On the surface the fix sounds straightforward, the misalignment is only one meter and most of the construction is already done, but the meter is load-bearing, the original team is gone, and whoever comes in now has to inherit every decision those people made without having been there when the decisions were made. Someone will fix the system eventually but the work won't be quick and it won't be cheap and most people I know wouldn't go near a project like that.

He said he's writing the client off and starting again, which is probably the right call and also the most expensive sentence in the conversation.

The people who built that product were probably doing everything right by the measures they were given. Tickets closed, sprints completed, standups attended. Nobody owned the outcome because the system the team was working inside was never built for anyone to own it, and when you optimise hard enough for process the accountability gets distributed so evenly across tools and hierarchy and ceremony that when something finally fails there's nobody left holding the bag, and the structure worked exactly as it was designed to work, which is the problem.

I fought that dynamic inside my own company for long enough to know the results are mixed. The instinct to let process absorb the risk is rational and process-led teams usually deliver, until they don't, and when they don't the failure looks like Paul's thirty stores: late, expensive, and with nobody left who remembers making the decisions that caused it. You can fight the dynamic from inside. You can own outcomes inside a structure someone else built. But you're always one bad quarter away from that structure making decisions you have no say in, and the quarter doesn't announce itself.

I've been having a lot of conversations over the last six months with friends who are thinking of starting something new. More people are actually moving in that direction than a year ago, but I think the ones who haven't started yet will eventually have no choice, and the difference between starting now and starting when that moment arrives is mostly the difference between doing it because you chose to and doing it because everything else ran out.

Andy lost his job last year and spent about three months looking, here in London where the market is harsh and the gap between roles feels longer than it used to. He found a new role that he was not the most happy with but he took it anyway. I kept encouraging him to start a company. Three months of uncertainty is a long time and the job was there. The visible risk always wins against the invisible one, and the invisible one doesn't disappear just because you stopped looking at it.

Oliver has done everything right. Good company, senior role, respected, the kind of engineer you want at the other end of a phone at 2am when something has gone wrong and nobody knows why. He's at the top of the ladder he was given and he's stopped enjoying it, which I think is what happens when you get there and realise the ladder was leaning against the wrong wall. What he actually lights up talking about is the work he does on the side, going into local schools, Year 5 and 6, teaching kids the basics of programming with micro:bits he bought himself. The kids are nine, ten years old and most of them can barely sit still long enough to read the instructions, and he loves the teaching. That side work exists completely outside the structure he works inside, and I think that's the point. We've talked a few times about whether he should start something of his own, and he's working toward it in the way people do when they're almost ready but not quite there yet.

Nina has been more deliberate about this than most people I know. Six years of runway saved, three ideas she's been stress-testing, and she's still working out which one to back, which is the right problem to be sitting with before you start rather than after.

I messaged Alistair last week about a small project, a few hours of work, skills he has. He said he was going for senior next year and his job was his main priority right now. He thinks his situation is personal. I think it's most of us.

The calculation he made is one I recognise, because most of us were trained to make it. Not by one thing, but by a long accumulation of sensible advice: don't rock the boat, secure the promotion first, wait until you're ready, don't risk what you have for something uncertain. It comes from home, from school, from watching people around you get hurt by taking chances that didn't pay off. By the time you're mid-career the risk aversion isn't a decision you're making, it's a posture you've already assumed, and it feels indistinguishable from prudence because for a long time it was.

Andy, Alistair, Oliver, Nina. Different stages, different reasons, different lives. All of them in the middle of working it out, which is probably where most people are.

I've had versions of this conversation with more people than I can count and the through line is almost always the same: the timing isn't right, the market is too harsh, the mortgage is real, things will be clearer in a few months. None of this is wrong. But underneath it is something harder to say out loud, which is that the career most of us were sold was designed for people who want work in the background. Not people who want to care about it. People for whom work is what funds the rest of life and who are broadly fine with that trade.

That's a legitimate way to live. But your job is roughly half your waking life, spent inside a structure you don't control, built for someone else's purposes, and one bad quarter away from disappointing you in ways you don't get to negotiate. The promotion you were tracking, the team you built, the project you cared about, all of it sits inside a decision someone above you will make based on numbers you don't see.

None of what I'm saying here is new but I think it lands differently when you've actually sat on both sides of that table, and I have: a few years as an employee early on, then twelve years as a founder and owner scaling to about seventy people, then a year back on the employee side after we were acquired. I've been in the room when the quarter goes bad from both ends of it, and they feel very different.

Starting your own thing doesn't fix everything. It swaps one set of problems for another, and most companies fail. But the failure rate argument only works if outcome is the only measure. Most founders I watched fail knew exactly why it happened, because they were there for every decision that led to it. The most useful thing I attended in 2015 was a meetup called Startup Funeral, at the Google Campus in Shoreditch, where three founders got on stage and walked through exactly why their companies didn't make it. It only ran for a few sessions and it was clearly hard for them to be up there, but it was more enlightening than anything else I came across that year, because the room was full of people who could see themselves in every decision being described. Failing at something you built teaches you more than being collateral damage in something you didn't. You're not choosing between risk and safety, you're choosing between two kinds of risk with different visibility and failure modes that land differently, one you can see coming and one that announces itself as a calendar invite.

Dobre was our very first employee and he's starting a charity to rescue dogs. He's already built the full CMS and everything the charity needs operationally using AI, moving faster than most professional teams would have managed, and right now he's working through the legal setup which is slow and unglamorous and not the part anyone enjoys but the thing actually exists, he built it, and the gap between having an idea and having a working system that used to take months and a team of people he closed in a few weeks on his own.

QTT worked with us a long time ago and has since built serious experience across a lot of different companies and problems. When we sold the company she came into some money, enough to give her the springboard she needed, and she used it the way you're supposed to, she found the idea, found the co-founder, and she's starting next month. Not because anyone pushed her into it but because she'd been building toward it for years and the pieces finally lined up.

Both of them got there differently and they're building very different things, but neither of them waited for the conditions to be perfect. They just got to a point where not starting felt worse than starting.

The standard line is that the best time to start was yesterday and the second best time is today, which is true as far as it goes but doesn't really capture what feels different about right now, so let me just describe what I've actually been doing.

While I was travelling earlier this year I ended up building five websites for people I met along the way: a dive school, a photographer, a boutique hotel I stayed at, a journalist building a membership platform, a neurotech company I'd invested in that needed a web presence. All of them free, all of them running off my home server, all of them built and live within about thirty minutes and another hour of feedback and small changes. None of these people had budgets or teams or any expectation that something real would exist by the end of the conversation. The dive school instructor was surprised it was done before he'd finished his coffee.

That kind of thing wasn't possible a few years ago, not on that timescale, not by one person with a laptop, a Starlink Mini and a bit of downtime between dives. I'm not saying this to suggest I did something impressive, I didn't, that's actually the point. The barrier between having a problem and having something working that real people can use has quietly collapsed, and most people haven't tried building anything yet so they don't quite believe how low the barrier has dropped. A problem worth solving and a few hours of attention, that's the entry cost now.

A few years from now the early advantage will be gone and the market will have filled in, and the people who moved in this window will have something the people who waited won't have and can't buy later.

The deal sold to anyone who built a career in tech over the last few decades was that the abstraction was the point, that process was maturity, that titles meant something, that a well-managed career inside a well-managed company was the destination, and for a while the economy was growing fast enough that the gap between the promise and the reality underneath stayed invisible and nobody had much reason to look too closely at the gap.

The gap is visible now, and the growth that papered over it for so long has slowed enough that the paper is starting to tear.

Paul's thirty stores are the loud version, a visible failure with a deadline and a client watching it happen. Most of it is much quieter: the senior engineer who's been inside the same abstraction layer for five years and doesn't know what he's lost, the product that ships but doesn't actually solve anything, the promotion that arrives inside a structure that's already quietly contracting around it. The skillcraft post covers how the pipeline got here, and most of the people in these conversations are living the consequences of that pipeline right now.

Do it inside your company and you might get recognised for it. Do it in your own startup and you give yourself a real shot at something that actually compounds. Either way, the outcomes you were promised are one bad quarter away from being scrapped, and a lot of companies are having bad quarters.

Most of what I've written here isn't new and I'm not pretending it is. I read most of these ideas a long time ago and they've just been sitting in the background of how I think. What I do think is mine is the timing argument, but honestly even that isn't just me. Carta's data shows solo-founded startups went from 17% of new companies in 2017 to 35% by 2024, accelerating to over 36% in the first half of 2025, and that jump tracks almost exactly with AI tooling going mainstream. It's all over Hacker News and Indie Hackers. A lot of engineers are feeling it right now. I'm just one of the ones who wrote it down.

Taleb's Skin in the Game. The accountability argument is basically his.

Kahneman's Thinking Fast and Slow is why Andy took the job. Loss aversion isn't a flaw, it's the default setting, and once you understand it you see it everywhere in section two.

Ben Horowitz's The Hard Thing About Hard Things is a good candid read that you should start with.

Paul Graham's essays are free and most of them are better than most books. Do Things That Don't Scale and Schlep Blindness first.

Paul Millerd's The Pathless Path is about why the default script doesn't fit as many people as it pretends to. Closer to section two than anything else on this list.

Eric Ries's The Lean Startup. Figure out if the thing is worth building before you build all of it. More useful than it sounds and more honest than most of what's written about early-stage product development.