One thing I’ve changed my mind about recently is the value of speed.
For a long time, I thought one of the biggest advantages of being a technical founder was simple:
I didn’t have to wait.
If I had an idea, I could build it. I didn’t necessarily need to find an engineer, raise money to hire a team, write a detailed specification and wait several months to discover whether the thing in my head could actually work.
I could just start.
That still feels like an enormous advantage but I no longer think the real advantage is being able to build faster.
I think it is being able to learn faster, that sounds like a small distinction. I’m increasingly convinced it is a very important one.
AI changed the economics of building
The distance between an idea and a convincing piece of software has totally collapsed. An idea that might previously have required weeks or months of engineering can sometimes be explored in days or hours.
AI can help write the code.
It can suggest the architecture.
It can build interfaces.
It can generate tests.
It can help debug problems, analyze data and write documentation.
Small teams can now attempt things that would previously have required significantly more people and money.
That’s extraordinary.
But it has created an interesting problem.
When building becomes cheaper, being able to build something becomes weaker evidence that it should be built.
Almost every interesting thought can now be followed far enough to resemble a product of some sort and I think that makes judgment more important, not less.
The cost of being wrong is getting cheaper
The cost of being wrong is getting cheaper, it may sound entirely positive and mostly it is but I think it could also make us wrong more often than not.
When building something required six months, a team and a significant amount of capital, there was friction before you committed. That certainly didn’t prevent bad products anyway… we’ve spent decades proving that.
But today that friction is disappearing.
I can have a thought in the morning and have something fairly convincing running shortly afterwards. The temptation is to interpret that velocity as progress.
Idea
Prototype.
Feature.
Integration.
Launch.
Repeat.
But moving quickly and learning quickly aren’t necessarily the same thing.
You can build very quickly in completely the wrong direction.
I used to optimize for execution speed
This is probably where my thinking has changed the most… sike! actually no! it hasn’t but its refined in a different way.
I still strongly hold that adequate consistent motion is better than a well thought-out execution that comes sporadically at time-friction-cost of solution.
I used to see the ability to move quickly from idea to implementation as an advantage but now I think the better use of that ability is to shorten the distance between:
assumption → experiment → evidence.
Build enough to learn.
Not enough to prove how sophisticated the architecture could become.
Build the uncomfortable version that answers the question you’re avoiding.
Put it in front of somebody.
Watch what they actually do.
Then decide what deserves to happen next.
That requires a different relationship with the things you build.
You have to be willing to throw them away
And throwing software away can be particularly difficult when you’re the person who knows exactly how much thinking went into creating it.
Restraint might be the new leverage
As execution becomes cheaper, I’m beginning to think restraint becomes more valuable.
- Knowing what not to build. (No one ever does in the first try *or a veryyyy few have).
- Knowing when a two-day integration isn’t worth two hours.
- Knowing when someone asking for a feature is actually describing a different product.
- Knowing when ten people saying “interesting” is weaker evidence than one person desperately trying to use something unfinished.
- Knowing when you need another iteration.
- And knowing when the evidence is telling you to stop.
That last one is difficult for engineers.
We’re used to problems eventually yielding if we spend enough time on them.
The test fails, you debug it.
The system is slow, you profile it.
The architecture breaks at scale, you redesign it.
Persistence is rewarded.
Markets don’t necessarily behave like that.
You cannot refactor your way into demand.
So what changed my mind?
Partly AI.
Partly building companies.
Mostly the accumulation of watching the difference between things that are technically possible and things people genuinely care about.
I’m probably capable of building more today than at any other point in my career.
The tools are better.
My experience is deeper.
AI has dramatically increased what one person can attempt.
But I increasingly want to measure progress by something other than how much software I can produce.
The technical founder’s advantage might not be:
I can build this faster than you.
It might be:
I can find out whether this should exist faster than you.
That means technical ability still matters enormously but the scarce skill moves somewhere else, it moves towards judgment.
Toward understanding people.
Toward asking better questions.
Toward recognizing weak signals before turning them into six months of work.
And toward having enough detachment from your own ability to build something to decide that you shouldn’t.
That’s what I’ve changed my mind about.
Speed still matters.
I’m just much less interested in the speed of building than I used to be.
I’m becoming far more interested in the speed of learning.
A picture I took during my run on Thursday looking across from the bay.
Originally published as I’ve Changed My Mind About Speed on Notes by Wale.