On moving fast

The biggest difference between YC startups and everywhere else is how long things sit before someone acts on them.

Two speeds

I've worked at four YC companies, all with technical founders. And I've worked at places that weren't. What stands out is how much time gets lost everywhere else between "we should do this" and someone actually doing it.

At the YC companies, if something was broken, you'd see a fix in prod within the hour. Not because anyone was reckless, but because there was no ceremony around it. No ticket, no standup. The founder would just say "that's broken" in Slack and someone would push a fix. Sometimes the founder pushed it themselves.

At other places, that same fix would take a week. Not because the fix was hard, but because it had to survive the process. Ticket, planning session, estimation, review, approval. A two-line fix would ship a week later and by then nobody remembered why it mattered.

Why technical founders change things

When the founder can read the code - or wrote most of it - decisions happen faster because there's no translation layer. You don't have to convince a non-technical PM that the bug is serious, who then has to convince the engineering lead to prioritize it, who then assigns it to someone who has to context-switch into it.

The founder looks at it, understands the severity, and either fixes it or tells you to. That loop is 5 minutes instead of 3 days. Over months, that difference is massive.

It also changes what gets built. Technical founders tend to kill features that aren't working instead of letting them linger. I've seen non-technical leadership hold onto a half-built feature for months because "we already invested in it." Technical founders are more willing to delete code. They know what it costs to maintain code nobody uses.

The thing that actually slows teams down

In my experience it's almost never an engineering problem. You end up in too many meetings about whether something is worth doing and who should do it, and by the time you get to the code, you've spent more time talking about the work than doing it.

The fastest teams I've been on had a rule, even if they never said it out loud: if you see something that needs doing and it'll take less than a day, just do it. Don't ask. Don't file a ticket. Just push the fix and mention it later.

That only works when you trust the people you work with. Which is really a hiring problem more than a process problem.

The tradeoff

Moving fast isn't free. You accumulate rough edges - code you know you'll have to revisit eventually.

The difference is that fast teams treat that as a conscious tradeoff, not an accident. You ship the rough version knowing you'll come back to it, and sometimes you don't come back and that's fine because it turned out not to matter.

Slow teams try to get it right the first time. But half the things they're perfecting will get thrown away in six months anyway.